Xiaomi MiMo reduce el precio en un 99% ¡no es solo marketing! Luo Fulili responde en X a quienes lo menosprecian

nulo

Escrito por | Xiang Xianzhi

Luo Fulili publicó un tuit en X para poner fin a la ola de bajadas de precios de Xiaomi MiMo.

El 26 de mayo, la cuenta oficial de Xiaomi MiMo publicó un anuncio en X: La serie MiMo-V2.5 tendrá una bajada de precio permanente en su API, con un máximo del 99%. Todos los precios de contexto tendrán una tarifa fija, y los paquetes de tokens se actualizarán de 5 a 8 veces.

Este anuncio estuvo en boca de todos en el círculo de IA nacional durante toda una semana. La reacción de la industria se dividió en varias corrientes. La más grande dijo que esto era "otra ronda de guerra de precios" — en los últimos dos años, desde Zhipu, DeepSeek, Byte Doubao hasta Alibaba Tongyi, los grandes modelos nacionales han estado bajando precios uno tras otro, todos compitiendo.

Otra corriente miraba con pesimismo: Xiaomi acaba de anunciar que sus beneficios se han reducido a la mitad este año, y ahora están gastando 600 millones en IA y reduciendo en un 90% sus API — típico ejemplo de "perder dinero para ganar mercado". Algunos pensaban que esto era una continuación del efecto DeepSeek — que ha llevado toda la referencia de precios de la industria a mínimos, y quien no siga el ritmo queda fuera.

Por eso, como responsable de MiMo, Luo Fulili publicó anoche un blog técnico de 5000 palabras, haciendo públicos los detalles de la bajada de precios y las cuentas técnicas.

“Mira, esto es verdadera capacidad técnica, no una estrategia de marketing”.

Para entender qué dice Luo Fulili, primero hay que comprender qué exactamente se ha reducido en ese 99%.

No se trata de una bajada de precio en todo el modelo. El 99% de descuento se aplica específicamente a una categoría llamada Input (Cache Hit), es decir, la parte en la que "el usuario repite la lectura del contexto histórico en diálogos largos". Las nuevas entradas normales (No Cache Hit) tienen una reducción mucho menor, y la salida del modelo (Output) la menor de todas.

Si comparas el modelo con una cafetería, esto es fácil de entender.

Pides un café con leche medio azucarado, y la cafetería tiene dos formas de prepararlo: moler los granos y añadir azúcar y leche cada vez, pagando la mano de obra cada vez; o, si sabe que todos los días vas a pedir lo mismo, preparar una jarra grande y guardarla en el congelador, y la próxima vez servirte una taza con una cuchara. MiMo ha optado por la segunda opción — en lugar de calcular en tiempo real, lo sacan de "la nevera", por lo que el coste real de esa parte es casi cero, y por eso pueden ofrecer un 99% de descuento.

Para lograr "extraer en el momento", el blog explica seis ingenierías, cada una imprescindible. Vamos a desglosarlas una por una.

Primera ingeniería: reducir la "memoria" del modelo a 1/7

Cuando el modelo conversa contigo, cada token necesita calcular un "estado intermedio" y almacenarlo para la siguiente operación. Esto se llama KVCache — puede entenderse como la "nota de memoria a corto plazo" del modelo. Cada vez que dice una frase, el modelo anota en la nota un resumen, y la próxima vez lee directamente esa nota en lugar de escuchar toda la conversación desde cero.

Los modelos tradicionales hacen "Full Attention" en cada capa — cada token mira todos los tokens de la conversación, haciendo que la nota se vuelva cada vez más gruesa. La versión MiMo-V2.5-Pro cambia la arquitectura: en 70 capas, 60 solo miran los últimos 128 tokens (SWA, Sliding Window Attention), y solo 10 capas actúan como "archivistas" que ven todo.

El resultado es que el tamaño de KVCache se reduce a 1/7 del tamaño de Full Attention, y el cálculo también es 1/7.

Este es el primer cimiento para reducir costes. Por ejemplo, en una empresa, cada empleado debía recordar todas las reuniones, pero eso sobrecargaba la memoria y bajaba la eficiencia. La nueva norma reduce la carga mental de 60 empleados a 10 archivistas que manejan toda la historia — la memoria global de la empresa no disminuye, pero la eficiencia aumenta 7 veces.

Segunda ingeniería: hacer que el espacio ahorrado por SWA sea realmente útil

Reducir la nota a 1/7 en la arquitectura es el primer paso, pero convertir ese "teórico 1/7" en un "real 1/7" requiere otro paso.

El sistema tradicional de KVCache asigna toda la memoria de GPU a todas las capas en función del "uso máximo posible". Es decir, aunque las 60 capas de SWA solo necesiten un cuaderno pequeño, el sistema reserva espacio como si todas usaran un gran archivador — el espacio ahorrado en SWA se reserva en vano, sin aprovecharse.

