MiMo-V2.6: Lo que el artículo de RL de Xiaomi realmente muestra y lo que deja sin verificar

La mayoría de los artículos sobre modelos publicados este mes son artículos de arquitectura. El informe técnico detrás de Xiaomi MiMo-V2.6-Pro y Xiaomi MiMo-V2.6-Flash no lo es. Titulado MiMo-V2.6: Escalando el aprendizaje por refuerzo hacia la automejora, presentado el 21 de septiembre de 2026 y atribuido a LLM-Core Xiaomi, no dedica casi nada de su extensión al backbone de mezcla dispersa de expertos y casi todo a una sola pregunta: qué ocurre cuando todo el presupuesto de postentrenamiento se destina a una única ejecución mixta de aprendizaje por refuerzo. El informe de DeepSeek-V4.1-Flash, en cambio, es un documento sobre memoria: su extensión se dedica a la atención dispersa comprimida, la reutilización de KV entre capas y el almacenamiento FP4. Si se ponen los dos uno al lado del otro, son argumentos sobre de dónde viene la capacidad, y no coinciden.

Vale la pena leer el informe en sus propios términos, pero merece una lectura cuidadosa, porque es un autoinforme del laboratorio que realizó la ejecución. Nombra sus mecanismos, muestra sus ablaciones, publica sus fallos y, en la misma respiración, informa cifras que no pueden comprobarse desde fuera. Separar esas dos cosas es la mayor parte del trabajo. Este texto lo hace, y está escrito el 23 de septiembre de 2026 —dos días después de que se subieran los checkpoints, cuando el artículo es lo más nuevo y menos corroborado que existe sobre ellos.

Por qué la fecha en el papel importa más de lo habitual

Los checkpoints MiMo-V2.6-Pro y MiMo-V2.6-Flash de Xiaomi llegaron al hub de modelos el 21 de septiembre de 2026, con licencia MIT y sin restricciones de acceso. El informe está fechado el mismo día y alcanzó el primer puesto de la lista de tendencias en el sitio de preprints donde se publicó. Ese momento es la razón por la que esto es una noticia y no una retrospectiva: el artículo no es una explicación posterior de un modelo que todo el mundo ya ha evaluado con benchmarks. Llega junto con los pesos, antes de que alguien fuera de Xiaomi haya publicado una ejecución independiente.

Ese orden también es la principal debilidad del artículo como evidencia. Todo lo que se deriva de ello —la curva de DeepSWE, las mejoras en la tasa de aprobación, la defensa contra el reward hacking— es una afirmación sobre un proceso de entrenamiento que ocurrió una vez, dentro de un laboratorio, en un clúster, y que nadie más ha reproducido. El hilo que señaló el informe considera que esa es la parte interesante: este es un artículo de datos y experimentos, no un artículo de arquitectura, y los experimentos son exactamente el tipo de resultado que o se replica o no.

Tres ejes de escalado, y solo uno de ellos es un problema de hardware

El planteamiento del informe es que el cómputo del aprendizaje por refuerzo se escaló a lo largo de tres ejes a la vez, y el tercero es el que cambia la forma en que uno piensa sobre el método.

• Lote y rendimiento — 1.568 muestras por actualización, expandidas a dieciséis rollouts cada una, de modo que se generan aproximadamente 25.000 trayectorias por paso, que consumen entre 2,7 y 3,7 mil millones de tokens por paso con longitudes de contexto de hasta un millón de tokens. La arquitectura de rollouts es totalmente asíncrona, que es lo que hace que ese tamaño de lote sea siquiera viable.

• Entornos: una única ejecución mixta que abarca tareas de código, de agente general, visuales y de ciberseguridad, bajo varios arneses de agentes a la vez, en lugar de ejecuciones de RL separadas por dominio. El propio término abreviado de Xiaomi para esto es "You Only RL Once". El argumento a favor de mezclar es que las mejoras en una capacidad refuerzan las demás; el riesgo es que un tipo de tarea lento se quede sin recursos, algo que, según el informe, se gestiona con planificación adaptativa.

