Optimización LLM en el dispositivo para agentes móviles

La calidad del agente móvil empieza por la espera percibida

Un agente de teléfono falla antes por sensación que por teoría. Si el usuario dice “responde a este mensaje”, espera ver un borrador rápido, una confirmación clara y una salida si la app pide atención. Si el teléfono se queda pensando, calienta, consume batería o pierde el estado de pantalla, la experiencia se rompe aunque el modelo sea bueno en pruebas aisladas.

La optimización LLM en el dispositivo para agentes móviles trata exactamente de eso: hacer que la IA local sea suficientemente rápida, estable y eficiente para tareas reales del teléfono. No se trata solo de tokens por segundo. Importan la memoria disponible, el arranque del modelo, el coste energético, la disponibilidad en primer plano, el tiempo hasta la primera respuesta y la manera en que el resultado vuelve a una acción Android visible.

Google presenta Gemini Nano en Android Developers como un modelo en el dispositivo que funciona mediante AICore para IA generativa local, con baja latencia, casos centrados en privacidad y experiencias posibles sin red cuando el dispositivo y la función lo soportan. Para un agente móvil, esa promesa se traduce en tareas como resumir un texto visible, preparar una respuesta corta o entender una intención sin enviar cada paso a la nube.

En FoneClaw miramos la latencia desde el flujo completo: voz, intención, pantalla, app, acción y confirmación. Un modelo local rápido ayuda al inicio, pero la experiencia se completa cuando el usuario ve el resultado. Si la tarea afecta a otra persona, como enviar un mensaje o iniciar una llamada, la confirmación tiene que llegar en un punto predecible. La velocidad que cuenta es la que mantiene el control del usuario.

Para el marco general de acciones del teléfono, enlazamos nuestra guía sobre control del teléfono con agentes IA. Aquí nos centramos en lo que ocurre debajo: por qué un LLM móvil debe ser pequeño, rápido, eficiente y compatible con las rutas reales de Android.

Tamaño del modelo, cuantización y rutas para tareas pequeñas

Un teléfono no es un centro de datos en miniatura. Tiene batería limitada, memoria compartida, temperatura, apps abiertas y un usuario que espera respuesta inmediata. Por eso el tamaño del modelo importa tanto. Un LLM grande puede razonar mejor en tareas complejas, pero un modelo más pequeño puede resolver antes tareas frecuentes: clasificar una notificación, redactar una frase, resumir una pantalla o elegir la siguiente acción.

La cuantización reduce el peso numérico del modelo para que ocupe menos y corra de forma más eficiente. En lenguaje práctico, es como empaquetar el modelo para que quepa mejor en el teléfono y use menos recursos, aceptando que cada tarea debe probarse con cuidado. Los adaptadores permiten ajustar comportamiento para casos concretos sin rehacer todo el modelo. Las rutas para modelos pequeños permiten mandar tareas simples al modelo local y reservar razonamiento más amplio para otro nivel.

Apple describe en sus actualizaciones de modelos fundacionales trabajo de eficiencia en el dispositivo, incluyendo cuantización, adaptadores, uso compartido de caché KV y división entre modelos locales y de servidor. Aunque el ecosistema sea distinto, la lección para agentes móviles es común: no todo requiere el modelo más grande; lo importante es elegir el nivel correcto para la acción.

Un ejemplo Android: “responde: voy en camino” puede pasar por un modelo local o una plantilla asistida si el contexto es claro. “Analiza veinte correos, compáralos con mi calendario y prepara una propuesta” exige más memoria, contexto y quizá razonamiento externo. En FoneClaw nos interesa que el usuario vea qué acción se prepara y dónde se pide confirmación, no que todo se fuerce por la misma ruta técnica.

El tamaño del modelo también afecta recuperación. Si una app se cierra, si el teléfono cambia de red o si el usuario interrumpe, el sistema debe volver a un estado útil. Un agente rápido que no sabe recuperarse sigue siendo frágil. La optimización real combina modelo, app, estado visible y continuidad.

AICore, Gemini Nano, ML Kit GenAI, LiteRT y LiteRT-LM en Android

Para que un LLM local sirva en un teléfono, necesita una ruta técnica confiable: cómo se descarga, dónde corre, qué dispositivos lo admiten, cómo se comprueba disponibilidad y qué límites aplica la plataforma. En Android, varios nombres aparecen en esa conversación: AICore, Gemini Nano, ML Kit GenAI, Google AI Edge, LiteRT y LiteRT-LM.

Google ML Kit GenAI Prompt API documenta un enfoque práctico: comprobar si la función está disponible, trabajar con dispositivos compatibles, descargar Gemini Nano cuando corresponde, usar preparación inicial para reducir la primera espera y atender límites de tokens y cuota por app. Para un producto de agente móvil, esas piezas son tan importantes como la calidad del texto generado.

Google AI Edge agrupa herramientas para IA y aprendizaje automático en el dispositivo, incluyendo APIs de tareas MediaPipe, LiteRT y LiteRT-LM. A su vez, la visión general de LiteRT-LM muestra ejemplos de LLM locales y dimensiones de rendimiento como preparación de entrada, generación, tiempo hasta el primer token, CPU, GPU, memoria y ejecución local sin conexión.

Estas rutas técnicas hacen que la IA local sea más concreta para Android. Un desarrollador puede pensar en disponibilidad, descarga, calentamiento inicial, memoria y backend; un usuario solo nota si la respuesta aparece rápido y si el teléfono sigue siendo usable. Entre ambos mundos está el producto: la app debe convertir capacidad técnica en una acción que se entienda.

