LLM de 1000 TPS para agentes de teléfono: qué cambia

La velocidad no es todo el agente

Un LLM de 1000 TPS para agentes de teléfono cambia una parte importante de la experiencia: la espera. Cuando un modelo genera respuestas a gran velocidad, el usuario siente menos pausa entre intención, razonamiento y siguiente paso. En un chat sencillo, eso puede parecer solo comodidad. En un agente móvil, la diferencia es mayor porque cada tarea real suele incluir varios ciclos: entender, planear, abrir un flujo, revisar el resultado y decidir si continuar.

Pero la velocidad no es el agente completo. Un modelo rápido puede producir planes, resumir pantallas, sugerir acciones o responder en tiempo real, pero no concede permisos de Android, no confirma un envío, no decide por sí solo qué app permite una operación y no garantiza que una acción haya terminado. La inferencia rápida mejora el ritmo del razonamiento; la fiabilidad del teléfono depende también de acciones soportadas, permisos, confirmación visible y manejo de fallos.

Por eso conviene separar dos capas. La primera es el modelo: entiende la intención y propone pasos. La segunda es el teléfono: ejecuta o abre acciones dentro de límites concretos. Si el lector quiere el marco de un agente de IA en Android, esa guía cubre la base. Aquí nos centramos en el ángulo estrecho: cómo 1000 tokens por segundo cambia la latencia, y por qué esa mejora no reemplaza la parte que actúa en el dispositivo.

En FoneClaw leemos esta tendencia como una señal positiva. Un modelo más rápido puede hacer que el agente parezca más presente y menos torpe. Aun así, nuestro papel no es afirmar que usamos MiMo ni que alcanzamos 1000 TPS. Nuestro trabajo es convertir una intención en pasos Android compatibles, visibles y controlables.

Qué demuestra MiMo UltraSpeed y qué no demuestra

La señal concreta viene de Xiaomi. Según la página oficial de MiMo de Xiaomi, verificada el 15 de julio de 2026, MiMo-V2.5-Pro-UltraSpeed es un modo de experiencia UltraSpeed de MiMo-V2.5-Pro, descrito como modelo insignia de 1T. Xiaomi afirma que su velocidad máxima de inferencia supera los 1000 tokens por segundo, con salida en el rango de 500 a 1000 TPS frente a 50 a 100 TPS para MiMo-V2.5-Pro.

La misma página describe entrada y salida de texto, llamadas a herramientas, streaming y soporte de caché. También menciona escenarios recomendados como trading cuantitativo, control de riesgo en tiempo real, investigación científica y asistencia de programación en tiempo real. Son ejemplos donde la latencia cambia el valor del sistema: una respuesta que llega tarde puede perder utilidad, aunque sea correcta.

Es importante leer esos datos con precisión. Son afirmaciones oficiales de Xiaomi, no una tabla de benchmarks independientes ni una clasificación universal de modelos. Tampoco prueban que cualquier agente de teléfono, cualquier app o cualquier dispositivo Android pueda actuar a esa velocidad. Para quien quiera ubicar MiMo V2.5 Pro UltraSpeed dentro de un mapa más amplio de capacidades de modelos, esa lectura pertenece a la guía de modelos; aquí nos interesa la implicación para tareas móviles.

Lo que sí demuestra la señal es que la inferencia rápida ya no es solo una métrica de laboratorio. Cuando un modelo puede producir muchos tokens por segundo y además admite herramientas y streaming, se vuelve más plausible diseñar agentes que conversen, comprueben estados y ajusten planes con menos fricción. La pregunta pasa de “¿puede responder?” a “¿puede mantener el ritmo de una tarea real?”.

Por qué la latencia importa más en tareas largas

La latencia se nota poco cuando pides una respuesta única. Se nota mucho cuando una tarea contiene pasos encadenados. Imagina revisar notificaciones, detectar qué mensajes requieren respuesta, preparar dos borradores, abrir una ruta para una reunión y crear un recordatorio para salir. Si cada paso tarda varios segundos, la experiencia se rompe. El usuario vuelve a hacerlo manualmente porque siente que está esperando a la máquina.

Un modelo más rápido reduce ese coste acumulado. Puede interpretar una notificación, generar una propuesta, ajustar el texto después de una corrección y volver a comprobar el contexto sin convertir cada microdecisión en una pausa incómoda. En tareas largas, la velocidad no solo ahorra tiempo; mantiene la continuidad mental. El usuario puede seguir supervisando el flujo sin perder el hilo.

También mejora la confianza cuando el agente necesita preguntar. Si falta una dirección, si hay dos contactos con nombres parecidos o si un recordatorio requiere una hora concreta, una respuesta rápida hace que la aclaración parezca parte natural de la tarea. Una respuesta lenta convierte cada duda en interrupción. En agentes de teléfono, esa diferencia decide si el usuario tolera el proceso.

Aun así, la latencia no elimina la necesidad de comprobar. Una ruta abierta debe mostrar el destino. Un mensaje debe mostrar destinatario y contenido. Un ajuste sensible debe llevar al usuario a una confirmación clara. La velocidad ayuda a que el agente llegue antes al punto de decisión, pero la decisión sigue necesitando contexto y control humano cuando hay riesgo.

El patrón de modelo rápido y modelo profundo

