Xiaomi MiMo: anatomía de un pipeline de razonamiento, de 7B a 1T

Una lectura técnica del preentrenamiento, el enrutamiento MoE, la destilación y la memoria de agentes.

Hay una razón para mirar de cerca Xiaomi MiMo más allá de las cifras de parámetros: el equipo publica modelos recientes y el trabajo técnico que los acompaña. Para Kuaapy, esta apertura tiene un valor propio. Poder estudiar un modelo, adaptar su ejecución y confrontar resultados amplía quién puede participar en el desarrollo de la IA.

La generación V2.6 forma parte de esa elección. El anuncio oficial presenta la apertura de la serie, del informe técnico, de los entornos de entrenamiento y del código de RL; las fichas públicas permiten acceder a los checkpoints. Esta combinación crea oportunidades de investigación más allá del servicio alojado de la empresa. Lanzamiento de V2.6 [1], modelos oficiales [2].

Un agente puede acertar la respuesta y desperdiciar decenas de llamadas hasta llegar a ella. Puede generar código correcto y perder la restricción que debería orientar el siguiente cambio. Puede tener un contexto enorme y seguir administrando mal el estado de la tarea.

Para analizar un sistema así, debemos seguir tres capas: los pesos que definen la política del modelo, la infraestructura que entrena y ejecuta esa política y el runtime que organiza las herramientas y la continuidad. La trayectoria pública de MiMo permite examinar las tres.

Este análisis utiliza fuentes primarias consultadas el 23 de octubre de 2026. Las métricas atribuidas a Xiaomi son resultados publicados por los autores; no representan una reproducción independiente de Kuaapy.

1. El razonamiento empieza antes del RL

El informe de MiMo-7B describe la optimización conjunta del preentrenamiento y el postentrenamiento. La base recibió aproximadamente 25 billones de tokens, una mezcla de datos en tres etapas y un objetivo auxiliar de Multi-Token Prediction, o MTP. La preparación de datos incluye contenido matemático, código y razonamiento sintético.

En el postentrenamiento, los autores utilizan SFT y aprendizaje por refuerzo con unos 130.000 problemas verificables de matemáticas y programación. La recompensa del código considera la dificultad de las pruebas; el remuestreo busca estabilizar el entrenamiento. Esto es más específico que afirmar que el modelo recibió una recompensa genérica por cada paso de razonamiento.

La conclusión adecuada es que los datos, los objetivos de preentrenamiento y el postentrenamiento contribuyen en etapas diferentes. El paper no sostiene que el razonamiento sea exclusivamente producto del RL. Tampoco un resultado final correcto, aislado, permite distinguir generalización de memorización. Esa distinción exige un diseño de evaluación propio. Informe MiMo-7B [3].

2. La escala total y el cómputo activo son cifras diferentes

MiMo-V2-Flash combina 309 mil millones de parámetros totales con 15 mil millones activos por token. Su informe describe atención local con una ventana de 128 tokens intercalada con atención global, en una proporción 5:1. El contexto de preentrenamiento de 32K se amplió a 256K. Informe V2-Flash [4].

En las fichas oficiales de la generación V2.6, la separación es esta:

V2.6-Pro-RL — Parámetros totales: 1,02 billones; Activos por token: 42 mil millones; Expertos enrutados / activados: 384 / 8; Contexto declarado: 1 millón

V2.6-Flash-RL — Parámetros totales: 309 mil millones; Activos por token: 15 mil millones; Expertos enrutados / activados: 256 / 8; Contexto declarado: 1 millón

Ambos reciben texto, imagen, vídeo y audio. Son modelos distintos, no solo dos configuraciones de velocidad del mismo checkpoint. Pro [5], Flash [6].

MoE reduce el conjunto de expertos utilizado en cada token. Eso no hace que el modelo completo quepa en la memoria correspondiente a los parámetros activos. Como cálculo ilustrativo, un billón de parámetros a un byte por parámetro ya representa aproximadamente un terabyte, antes de escalas de cuantización, cachés y buffers. La distribución, el offload y la transferencia de pesos siguen siendo cuestiones de arquitectura.

Del mismo modo, el contexto máximo declarado no informa por sí solo de la latencia, el coste o la calidad de recuperación de una información distante.

3. Cuando el rollout y el entrenamiento eligen expertos diferentes

