Xiaomis MiMo-Inferenzmodell

• MiMo-7B von Xiaomi ist eine von Grund auf für Reasoning-Aufgaben trainierte Reihe von 7B-Sprachmodellen; Base-, SFT- und RL-Modell-Checkpoints wurden als Open Source veröffentlicht
• Mit dem Update vom 30. Mai 2025 wurde der SFT-Datensatz von etwa 500.000 auf 6 Millionen Einträge erweitert und die Fenstergröße für das RL-Training von 32K auf 48K vergrößert, wodurch MiMo-7B-RL-0530 auf AIME 2024 eine Leistung von 80,1 erreicht
• Das Pretraining nutzt rund 25 Billionen Token und eine dreistufige Datenmischungsstrategie; enthalten sind Datenfilterung zur Erhöhung der Dichte von Reasoning-Mustern, synthetische Reasoning-Daten und Multiple-Token Prediction
• Das Post-Training verwendet 130.000 Mathematik- und Code-Aufgaben, regelbasierte Verifier, regelbasierte Genauigkeits-Rewards, Rewards auf Basis der Testschwierigkeit für Code-Aufgaben sowie eine Resampling-Strategie für einfache Aufgaben
• Für die Bereitstellung werden SGLang, Xiaomis vLLM-Fork und HuggingFace-Beispiele angeboten; die Validierung von MiMo in anderen Inferenz-Engines ist noch nicht abgeschlossen, Beiträge sind willkommen

---

Ziel und Veröffentlichungsumfang der MiMo-7B-Serie

• MiMo-7B ist eine Modellreihe mit dem Ziel, das Reasoning-Potenzial von Sprachmodellen vom Pretraining bis zum Post-Training auszuschöpfen
• Die veröffentlichten Checkpoints umfassen die folgenden 4 Varianten
  • MiMo-7B-Base: ein Basismodell mit Reasoning-Potenzial
  • MiMo-7B-RL-Zero: ein per RL aus dem Basismodell trainiertes Modell
  • MiMo-7B-SFT: ein per SFT aus dem Basismodell trainiertes Modell
  • MiMo-7B-RL: ein per RL aus dem SFT-Modell trainiertes Modell
• Die Modelle sind auf HuggingFace und ModelScope verfügbar
• Der technische Bericht wurde auf arXiv veröffentlicht

Update vom 30. Mai 2025

• MiMo-7B-RL-0530 spiegelt die Ergebnisse der Erweiterung des SFT-Datensatzes von etwa 500.000 auf 6 Millionen Einträge sowie der weiteren Vergrößerung der Fenstergröße im RL-Training von 32K auf 48K wider
• Auf AIME 2024 erreichte MiMo-7B-RL-0530 80,1 und übertraf damit DeepSeek R1 mit 79,8
• Die wichtigsten Benchmark-Änderungen sind wie folgt
  • MATH500 Pass@1: 95,8 → 97,2
  • AIME 2024 Pass@1: 68,2 → 80,1
  • AIME 2025 Pass@1: 55,4 → 70,2
  • LiveCodeBench v5 Pass@1: 57,8 → 60,9
  • LiveCodeBench v6 Pass@1: 49,3 → 52,2
  • GPQA-Diamond Pass@1: 54,4 → 60,6
  • Alignbench1.1, GPT-4.1-Bewertung: 6,9 → 7,4

Pretraining: Basismodell für Reasoning

• MiMo-7B-Base ist ein von Grund auf für Reasoning-Aufgaben trainiertes Basismodell
• Das Pretraining nutzt rund 25 Billionen Token
• Bei der Datenverarbeitung wurden Werkzeuge zur Textextraktion verbessert und mehrdimensionale Datenfilterung angewendet, um die Dichte von Reasoning-Mustern in den Pretraining-Daten zu erhöhen
• Zur Erzeugung vielfältiger großer synthetischer Reasoning-Daten werden mehrere Strategien verwendet
• Im Pretraining kommt eine dreistufige Strategie zur Datenmischung zum Einsatz
• Multiple-Token Prediction wurde als zusätzliches Trainingsziel aufgenommen, um Modellleistung und Inferenzgeschwindigkeit zu verbessern

