La nueva pila de ejecución de la IA en el dispositivo: de ML Drift a TensorRT Edge-LLM

La IA en el dispositivo ya no es solo una cuestión de chips. El entorno de ejecución compartido que carga, acelera y actualiza los modelos se está convirtiendo en la verdadera superficie de producto que entregan los desarrolladores.

Durante buena parte de la década de 2020, las conversaciones sobre la IA en el dispositivo empezaban con gráficos de TOPS. Esas cifras siguen importando (véase nuestra guía sobre la IA en el dispositivo y las NPU), pero finales de octubre de 2026 puso de relieve algo más discreto: la elección del runtime de IA en el dispositivo, es decir, del entorno de ejecución de los modelos, decide ya si un modelo es portable, si puede actualizarse y si es lo bastante rápido como para percibirse como local.

En tres semanas llegaron tres anuncios. El equipo Google AI Edge publicó como código abierto ML Drift, su motor de cómputo en GPU de nueva generación para dispositivos (8 de octubre de 2026). Esa misma pieza se incorporó después como aceleración por GPU en LiteRT en los servicios de Google Play, con datos de la propia Google que hablan de una inferencia en GPU alrededor de 1,4 veces más rápida que con el antiguo delegado de GPU y de aplicaciones unos 8 MB más ligeras cuando el runtime se comparte en lugar de integrarse en cada una (28 de octubre de 2026). NVIDIA siguió con una vía de desarrollo para TensorRT Edge-LLM, un runtime de inferencia ligero escrito en C++ que abarca desde la creación de prototipos en DGX Spark hasta el despliegue en Jetson Thor, DRIVE AGX Thor e IGX Thor (30 de octubre de 2026).

Este artículo se centra en ese ángulo del runtime: qué es una pila de inferencia en el dispositivo, por qué la fragmentación obligó a reescribir los delegados de GPU, cómo cambia el modelo de los servicios de Play de LiteRT el empaquetado de las aplicaciones Android y cómo plantea TensorRT Edge-LLM los flujos de trabajo de los LLM embebidos. No es un catálogo de chips.

Qué hace realmente un runtime de IA en el dispositivo

Un runtime se sitúa entre un archivo de modelo congelado y el silicio. En la práctica, asume cinco funciones:

1. Cargar y validar un grafo de modelo (por ejemplo, .tflite, motores derivados de ONNX o cachés HEF o de motores propios de cada fabricante).
2. Repartir el trabajo entre la CPU, la GPU y, cuando existen, la NPU u otros aceleradores, con alternativas de respaldo sensatas.
3. Traducir los operadores a núcleos de cómputo para OpenCL, OpenGL ES, Metal, WebGPU, CUDA y TensorRT, o para las NPU de los fabricantes.
4. Gestionar la memoria: búferes de tensores, cachés clave-valor (KV) para la decodificación generativa y huella máxima cuando hay varias aplicaciones en ejecución simultánea.
5. Servir el modelo al código de la aplicación, mediante API nativas o, cada vez más, mediante una interfaz HTTP local compatible con la de OpenAI para crear prototipos de agentes.

Cuando alguna de esas capas falla, el usuario lo percibe en forma de fotogramas perdidos en la cámara, tirones en el arranque o una «IA local» que sigue conectándose a un servidor remoto porque el procesamiento en el dispositivo nunca llegó a ser fiable.

ML Drift: un motor de GPU abierto para un parque de dispositivos fragmentado

El anuncio de Google del 8 de octubre de 2026 presenta ML Drift como un motor de cómputo en GPU multiplataforma y de alto rendimiento, diseñado específicamente para la inferencia de IA y aprendizaje automático en el dispositivo y publicado con licencia Apache 2.0. La compañía lo sitúa a la vez como el núcleo de la aceleración por GPU de LiteRT y como una biblioteca independiente para motores gráficos y runtimes de inferencia a medida.

Por qué no bastaba el antiguo delegado de GPU