Durante el RL, un motor genera trayectorias y otro calcula actualizaciones. En un MoE, distintas decisiones de enrutamiento pueden hacer que esas etapas activen expertos diferentes para la misma secuencia. El problema aparece en la relación entre la política que produjo la muestra y la política utilizada para actualizarla.

Rollout Routing Replay, o R3, registra las selecciones de expertos durante el rollout y las vuelve a aplicar en el entrenamiento. La implementación mantiene el cálculo de las probabilidades del router durante el entrenamiento, conservando el camino del gradiente. El objetivo es reducir divergencias entre los motores sin descartar simplemente las muestras difíciles.

Los experimentos del paper incluyen Qwen3-30B-A3B; sus cifras no deben presentarse como mediciones de MiMo. El resultado relevante para esta discusión es el mecanismo: el comportamiento del router y la consistencia entre stacks participan en la estabilidad del RL. Paper de R3 [7].

4. MOPD integra expertos en las trayectorias del estudiante

Entrenar a un profesor de matemáticas y a otro de ingeniería de software no resuelve automáticamente cómo reunir sus habilidades. En MOPD se desarrollan profesores especializados por dominio. El estudiante produce sus propios rollouts y recibe supervisión del profesor correspondiente, con una señal densa por token.

Una de las formulaciones utiliza divergencia KL inversa entre las distribuciones del estudiante y del profesor en los contextos visitados por el estudiante. El objeto aprendido es una política conjunta; el procedimiento no consiste en concatenar respuestas ni en hacer una media simple de los pesos de los profesores.

El estudio compara la técnica con alternativas en Qwen3-30B-A3B e informa de una aplicación industrial en V2-Flash. La integración no significa ausencia de pérdidas: en la tabla de MiMo, algunos resultados quedan por debajo del profesor especialista. Evaluar la retención por dominio es más informativo que anunciar un estudiante superior en todo. Paper de MOPD [8].

5. Inferencia: MTP y la caché resuelven cuellos de botella distintos

En V2-Flash, los módulos MTP se reutilizan como borrador para la decodificación especulativa: proponen tokens cuya aceptación verifica el modelo principal. El informe publica una aceleración de decodificación de hasta 2,6 veces en la configuración evaluada. Esta cifra no es una promesa para cualquier lote, hardware o longitud de entrada. Informe V2-Flash [4].

HySparse, en cambio, investiga la atención y el almacenamiento de KV. Una capa de atención completa proporciona selección de tokens y caché a las capas dispersas siguientes. Así, la propuesta busca reducir el cómputo y la memoria, en lugar de ahorrar solo operaciones mientras mantiene cachés independientes.

El paper evalúa modelos densos de 7B y MoE de 80B; en el segundo informa de una reducción de KV cercana a diez veces. Son experimentos de esa arquitectura. HySparse no debe tratarse como sinónimo de la atención híbrida SWA/global de V2-Flash ni como un ahorro de memoria demostrado para todos los MiMo. Paper de HySparse [9].

Qué hay detrás de los mil tokens por segundo

El anuncio UltraSpeed de V2.5-Pro combina cuantización FP4 de los expertos con entrenamiento consciente de la cuantización, un borrador DFlash y kernels adaptados por TileRT. Los demás módulos conservan la precisión original. Xiaomi informa de más de mil tokens por segundo de decodificación en un nodo con ocho GPU.

Hay tres precauciones de lectura. Primero, la decodificación por sí sola no describe el prefill, la espera en cola ni la latencia total. Segundo, un nodo con ocho GPU no equivale a una máquina personal. Tercero, la aceptación de los tokens propuestos varía según la tarea; el propio artículo reconoce dificultades en conversaciones más divergentes.

El periodo de acceso anunciado era del 9 al 23 de junio de 2026. Ese anuncio histórico no demuestra la disponibilidad comercial actual. El interés técnico está en la combinación de representación de pesos, propuesta especulativa y ejecución de kernels. Anuncio técnico UltraSpeed [10].

6. El RL agéntico también depende de quién espera los recursos

Un rollout puede depender de la ejecución de código en CPU, la evaluación en GPU y servicios externos. Reservarlo todo para la trayectoria completa mantiene los recursos ocupados incluso cuando esa etapa no los utiliza.

ARL-Tangram propone orquestación a nivel de acción, con compartición y elasticidad de recursos externos. La métrica central incluye el tiempo para completar acciones, no solo el uso de la GPU de entrenamiento. Los autores informan de una mejora de hasta 4,3 veces en esa medida y de una aceleración de hasta 1,5 veces en los pasos de entrenamiento, en sus escenarios.