Post-Training und RL-Trainingsmethode

• Für das Post-Training werden 130.000 Mathematik- und Code-Aufgaben, die durch regelbasierte Verifier überprüfbar sind, als RL-Trainingsdaten verwendet
• Jede Aufgabe durchläuft zur Qualitätssicherung eine Bereinigung und Schwierigkeitsbewertung
• Als Reward wird ausschließlich ein regelbasierter Genauigkeits-Reward verwendet, um potenzielles Reward Hacking zu vermeiden
• Um das Problem spärlicher Rewards bei schwierigen Code-Aufgaben abzumildern, wurde ein Code-Reward auf Basis der Testschwierigkeit eingeführt
  • Testfällen mit unterschiedlicher Schwierigkeit werden fein abgestufte Punktzahlen zugewiesen
  • Die Policy kann mit dichteren Reward-Signalen optimiert werden
• Für einfache Aufgaben wird eine Resampling-Strategie angewendet, um die Effizienz des Rollout-Samplings zu erhöhen und insbesondere Policy-Updates in der späteren Phase des RL-Trainings zu stabilisieren

RL-Infrastruktur und Modellstruktur

• Die Seamless Rollout Engine wurde entwickelt, um RL-Training und Validierung zu beschleunigen
• Das Design kombiniert kontinuierliche Rollouts, asynchrone Reward-Berechnung und Early Termination, um GPU-Leerlaufzeiten zu reduzieren
• Die Leistungsverbesserungen sind wie folgt
  • 2,29-fach höhere Trainingsgeschwindigkeit
  • 1,96-fach höhere Validierungsgeschwindigkeit
• Die MTP-Layer von MiMo-7B werden während Pretraining und SFT getunt und während RL eingefroren
• Wird ein MTP-Layer für spekulatives Decoding verwendet, liegt die Akzeptanzrate bei etwa 90 %
• vLLM unterstützt MTP und stärkt die Robustheit der Inferenz-Engine im RL-System

Evaluationsergebnisse

• MiMo-7B-RL wird als Modell dargestellt, das bei Mathematik- und Code-Reasoning-Aufgaben eine Leistung auf Augenhöhe mit OpenAI o1-mini zeigt
• In wichtigen Modellvergleichen sind die Mathematik- und Code-Ergebnisse von MiMo-7B-RL wie folgt
  • MATH-500 Pass@1: 95,8
  • AIME 2024 Pass@1: 68,2
  • AIME 2025 Pass@1: 55,4
  • LiveCodeBench v5 Pass@1: 57,8
  • LiveCodeBench v6 Pass@1: 49,3
• Im internen Vergleich der MiMo-7B-Serie steigt die Leistung nach Anwendung von RL deutlich
  • MATH500: Base 37,4 → RL-Zero 93,6 → SFT 93,0 → RL 95,8
  • AIME 2024: Base 32,9 → RL-Zero 56,4 → SFT 58,7 → RL 68,2
  • LiveCodeBench v5: Base 32,9 → RL-Zero 49,1 → SFT 52,3 → RL 57,8
• Die Evaluationseinstellung ist temperature=0.6
• Die Bedingungen für wiederholte Evaluationen sind wie folgt
  • AIME24 und AIME25 sind Durchschnitte aus 32 Wiederholungen
  • LiveCodeBench v5, LiveCodeBench v6, GPQA-Diamond und IF-Eval sind Durchschnitte aus 8 Wiederholungen
  • MATH500 und SuperGPQA sind Einzelläufe

Bereitstellung und Nutzung für Inferenz

• SGLang unterstützt MiMo im Mainstream durch Unterstützung für MiMo-Modelle und MTP
  • Zugehörige PRs: MiMo model support, MTP
  • Die Nutzungsdokumentation ist in den SGLang documents verfügbar
• Für vLLM-Inferenz wird die Nutzung von Xiaomis vLLM-Fork empfohlen
  • Empfohlener Fork: XiaomiMiMo/vllm
  • Dieser Fork wurde auf Basis von vLLM 0.7.3 entwickelt
