LiteRT en Google Play services: apps Android más pequeños y GPU más rápida

La actualización de LiteRT publicada por Google el 28 de octubre de 2026 es relevante para los desarrolladores de Android porque cambia dónde vive la infraestructura de aprendizaje automático en el dispositivo. Las aplicaciones compatibles ya no tienen que incluir todo el runtime de LiteRT y el acelerador GPU dentro de su propio paquete; pueden usar LiteRT en Google Play services. El resultado práctico es una descarga más pequeña, un runtime compartido que puede actualizarse por separado y una ruta más clara hacia la inferencia GPU mediante la API moderna CompiledModel.

Qué cambió en LiteRT para Google Play services

LiteRT es el runtime de inferencia en el dispositivo de Android para modelos de machine learning personalizados. Google afirma que procesa más de un billón de inferencias al día en miles de millones de dispositivos. La nueva versión añade inferencia GPU impulsada por ML Drift y, según las pruebas de Google, ofrece un rendimiento aproximadamente 1,4 veces superior al antiguo GPU delegate. La nueva ruta utiliza CompiledModel, el sucesor moderno de la API Interpreter.

También cambia el empaquetado. En las pruebas de Google, las aplicaciones que sustituyeron una copia incluida de LiteRT por el runtime de Play services fueron aproximadamente 8 MB más pequeñas. El runtime y el acelerador GPU se distribuyen una vez mediante Google Play services, en lugar de repetirse dentro de cada APK. Google dice además que más de 100.000 aplicaciones Android todavía incluyen su propia copia de LiteRT o TensorFlow Lite, por lo que pequeñas reducciones pueden acumularse a gran escala.

Eso no significa que todas las aplicaciones vayan a reducir exactamente 8 MB. El resultado depende de los modelos, las bibliotecas, la configuración ABI y otras dependencias. La decisión debe basarse en medir el tamaño de descarga y de instalación antes y después, no en tratar la cifra destacada como una garantía.

Por qué ayuda un runtime compartido

Un runtime compartido responde a tres límites habituales del móvil: tamaño de descarga, almacenamiento del dispositivo y coordinación de actualizaciones. Eliminar una biblioteca de inferencia duplicada puede acelerar la primera instalación y dejar más espacio para los datos del usuario. El equipo también tiene menos binarios nativos que empaquetar y probar para cada arquitectura.

Hay un segundo beneficio: las actualizaciones del runtime pueden llegar mediante el componente de la plataforma, sin esperar a que cada equipo publique un APK o App Bundle nuevo. Esto no elimina la compatibilidad a nivel de aplicación. Hay que verificar las salidas del modelo, el comportamiento de fallback, los permisos y la cobertura de dispositivos. La ventaja es que el calendario del runtime queda menos ligado al calendario de lanzamiento de la app.

Google cita Google AI Edge Gallery como ejemplo real. Su función Scrapbook de segmentación de imágenes utiliza LiteRT en Google Play services y ofrece una referencia de IA en el dispositivo orientada al consumidor, no solo un benchmark.

CompiledModel es el objetivo de la migración

Los equipos que ya usan la API Interpreter antigua pueden seguir ejecutando ese código en la CPU al cambiar al paquete de Play services. Para usar la GPU hay que migrar a CompiledModel y pasar el entorno LiteRT al crear el CompiledModel. La lógica general puede seguir siendo parecida, pero la migración exige revisar el diff, compilar la aplicación, comparar resultados y probar en dispositivos físicos representativos.

Android Studio Agent Mode incluye ahora una skill de LiteRT para automatizar la primera parte. El desarrollador puede pedir que migre código de TensorFlow Lite a CompiledModel o escribir @litert-runtime. La skill actualiza dependencias, reescribe llamadas a Interpreter, configura la aceleración GPU con fallback de CPU y puede crear una aplicación LiteRT nueva. El repositorio oficial de Android skills en GitHub es un buen punto de partida, pero los cambios generados deben revisarse como un primer borrador.

Lista de comprobación para una migración segura

Registra primero el tamaño de descarga, el tamaño instalado, el arranque en frío, la latencia de la primera inferencia, el comportamiento sostenido de la GPU, el consumo de batería y la precisión del modelo. Después identifica qué modelos y APIs se ejecutan realmente en CPU o GPU; no todos los modelos se benefician del mismo delegate o camino de ejecución.

Migra una función pequeña antes de cambiar toda la aplicación. Conserva un fallback de CPU, compara los resultados dentro de una tolerancia acordada y prueba escenarios de poca memoria y dispositivos antiguos. Comprueba que la disponibilidad y el comportamiento de versión de Google Play services encajen con los países y la flota que soportas. Por último, añade una barrera de release que revise el App Bundle, los errores del runtime, la latencia y la calidad del modelo antes de ampliar el despliegue.

El calendario de obsolescencia también importa. Google afirma que el antiguo GPU delegate y las APIs de delegate personalizado están obsoletos en favor de la aceleración GPU de CompiledModel, Compiler Plugin y Dispatch. NNAPI se eliminará a partir de 2027. Los SDK antiguos solo reciben correcciones críticas de seguridad. Las aplicaciones ya publicadas siguen funcionando, pero el código que usa APIs obsoletas puede dejar de compilar contra el SDK más reciente.

Para comparar herramientas Android, aplicaciones de IA y software para dispositivos, visita el catálogo de software de BTTC y las guías del blog tecnológico de BTTC.

Preguntas frecuentes

La idea central es sencilla: LiteRT en Google Play services saca la infraestructura común de inferencia de cada APK y la coloca en un canal compartido de Android. La oportunidad es reducir el tamaño de las apps y acelerar la GPU; la responsabilidad sigue siendo validar compatibilidad, calidad del modelo y comportamiento en dispositivos reales antes de publicar.