Artículo por Xiang Xianzhi
Ro Fuli publicó un mensaje en X para cerrar el escándalo de la reducción de precios de MiMo de Xiaomi.
El 26 de mayo, la cuenta oficial de MiMo de Xiaomi publicó un anuncio en X: las API de la serie MiMo-V2.5 experimentarán una reducción permanente de precios, con un descuento máximo del 99%. Todos los contextos tendrán un precio uniforme, y los paquetes de tokens se incrementarán entre 5 y 8 veces.
Este anuncio dominó el círculo de IA en China durante toda una semana. La reacción inicial de la industria se dividió en varias corrientes. La más grande dijo que era "otra ronda de guerra de precios": en los últimos dos años, desde Zhipu, DeepSeek, ByteDance DouBao hasta Alibaba Tongyi, los modelos grandes nacionales han estado reduciendo precios en rotación, y nadie se queda fuera de la competencia.
Otra perspectiva es pesimista: Xiaomi acaba de anunciar que su utilidad este año se ha reducido a la mitad, y aún así sigue invirtiendo 60 mil millones en IA y recortando los API en un 90 %: un claro ejemplo de "perder dinero para ganar cuota de mercado". Algunos creen que esto es una continuación del efecto DeepSeek, que ha llevado el benchmark de precios de toda la industria al suelo: quien no siga, se queda fuera.
Como responsable de MiMo, Luo Fuli presentó directamente anoche un blog técnico de 5000 palabras, haciendo públicos los detalles contables del descuento.
Mira, esta es una verdadera capacidad técnica, no una estrategia de marketing.
Para entender lo que dice Luo Fuli, primero debes saber qué es exactamente lo que bajó un 99%.
No es una reducción general del modelo. El descuento del 99% se aplica exclusivamente a un nivel de precios llamado Input (Cache Hit), es decir, la parte correspondiente a "cuando los usuarios leen repetidamente el historial de contexto en conversaciones largas". Los nuevos inputs normales (No Cache Hit) tienen un descuento mucho menor, y la salida del modelo (Output) tiene el descuento más pequeño.
Si piensas en el modelo como una cafetería, esto resulta más fácil de entender.
Pediste un latte con mitad de azúcar, y la cafetería tiene dos formas de hacerlo: cada vez muelen los granos, miden el jarabe y vierten la leche, pagando por los ingredientes y la mano de obra cada vez; pero el modelo sabe que esta semana vas a tomar el mismo latte con mitad de azúcar todos los días, así que prepara un gran recipiente y lo guarda en la nevera, y luego sirve una porción por taza cada vez. MiMo hizo lo segundo: cambió la parte que los usuarios leen repetidamente de "calcular en tiempo real" a "recuperar en tiempo real", por lo que el costo real de esta parte se acerca a 0, lo que permite ofrecer un descuento del 99%.
Para lograr "retiro en el acto", el blog técnico describe seis proyectos, ninguno de los cuales puede faltar. A continuación, los analizamos uno por uno.
Proyecto 1: Reducir la "memoria" del modelo a 1/7
Cuando el modelo dialoga contigo, cada token genera un "estado intermedio" que se almacena para su uso en el siguiente paso. Esto se llama KVCache — puedes entenderlo como la "libreta de memoria a corto plazo" del modelo. Cada vez que dices algo, el modelo anota un resumen de esa frase en su libreta y, la próxima vez, simplemente consulta la nota en lugar de escuchar nuevamente todo lo que has dicho desde el principio.
El modelo tradicional realiza "Atención Completa" en cada capa: es decir, cada token revisa todos los tokens de toda la conversación, haciendo que el cuaderno se vuelva cada vez más grueso. MiMo-V2.5-Pro modificó la arquitectura: de las 70 capas, 60 solo miran los últimos 128 tokens (SWA, Sliding Window Attention), mientras que solo 10 capas, los "administradores de archivos", miran todos los tokens.
El resultado es que el tamaño de KVCache se reduce directamente a 1/7 del Full Attention, y la cantidad de cálculo también es 1/7.
Esta es la primera base para reducir costos. Por ejemplo, anteriormente se requería que cada empleado de la empresa recordara todos los actas de reunión, lo que saturaba la capacidad mental de todos y reducía la eficiencia. La nueva norma reduce la carga mental de 60 empleados a 1/7, asignando solo a 10 administradores de archivos el manejo de todo el historial: la capacidad de memoria general de la empresa no disminuye, pero la eficiencia aumenta siete veces.
Proyecto 2: Hacer que el espacio ahorrado por SWA sea realmente utilizable
Reducir la laptop a 1/7 en la arquitectura es el primer paso, pero hay un obstáculo para convertir el "1/7 teórico" en un "1/7 real".
El sistema tradicional de KVCache asigna memoria GPU a todas las capas según el "uso máximo posible". Esto significa que, aunque las 60 capas de SWA solo necesiten una pequeña libreta, el sistema asigna a todas las capas una "libreta grande de administrador de archivos": el espacio ahorrado por SWA se reserva innecesariamente, lo que equivale a no haber ahorrado nada.
El enfoque del equipo de Luo Fuli consiste en dividir el KVCache en dos piscinas independientes. Las 10 capas de Full Attention utilizan la "piscina grande", asignada según la longitud completa; las 60 capas de SWA utilizan la "piscina pequeña", asignada solo según una ventana de 128 tokens.
Por ejemplo, antes la empresa le daba a cada empleado un archivador capaz de almacenar 100 años de documentos, pero en realidad, los 60 empleados solo necesitaban un pequeño archivador para una semana de archivos, dejando el 99% del espacio en los archivadores grandes vacío. El nuevo enfoque asigna archivadores según la necesidad real. Como resultado, la oficina puede acomodar más de cinco veces más colegas: el mismo GPU puede atender cinco veces más usuarios simultáneos.
Este paso parece sencillo, pero sin él, las ventajas del arquitectura SWA anteriores serían equivalentes a haberlas diseñado en vano.
Proyecto 3: Asegurar que los "usuarios existentes lean repetidamente" realmente golpeen la caché
La laptop se presiona al 1/7 + el espacio realmente es asequible; el siguiente paso es resolver un problema antiguo: la tasa de aciertos del caché de prefijos.
Muchas conversaciones de usuarios comparten el mismo inicio: el mismo prompt del sistema, el mismo repositorio de código y el mismo documento largo. El sistema almacena los resultados ya calculados y, al encontrar una coincidencia posterior, los reutiliza directamente. Este mecanismo se llama caché de prefijos.
Pero en el modo SWA surge un problema: dos solicitudes con el mismo token no significan que el KV aún esté vigente. Es posible que el prefijo haya sido calculado, pero la parte fuera de la ventana SWA ya fue descartada. Si el sistema sigue la regla antigua de "mismo token = acierto" y reutiliza los datos, se leerán datos inválidos o sobrescritos, lo que hará que el rendimiento del modelo se derrumbe por completo.
El equipo de Luo Fuli actualizó las reglas a "longitud segura de la ventana": solo compromete "la parte que puedes pedir prestada completamente".
Por ejemplo, una biblioteca tiene un millón de libros y deseas prestar la serie completa de tres volúmenes de "The Three-Body Problem". La arquitectura anterior te diría "el libro está disponible", pero cuando vas a buscarlo, descubres que en el estante solo queda la cubierta y el primer volumen; los dos siguientes ya han sido prestados. Este "falso acierto" te hace perder tiempo y obliga a solicitarlo nuevamente. El nuevo sistema cambia la regla: solo promete entregarte lo que puedas obtener completamente—primero te da el primer volumen, luego te trae los otros dos.
Parece que sería más estricto y que la tasa de acierto disminuiría, pero en realidad ocurre lo contrario: como SWA reduce el tamaño del KVCache a 1/7, el mismo espacio de almacenamiento puede contener varias veces más contenido, lo que aumenta significativamente la tasa de acierto real.
En el blog de Luo Fuli, se proporcionan cifras de prueba en línea: bajo los marcos de harness más populares, la tasa de aciertos de la caché del servidor promedia el 93%, y puede superar el 95% para usuarios de alto volumen con ciclos largos.
El significado de este número es: el 95 % de las solicitudes de "lectura repetida" no utilizan en absoluto la GPU, sino que se obtienen directamente desde la caché. Esta es la base física del descuento del 99 %.
Proyecto 4: Instalar la "caché" en el SSD integrado de la GPU
La tasa de aciertos aumentó, el siguiente problema es: ¿dónde se almacenan estos cachés?
La memoria VRAM (HBM en GPU) es cara y limitada: una máquina con ocho GPU H100 tiene solo 640 GB de VRAM, pero el KVCache que necesita MiMo podría ser de decenas de TB. Por lo tanto, es necesario implementar una jerarquía: los datos más recientes se almacenan en la VRAM (L1), los ligeramente antiguos en la memoria RAM de la CPU (L2), y los datos fríos en una caché distribuida (L3).
Es lo mismo que manejar tu dinero. El efectivo en tu billetera es la memoria visible: lo usas y lo retiras fácilmente, pero no puedes guardar mucho. El saldo de tu tarjeta bancaria es la memoria RAM de la CPU: tardas 30 segundos en retirarlo, pero puedes guardar mucho. El depósito a plazo fijo es la caché distribuida L3: tardas dos minutos en retirarlo, pero es mucho más económico.
La práctica habitual de la industria es crear un clúster de almacenamiento independiente para L3, con equipos dedicados y salas dedicadas, pagando alquiler mensual.
El equipo de almacenamiento de Xiaomi lo hace de manera diferente. Desarrollaron su propio sistema de caché distribuida llamado GCache, que se implementa directamente en los SSD integrados en las máquinas GPU, compartiendo la misma máquina con tareas de entrenamiento e inferencia.
Alguien alquiló un almacén específico para almacenar grandes cantidades de datos; Xiaomi descubrió que el garaje con máquinas GPU estaba vacío y almacenó directamente los datos allí. Se ahorró el alquiler mensual.
El costo adicional de almacenamiento es 0.
El impacto de esto es mayor de lo que parece. En el "cálculo de capacidad de IA" convencional, el costo de almacenamiento es un gasto fijo: cuanto más grande sea tu modelo y más usuarios tengas, más larga será tu factura de almacenamiento. El enfoque de GCache elimina directamente este costo. Combinado con el pequeño tamaño de SWA y una tasa de acierto del 93-95%, el tiempo de vida (TTL) del KVCache en L3 se extiende de minutos a horas e incluso días: cuanto más largo sea el TTL, más amplio será el margen de acierto para el contexto histórico, mayor será la tasa de acierto del caché, y más sólido será el descuento del 99%.
Proyecto 5: Hacer que las solicitudes que dan en la caché sigan la ruta más corta
La caché puede almacenar, buscar y es económica; el último paso es: cómo redirigir las solicitudes correctas a la máquina adecuada.
Xiaomi desarrolló un sistema de programación propio llamado LLM-Router, que realiza tres tareas:
Primero, programación afín. Las solicitudes con el mismo prefijo se enrutan a la misma máquina para maximizar la reutilización de la memoria caché.
En segundo lugar, agrupar por longitud. Dirigir las solicitudes cortas (0-64 K), las solicitudes medias (64 K-256 K) y las solicitudes largas (256 K-1 M) a canales de procesamiento distintos para evitar que las solicitudes cortas se vean ralentizadas por las largas.
Tercero, optimización de TTFT. En la cola de espera para inferencia, prioriza la programación de solicitudes con menor carga de cálculo real (es decir, aquellas que tienen una alta tasa de aciertos en caché): evita que se vean bloqueadas por solicitudes de "entrada nueva" que requieren cálculos intensivos.
Por ejemplo, en la programación habitual de un aeropuerto, todos los pasajeros con destino al mismo lugar se reúnen en la misma sala de espera y comparten el proceso de reclamo de equipaje: esto es programación por afinidad. Los pasajeros con equipaje de mano y los que llevan tres maletas facturadas pasan por dos canales de seguridad distintos, evitando que los rápidos se retrasen por los lentos: esto es agrupamiento por longitud. Al embarcar, se permite primero el ingreso a quienes solo llevan equipaje de mano, ya que abordan más rápido y permiten que el avión despegue antes: esto es optimización TTFT.
Esta estrategia de programación ha aumentado la tasa de aciertos en la caché L2 en un 25%, el rendimiento de entrada por servidor en un 30% y reducido la latencia P90 de las solicitudes largas en un 30%.
La misma GPU puede atender a más usuarios. La otra mitad de la lógica detrás de la reducción de precios es aquí: la producción efectiva por unidad de poder de cómputo es mayor y el costo por usuario es menor.
Proyecto 6: Hacer que el modelo "escriba" más rápido
Las cinco primeras cosas optimizan el lado de la "lectura" — reduciendo el costo para que el usuario vuelva a leer el contexto histórico a casi 0. La sexta cosa optimiza el lado de la "escritura" — es decir, el proceso en el que el modelo genera el siguiente token.
Los modelos tradicionales generan solo un token a la vez. MiMo admite nativamente 3 niveles de MTP (Multi-Token Prediction): predice los siguientes 3 tokens a la vez, y si la predicción intermedia es correcta, se salta directamente el cálculo intermedio.
Por ejemplo, en la escritura tradicional, se presiona una tecla por cada carácter: si quieres escribir "今天天气", debes presionar 4 teclas. MTP tiene una función de autocompletado que adivina tus próximos 1-2 caracteres; si acierta, no necesitas presionar esas dos teclas adicionales.
Pruebas reales de MTP de MiMo en escenarios agentic: aceleración de 2.3 veces para los primeros 128 tokens y 1.5 veces para los tokens 128-256.
El significado de esto es que el descuento del 99% se dirige específicamente a Input (Cache Hit), pero cuando el modelo sirve a los usuarios, el input y el output ocurren en la misma solicitud: si el output no se ahorra, el costo total de la solicitud solo se reduce a la mitad. MTP reduce también esa mitad del output, cerrando así el modelo de rentabilidad de la reducción completa.
Conecta seis cosas en una cadena de reducción de costos:
Arquitectura SWA → KVCache 1/7 → Doble piscina que libera verdaderamente capacidad → Una misma GPU puede alojar 5+ veces más concurrencia → Tasa de acierto del caché de prefijos: 93-95% → El 95% de las solicitudes casi no requieren cálculo → GCache reduce el costo de almacenamiento a cero → La programación prioriza las solicitudes con acierto → MTP también ahorra en generación → El tiempo de GPU por solicitud disminuye una orden de magnitud → El costo unitario disminuye más del 95% → El precio se reduce un 99%, pero la margen bruta sigue siendo positiva.
Si falta cualquier eslabón, esta cadena se rompe en uno de ellos. El descuento del 99% no es un número de marketing, sino el efecto acumulado de seis pilares de ingeniería combinados con validación en línea real.
Al mirar hacia atrás las primeras interpretaciones de la industria, cada una tenía algo de verdad. La guerra de precios entre las empresas chinas de modelos grandes de estos dos años es real; que Xiaomi haya reducido sus ganancias a la mitad y aún así invierta en IA es real; que DeepSeek haya llevado la fijación de precios de la industria al suelo también es real.
Pero al publicar este blog técnico y desglosar detalladamente los aspectos técnicos, Ro Fuli sin duda espera contrarrestar las afirmaciones sobre la guerra de precios, haciendo clear que "los problemas técnicos pertenecen a la técnica, y los problemas de marketing pertenecen al marketing."
Ella escribió en su blog que la eficiencia de inferencia de la serie de modelos MiMo-V2.5 no proviene de un avance puntual en un solo componente, sino del resultado de una optimización coordinada en múltiples dimensiones. Hybrid SWA beneficia simultáneamente al prefill y al decode, pero una implementación no suficientemente optimizada de KVCache puede aumentar los costos en cada etapa. En torno a este objetivo, el equipo MiMo reestructuró sistemáticamente la gestión de KVCache, la caché jerárquica y el árbol de caché de prefijos, resolvió los problemas centrales de SWA KVCache, optimizó las estrategias de programación y las rutas de Prefill/Decode, y validó estos logros en escenarios reales en producción, logrando finalmente materializar las ventajas teóricas de eficiencia en el entorno real. Así, Hybrid SWA pudo desplegar plenamente sus ventajas arquitectónicas en términos de potencia y eficiencia para la inferencia de textos largos. Combinado con configuraciones MoE y diversas optimizaciones para la inferencia multimodal, se mejoró considerablemente el rendimiento del servicio de inferencia en producción.
Este es un enfoque sistemático de ingeniería de IA y también una medida de reducción de costos que la industria debería considerar y adoptar.
No necesitas escribir un blog para una guerra de precios, sí para la ejecución técnica.