• Der vLLM-Loader kann auch so registriert werden, dass MTP-Parameter nicht geladen werden
  • Registrierungsdatei: registry/register_mimo_in_vllm.py
• Das HuggingFace-Inferenzbeispiel verwendet AutoModelForCausalLM.from_pretrained und AutoTokenizer.from_pretrained
• Die empfohlene Prompt-Einstellung ist ein leerer system prompt
• Die Validierung von MiMo in anderen Inferenz-Engines ist noch nicht abgeschlossen; Beiträge auf Basis der Modelldefinition im HuggingFace-Repository sind willkommen

[GN⁺]

Meinungen auf Hacker News

• Interessant war, wie das Paper die Reinforcement-Learning-Phase für Code-Daten behandelt hat. Trainiert wurde mit schwierigen, aber lösbaren Codegenerierungsaufgaben, die per Unit-Tests ausgeführt wurden; ich frage mich, ob andere Modelle ebenfalls solche Trainingsschritte durchlaufen
  Dem Paper zufolge wurden Aufgaben ohne Testfälle entfernt; Aufgaben mit Referenzlösung wurden ausgeschlossen, wenn diese nicht alle Tests bestand; und Aufgaben ohne Referenzlösung wurden verworfen, wenn bei 16 Samples eines fortgeschrittenen Reasoning-Modells kein Test gelöst wurde. Auch leichte Aufgaben wurden mit der SFT-Version von MiMo-7B herausgefiltert, sodass am Ende 30.000 Code-Aufgaben entstanden
  Außerdem mussten in jeder Reinforcement-Learning-Iteration Tausende Aufgaben und Hunderte Testfälle pro Aufgabe bewertet werden; deshalb wurde eine Online-Judge-Umgebung aufgebaut, die extrem viele Unit-Tests parallel ausführt, um GPU-Leerlauf zu vermeiden

  • Gibt es Fälle, in denen Reinforcement Learning ohne Unit-Tests gemacht wird? Falls nicht, würde das ja bedeuten, dass andere Modellhersteller Genauigkeit ignorieren, was überraschend wäre
    Für kleine, modulare Probleme mag das funktionieren, aber bei Aufgaben mit 200.000 Token Eingabe könnte dieser Ansatz schwierig sein

• Ich frage mich, warum es unter den KI-Modellen aus China so viele English-first-Modelle gibt. Haben sie nicht vor, Nutzer im eigenen Land anzusprechen, oder liegt es daran, dass Chinese-first-Modelle im Westen kaum Beachtung finden würden?

  • CommonCrawl ist der größte und am leichtesten zugängliche legale Crawling-Datensatz, der seit 2008 Daten sammelt. Fast alle nutzen ihn als Basisdatensatz für das Training grundlegender großer Sprachmodelle, und da der Großteil auf Englisch ist, werden die Modelle gut in Englisch
    https://commoncrawl.org/
  • In der wissenschaftlichen Forschung, insbesondere bei AI-Benchmarks, ist Englisch meines Erachtens praktisch zur Standardsprache geworden
    Etwas direkt auf Chinesisch zu testen, ist offensichtlich unmöglich; dafür braucht es Übersetzung
  • Was ich an diesem Paper zum Verständnis von LLMs interessant fand, war der Teil, dass Modelle Wörter und Konzepte verschiedener Sprachen über Multilingual Circuits miteinander verbinden
    Das Beispiel ist etwa, dass das Gegenteil des englischen „small“ zu „big“ führt, das Gegenteil des französischen „petit“ zu „grand“ und das Gegenteil des chinesischen „小“ zu „大“. Die dazugehörige Abbildung ist auch ziemlich cool
    Englisch ist die Lingua franca des Internets und stellt den größten Korpus, aber Mainstream-Modelle können englische Datensätze nutzen, um sprachübergreifende Verknüpfungen aufzubauen. Dadurch können Sprachräume, denen Daten, Technik und Ressourcen fehlen, um eigene regionale Modelle zu bauen, deutlich stärkere KI- und Reasoning-Fähigkeiten erhalten
    https://www.anthropic.com/research/tracing-thoughts-language...
    https://www.anthropic.com/_next/image?url=https%3A%2F%2Fwww-...
  • Ich vermute, ein erheblicher Teil des hochwertigen Trainingsmaterials ist auf Englisch
  • Das chinesische Internet besteht im Wesentlichen aus einigen stark von Großunternehmen kontrollierten Walled Gardens. Wenn jedes Unternehmen Heerscharen von Engineers einsetzt, um die eigenen Daten zu schützen, funktionieren Crawler nicht richtig
    Viele beliebte Websites sind zudem App-only, wodurch es unmöglich wird, den Korpus zu bekommen, der für gutes LLM-Training nötig ist