La ganancia de una acción no se convierte automáticamente en la misma ganancia del entrenamiento completo. Ese desajuste es precisamente una razón para medir todo el pipeline. Paper de ARL-Tangram [11].

7. Repetición de herramientas: medir el camino hasta la respuesta

Xiaomi documentó la repetición en V2.6. Para una medida reproducible, contó llamadas idénticas, con argumentos JSON canonicalizados, dentro de un turno antes de la respuesta de las herramientas. La tasa es (N − U) / N: llamadas totales menos únicas, dividido por el total.

Esta medida no captura bucles entre turnos, casi duplicados ni subllamadas ocultas en scripts. Tampoco confunde repetición con reintentos justificados.

Aplicar una penalización de volumen fue un intento con generalización limitada. La corrección final entrenó a un profesor de RL especializado e incorporó el comportamiento mediante MOPD. Acertar la tarea y evitar acciones redundantes debían entrar en el proceso de entrenamiento.

La empresa informa de una reducción de la repetición; eso no significa ausencia universal de bucles. Los checkpoints corregidos utilizan el sufijo MOPD, una distinción importante al reproducir una evaluación. Diagnóstico y corrección [12], Pro-MOPD [13], Flash-MOPD [14].

8. La memoria del agente es arquitectura de estado

En MiMo Code, la continuidad implica un writer separado, checkpoints estructurados y reconstrucción del contexto. Las memorias de sesión, proyecto y usuario tienen ciclos de vida distintos; el historial permite volver a los registros originales. El diseño también incluye selección de candidatos, verificación de finalización y workflows ejecutados en código.

Esto permite encadenar ventanas físicas limitadas en una sesión lógica más larga. No convierte la ventana del modelo en memoria infinita. La consolidación de registros y la creación de skills cambian el contexto y los procedimientos disponibles para el agente; no equivalen por sí mismas a actualizar los pesos.

Este es el punto técnico más útil para quienes construyen agentes: la continuidad exige decidir qué persistir, quién puede escribir y cómo recuperar el estado. Un resumen puede ayudar, pero debe formar parte de un contrato operativo. Arquitectura de MiMo Code [15].

9. Una familia abierta que va más allá del modelo principal

El conjunto de papers y proyectos muestra frentes complementarios:

MiMo-VL — Qué añade a la familia: Integra visión y lenguaje; ofrece checkpoints SFT y RL del modelo de 7B.; Material oficial: Repositorio MiMo-VL [16]

MiMo-Audio — Qué añade a la familia: Investiga la comprensión y generación de audio, incluido el aprendizaje con pocos ejemplos.; Material oficial: Repositorio MiMo-Audio [17]

MiMo-V2.5-ASR — Qué añade a la familia: Reconocimiento de voz con un enfoque documentado en mandarín, inglés, dialectos chinos y condiciones acústicas difíciles.; Material oficial: Repositorio MiMo-V2.5-ASR [18]

MiMo-V2.6 — Qué añade a la familia: Modelos Pro y Flash omnimodales, con pesos y documentación públicos.; Material oficial: Anuncio y materiales [1]

Este recorrido puede seguirse en las secciones de papers [19] y blog técnico [20]. La contribución está tanto en los modelos como en la posibilidad de examinar decisiones y problemas de ingeniería. Publicar una corrección y explicar el fallo que la motivó también produce conocimiento útil para quienes construyen otros sistemas.

El ejemplo de Distill-Qwen-9B

MiMo-V2.6-Distill-Qwen-9B hace especialmente concreta esta circulación de conocimiento. Según la ficha oficial, se desarrolló mediante SFT de Qwen3.5-9B con datos generados por MiMo, como punto de partida abierto para investigar el RL agéntico. La ficha declara licencia MIT.

Es un checkpoint de 9B con un origen técnico explícito. Esto permite investigar la transferencia de capacidades a otra escala sin confundirlo con una versión reducida automáticamente del MoE de 1,02T. Tampoco establece que los demás modelos MiMo tengan la misma base Qwen. Modelo y descripción del entrenamiento [21].

10. Voz: un frente que queremos escuchar en portugués

