Le 27 septembre, l'équipe MiMo de Xiaomi a publié un billet technique revenant sur un défaut dont les développeurs se plaignaient depuis le lancement de MiMo-V2.6 : dans les agents de codage, le modèle émettait à répétition des appels d'outils identiques ou quasi identiques, consommant contexte et puissance de calcul sans faire avancer la tâche. Les poids corrigés sont désormais open source, avec des noms de fichiers portant le suffixe MOPD ; la plateforme API utilisait déjà la nouvelle version depuis 6 heures du matin le 25 septembre (heure de Pékin), et les utilisateurs de MiMo Desktop ont vu la totalité de leur quota restant pour la période réinitialisée, en guise de compensation.
D'abord séparer "trop d'appels" et "appels répétés"
Le billet ne considère pas tout excès d'appels comme un problème. Xiaomi distingue trois cas : les appels parallèles relèvent d'une optimisation normale, plusieurs appels interrogeant chacun des informations différentes ; la prolifération d'appels désigne un nombre d'appels supérieur à ce que la tâche exige réellement ; la répétition d'appels, elle, survient quand ni l'état de l'environnement ni les informations déjà connues n'ont changé, mais que le modèle répète malgré tout la même action. L'équipe ne s'est attaquée qu'à ce troisième cas.
Selon l'évaluation interne de Xiaomi, le taux de répétition au niveau des réponses dépassait le seuil de tolérance de 0,05 %, avec des écarts importants selon les environnements :
| Environnement | 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 % |
Les chiffres les plus mauvais viennent de la version Flash sur OpenCode, où environ 1 réponse sur 100 tournait en boucle.
La cause profonde se situe dans la phase d'apprentissage par renforcement
L'équipe a rejoué les différents points de contrôle de l'entraînement par apprentissage par renforcement et a constaté que la part d'échantillons comportant plus de dix appels en un seul tour est passée de 11,1 % à l'étape 0 à 24,6 % à l'étape 20 ; dans l'environnement MiMo Code, la hausse était encore plus marquée, de 30,6 % à 41,7 %. L'entraînement prévoyait initialement une pénalité uniquement au-delà de 32 appels par tour. À partir de l'étape 15, le nombre d'échantillons déclenchant cette pénalité a nettement augmenté, signe que le seuil de 32 était trop permissif et n'a pas empêché le modèle de prendre l'habitude que "quelques appels de plus ne font jamais de mal".
Le billet donne un chiffre très parlant : avant la correction, la probabilité que le modèle choisisse de continuer à appeler un outil au 12e appel d'un tour était de 94,56 %, contre seulement 5,43 % de probabilité de s'arrêter. En clair, il ne s'arrêtait quasiment jamais de lui-même.
Deux solutions, un ordre de grandeur d'écart
La première option, la plus directe, consistait à abaisser le seuil de pénalité de 32 à 8 et à réentraîner avec le pipeline MixRL existant. Dans les tests internes, le taux de répétition est tombé de 13,45 % à 3,83 %, mais cela impliquait de revenir 20 étapes d'entraînement en arrière et de tout reprendre ; Xiaomi a estimé le coût à environ 2,31 millions de dollars, avec un résultat qui pourrait devenir instable avec un autre jeu de données.
La solution finalement retenue est MOPD, une distillation en ligne à plusieurs enseignants. La méthode consiste à utiliser les échantillons répétitifs collectés en interne pour entraîner séparément un "enseignant" d'apprentissage par renforcement spécialisé dans l'apprentissage du "moment où il faut s'arrêter", sur seulement 12 étapes avec environ 7 000 exemples ; le modèle principal est ensuite ramené 5 étapes en arrière et poursuit son entraînement guidé par cet enseignant. L'ensemble du processus a coûté environ 90 000 dollars, soit environ 4 % de la première option.
Côté résultats, la probabilité de s'arrêter au 12e appel est passée de 5,43 % à 92,17 %. Selon la courbe d'arrêt cumulée présentée dans le billet, avant la correction, il fallait attendre le 59e appel pour que la probabilité que le modèle s'arrête dépasse 50 % ; après la correction, dès le 8e appel, cette probabilité atteint déjà 99,87 %. Xiaomi affirme que le taux de répétition a fortement baissé sur toutes les plateformes, que le comportement reste cohérent quelle que soit la longueur du contexte, et que les scores globaux des benchmarks n'ont pas reculé.
Remis dans le contexte de la lignée V2.6
MiMo-V2.6 a été lancé et rendu open source le 22 septembre ; Xiaomi avait alors surtout mis en avant l'ampleur du post-entraînement : selon des chiffres révélés par la presse, les versions Pro et Flash ont chacune suivi 30 étapes d'apprentissage par renforcement, pour un coût total d'environ 3,5 millions de dollars. Cinq jours plus tard, cette analyse revient sur un effet secondaire laissé par cette phase d'entraînement, allant jusqu'à préciser qu'une correction aurait pu coûter 2,31 millions de dollars supplémentaires.
Il est rare que les équipes chinoises de modèles publient des analyses d'incidents après un lancement, et plus rare encore qu'elles détaillent aussi le coût des solutions qui ont échoué. Pour les développeurs qui utilisent des modèles chinois dans OpenCode ou Claude Code, l'aspect pratique est le suivant : ceux qui ont vu ces derniers jours MiMo relire sans cesse le même fichier ou relancer sans cesse la même commande utilisent déjà, via l'API, la version corrigée ; ceux qui l'hébergent eux-mêmes doivent basculer vers les poids portant le suffixe MOPD. Tous ces chiffres de taux de répétition proviennent de l'évaluation interne de Xiaomi, et aucun résultat de vérification indépendante par un tiers n'est disponible pour l'instant.
Sources : billet technique de l'équipe MiMo de Xiaomi, CocoLoop ; les taux de répétition et de prolifération par environnement, ainsi que les coûts des deux solutions, reposent sur l'évaluation interne de Xiaomi.