• Für ein 7B-Modell ist die Coding-Performance unglaublich stark. Gemini Pro 2.5, das ich nutze, liegt bei 67,8, dieses Modell bei 57,8 und damit sehr nah an Gemini 2.5 Flash mit 60,6
  Nach den Geschichten rund um llama4 bin ich gegenüber Evaluationsergebnissen ziemlich skeptisch geworden; man muss also sehen, wo es in privaten Evaluationen landet, aber die aktuellen Zahlen sind sehr beeindruckend

• GGUF-Version für LM Studio, Ollama usw.: https://huggingface.co/jedisct1/MiMo-7B-RL-GGUF

• Ich frage mich, ob man bei der Nutzung von gguf-Dateien in Ollama üblicherweise selbst ein passendes Modelfile erstellt und verwendet, oder ob man erwartet, dass die Ollama-Defaults auch für neue Modelle gut passen
  https://github.com/ollama/ollama/blob/main/docs%2Fmodelfile....

  • Eines der Kernziele von Georgi Gerganov beim Design von GGUF war, dass keine weiteren Dateien nötig sind. Schon der erste Punkt der Spezifikation ist buchstäblich Single-File-Distribution
    Alle Informationen, die zum Laden des Modells nötig sind, befinden sich in der Modelldatei, und Nutzer müssen keine zusätzlichen Informationen bereitstellen
    https://github.com/ggml-org/ggml/blob/master/docs/gguf.md
    Kaum hatte man die Verwirrung durch mehrere Dateien beseitigt, hat Ollama sie gewissermaßen wieder eingeführt; das ist schade
  • Wenn man ollama pull ausführt, wird auch das Modelfile zusammen mit den Blobs heruntergeladen. Wenn man ein Modell dauerhaft ändern will, kann man das Modelfile in einen Texteditor kopieren, die nötigen Änderungen einfügen und aus dem bestehenden Modelfile ein neues Modell erstellen
    Mein Workflow mit Open WebUI ist: mit ollama show qwen3:30b-a3b-q8_0 --modelfile nachsehen, den Inhalt des Modelfile in admin -> models -> OpenwebUI einfügen, den Namen etwa in qwen3:30b-a3b-q8_0-monkversion-1 ändern, mit Parametern wie num_gpu 90 die Anzahl der Layer anpassen und die alte Datei dann behalten oder löschen
    Im Modelfile steht der Hinweis, dass man zum Erstellen eines neuen Modelfile FROM etwa in # FROM qwen3:30b-a3b-q8_0 ändern soll; außerdem muss man prüfen, ob der Pfad stimmt. Ich speichere die Modelle nicht am Standardort von Ollama, sondern auf einer großen NVMe-SSD, daher ist das wichtig
    Nebenbei: Ich mag den Modelfile-Workflow überhaupt nicht, weil er wirklich umständlich und ein miserables Muster ist. Manche Modelle sind 30–60 GB groß; das Ganze zu kopieren, nur um einen einzigen Parameter zu ändern, ist eine dumme Vorgehensweise
    Trotzdem macht Ollama vieles gut und erleichtert den Einstieg. vLLM, SGLang, Mistral.rs und llama.cpp erfordern deutlich mehr Konfigurationsaufwand
  • Normalerweise nutze ich anfangs die Defaults, und wenn es ein Modell ist, das ich weiterverwende, nehme ich ein Modelfile. Man könnte wohl auch das von Ollama verwendete Modelfile dumpen und als Vorlage nehmen

