Durante años, TensorFlow Lite fue la herramienta “de confianza” para llevar modelos de aprendizaje automático a móviles, relojes y otros dispositivos. Funcionaba especialmente bien para el machine learning clásico: reconocimiento de imágenes, clasificación, detección de objetos o pequeñas redes que podían vivir sin demasiadas exigencias de cómputo. El problema es que la IA generativa y los modelos modernos han cambiado el listón: ya no basta con “que corra”, ahora importa que responda rápido, que consuma menos energía y que aproveche el hardware especializado que ya traen muchos chips.Ahí es donde entra LiteRT, la evolución del stack de Google para inferencia en el borde. Según explicó Google en el blog de Google for Developers (28 de enero de 2026), la compañía empezó a presentar esta transición en 2024 y enseñó un adelanto más ambicioso en Google I/O 2025: un runtime diseñado para exprimir aceleración avanzada. La novedad ahora es que esa aceleración “graduó” y forma parte del stack de producción de LiteRT, disponible para desarrolladores.Un objetivo claro: hacer la inferencia on-device más rápida, simple y flexibleGoogle define LiteRT como un marco universal de inferencia en el dispositivo, con una promesa que se entiende con una metáfora doméstica: si antes cocinar IA era como usar una cocina estándar (CPU) y, con suerte, un buen horno (GPU), ahora se busca que el plato salga a tiempo usando también los electrodomésticos especializados (NPU) sin que el cocinero tenga que aprender el manual de cada marca.En esa línea, Google destaca cuatro ejes: más velocidad, un flujo de aceleración unificado, soporte sólido para GenAI con modelos abiertos y una integración más directa con frameworks como PyTorch y JAX, todo sin abandonar la compatibilidad del formato .tflite.Aceleración GPU multiplataforma: del “solo Android” a casi cualquier pantallaUno de los saltos más prácticos está en la aceleración GPU. La idea no es nueva: TFLite ya tenía delegados para GPU, pero Google afirma que LiteRT da un paso más en rendimiento y cobertura. En lugar de quedarse en Android, el soporte se extiende a Android, iOS, macOS, Windows, Linux y Web.El enfoque técnico también se amplía. LiteRT incorpora soporte para OpenCL, OpenGL, Metal y WebGPU a través de un motor de GPU de nueva generación que Google llama ML Drift. Para quienes desarrollan en Android, el runtime prioriza automáticamente OpenCL cuando está disponible y recurre a OpenGL como plan B para llegar a más dispositivos. En términos de mejora, Google habla de un promedio de 1,4 veces más rendimiento en GPU frente al delegado GPU heredado de TFLite, con menor latencia en diferentes modelos (según sus benchmarks publicados en anuncios previos).Latencia real: ejecución asíncrona y “cero copias” para no desperdiciar tiempoSi alguna vez has notado que una app “piensa” más de la cuenta, muchas veces no es solo por el modelo, sino por el tráfico de datos y la coordinación entre CPU y aceleradores. Google insiste en dos mejoras para reducir latencia extremo a extremo: ejecución asíncrona y zero-copy buffer interoperability.Traducido a un ejemplo cotidiano: imagina que estás haciendo una tortilla y cada vez que rompes un huevo tienes que llevar el bol a otra habitación para batirlo. Eso es lo que pasa cuando el sistema mueve datos de un lado a otro innecesariamente. Con zero-copy, se intenta que el modelo consuma el dato directamente desde el “recipiente” donde ya está, sin duplicarlo ni pasar por CPU más de lo imprescindible. Google asegura que, en casos concretos como segmentación en segundo plano o ASR (reconocimiento automático de voz), estas optimizaciones pueden llegar a suponer hasta 2 veces más rendimiento en muestras como su app de segmentación.La NPU como pieza clave y el problema de la fragmentaciónLa NPU (unidad de procesamiento neuronal) es, en teoría, el carril rápido para IA: mejor eficiencia energética y gran rendimiento en tareas específicas. En la práctica, el panorama suele ser un rompecabezas: cientos de variantes de SoC, SDKs diferentes, compiladores propios y flujos de despliegue que terminan siendo artesanales. Google plantea que LiteRT intenta esconder esa complejidad con un flujo unificado, delegando el trabajo de lidiar con la fragmentación al runtime.La propuesta combina precompilación opcional y despliegue automatizado en Android mediante Google Play for On-device AI (PODAI), con una capa de inferencia que decide delegación a NPU y, si hace falta, recurre a GPU o CPU como respaldo. En el discurso de Google, el objetivo es que el desarrollador no tenga que “perseguir” cada NPU como si fueran cargadores de móvil distintos.Compilación AOT y JIT: escoger entre arranque instantáneo o distribución flexibleUn detalle relevante es que LiteRT admite dos estrategias de compilación para NPU. Con AOT (ahead-of-time), el modelo se prepara por adelantado para SoC concretos, reduciendo tiempo de arranque y huella de memoria, ideal para experiencias “instant-start”. Con compilación en el dispositivo (JIT), se gana facilidad de distribución para modelos pequeños y variedad de plataformas, con el coste de una primera ejecución más lenta por el trabajo inicial de compilación.Google también presume de sus primeras integraciones “listas para producción” con MediaTek y Qualcomm. En sus documentos técnicos asociados, la compañía habla de alcanzar picos de hasta 100 veces más velocidad que CPU y 10 veces más que GPU en ciertos escenarios, cifras que, si se sostienen en casos reales, pueden cambiar la viabilidad de ejecutar funciones avanzadas sin depender de la nube.GenAI en el borde: menos fricción para modelos abiertos como GemmaLa otra gran carta es el soporte de IA generativa en múltiples plataformas. Google reconoce el punto de dolor: bajar modelos, ajustar inferencia, medir rendimiento y lograr estabilidad puede devorar tiempo de ingeniería. Para reducir esa fricción, LiteRT se apoya en un conjunto de componentes que trabajan en cadena: una API generativa orientada a PyTorch para autoría y conversión de transformadores, una capa de orquestación llamada LiteRT-LM pensada para LLMs (que Google describe como infraestructura probada en despliegues de Gemini Nano en productos como Chrome y Pixel Watch), y el convertidor/runtime base que ejecuta y optimiza en CPU, GPU y NPU.Como demostración, Google comparó Gemma 3 1B en un Samsung Galaxy S25 Ultra frente a llama.cpp, indicando ventaja de LiteRT en CPU/GPU tanto en prefill como en decode, y un extra de rendimiento con NPU que llegaría a 3 veces sobre GPU para el prefill (según sus pruebas). La narrativa aquí es clara: si el modelo es el “cerebro”, el runtime es el “sistema nervioso” que decide por dónde circula la señal para responder antes.Compatibilidad con PyTorch, TensorFlow y JAX sin encerrar al desarrolladorUno de los mensajes más pragmáticos es que el despliegue no debería depender del framework con el que entrenas. LiteRT busca ser un punto de encuentro: conversión directa desde PyTorch con su librería LiteRT Torch, soporte continuado para el ecosistema TensorFlow, y una vía para JAX mediante el puente jax2tf. En un mercado donde muchos equipos combinan investigación en un stack y producto en otro, esta promesa apunta a reducir el “peaje” entre prototipo y app.Convivencia con lo existente: el formato .tflite y dos APIs para distintos tiemposUn aspecto tranquilizador para quien ya tiene modelos en producción es que LiteRT mantiene el formato .tflite como pieza central: un archivo único que viaja entre Android, iOS, macOS, Windows, Linux, Web e IoT. Google plantea una transición con dos caminos: la Interpreter API para mantener compatibilidad y estabilidad con lo ya desplegado, y la nueva CompiledModel API como vía moderna para exprimir GPU y NPU con un flujo más directo.Visto desde fuera, la estrategia suena a “renovar la casa sin tirar las paredes”: conservar lo que funciona y abrir una puerta para cargas más exigentes, especialmente las que llegan con la GenAI on-device.La noticia LiteRT: el nuevo marco universal de IA en el dispositivo que Google quiere convertir en estándar fue publicada originalmente en Wwwhatsnew.com por Natalia Polo.