En FoneClaw diseñamos con esa separación clara. El modelo puede ayudar a entender intención o resumir contexto; Android ofrece permisos, apps y pantalla; FoneClaw organiza el paso visible. Para una mirada más amplia sobre la base del sistema, nuestra guía de base de tres capas del agente de sistema cubre ese nivel sin convertir este artículo en teoría de plataforma.

Caché KV, preparación inicial, contexto y velocidad repetida

Algunas demoras se sienten una sola vez; otras se repiten hasta cansar. Abrir un modelo por primera vez, cargar contexto, preparar la entrada y empezar a generar respuesta son partes distintas de la experiencia. Por eso términos como caché KV, prefill, decode, warmup y longitud de contexto importan para un agente de teléfono.

La caché KV guarda información interna que el modelo ya calculó sobre el contexto. Cuando se reutiliza bien, ayuda a no recalcular todo desde cero. Prefill es la etapa en la que el modelo procesa la entrada inicial; decode es la generación paso a paso de la respuesta. Warmup, o preparación inicial, busca reducir la espera del primer uso. En español cotidiano: preparar el motor antes de pedirle que acelere.

LiteRT-LM publica dimensiones de rendimiento como prefill, decode, tiempo hasta el primer token, memoria y backends CPU/GPU. Esas métricas son útiles porque un phone agent suele trabajar en bucles: leer contexto visible, proponer acción, esperar confirmación, ejecutar paso, revisar resultado. Si cada vuelta empieza desde cero, el usuario siente lentitud.

La longitud de contexto también tiene coste. Darle al modelo mucha información puede mejorar respuesta, pero consume memoria y tiempo. Un agente móvil debe elegir qué contexto llevar: una notificación, una pantalla, un mensaje reciente, una instrucción del usuario. Más contexto no siempre mejora el flujo; el contexto correcto sí.

En FoneClaw, esta idea aparece en tareas repetidas. Si el usuario está gestionando mensajes, no necesita que el modelo olvide cada paso. Si está navegando una rutina de Android, conviene conservar lo que ya se confirmó. La optimización LLM en el dispositivo para agentes móviles vale cuando acelera esa continuidad y mantiene una salida visible si el usuario cambia de app o interrumpe la tarea.

Cuándo usar inferencia local y cuándo ampliar con nube

La IA local es excelente para respuestas rápidas, contexto cercano y tareas con datos que conviene procesar en el propio dispositivo cuando la función está disponible. La nube sigue siendo útil para razonamiento más pesado, contexto amplio, modelos grandes o tareas que requieren información externa. Un agente móvil maduro combina ambas rutas según la tarea.

Una acción local puede bastar para resumir una notificación, reformular un mensaje corto, clasificar una intención o preparar un recordatorio. Una tarea más compleja, como comparar documentos largos o planificar varios pasos con mucha información, puede beneficiarse de razonamiento remoto. Lo importante es que el usuario entienda qué está pasando y que el resultado vuelva a una acción Android visible.

Apple muestra una lógica parecida en su documentación de Foundation Models, donde el modelo en el dispositivo puede trabajar con salida estructurada y llamadas a herramientas dentro de apps. La industria se mueve hacia una mezcla de modelos locales, herramientas de app y recursos más potentes cuando el caso lo pide.

En FoneClaw diseñamos esa mezcla desde la acción del teléfono. Si el modelo local puede preparar el texto y la app permite mostrarlo, el usuario confirma. Si una tarea necesita más razonamiento, el flujo puede ampliarse y volver con un resultado revisable. Si una app requiere permiso o selección manual, mantenemos la pantalla como punto de decisión.

Para una comparación más centrada en privacidad y arquitectura, agente IA local frente a nube desarrolla ese eje. Aquí la pregunta es más operativa: qué ruta hace que la acción sea rápida, fiable, visible y confirmable.

Checklist para evaluar un LLM local en un teléfono

Cuando una función promete IA en el dispositivo, conviene evaluarla como usuario de phone agent, no solo como lector de especificaciones. La pregunta clave es: ¿me ayuda a terminar una acción real del teléfono con menos espera y más claridad?

• Compatibilidad: comprueba si el dispositivo admite la función local, como Gemini Nano, AICore, ML Kit GenAI o una ruta LiteRT-LM concreta.
• Descarga y disponibilidad: revisa si el modelo se descarga, si hay comprobación previa de función y si la app explica el estado.
• Primera espera: observa si hay preparación inicial para reducir la primera respuesta.
• Latencia repetida: prueba tareas encadenadas, no solo una pregunta aislada.
• Memoria y batería: nota si el móvil se calienta, cierra apps o cae rápido de batería.
• Privacidad práctica: identifica qué se procesa en el dispositivo y qué requiere servicio remoto.
• Cuotas y límites: revisa límites de tokens, uso por app o disponibilidad diaria cuando existan.
• Recuperación de interfaz: prueba qué ocurre al cambiar de app, bloquear la pantalla o interrumpir la tarea.
• Confirmación: verifica que mensajes, llamadas, cambios sensibles y acciones externas se muestran antes de completarse.

Una función local excelente para redactar frases puede ser débil para gestionar flujos largos. Un modelo rápido puede sentirse torpe si la app pierde estado. Un sistema con buena privacidad local puede necesitar nube para tareas complejas. Por eso la evaluación debe cubrir toda la acción, desde intención hasta resultado.

En FoneClaw usamos esta checklist como criterio de producto: velocidad real, resultado visible, permisos comprensibles, confirmación en acciones sensibles y una salida práctica cuando el contexto cambia. La optimización LLM en el dispositivo para agentes móviles no termina en el modelo; termina cuando el usuario consigue hacer algo útil en Android.