• Es ist schon etwas amüsant, wenn in Benchmarks Top-Modelle wie O3, Gemini Pro oder Claude 3.7, die derzeit in mehreren Evaluierungen ganz vorne liegen, ausgelassen werden

  • Diese Modelle sind sehr viel größer und proprietäre Modelle. Die jeweiligen Anbieter haben auch keine destillierten Versionen identifiziert und veröffentlicht
    Man sollte sehen, dass die meisten Vergleichsmodelle 7B-Modelle sind. Die Ausnahme ist Qwen-2.5-32B-RL-Zero, ebenfalls ein Open-Weights-Modell, und MiMo-7B schneidet sogar besser ab als dieses Modell mit 32B Parametern
  • Ich denke, das Ziel hier ist der Vergleich mit ähnlichen Modellen, die für den Betrieb offline oder auf mobiler Hardware optimiert sind

• MiMo-7B behauptet, ein von Grund auf trainiertes 7B-Modell zu sein, das größere Modelle wie Qwen-32B übertrifft und bei Mathe- und Code-Benchmarks mit OpenAI o1-mini gleichzieht. Ich frage mich, ob das ein Zeichen ist, dass Pretraining + RLHF-Optimierung endlich beginnt, reine Skalierung zu schlagen, oder ob man nur besser darin geworden ist, enge Fähigkeiten in Benchmarks zu messen

  • Ich frage mich, ob es Qwen 3 oder 2.5 ist

• Im README steht nicht, welche Art von Reinforcement Learning verwendet wurde; dort steht einfach nur RL. Ich weiß, dass Forschende beschäftigt sind und gutes Schreiben Zeit kostet, aber solche Details sollte man nicht weglassen

  • Der technische Bericht behandelt ziemlich ausführlich, wie Reinforcement Learning eingesetzt wurde, etwa mit einer modifizierten GRPO-Zielfunktion. Was das README angeht: Ich denke, die meisten, die in diesem Bereich aktiv sind, verstehen, was „RL“ bei Reasoning-Modellen bedeutet
  • Ich habe „RL“ als Reinforcement Learning verstanden, und obwohl es rund zehn Jahre her ist, dass ich an der Uni KI studiert habe, finde ich es durchaus vertretbar, einfach RL zu schreiben. Ich frage mich, ob du mehr Konkretheit willst, etwa ob Q-Learning oder ein anderer Algorithmus verwendet wurde

• Ich frage mich, ob dieses Modell im AI Assistant der Xiaomi-15-Serie eingesetzt wird. Das erscheint wahrscheinlich, aber welche Ergebnisse dabei herauskommen, weiß ich nicht

• Es ist schwer zu glauben, dass solche Benchmark-Werte aus einem 7B-Modell kommen

  • Die Leistung kleiner Modelle steigt Stück für Stück weiter. Es ist nicht so, dass sie die Mainstream-Modelle großer Unternehmen auf einen Schlag überholen, deshalb machen sie keine Schlagzeilen, aber sie sind alle ziemlich leistungsfähig geworden
    Vor Kurzem habe ich bei Ollama irgendein 12B-Modell geladen, und angesichts der Maschine, die ich nutzte, war ich überrascht, wie gut und schnell es sich anfühlte. Vor etwa einem Jahr wäre das wohl nicht so gewesen
  • Wenn diese Zahlen unrealistisch wirken, sollte man sich die Benchmark-Zahlen von qwen3-4B ansehen
    https://qwenlm.github.io/blog/qwen3/
  • Meine Vermutung ist, dass es auf die Tests overfitted ist
  • Alle LLMs werden faktisch auf Benchmarks trainiert, daher verliert das Wort „Benchmark“ im Zusammenhang mit LLMs ziemlich an Bedeutung
  • Das beste Modell von heute wird für den Rest seines Lebens immer weiter zu einem schlechteren Modell werden