A diferencia de la inferencia en centros de datos, que se ejecuta en clústeres homogéneos, las GPU de los dispositivos forman un auténtico mosaico de arquitecturas, controladores y API. Google recuerda que el delegado de GPU de TensorFlow Lite sentó las bases de la aceleración, pero que las cargas actuales, desde la visión y el audio en tiempo real hasta los modelos generativos con gran número de parámetros, generan cuellos de botella de cómputo y de memoria para los que no se diseñaron los runtimes anteriores.

Según la entrada de Google, las respuestas estructurales de ML Drift son:

• Virtualización de tensores: desacopla la disposición lógica de un tensor de los objetos físicos de la GPU, de modo que los shaders puedan unificarse para OpenGL ES, OpenCL, Metal y WebGPU en lugar de mantener bases de código separadas para cada interfaz.
• Operaciones personalizadas extensibles: API de registro con acceso al lenguaje de shading de bajo nivel, incluidas herramientas pensadas para agentes de programación que escriben shaders a medida.
• Compatibilidad con tensores de cinco dimensiones: supera un límite estricto del antiguo delegado de GPU de TFLite, centrado en cuatro dimensiones, para los modelos espaciotemporales y volumétricos.
• Núcleos para LLM adaptados a cada fase: cambian la disposición de los datos y los núcleos entre el prellenado, limitado por el cómputo, y la decodificación, limitada por la memoria, con una disposición de la caché KV alineada con la convolución y una cuantización de las activaciones dentro del núcleo durante la decodificación.

Google afirma además que, en sus pruebas con Gemma, ML Drift logra hasta un 12 % menos de sobrecarga de memoria que otros frameworks. Es una afirmación de Google, pero relevante: un rendimiento máximo en tokens por segundo no sirve de nada si el proceso no puede convivir con la canalización de la cámara.

Pruebas en producción (siempre según Google)

Google sostiene que ML Drift ya funciona a diario en producción en millones de dispositivos, dentro de productos como Chrome, YouTube Shorts, Fotos y Meet. Entre los resultados que la misma entrada atribuye a los equipos de producto figuran:

• YouTube Shorts: una reducción de hasta el 40 % de la latencia media por fotograma en los efectos basados en segmentación, en Android e iOS, tras migrar a ML Drift.
• Google Fotos: una mejora de hasta 2 segundos frente al antiguo delegado de GPU en los procesos de fotografía computacional y segmentación (según la formulación de Google).
• Funciones móviles de Adobe Lightroom y Photoshop: un rendimiento en el dispositivo hasta un 30 % superior en determinadas funciones de edición tras pasar a ML Drift (según Google).
• Snap: una mejora del 30 % en la latencia de los modelos que impulsan los efectos de rostro y estilo de las lentes de Snapchat, gracias al acelerador de GPU ML Drift de LiteRT (según Google).

Conviene tomarlas como diferencias comunicadas por el proveedor y sus socios, no como resultados de laboratorios independientes. Aun así, la pauta es clara: fue el runtime, y no un nuevo chip, lo que hizo posible la mejora.

Con el lanzamiento de ML Drift, Google anuncia que el antiguo delegado de GPU de TFLite dejará de recibir nuevas funciones y recomienda migrar al acelerador de GPU ML Drift de LiteRT, compatible con los modelos existentes.

LiteRT en los servicios de Google Play: distribuir el modelo y compartir el runtime

Si ML Drift es el motor, LiteRT en los servicios de Google Play es la estrategia de distribución de los modelos personalizados en Android. La entrada de Google del 28 de octubre de 2026 lo describe como el runtime de inferencia en el dispositivo de Android para modelos personalizados, que «gestiona más de un billón de inferencias al día en miles de millones de dispositivos», y califica la actualización como la mayor hasta la fecha: inferencia en GPU impulsada por ML Drift a través de la API CompiledModel, el sucesor moderno de la antigua API Interpreter de LiteRT.

Las principales afirmaciones de Google (atribúyanse con cuidado)

