Das MiMo-Team von Xiaomi veröffentlichte am 27. September einen technischen Blogbeitrag, in dem es einen Fehler aufarbeitet, über den sich Entwickler seit dem Start von MiMo-V2.6 wiederholt beschwert hatten: In Coding-Agenten gab das Modell wieder und wieder identische oder nahezu identische Tool-Aufrufe aus, verbrannte dabei Kontext und Rechenleistung, ohne dass die Aufgabe vorankam. Die reparierten Gewichte sind bereits quelloffen verfügbar, die Dateinamen tragen das Suffix MOPD. Die API-Plattform lief bereits ab dem 25. September, 6 Uhr Pekinger Zeit, auf der neuen Version; MiMo-Desktop-Nutzern wurde als Ausgleich ihr verbleibendes Kontingent für den laufenden Zeitraum vollständig zurückgesetzt.
Erst "viele Aufrufe" von "wiederholten Aufrufen" trennen
Der Blogbeitrag behandelt nicht jede Häufung von Tool-Aufrufen als Problem. Xiaomi unterscheidet drei Fälle: Parallele Aufrufe sind eine normale Optimierung, bei der mehrere Aufrufe jeweils unterschiedliche Informationen abfragen; exzessive Aufrufe bedeuten mehr Aufrufe, als die Aufgabe eigentlich braucht; wiederholte Aufrufe liegen vor, wenn sich weder der Zustand der Umgebung noch der bekannte Informationsstand geändert haben und das Modell trotzdem dieselbe Aktion wiederholt. Behoben werden sollte ausschließlich der dritte Fall.
Nach Xiaomis interner Auswertung überschritt die Wiederholungsrate auf Antwortebene die Toleranzgrenze von 0,05 % deutlich, mit großen Unterschieden zwischen den Umgebungen:
| Umgebung | 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 % |
Am schlechtesten schnitt die Flash-Version in OpenCode ab: Dort drehte sich das Modell bei etwa jeder 100. Antwort im Kreis.
Die Wurzel liegt in der Reinforcement-Learning-Phase
Das Team spielte die einzelnen Checkpoints des Reinforcement-Learning-Trainings zurück und stellte fest, dass der Anteil der Antworten mit mehr als zehn Aufrufen pro Runde von 11,1 % bei Schritt 0 auf 24,6 % bei Schritt 20 anstieg; in der Umgebung MiMo Code fiel der Anstieg noch drastischer aus, von 30,6 % auf 41,7 %. Im Training war ursprünglich eine Strafe vorgesehen: Erst ab mehr als 32 Aufrufen pro Runde gab es einen Punktabzug. Ab Schritt 15 nahm die Zahl der Antworten, die diese Strafe auslösten, deutlich zu – ein Zeichen dafür, dass die Schwelle von 32 zu locker gesetzt war und das Modell nicht davon abhielt, sich anzugewöhnen, dass "ein paar Aufrufe mehr nie schaden".
Der Blogbeitrag liefert dazu eine anschauliche Zahl: Vor dem Fix lag die Wahrscheinlichkeit, dass das Modell beim zwölften Aufruf einer Runde noch einen weiteren Aufruf tätigte, bei 94,56 %, während es sich nur mit 5,43 % Wahrscheinlichkeit selbst stoppte. Grob gesagt: Es hörte praktisch nie von selbst auf.
Zwei Lösungswege, eine Größenordnung Unterschied
Der naheliegendste Weg: die Strafschwelle von 32 auf 8 senken und mit dem bestehenden MixRL-Prozess neu trainieren. In internen Tests sank die Wiederholungsrate dabei von 13,45 % auf 3,83 %, allerdings hätte man 20 Trainingsschritte zurückspulen und neu trainieren müssen. Xiaomi schätzte die Kosten dafür auf rund 2,31 Millionen US-Dollar, und mit einem anderen Datensatz wäre das Ergebnis nicht stabil gewesen.
Am Ende entschied sich das Team für MOPD, Multi-Teacher Online Distillation. Dabei wurden intern gesammelte Wiederholungsbeispiele genutzt, um separat einen Reinforcement-Learning-"Lehrer" zu trainieren, der speziell lernt, wann Schluss sein sollte – nur 12 Schritte mit rund 7.000 Beispielen. Anschließend wurde das Hauptmodell um 5 Schritte zurückgesetzt und unter Anleitung dieses Lehrers weitertrainiert. Die Gesamtkosten lagen bei rund 90.000 US-Dollar, etwa 4 % der ersten Option.
Der Effekt: Die Wahrscheinlichkeit, beim zwölften Aufruf zu stoppen, stieg von 5,43 % auf 92,17 %. Laut der kumulierten Stoppkurve im Blogbeitrag lag die Wahrscheinlichkeit, dass das Modell überhaupt anhält, vor dem Fix erst beim 59. Aufruf über 50 %; nach dem Fix erreicht sie beim 8. Aufruf bereits 99,87 %. Xiaomi zufolge sank die Wiederholungsrate auf allen Plattformen deutlich, das Verhalten blieb über unterschiedliche Kontextlängen hinweg konsistent, und die allgemeinen Benchmark-Werte gaben nicht nach.
Eingeordnet in die V2.6-Geschichte
MiMo-V2.6 wurde am 22. September veröffentlicht und quelloffen bereitgestellt; damals betonte Xiaomi vor allem den Umfang des Post-Trainings: Medienberichten zufolge liefen für Pro und Flash jeweils 30 Reinforcement-Learning-Schritte, mit Gesamtkosten von rund 3,5 Millionen US-Dollar. Fünf Tage später legt dieser Rückblick eine Nebenwirkung jener Trainingsrunde offen – inklusive der Angabe, dass eine Korrektur eigentlich 2,31 Millionen US-Dollar zusätzlich hätte kosten können.
Öffentliche Fehleranalysen nach dem Launch sind bei chinesischen Modell-Teams selten, und noch seltener werden dabei auch die Kosten gescheiterter Lösungswege offengelegt. Für Entwickler, die MiMo-Modelle in OpenCode oder Claude Code einsetzen, ist der praktische Punkt: Wer in den vergangenen Tagen erlebt hat, dass MiMo wiederholt dieselbe Datei liest oder denselben Befehl ausführt, arbeitet über die API bereits mit der reparierten Version; wer selbst hostet, muss auf die Gewichte mit dem MOPD-Suffix wechseln. Alle genannten Wiederholungsraten stammen aus Xiaomis interner Auswertung, unabhängige Nachtests liegen bislang nicht vor.
Quellen: Technischer Blog des Xiaomi-MiMo-Teams, CocoLoop; Wiederholungs- und Exzessraten je Umgebung sowie die Kosten beider Lösungswege beruhen auf Xiaomis interner Bewertung.