El 27 de septiembre, el equipo de MiMo de Xiaomi publicó una entrada técnica en su blog en la que analiza un problema del que los desarrolladores se quejaban repetidamente desde el lanzamiento de MiMo-V2.6: en agentes de programación, el modelo emitía una y otra vez llamadas a herramientas idénticas o casi idénticas, consumiendo contexto y capacidad de cómputo sin que la tarea avanzara. Los pesos corregidos ya se han publicado en abierto, con nombres de archivo que incluyen el sufijo MOPD; la plataforma de API ya utilizaba la nueva versión desde las 6:00 del 25 de septiembre (hora de Pekín), y a los usuarios de MiMo Desktop se les restableció por completo la cuota restante del periodo, a modo de compensación.
Separar "demasiadas llamadas" de "llamadas repetidas"
El blog no trata todo exceso de llamadas como un problema. Xiaomi distingue tres situaciones: las llamadas paralelas son una optimización normal, en la que varias llamadas consultan cada una información distinta; la proliferación de llamadas ocurre cuando la cantidad supera lo que la tarea realmente necesita; y la repetición de llamadas se da cuando ni el estado del entorno ni la información ya conocida han cambiado, pero el modelo repite la misma acción de todos modos. El equipo se propuso corregir únicamente este tercer caso.
Según la evaluación interna de Xiaomi, la tasa de repetición a nivel de respuesta superó el umbral de tolerancia del 0,05%, con diferencias notables entre entornos:
| Entorno | Flash | Pro |
|---|---|---|
| OpenCode | 1,02% | 0,54% |
| Claude Code | 0,27% | 0,10% |
| MiMo Desktop | 0,19% | 0,19% |
| MiMo Code | 0,11% | 0,07% |
Los peores números correspondieron a la versión Flash en OpenCode, donde aproximadamente 1 de cada 100 respuestas quedaba atrapada en bucle.
La raíz del problema está en la fase de aprendizaje por refuerzo
El equipo revisó los distintos puntos de control del entrenamiento de aprendizaje por refuerzo y descubrió que la proporción de muestras con más de diez llamadas en una sola ronda subió del 11,1% en el paso 0 al 24,6% en el paso 20; en el entorno MiMo Code el aumento fue aún más pronunciado, del 30,6% al 41,7%. El entrenamiento originalmente solo aplicaba una penalización cuando una ronda superaba las 32 llamadas. A partir del paso 15, el número de muestras que activaban esa penalización aumentó de forma notable, lo que indica que el umbral de 32 era demasiado laxo y no impidió que el modelo adquiriera el hábito de que "unas cuantas llamadas más nunca hacen daño".
El blog ofrece una cifra muy elocuente: antes de la corrección, la probabilidad de que el modelo optara por seguir llamando en la duodécima llamada de una ronda era del 94,56%, frente a solo un 5,43% de probabilidad de detenerse. Dicho de forma sencilla, prácticamente nunca se detenía por sí solo.
Dos soluciones, con una diferencia de un orden de magnitud
La opción más directa era bajar el umbral de penalización de 32 a 8 y reentrenar con el flujo MixRL original. En pruebas internas, la tasa de repetición bajó del 13,45% al 3,83%, pero habría requerido retroceder 20 pasos de entrenamiento y volver a empezar; Xiaomi estimó el coste en unos 2,31 millones de dólares, y con otro conjunto de datos el resultado podría no ser estable.
La solución finalmente adoptada fue MOPD, destilación en línea con múltiples maestros. El método consistió en usar las muestras repetidas recopiladas internamente para entrenar por separado un "maestro" de aprendizaje por refuerzo especializado en aprender "cuándo hay que parar", ejecutando solo 12 pasos con unos 7.000 ejemplos; después se retrocedió el modelo principal 5 pasos y se continuó entrenando bajo la guía de ese maestro. El proceso completo costó unos 90.000 dólares, alrededor del 4% de la primera opción.
En cuanto a resultados, la probabilidad de detenerse en la duodécima llamada subió del 5,43% al 92,17%. Según la curva acumulada de parada que muestra el blog, antes de la corrección el modelo no superaba el 50% de probabilidad de detenerse hasta la llamada número 59; después de la corrección, ya en la octava llamada esa probabilidad alcanza el 99,87%. Xiaomi afirma que la tasa de repetición bajó drásticamente en todas las plataformas, que el comportamiento se mantuvo consistente con distintas longitudes de contexto, y que las puntuaciones generales de los benchmarks no se resintieron.
En el contexto de la línea V2.6
MiMo-V2.6 se lanzó y se publicó en abierto el 22 de septiembre, momento en el que Xiaomi hizo especial hincapié en la escala del posentrenamiento: según cifras reveladas por los medios, las versiones Pro y Flash pasaron cada una por 30 pasos de aprendizaje por refuerzo, con un coste total de unos 3,5 millones de dólares. Cinco días después, este análisis expone un efecto secundario de aquella ronda de entrenamiento, e incluso detalla que la corrección podría haber costado 2,31 millones de dólares adicionales.
No es habitual que los equipos de modelos chinos publiquen análisis de incidentes tras un lanzamiento, y es todavía más raro que enumeren también el coste de las soluciones fallidas. Para los desarrolladores que usan modelos nacionales chinos en OpenCode o Claude Code, el dato práctico es este: quien en los últimos días haya visto a MiMo leer una y otra vez el mismo archivo o ejecutar el mismo comando repetidamente ya está usando, vía API, la versión corregida; quien lo aloja por su cuenta debe cambiar a los pesos con el sufijo MOPD. Todas estas cifras de tasa de repetición proceden de la evaluación interna de Xiaomi, y por ahora no existen resultados de verificación independiente por parte de terceros.
Fuentes: blog técnico del equipo MiMo de Xiaomi, CocoLoop; las tasas de repetición y proliferación por entorno, así como los costes de ambas soluciones, se basan en la evaluación interna de Xiaomi.