• La inferencia en GPU, impulsada por ML Drift, es alrededor de 1,4 veces más rápida que con el antiguo delegado de GPU de TensorFlow Lite.
• En las pruebas de Google, las aplicaciones que pasaron a LiteRT en los servicios de Google Play pesan unos 8 MB menos, porque el runtime, acelerador de GPU incluido, se distribuye una sola vez con los servicios de Play en lugar de dentro de cada APK.
• Google señala que más de 100 000 aplicaciones Android siguen incluyendo su propia copia de LiteRT o de TensorFlow Lite, de modo que el ahorro del runtime compartido se multiplica a medida que las aplicaciones migran.

Esas cifras son afirmaciones de Google, basadas en sus propias pruebas y en su lectura de la telemetría, no mediciones de terceros.

Por qué importa el modelo de empaquetado

Incluir un runtime de GPU en cada aplicación duplica megabytes y supedita los parches de seguridad y rendimiento al calendario de publicación de cada desarrollador. La distribución a través de los servicios de Play aporta, según Google, estas ventajas:

• descargas más ligeras y almacenamiento y memoria compartidos;
• actualizaciones automáticas mediante los despliegues escalonados de los servicios de Play;
• una cobertura más amplia: teléfonos desde Android 7 (API 24), además de Wear OS 4 y posteriores y Android Automotive OS (desde Android 11), según Google;
• la reutilización de la misma infraestructura que ya da servicio a gran escala a las API de Vision y Text de ML Kit.

CompiledModel se plantea como un flujo de trabajo único para la aceleración en CPU y GPU (OpenCL cuando está disponible y OpenGL en su defecto, con la CPU como respaldo), que mantiene el conocido formato de modelo .tflite. Google advierte también de que las API del antiguo delegado de GPU y de los delegados personalizados quedan obsoletas en favor de la aceleración por GPU de CompiledModel y de las API de complementos y distribución asociadas, y de que NNAPI se eliminará a partir de 2027, una señal para la planificación de cualquier equipo que siga con flujos heredados de la época de Interpreter. En cuanto a la compatibilidad con NPU en los servicios de Play, Google afirma que «se está trabajando activamente en ella».

TensorRT Edge-LLM: un mismo framework del escritorio al dispositivo

Los delegados de GPU móviles son solo la mitad de la historia. La IA física y los agentes para habitáculos o robots necesitan servir modelos de la clase LLM con presupuestos ajustados de memoria, consumo y latencia, a menudo en la gama embebida de NVIDIA y no en el chip de un teléfono.

El blog técnico de NVIDIA del 30 de octubre de 2026 presenta TensorRT Edge-LLM como un runtime de inferencia ligero en C++ para cargas embebidas, que lleva el mismo framework de inferencia al desarrollo en DGX Spark (incluida una configuración de 64 GB) y al despliegue en plataformas como Jetson Thor, DRIVE AGX Thor e IGX Thor.

Una herramienta para desarrolladores, no un folleto de silicio

La entrada pone el acento en lo operativo:

• instalar tensorrt-edgellm y usar la interfaz de línea de comandos trtedge para descargar un modelo y compilar motores TensorRT optimizados;
• conversar en local con modelos como NVIDIA Nemotron-3.5 Lightning;
• servir el modelo mediante una API local compatible con la de OpenAI para crear prototipos de aplicaciones;
• activar, de forma opcional, la decodificación especulativa DSpark con un modelo borrador.

Esa promesa de «unos pocos comandos» es el producto en sí: reducir la distancia entre un punto de control de Hugging Face y un motor capaz de funcionar detrás de un agente de habitáculo o de fábrica.

Las cifras publicadas por NVIDIA en Spark (mediciones de NVIDIA)