Una forma útil de pensar en esta etapa es combinar modelos rápidos y modelos más profundos. Un modelo ligero o veloz puede encargarse de comprobaciones frecuentes: interpretar una frase, clasificar una notificación, detectar si falta información o proponer el siguiente paso. Un modelo más profundo puede entrar cuando la tarea requiere razonamiento complejo, comparación de opciones o una decisión con más contexto.

Este patrón no depende de un proveedor concreto. Es una arquitectura de producto: usar velocidad donde la tarea exige ritmo y usar más razonamiento donde la tarea exige cuidado. En una conversación en tiempo real, el modelo rápido puede mantener la respuesta fluida. En una planificación delicada, el modelo más profundo puede revisar el plan antes de una acción importante. Lo relevante no es solo cuántos tokens salen por segundo, sino cuándo conviene gastar más pensamiento.

Para un agente móvil, el patrón puede verse así: respuesta rápida para entender “llego tarde”, razonamiento más profundo para decidir si conviene avisar, abrir ruta o mover un recordatorio, y una comprobación rápida para confirmar que el usuario aprobó el borrador. La experiencia final parece simple, pero por debajo necesita cambios de ritmo.

En FoneClaw no usamos este punto para revelar ni reclamar una arquitectura interna específica. Lo tratamos como una lección de diseño: los agentes de teléfono no deberían depender solo de velocidad bruta ni solo de razonamiento pesado. La experiencia útil combina inmediatez, juicio y límites de acción. Un 1000 TPS ayuda en el primer componente; no resuelve por sí solo los demás.

Por qué las acciones del teléfono aún necesitan una capa fiable

La diferencia entre razonar y actuar se vuelve crítica en Android. Un modelo puede decidir que el siguiente paso lógico es enviar un mensaje, abrir una ruta, resumir una captura o cambiar una configuración. Pero el teléfono necesita permisos, apps disponibles, estado de pantalla, confirmaciones y rutas de recuperación. Si falta una pieza, el modelo no debería fingir que la acción ocurrió.

Las acciones del teléfono no son solo comandos. Algunas son reversibles y de bajo riesgo; otras pueden compartir datos, contactar a alguien, modificar ajustes o afectar una cuenta. Por eso el diseño debe incluir confirmación visible, no solo intención interpretada. Enviar un mensaje sin mostrarlo puede ser rápido, pero no necesariamente seguro. Abrir una ruta sin confirmar destino puede ser eficiente, pero no necesariamente correcto.

Este es el punto donde las acciones del teléfono dependen tanto del dispositivo como del modelo. Sensores, notificaciones, apps, permisos y pantalla crean el entorno donde el agente actúa. Un modelo rápido mejora la parte de razonamiento, pero la parte del teléfono necesita gobernanza: qué se puede hacer, qué requiere aprobación, qué se registra y qué ocurre si el flujo no está soportado.

En FoneClaw nos centramos en esa parte práctica. Nuestro enfoque trabaja con acciones Android compatibles, no con la idea de control total. Si una tarea puede prepararse y mostrarse de forma fiable, el agente puede ayudar. Si una app bloquea el flujo, falta un permiso o la acción es demasiado sensible, necesitamos fallback: explicar, abrir la app correcta o devolver el control al usuario.

Cómo aplicamos esta lección en FoneClaw

En FoneClaw vemos la inferencia rápida como una mejora real para el futuro de los agentes móviles. Un modelo más veloz puede reducir la fricción de conversaciones, comprobaciones y ajustes durante una tarea. Puede hacer que el usuario sienta que el agente acompaña el flujo en vez de frenarlo. Esa es una señal importante para todo el sector.

Este cambio ya tiene una aplicación práctica en FoneClaw. FoneClaw ha obtenido acceso de prueba interna a MiMo V2.5 Pro UltraSpeed y está usando este modelo de clase 1T, con la velocidad máxima superior a 1000 TPS que Xiaomi afirma, para mejorar la experiencia de uso. En un agente de teléfono, la ventaja no es una cifra abstracta: es entender antes la intención, revisar pasos con menos espera y ejecutar con más rapidez las acciones compatibles del móvil.

Pero nuestra lectura de producto es deliberadamente acotada. No decimos que FoneClaw use MiMo. No afirmamos alcanzar 1000 TPS. No prometemos que todos los teléfonos o todas las apps se vuelvan automatizables por tener modelos más rápidos. Lo que tomamos de esta tendencia es la dirección: cuanto más rápida y flexible sea la capa de razonamiento, más importante se vuelve una capa de acción que sea fiable, visible y respetuosa con permisos.

Nuestro papel es convertir una intención en un paso Android soportado. Eso puede significar preparar un mensaje, abrir un flujo, ayudar con una notificación, guiar hacia una configuración o organizar una pequeña secuencia de productividad. En cada caso miramos el mismo conjunto de preguntas: ¿la acción está soportada?, ¿qué permiso interviene?, ¿el usuario ve el resultado?, ¿hace falta confirmación?, ¿qué alternativa damos si no se puede completar?

El aprendizaje práctico para los lectores es sencillo. Los LLM de 1000 TPS pueden hacer que los agentes sean más rápidos, conversacionales y capaces de sostener tareas largas. Pero un agente de teléfono útil no nace de la velocidad sola. Nace cuando el razonamiento rápido se conecta con acciones compatibles, confirmaciones visibles y fallos claros. Esa es la frontera donde en FoneClaw concentramos nuestro trabajo.