• Cómputo del evaluador — el eje que no se trata de GPU en el sentido habitual. El aprobado/fallo binario no puede clasificar dos soluciones que ambas aprueban, así que la propia señal de recompensa se convierte en lo que escalas. Un evaluador agéntico compara conjuntamente los dieciséis intentos de una tarea y produce una señal graduada en lugar de un bit.

Ese tercer eje es donde la frase «automejora» del título se gana su lugar, y donde el informe está más expuesto. Un modelo que califica sus propias trayectorias es una superficie de manipulación de recompensas, y el informe lo trata como tal.

Los dos mecanismos que realmente vale la pena entender

Redistribución de ventajas por grupos

Después de cada paso, la política produce dieciséis intentos por tarea y todos ellos se colocan en un espacio de trabajo compartido para que un modelo evaluador pueda examinarlos juntos en lugar de uno a la vez. Luego, los parches que pasan se puntúan según cinco ejes: si el enfoque se ajusta al problema, si la implementación es precisa sin mecanismos de reserva innecesarios, si el cambio es mínimo, si modifica algo fuera del alcance y si coincide con el estilo del código circundante. Los parches aprobados con menor clasificación reciben menos refuerzo positivo. Un parche confirmado como hack se restablece a cero y se trata como un fallo.

La consecuencia es una señal de entrenamiento que empuja hacia soluciones más cortas y baratas en lugar de meramente correctas; el informe lo describe como orientar hacia menos tokens por tarea. Esa es la parte que hay que retener, porque los resultados principales que aparecen más adelante en el artículo apuntan en la dirección opuesta.

Síntesis de recompensa por grupo

La mitad offline de la misma idea. En lugar de derivar la calidad puramente de un evaluador en vivo, el equipo precalcula rúbricas específicas para cada tarea y multiplica la recompensa binaria de la prueba por puntuaciones de calidad y comportamiento extraídas de esas rúbricas. El informe describe esto como construir las rúbricas a partir de rollouts contrastantes —es decir, de casos en los que el resultado difirió, que es donde está la información.

La evaluación no sale gratis. El informe sitúa el costo de los evaluadores en aproximadamente el 12,7 % del costo total de aprendizaje por refuerzo de MiMo-V2.6-Pro. Esa única cifra es lo más útil del artículo para cualquiera que se plantee copiar el método, porque convierte «escala tus evaluadores» de una idea en una partida presupuestaria.

El router congelado es el resultado que la mayoría de los equipos copiará primero.

La sección de estabilidad del informe contiene un hallazgo que se sostiene por sí solo, independientemente de MiMo-V2.6 y de lo bien que se desempeñe el modelo.

Con enrutadores de mezcla de expertos entrenables, la carga de los expertos se desvió gravemente a lo largo de veinte pasos. El coeficiente de variación entre expertos aumentó de 0,78 a 2,0. La carga máxima en el experto más ocupado pasó de seis veces el promedio a dieciséis veces. La proporción de expertos fríos —aquellos que reciben casi nada de tráfico— pasó de 0,5% a 22%. Restaurar los pesos del enrutador a sus valores iniciales en el paso 20 recuperó el equilibrio de inmediato.

La respuesta de Xiaomi fue congelar el enrutador MoE durante la ejecución. El razonamiento no es sutil: a esta escala de lote, la inestabilidad del enrutamiento es un problema de dinámica de entrenamiento que sencillamente puedes optar por no tener, y el enrutador no es donde el aprendizaje por refuerzo está haciendo su trabajo. Que congelarlo cueste algo en la calidad final no queda respondido por una ablación en el material publicado, y es razonable querer saberlo.

Lo que el hallazgo no dice es nada acerca del serving. El equilibrio de carga del router durante una ejecución de entrenamiento y la utilización de expertos bajo tráfico de producción son cuestiones distintas, y el informe solo aborda la primera.

Los números, con sus etiquetas adjuntas

Los resultados principales del informe son limpios en su forma y desordenados en su detalle, y ese desorden no es un escándalo: son tres mediciones distintas de tres objetos distintos que comparten un nombre.