El equipo de Luo Fulili dividió KVCache en dos pools independientes. Las 10 capas de Full Attention usan un "gran pool", asignado a toda la secuencia; las 60 capas de SWA usan un "pequeño pool", solo para una ventana de 128 tokens.

Por ejemplo, en una oficina, cada empleado tenía un armario para guardar documentos de 100 años, pero en realidad solo necesitaban uno para una semana. Los grandes armarios estaban en su mayoría vacíos. La nueva estrategia es asignar armarios según la necesidad real. Como resultado, la oficina puede admitir a 5 veces más empleados con la misma GPU, multiplicando por cinco la cantidad de usuarios concurrentes.

Este paso, aunque parece simple, es esencial; sin él, las ventajas de la arquitectura SWA serían inútiles.

Tercera ingeniería: hacer que la "repetición del usuario" realmente aproveche la caché

Reducir la memoria a 1/7 y usar espacio de forma efectiva, requiere resolver un problema clásico: la tasa de acierto del caché de prefijos.

Muchos diálogos empiezan igual — mismo prompt, misma base de código, mismo documento largo. El sistema guarda estos resultados ya calculados, y si vuelve a encontrarlos, los reutiliza. Esto se llama caché de prefijos.

Pero en modo SWA hay un problema: si dos solicitudes tienen el mismo token, no significa que el KV todavía esté válido. Puede que el prefijo ya se haya calculado, pero la parte fuera de la ventana SWA ya fue descartada. Si el sistema simplemente reutiliza los datos antiguos, puede leer información inválida o sobreescrita, y el rendimiento del modelo se desploma.

El equipo de Luo Fulili actualizó la regla a "longitud segura de la ventana" — solo garantiza que puedas acceder a la parte completa.

Por ejemplo, en una biblioteca, quieres tomar en préstamo los tres volúmenes de "El problema de los tres cuerpos". La antigua regla te dice que "el libro está", pero en realidad solo quedan las cubiertas y el primer volumen, los otros dos ya están prestados. Esa "pseudo-coincidencia" te hace perder tiempo y tener que volver a pedir. La nueva regla solo garantiza que puedas obtener la parte completa que necesitas — primero te dan el primer volumen, y luego te traen los otros dos.

Parece más estricta y puede reducir la tasa de acierto, pero en realidad aumenta mucho, porque con SWA el KVCache se reduce a 1/7, y el contenido almacenado puede ser varias veces mayor. La tasa de acierto real aumenta significativamente.

El blog de Luo Fulili comparte datos en producción: en los principales frameworks, la tasa de acierto del caché en el servidor alcanza un promedio del 93%, y en usuarios frecuentes y de ciclos largos, supera el 95%.

¿Y qué significa esto? Que el 95% de las solicitudes de "lectura repetida" no necesitan cálculo en GPU, sino que se sirven directamente desde la caché. Esa es la base física del descuento del 99%.

Cuarta ingeniería: poner la "caché" en el SSD integrado en la GPU

Con la tasa de acierto mejorada, el siguiente problema es: ¿dónde se almacenan esas cachés?

La memoria de la GPU (HBM) es cara y limitada — una H100 de 8 tarjetas tiene solo 640 GB en total, pero el KVCache que necesita MiMo puede llegar a decenas de TB. Por eso, se usa una jerarquía: lo más reciente en memoria de GPU (L1), lo algo más antiguo en memoria del CPU (L2), y los datos fríos en caché distribuido (L3).

La práctica habitual en la industria es crear un clúster dedicado para L3, con hardware y salas específicas, pagando alquiler mensual.

El equipo de almacenamiento de Xiaomi hizo algo diferente: desarrollaron GCache, un sistema de caché distribuido que se despliega directamente en los SSD integrados en las máquinas GPU — compartiendo recursos con tareas de entrenamiento y inferencia en la misma máquina.

En palabras simples: en lugar de alquilar un almacén para guardar datos, Xiaomi encontró que los SSD en las máquinas GPU estaban en blanco, y simplemente almacenó los datos allí. Ahorrando en alquiler.

El blog técnico dice: "El costo adicional de almacenamiento es cero".

Esto tiene un impacto mucho mayor de lo que parece. En los cálculos tradicionales de costos de IA, el almacenamiento es un gasto fijo — cuanto más grande sea el modelo y más usuarios, mayor será el gasto en almacenamiento. GCache elimina ese gasto. Combinado con SWA, que reduce el tamaño y aumenta la tasa de acierto a 93-95%, la vida útil del KVCache en L3 (TTL) se extiende de minutos a horas o incluso días — cuanto más largo, mayor la ventana de acierto, y más efectivo el descuento del 99%.

Quinta ingeniería: hacer que las solicitudes con caché sean las más cortas

Con la caché en su lugar, y con un coste bajo, el siguiente paso es: ¿cómo enrutar las solicitudes correctas a las máquinas correctas?

