EngineAgent: agentes de IA que adaptan modelos de lenguaje a móviles

Qué se ha publicado

El 10 de noviembre apareció en arXiv un preprint firmado por nueve investigadores de la Universidad Jiao Tong de Shanghái y Alibaba que propone automatizar con agentes de IA una tarea de ingeniería que hoy se hace a mano: adaptar un modelo de lenguaje nuevo para que funcione en un motor de inferencia ejecutado en un dispositivo móvil. El sistema, EngineAgent, resuelve el 75 % de las tareas de un banco de doce casos, frente al 33 % del mejor agente de programación comercial con el que lo comparan.

No hay un modelo nuevo ni un producto: hay un sistema que usa agentes para modificar código de infraestructura. El resultado importa porque el cuello de botella de la IA en el dispositivo no es solo el tamaño del modelo, sino el porte: conseguir que una arquitectura nueva funcione en CPU, GPU y NPU sin errores numéricos.

El trabajo está firmado por Zhengxiang Huang, Yujie Sun, Shengheng Chen, Zhaode Wang, Chaoyue Niu, Zeyu Zhao, Chengfei Lv, Fan Wu y Guihai Chen, con afiliaciones en Shanghai Jiao Tong University y Alibaba Group. Es un preprint sin revisión por pares.

El problema: adaptar un modelo a un móvil puede llevar un mes

Los motores de inferencia on-device —MNN, llama.cpp, MLC-LLM y ExecuTorch— están entre dos mundos que cambian a distinta velocidad. Arriba, las arquitecturas de modelos: el artículo recuerda que de Gemma 3 a Gemma 3n pasaron unos cuatro meses y de MiniCPM-V 4.0 a 4.5 solo 24 días, y que cada generación introduce módulos nuevos (atención lineal, ventanas deslizantes, compresión de tokens visuales). Abajo, el hardware: CPU, GPU Vulkan y NPU de Qualcomm, MediaTek y Apple, cada una con su lenguaje, sus layouts de tensores y su flujo de compilación.

El artículo cuantifica el retraso en su Tabla 1. Habilitar Qwen3.5-2B en MNN tocó 42 archivos y más de 4.200 líneas entre exportación, inferencia y backends CPU y GPU; en ExecuTorch, 20 archivos y más de 1.000 líneas para soporte de CPU solo texto, con una primera habilitación que llegó 30 días después del lanzamiento del modelo. Gemma4-E2B-it no está soportado en dos de los cuatro motores y MiniCPM-V 4.6 en tres. Los autores calculan que la primera habilitación puede tardar hasta 30 días.

Cómo funciona EngineAgent

EngineAgent separa lo que no cambia de lo que sí. Antes de habilitar ningún modelo, construye un índice de jerarquía del motor que mapea las capas de abstracción y las dependencias entre capas, y prevalida flujos de compilación, ejecución y depuración para cada backend usando modelos que ya están soportados. Para cada modelo nuevo, un constructor usa ese conocimiento para coordinar los cambios entre capas, y un auditor comprueba que la implementación está completa y guía la depuración con validación en el dispositivo.

El bucle constructor-auditor es la pieza central: el auditor solo acepta la implementación cuando pasan las comprobaciones por capas y la validación end-to-end en el dispositivo. El éxito exige compilación en el host, ejecución en el dispositivo y que los logits de salida coincidan con la referencia de PyTorch.

Los resultados: 75 % frente al 33 %

El banco tiene 12 tareas, tres modelos móviles (Qwen3.5-2B, Gemma4-E2B-it y MiniCPM-V 4.6) y cuatro pares motor-backend: MNN+CPU, llama.cpp+Vulkan, MLC-LLM+OpenCL y ExecuTorch+QNN. EngineAgent resuelve 9 de 12 (75 %) con dos modelos de base distintos, DeepSeek-V4-Flash y GPT-5.6 Sol. El mejor baseline, Codex con GPT-5.6 Sol, resuelve 4 de 12 (33,3 %). OpenCode y el montaje OpenCode + CodeGraph + AgenTracer resuelven 1 de 12, y SWE-Agent ninguno.

La ventaja no es solo el porcentaje. Con DeepSeek-V4-Flash, EngineAgent tarda 3,82 horas por tarea y cuesta 1,53 dólares, frente a las 4,78-4,91 horas y 2,11-2,44 dólares de los baselines. Con GPT-5.6 Sol, 4,16 horas y 11,29 dólares frente a las 4,82 horas y 14,90 dólares de Codex.

El desglose por etapas muestra dónde se pierde la ventaja: los agentes generales llegan al 4/12 en host y caen a 0-1/12 en el dispositivo. EngineAgent llega a 10/12 en host y 9/12 en dispositivo. La ablación confirma las dos piezas: quitar el índice de jerarquía baja el éxito de 9/12 a 3/12 y dispara las vueltas de exploración de 42 a 271; quitar las habilidades de hardware lo baja a 5/12 y las fallas de compilación y depuración pasan de 11 a 83.

Por qué importa

La IA en el dispositivo está creciendo por una razón sencilla: enviar cada consulta a la nube cuesta dinero, añade latencia y deja los datos fuera de casa. Pero el ecosistema está fragmentado, y el porte es la parte que frena la llegada de los modelos nuevos a los móviles. Si se automatiza, los motores pueden seguir el ritmo de las arquitecturas y el mantenimiento depende menos de una persona que conozca cada capa.

El trabajo también es un caso de estudio de cómo los agentes de IA se están usando para automatizar ingeniería de sistemas, no solo para escribir código de aplicación. Y muestra una pauta que se repite: el conocimiento reutilizable se construye una vez y se mantiene barato. El índice cuesta 0,66-1,25 dólares por motor y las habilidades 1,83-2,68; actualizarlos cuesta de media 0,072 dólares por commit.

Qué sigue sin saberse

Es un preprint sin revisión por pares y los resultados proceden del banco que han construido los propios autores. Son 12 tareas y tres modelos; no dice nada de modelos más grandes ni de otros motores. El banco resetea los motores a commits anteriores y prohíbe buscar implementaciones futuras, una condición de laboratorio que en la práctica no se da: los equipos reales sí tienen acceso a los commits y a la documentación. Los tres fallos restantes (dos de grafo y uno de kernel) no se explican en detalle, y no hay validación en dispositivos comerciales ni con cargas de trabajo reales. Los tiempos y costes son los de las ejecuciones de los autores.

Hasta que haya réplicas independientes, lo que queda es un resultado prometedor y bien medido en un problema incómodo: la misma prisa con la que llegan los modelos sigue muy por delante de la capacidad de llevarlos a los dispositivos.