• DeepSWE v1.1, en reserva — MiMo-V2.6-Pro subió de 58.4 a 72.6 a lo largo de la ejecución; MiMo-V2.6-Flash, de 48.7 a 65.7. El benchmark consta de 113 tareas de ingeniería de repositorios de horizonte largo evaluadas por verificadores funcionales en cinco lenguajes de programación, y la métrica es average@3 — la tasa media de aprobación del verificador en tres intentos muestreados, que no es lo mismo que si uno cualquiera de los tres intentos tuvo éxito. Interpretar avg@3 como pass@3 exagerará cada número de la página.

• La misma prueba comparativa, medida en otro lugar — las tarjetas de modelo publicadas indican 71.9 para Pro y 67.9 para Flash. El panel de entrenamiento público de Xiaomi mostró 72.57 y 65.68. Así que hay tres cifras publicadas por modelo, dos de ellas de Xiaomi, y la dirección de la discrepancia es diferente para cada hermano. Ninguna de ellas es incorrecta; describen una instantánea del panel, una entrada de tarjeta y una línea de informe, en momentos diferentes y posiblemente bajo arneses diferentes.

• Destilación — MiMo-V2.6-Distill-Qwen-9B, ajustado a partir de Qwen3.5-9B sobre demostraciones generadas por MiMo, movió SWE-bench Verified de 61.1 a 66.2. Este es el número más transferible en el artículo, porque un estudiante de 9B es un tamaño que la mayoría de los equipos puede realmente ejecutar.

• Un mini-benchmark interno de ciberseguridad — 31.3 a 47.0. Interno significa interno: las tareas no están publicadas, así que el delta no se puede reproducir ni siquiera en principio.

• El Artificial Analysis Intelligence Index — 46 para MiMo-V2.6-Pro. Este es distinto en esencia. Fue producido por Artificial Analysis ejecutando su propio harness contra el checkpoint publicado, no por Xiaomi, lo que lo convierte en la única cifra destacada de este lanzamiento que un lector puede considerar medida en lugar de reportada. También es el número con el que hay que comparar frente a GLM-5.3, Kimi K3 y la frontera de modelos cerrados, y se sitúa cinco puntos por debajo de Claude Opus 5.

El informe es honesto sobre los límites de su propia tabla, y esta es la frase que vale la pena citar de vuelta a cualquiera que no lo sea: las comparaciones mezclan benchmarks públicos e internos y no aíslan la contribución del aprendizaje por refuerzo de la arquitectura o del preentrenamiento. Un modelo que es mejor después del RL no es prueba de que el RL sea la razón.

Hay una segunda salvedad, y es la que va en contra del encuadre. Las ganancias reportadas generalmente acompañan un aumento en el uso de tokens. El informe lo presenta como una mejora sostenida de la capacidad y no como eficiencia, y hace bien. Pero GAR se diseñó explícitamente para orientar hacia rutas más cortas y menos tokens por tarea, y el resultado agregado no muestra que la carga de trabajo se esté abaratando. La capacidad aumentó; el costo por tarea no bajó. Si interpretas "automejora" como "el modelo necesitará menos de mi dinero el próximo trimestre", el artículo no respalda esa lectura.

Lo que el informe deja sin verificar

A 23 de septiembre de 2026, ningún tercero ha publicado una repetición independiente de las columnas DeepSWE, Terminal Bench o CyberGym. La distinción que importa es entre el punto del índice y todo lo demás: 46 es una medición que hizo alguien más, y 72.6 es una afirmación sobre una ejecución de entrenamiento que nadie puede volver a ejecutar, porque la ejecución costó, según se informa, $2.6 millones para Pro y $0.9 millones para Flash, y no va a ocurrir dos veces.

Lo que Xiaomi sí publicó, y que la mayoría de los laboratorios no, son las dinámicas de entrenamiento, el marco de aprendizaje por refuerzo y los entornos de tareas —más de 7.000 entornos calificados en ingeniería de software, reproducción de vulnerabilidades, trabajo de conocimiento y diseño web—. Ese es el artefacto con la vida útil más larga. Los pesos te dicen qué produjo la ejecución; los entornos te dicen cómo ejecutar el experimento tú mismo, que es la única forma en que alguna vez se resuelvan las afirmaciones de RL.