En un DGX Spark de 64 GB, NVIDIA publica los resultados de TensorRT Edge-LLM con Nemotron-3.5 Lightning (NVFP4, razonamiento activado, tamaño de lote uno, una solicitud en streaming simultánea y salida limitada a 128 tokens). La velocidad media de generación con las peticiones de HumanEval pasa de 73,4 tokens por segundo sin DSpark a 126,9 tokens por segundo con DSpark (tres tokens de borrador), mientras que el uso máximo de memoria total del sistema durante la inferencia con DSpark fue de 27,9 GB, incluido el sistema operativo, según la tabla y las notas de NVIDIA. Las medianas del tiempo hasta el primer token (TTFT) de esa misma tabla (alrededor de 98 ms en HumanEval, con o sin DSpark) también son datos de NVIDIA en esa configuración.

Lo relevante para este artículo es la arquitectura: Edge-LLM es un runtime de IA en el dispositivo que intenta mantener la misma ruta optimizada desde la estación de trabajo del desarrollador hasta los destinos de despliegue de la clase Thor, en lugar de improvisar una pila de demostración móvil sin continuidad.

Cómo encajan las piezas (y dónde no)

Son más complementarios que competidores. Un efecto de cámara en un teléfono requiere LiteRT y ML Drift. El prototipo de un agente para un robot o un vehículo puede necesitar TensorRT Edge-LLM en Spark antes de fijar un motor embebido. Los equipos que tratan «en el dispositivo» como una categoría única pasan por alto esa división.

Lista de comprobación práctica para los equipos

1. Dejar de incluir runtimes duplicados por defecto. En Android, con modelos .tflite personalizados, conviene evaluar LiteRT en los servicios de Play: el ahorro de unos 8 MB que reivindica Google se debe precisamente a no integrar el runtime.
2. Planificar la migración de Interpreter a CompiledModel. Los calendarios de obsolescencia (incluida la eliminación de NNAPI a partir de 2027, según Google) son fechas de agenda, no simple retórica.
3. Perfilar por separado el prellenado y la decodificación en los LLM locales. Tanto el diseño por fases de ML Drift como los ajustes de decodificación especulativa de Edge-LLM presuponen saber qué fase domina.
4. Tomar las mejoras de los socios como orientativas. Los ejemplos del 30 al 40 % que cita Google y la tabla de tokens por segundo en Spark de NVIDIA son útiles, pero son expresamente sus mediciones en sus condiciones.
5. Mantener la cultura del silicio, pero contratar en función de los runtimes. Las API, las cachés de motores y los canales de actualización sobreviven a una generación de NPU; otra razón por la que la explicación sobre las NPU de nuestra guía sobre la IA en el dispositivo y las NPU complementa este artículo sobre runtimes en lugar de sustituirlo.

Conclusión

Octubre de 2026 no inventó la inferencia en el dispositivo, pero sí hizo imposible ignorar el runtime de IA en el dispositivo. ML Drift abrió el código de un motor de GPU concebido para modelos generativos y clásicos en el dispositivo, compatible con OpenGL ES, OpenCL, Metal y WebGPU. LiteRT llevó ese motor a una vía de distribución compartida en Android, con Google reivindicando una aceleración en GPU de alrededor de 1,4 veces frente al antiguo delegado y aplicaciones unos 8 MB más ligeras cuando el runtime reside en los servicios de Play. TensorRT Edge-LLM mostró la vertiente embebida de la misma idea: una única ruta en C++ y línea de comandos desde los prototipos en Spark hasta el despliegue en la clase Thor, con cifras concretas de rendimiento en Spark con DSpark publicadas por NVIDIA.

Los chips siguen marcando el techo. Los runtimes deciden si alguna vez se alcanza, y si se puede elevar el suelo sin esperar a un nuevo teléfono, un nuevo coche o un nuevo robot.

Lecturas relacionadas

• IA en el dispositivo en 2026: NPU, modelos locales y lo que aún necesita la nube
• IA siempre activa: cuando la inferencia debe caber en una pila de botón
• IA sin conexión: cuando robots y vehículos deben pensar sin la nube

Imágenes: ilustraciones originales creadas para AndBeyond.Tech; no aparecen logotipos ni personas reales.