Xiaomi desarrolló su propio sistema de enrutamiento llamado LLM-Router, que realiza tres tareas:

Primero, afinidad en la asignación. Las solicitudes con prefijos iguales se envían a la misma máquina, para maximizar la reutilización de caché.

Segundo, agrupación por longitud. Las solicitudes cortas (0-64K), medias (64K-256K) y largas (256K-1M) se envían a canales diferentes, para evitar que las largas ralenticen a las cortas.

Tercero, optimización TTFT. En la cola de inferencia, se priorizan las solicitudes con menor carga computacional (las que tienen más caché), para evitar que las nuevas entradas las bloqueen.

Por ejemplo, en un aeropuerto, los pasajeros con el mismo destino se agrupan en la misma sala, compartiendo el proceso de recogida de equipaje — eso es afinidad. Los que llevan maletas pequeñas y grandes usan carriles diferentes, para que los rápidos no se retrasen — eso es agrupación por longitud. Y se prioriza a los pasajeros con menos equipaje para que puedan embarcar antes — eso es TTFT.

Este sistema de enrutamiento mejoró la tasa de acierto en caché en un 25%, la capacidad de procesamiento en un 30%, y redujo en un 30% la latencia P90 de las solicitudes largas.

En resumen, una misma GPU puede atender a más usuarios. La otra mitad del razonamiento del descuento es que, con más eficiencia, se obtiene más producción por unidad de potencia, y menor coste por usuario.

Sexta ingeniería: acelerar la "escritura" del modelo

Las cinco primeras optimizaciones mejoran la lectura — reducir el coste de leer el contexto histórico. La sexta optimización se centra en la "escritura" — acelerar la generación del siguiente token.

Los modelos tradicionales generan un token a la vez. MiMo soporta nativamente MTP (Predicción Multi-Token) en 3 capas — predice los próximos 3 tokens en una sola pasada, y si acierta, salta pasos intermedios.

Por ejemplo, en escritura, en lugar de teclear una palabra a la vez, es como tener un autocompletado que adivina los próximos 1-2 caracteres — si acierta, no tienes que teclear más.

En escenarios agentic, las pruebas muestran que, al decodificar los primeros 128 tokens, la velocidad aumenta 2.3 veces; entre 128 y 256 tokens, 1.5 veces.

Esto es importante porque el descuento del 99% se aplica principalmente a Input (Cache Hit), pero en la práctica, la entrada y la salida ocurren en la misma solicitud. Si no se reduce la salida, solo se ahorra la mitad del coste total. MTP permite reducir también la generación, cerrando así el ciclo de beneficios del descuento.

Resumiendo las seis ingenierías en una cadena de reducción de costes:

Arquitectura SWA → KVCache a 1/7 → doble pool con capacidad real liberada → más de 5 veces más usuarios en la misma GPU → tasa de acierto de prefijos 93-95% → 95% de solicitudes sin cálculo → GCache sin coste de almacenamiento → enrutamiento prioritario a solicitudes cacheadas → MTP acelerando generación → reducción de tiempo por solicitud en un orden de magnitud → coste por usuario disminuye más del 95% → precios bajan un 99%, con margen positivo.

Cualquier paso que falte rompe la cadena. La bajada del 99% no es solo marketing, sino el resultado acumulado de seis pilares técnicos y validaciones en producción.

Revisando las interpretaciones iniciales en la industria, cada una tiene parte de verdad. La guerra de precios en China en estos años es real; Xiaomi realmente ha reducido beneficios y apuesta por IA; DeepSeek efectivamente ha llevado los precios a mínimos.

Pero la publicación técnica de Luo Fulili, con detalles y análisis, sin duda busca contrarrestar esas interpretaciones, diferenciando claramente "problemas técnicos" de "estrategias de marketing".

En su blog, ella afirma que la eficiencia del modelo MiMo-V2.5 no proviene de un solo avance, sino de una optimización multidimensional. El híbrido SWA permite beneficiarse tanto en prefill como en decode, pero una implementación no optimizada de KVCache puede aumentar los costes en todos los frentes. La reconstrucción sistemática del equipo de MiMo en la gestión de KVCache, caché jerárquica, árbol de caché de prefijos, resolución de problemas clave de SWA KVCache, optimización de la estrategia de enrutamiento y de las cadenas de prefill/decode, ha sido validada en escenarios reales, logrando que la eficiencia teórica se refleje en producción. Solo así, Hybrid SWA puede desplegar su potencial en razonamiento de textos largos, combinándose con configuraciones MoE y optimizaciones multimodales, para mejorar significativamente el rendimiento del servicio en línea.

Se trata de un enfoque sistemático en ingeniería de IA, que puede servir de referencia para toda la industria.

La guerra de precios no necesita blogs, sino resultados técnicos concretos.