La defensa contra el reward hacking merece una salvedad específica. Se describe como multicapa —diseño de recompensas, evaluación adversarial, detección de anomalías y verificación cruzada entre verificadores—, y la describe enteramente la parte a la que le avergonzaría que fallara. Una defensa contra un modelo que engaña a un evaluador basado en modelos no es el tipo de cosa que un autoinforme pueda dar por zanjada. Se nombra el mecanismo y se reconoce el modo de fallo, lo que es más de lo que hacen la mayoría de los artículos, y sigue siendo una cuestión abierta.

Lo que realmente puedes hacer con esto hoy

Ambos checkpoints son descargables, sin restricciones de acceso, bajo una etiqueta de licencia MIT: Xiaomi MiMo-V2.6-Pro-RL y Xiaomi MiMo-V2.6-Flash-RL, omnimodales, con contexto de un millón de tokens, y el índice Flash reporta 172,9 GB de datos de pesos en 65 fragmentos en FP8. Xiaomi no ha publicado una tabla de precios por token para la generación V2.6, así que la elección hoy es el autoalojamiento frente a un modelo alojado que ya pagas.

Esa comparación es donde reside el valor real del artículo, y es poco halagadora para el artículo de una manera útil. La afirmación que se pone a prueba no es "¿es bueno MiMo-V2.6-Pro?" — eso lo responden las 46 respuestas. Es "¿produce el aprendizaje por refuerzo sobre tareas agénticas mixtas un razonamiento que se transfiera a mi carga de trabajo?", y la única forma honesta de responder eso es ejecutar ambos y comparar, lo cual es un problema de enrutamiento antes que un problema de investigación. DeepSeek-V4.1-Flash está a una clave de API de distancia, a $0.15 y $0.60 por millón de tokens, Qwen3.8-Flash y GLM-5.3-Flash están en la misma clave, y si quieres poner un checkpoint de MiMo autoalojado detrás del mismo endpoint durante una semana y ver si la curva de DeepSWE aparece en tus propias evaluaciones, eso es un cambio de configuración y no una migración. OrcaRouter no aloja los modelos de Xiaomi, y nada de lo que aquí se dice debe interpretarse como que afirma lo contrario, pero los modelos contra los que los compararías son todos accesibles mediante una sola clave de API de OrcaRouter al precio de lista del proveedor, con un 0 % de margen repercutido, con conmutación por error automática si un checkpoint que estás probando resulta ser inestable bajo carga.

El caso del modelo no comprobado es aquel para el que se diseñó la conmutación por error. Un checkpoint publicado hace dos días, con una evaluación realizada por el proveedor y sin una reejecución independiente, es exactamente lo que quieres probar sin poner una ruta de producción detrás de él.

¿Quién debería leer el artículo?

Si haces post-entrenamiento, léelo por el hallazgo del enrutador y la cifra del coste del evaluador. Ambos son portables, ambos son baratos de probar, y ninguno depende de creer nada sobre la tabla de benchmarks de MiMo-V2.6. El resultado del enrutador congelado, en particular, es el tipo de cosa que cuesta una tarde probar y ahorra una ejecución.

Si estás eligiendo un modelo, lee el punto del índice y omite el resto. Artificial Analysis midió 46 en el artefacto publicado; ese es el único número de esta publicación que no provino del proveedor, y coloca a MiMo-V2.6-Pro en la cima del campo de pesos abiertos y cinco puntos por detrás de Claude Opus 5. Todo lo demás en el informe describe cómo llegó Xiaomi allí, y cómo llegó Xiaomi allí no es algo que se pueda comprar.

Y si estás leyendo la cobertura en lugar del artículo, lo que hay que observar es la palabra «automejora». Los propios resultados del informe muestran que la capacidad aumenta a la par que el uso de tokens, lo cual es un hallazgo real y repetible sobre el escalado del aprendizaje por refuerzo. No es una afirmación de que el modelo se haya vuelto más barato de ejecutar, y los artículos que siguen a este son los que te dirán si con el tiempo llega a serlo.