La familia MiMo-V2.5-TTS incluye síntesis con voces preparadas, creación de voz a partir de una descripción y clonación desde muestras. El control expresivo mediante instrucciones y marcas de audio permite trabajar ritmo, emoción y entonación. Es un frente interesante para agentes cuya interacción debe ir más allá del texto. Presentación de TTS [22].

Aquí queda un deseo nuestro: poder experimentar esta propuesta en portugués brasileño. En la documentación consultada, las voces preparadas están identificadas en chino e inglés; no encontramos soporte oficial documentado para portugués. Esperamos que nuestro idioma sea incluido, especialmente por lo que una voz expresiva puede añadir a la accesibilidad. Aún no hemos realizado una evaluación propia de la calidad sonora. Documentación de síntesis y voces [23].

El TTS se presenta en estos materiales como un servicio de API. Su disponibilidad no debe confundirse con la liberación de pesos de los demás modelos: la apertura debe identificarse en cada componente.

Qué necesitamos medir en un sistema real

Nuestra lectura es que una evaluación de agentes debe reunir resultado, trayectoria y continuidad. Además de las pruebas de la tarea, conviene registrar llamadas redundantes, consumo de contexto, tiempo sin avance, coste por tarea completada y fidelidad a las restricciones después de reconstruir el contexto.

Para reproducir una comparación, el registro debe identificar checkpoint y revisión, tokenizador y plantilla, precisión, motor de inferencia, hardware, parámetros de generación, harness y conjunto de tareas. Debe separar la evaluación de una ejecución aislada de las tareas con varias interacciones, incluidos los fallos y la dispersión de resultados.

Las fichas V2.6 consultadas declaran MIT. Esto no autoriza a atribuir una licencia única a todo el ecosistema: el repositorio GitHub de V2-Flash, por ejemplo, presenta Apache-2.0. Es necesario identificar el artefacto citado. Ficha Pro-MOPD [13], repositorio V2-Flash [24].

En Kuaapy, esta investigación se conecta con la experiencia de quienes dependen de un agente para terminar una tarea: cuántas decisiones hay que repetir, cuántas correcciones son necesarias y cuánto esfuerzo humano queda después de la supuesta automatización. Son preguntas de ingeniería y accesibilidad que pueden orientar experimentos sin anticipar sus resultados.

Por eso la apertura de los modelos es una parte central del valor que reconocemos en Xiaomi MiMo. Disponer de pesos, documentación y referencias amplía el espacio para examinar y desarrollar tecnología, incluso fuera de los grandes laboratorios. Esta es también una dirección que consideramos para los modelos que podamos desarrollar en Kuaapy. Los formatos y las condiciones de una eventual publicación aún no están definidos.

Conoce Xiaomi MiMo en las fuentes oficiales

Para seguir el trabajo del equipo, consultar los modelos y explorar los materiales originales:

• Sitio oficial de Xiaomi MiMo [25] — novedades, investigación y productos.

• Xiaomi MiMo en Hugging Face [2] — modelos, fichas técnicas y colecciones publicadas por el equipo.

• Xiaomi MiMo en GitHub [26] — repositorios oficiales de los proyectos.

• MiMo Code [27] — página oficial del agente de programación.

• Papers del equipo [19] y blog técnico [20] — índices para seguir la investigación.

• Familia MiMo-V2.5-TTS [22] y documentación de síntesis de voz [23].

Papers y documentación técnica de este artículo

• MiMo-7B: del preentrenamiento al postentrenamiento [28].

• MiMo-V2-Flash — informe técnico [4].

• Rollout Routing Replay — alineación de routers [29].

• MOPD — destilación on-policy con varios profesores [30].

• HySparse — atención dispersa y compartición de KV [9].

• ARL-Tangram — infraestructura para RL agéntico [11].

• MiMo Code — arquitectura para tareas de horizonte largo [15].

• Diagnóstico y corrección de llamadas repetidas [12].

• UltraSpeed — codesign con TileRT [10].

Modelos citados y checkpoints corregidos

• MiMo-V2.6-Pro-RL [5].

• MiMo-V2.6-Flash-RL [6].

• MiMo-V2.6-Pro-MOPD [13].

• MiMo-V2.6-Flash-MOPD [14].

• Repositorio oficial de MiMo-V2-Flash [24].

• MiMo-V2.6-Distill-Qwen-9B [21].

• MiMo-VL [16], MiMo-Audio [17] y MiMo-V2.5-ASR [18].