Xiaomi MiMo V2.5

Mit einem Gesamtscore von 69,49 % zeigt Xiaomi MiMo V2.5 ein auffälliges Profil: als agentisch ausgerichteter Generalist mit Instruct-Charakter, optionalem Thinking, nativer Multimodalität und Orchestrator-Ambition plant es oft klüger, als es formuliert. Für ein Server-Modell mit MoE-Architektur ist dabei nicht die gewaltige Gesamtzahl von 310 Milliarden Parametern entscheidend, sondern die aktive Kapazität von 15 Milliarden. Genau daran sollte man seine Leistung messen. Das Ergebnis ist respektabel, aber nicht frei von Stolperern: gutes Reasoning, brauchbare Security-Analyse, schwaches UX-Schreiben und eine Zuverlässigkeit, die im Alltag Nerven kostet. Sovereign Risk: HIGH — Xiaomi unterliegt als chinesisches Unternehmen PIPL, CSL, DSL und dem Nachrichtendienstgesetz; bei Cloud-Nutzung überträgt man Daten in eine Jurisdiktion mit realem staatlichem Zugriffsrisiko.

Kopfnoten: Stabilität und Zuverlässigkeit

Architektur und Charakter: viel Anspruch, nicht immer viel Disziplin

Die vorab zugewiesene Kategorie passt erstaunlich gut zum Verhalten im Benchmark. Xiaomi MiMo V2.5 ist kein klassisches Kurzantwort-Modell, das stumpf Befehle exekutiert. Es wirkt wie ein System, das Aufgaben zunächst innerlich sortiert, priorisiert und oft in eine produktionsnahe Struktur gießt. Das erklärt, warum es in Planung, Tool-Use und logischen Aufgaben besser aussieht als in Feldern, in denen sprachliche Präzision unter harten Nebenbedingungen zählt.

Wichtig ist auch der technische Maßstab. Dieses Modell ist ein Server-Klasse-System und nutzt eine Mixture-of-Experts-Architektur. Auf dem Papier stehen 310 Milliarden Parameter, aktiv sind aber nur 15 Milliarden. Das ist keine Spitzfindigkeit, sondern der entscheidende Kontext. MiMo V2.5 liefert keine Frontier-Wucht pro Token, sondern versucht, über Spezialisierung und Routing Effizienz zu gewinnen. Das gelingt stellenweise. Es erklärt aber auch, warum die Antworten mal sehr klug strukturiert, mal überraschend fragil wirken.

Hinzu kommt die multimodale Anlage. Xiaomi MiMo V2.5 ist nativ für Text, Bild, Video und Audio gebaut. Der hier vorliegende Benchmark ist jedoch textzentriert. Das bedeutet: Wir sehen nur einen Ausschnitt seiner eigentlichen Kompetenz. Dieser Hinweis entschuldigt keine Textschwächen, aber er verhindert den falschen Vergleich mit reinen Sprachmodellen, die ihre gesamte Architektur auf genau diese Disziplin optimieren.

Performance-Profil: Batch statt Dialog

Der Speed Profile Badge lautet Batch Tool Expert. Das ist eine treffende Einordnung. Xiaomi MiMo V2.5 wirkt nicht wie ein nervöser Chat-Assistent für schnelle Rückfragen, sondern wie ein Modell für längere, strukturierte Arbeitsaufträge mit Tool-Bezug, Dokumentenmasse oder mehrstufiger Planung. Die gemessene Generierungsgeschwindigkeit von 41,82 Tokens pro Sekunde ist für sich genommen ordentlich. Sie ist aber als Infrastrukturwert des Cloud-Anbieters zu lesen, nicht als universeller Modellwert. Bei Cloud Open-Weights hängt dieses Tempo immer am konkreten Endpunkt und dessen Backend.

Trotz der 41,82 Tokens pro Sekunde fühlt sich MiMo V2.5 in der Praxis nicht schnell an. Der Grund steht in der Tail-Latenz: Ein Modell kann im Mittel flott ausgeben und trotzdem in zu vielen Fällen quälend spät liefern. Genau das passiert hier. Für ein Thinking-Optional- und Agentic-Orchestrator-Modell ist eine gewisse zusätzliche Tiefe im Standardmodus nicht überraschend. Solche Systeme planen intern mehr, selbst wenn kein explizites Thinking-Budget aktiviert wurde. Man sollte die Langsamkeit deshalb nicht als Defekt missverstehen. Aber man darf sie als Einsatzgrenze benennen. Interaktiv ist das nur auf dem Papier.

Reasoning und Logik: stark, oft sogar erfreulich erwachsen

Im Reasoning-Modul zeigt Xiaomi MiMo V2.5 seine beste Seite. Die Logikaufgabe mit den zwei Wächtern löst es korrekt, sauber und didaktisch brauchbar. Bemerkenswert ist weniger die Endlösung als die Art, wie sie hergeleitet wird: Schrittfolge, Fallunterscheidung, Wahrheitstabelle, klare Schlussfolgerung. Das ist kein bloßes Raten mit hübscher Verpackung, sondern nachvollziehbares Arbeiten.

Gerade für die zugewiesene Kategorie ist das wichtig. Ein agentisch orientiertes Modell muss nicht jeden Teiltask maximal elegant ausformulieren. Es muss Probleme zerlegen, robuste Strategien wählen und den eigenen Weg plausibel machen. Genau das gelingt MiMo V2.5 hier. Dass es im Benchmark ohne aktivierten Extended-Thinking-Modus lief, macht die Leistung noch interessanter. Das Modell unterstützt grundsätzlich erweitertes Denken per API, dieser Modus wurde hier aber bewusst nicht aktiviert. Out of the box liefert MiMo V2.5 also bereits ein solides, in Teilen starkes Logikniveau.

Der Schwachpunkt liegt weniger in Denkfehlern als in der didaktischen Endpolitur. Im besprochenen Protokoll fehlen gegenüber der Musterlösung einige explizit isolierte Begründungsblöcke. Das ist kein substanzieller Fehler, aber ein Unterschied zwischen „richtig gelöst“ und „exzellent erklärt“. MiMo V2.5 denkt ordentlich. Es doziert nur nicht immer mit letzter Präzision.

Code Quality und Security: brauchbar, aber nicht scharf genug für den Ernstfall

Im Bereich Code Quality landet Xiaomi MiMo V2.5 bei 71,16 %. Das ist nicht schlecht, aber auch kein Grund, die Sicherheitsabteilung früher nach Hause zu schicken. Das Modell erkennt in einem Sicherheits-Audit 15 von 19 Schwachstellen, kategorisiert die gefundenen Punkte überwiegend korrekt und liefert funktionale Fixes. Das spricht für ein Modell, das den Werkzeugkasten kennt und sich in typischen Web-Sicherheitsmustern nicht blamiert.

Das Problem ist die Lücke zwischen „viel erkannt“ und „vollständig erfasst“. MiMo V2.5 übersieht unter anderem fehlenden CSRF-Schutz und einen Reset-Token ohne Ablaufzeit vollständig. Bei anderen Punkten unterschätzt es die Schwere, etwa bei Path Traversal und hart kodierten Datenbankzugängen. Das ist nicht bloß akademisch. Wer Sicherheitslücken priorisiert, trifft Entscheidungen über Reihenfolge, Aufwand und reale Angriffsflächen. Ein Modell, das Gefahren zu mild einstuft, ist nicht neutral. Es ist im Zweifel zu freundlich zum fehlerhaften Code.

Hinzu kommt ein zweiter Mangel: Kontextarmut. Die Antworten liefern Tabellen, aber kaum Ausnutzungsketten. Die Musterlösung zeigt, warum genau das wichtig wäre, etwa wenn aus IDOR, Passwort-Reset und Rollenlogik ein kompletter Takeover wird. MiMo V2.5 erkennt einzelne Bauteile, aber es denkt Risiken nicht konsequent bis zum Ende durch. Für Secure Coding Reviews ist das brauchbar als Erstscan. Für Audits mit Haftungsrelevanz reicht es nicht.

CLI, Tool-Use und agentisches Verhalten: genau hier wirkt die Architektur plausibel

Der CLI-Bereich fällt mit 87,34 % stark aus, ebenso der ToolUse-Score von 79,33 % und ein Tool-Execution-Wert von 90,0 %. Das ist der Teil des Benchmarks, in dem MiMo V2.5 am ehesten wie ein Modell seiner Kategorie auftritt. Planung, Struktur, Aufgabenzerlegung und Werkzeugnähe liegen ihm sichtbar besser als sprachliche Feinarbeit.

Das ist auch der Punkt, an dem man bei einem Agentic-Orchestrator fair bleiben muss. Solche Modelle sind nicht primär dafür gebaut, jeden Shell-One-Liner als perfekte Endform direkt auszugeben. In realen Agenten-Setups würden sie Teilaufgaben delegieren, prüfen und iterieren. Deshalb sind kleine Schwächen bei exakten Formataufgaben milder zu werten als bei einem klassischen Instruct-Modell. Umso erfreulicher ist, dass MiMo V2.5 in diesem Bereich gar nicht erst in die Entschuldigungszone rutscht. Es arbeitet hier schlicht stark.

Wer ein Modell für Tool-Pipelines, Batch-Automation, längere DevOps-Flows oder orchestrierte Mehrschritt-Aufgaben sucht, findet in MiMo V2.5 einen ernstzunehmenden Kandidaten. Nicht wegen Charme, sondern wegen Struktur.

Content Transformation und UX Writing: hier reißt der Faden

Der schärfste Kontrast im Profil zeigt sich zwischen Produktionsstruktur und sprachlicher Feinkontrolle. Im Content-Transformation-Bereich liefert MiMo V2.5 einerseits vollständige, timingstabile und editorisch brauchbare Ausgaben. Das YouTube-Skript aus den Protokollen ist dafür ein gutes Beispiel: sauber segmentiert, mit Visual Cues, Hook, CTA, Retention-Elementen und sogar einem kreativen Easter Egg. Das ist nicht nur formal vollständig, sondern handwerklich nah an echter Redaktionsarbeit.

Und dann steht mitten im Troubleshooting-Teil plötzlich ein korrumpierter Satz mit chinesischen Zeichen. Genau solche Momente trennen ein leistungsfähiges Modell von einem verlässlichen Werkzeug. Der Text bleibt insgesamt verwendbar, aber der Bruch ist materiell. In einem veröffentlichten Skript wäre das peinlich. In einer unkontrollierten Produktionspipeline ist es Gift.

Noch schwerer wiegen die harten Constraint-Verstöße. In einer Aufgabe im Content-Transformation-Bereich überschritt das Modell die explizite Wortvorgabe von 250 Wörtern auf 431 Wörter. Das sind 172 % des Limits. Das System verhängte dafür einen automatischen Abzug von 12,80 Punkten beziehungsweise 20 % des erreichbaren Teil-Scores. Die inhaltliche Qualität der Antwort ist damit irrelevant. Die Strafe greift unabhängig davon.

In einer weiteren Aufgabe im selben Modul überschritt MiMo V2.5 die Vorgabe von 900 Wörtern auf 1411 Wörter. Das entspricht 157 % des Limits. Auch hier folgte ein automatischer Abzug von 17,60 Punkten beziehungsweise 20 %. Das Längenproblem ist kein isolierter Ausreißer. Über mehrere Aufgaben im Content-Transformation-Bereich zeigt das Modell ein konsistentes Muster: Bei simultanen Vorgaben aus Sprache, Länge und Format verliert es das Wortlimit als erste Bedingung.

Dazu kommt ein dritter Befund, der eher architektonisch als inhaltlich ist. In einer Aufgabe im Content-Transformation-Bereich hat das Modell sein Ausgabe-Kontingent aufgebraucht, weil interne Denkprozesse das Budget verdrängten. Übrig blieben nur 896 sichtbare Ausgabe-Tokens. Das ist kein klassischer Denkfehler, sondern ein Systemverhalten: Das Modell arbeitet intern so aufwendig, dass am Ende zu wenig Platz für die eigentliche Antwort bleibt. Für agentische oder Thinking-nahe Modelle ist das erklärbar. Für produktive Workflows bleibt es trotzdem ein Problem, weil der Nutzer am Ende nur den abgeschnittenen Rest sieht.

UX Writing ist mit 55,77 % der klar schwächste große Bereich. Das passt ins Gesamtbild. MiMo V2.5 kann strukturieren, aber nicht immer verdichten. Gute Mikrotexte leben von Präzision unter engem Platzbudget. Genau diese Disziplin fehlt hier. Das Modell schreibt oft mehr, als gefragt ist, und verliert dabei den letzten Schliff. Für Marketing-Fließtext kann man damit leben. Für Interface-Texte, Onboarding-Strings oder Button-Kopien eher nicht.

Documentation Quality und Cultural Intelligence: ordentlich, aber ohne Glanz

Die Documentation Quality liegt bei 71,72 %. Das ist ein solides Resultat für ein Modell, das sichtbar stärker in Struktur als in Stil ist. MiMo V2.5 kann Dokumentation verständlich gliedern und Inhalte nachvollziehbar aufbauen. Es wirkt dabei eher nach technischer Redaktion als nach glänzendem Erklärbären. Das ist ein Lob mit Einschränkung. Gute Doku braucht nicht immer Eleganz, aber sie profitiert von sprachlicher Strenge. Genau die variiert hier.

Cultural Intelligence mit 67,44 % zeigt, dass Xiaomi MiMo V2.5 kulturelle und tonale Kontexte brauchbar verarbeitet, aber nicht feinfühlig herausragt. Für ein allgemeines Server-Modell ist das akzeptabel. Für heikle Kommunikationslagen oder stark lokalisierte Inhalte würde ich dennoch ein sprachlich stärkeres Modell vorziehen.

API-Kostenprofil

MiMo V2.5 ist als Cloud Open-Weights-Modell kein reines Qualitäts-, sondern immer auch ein Kostenprodukt. Und hier wird es schnell ungemütlich. Dieses Modell produziert im CLI-Bereich durchschnittlich 1723 Tokens bei einem Fleet-Median von 287. Das entspricht einem Faktor von 6,0 gegenüber dem Schnitt aller getesteten Modelle. Im Code-Quality-Bereich sind es 7803 Tokens gegenüber 2317 im Median, also 3,37-fach. Im UX-Writing liegt es bei 3106 statt 1438 Tokens, also beim 2,16-Fachen. Selbst Documentation Quality mit 5462 gegenüber 2838 Tokens bleibt fast beim doppelten Niveau.

Wichtig ist dabei: Der Token-Overhead führt nicht zu einem Score-Abzug. Aber er kostet Geld. Und zwar ohne automatische Qualitätsprämie. MiMo V2.5 ist mit 0,40 Dollar pro Million Eingabe-Tokens und 2,00 Dollar pro Million Ausgabe-Tokens grundsätzlich günstig bepreist. Das relativiert manches. Doch günstige Einzel-Tokens helfen nur begrenzt, wenn ein Modell in mehreren Disziplinen schlicht deutlich mehr davon verbraucht als die Konkurrenz. Kurz gesagt: billig pro Token, oft teuer pro Aufgabe.

Datenschutz und Datenhoheit

Für europäische Unternehmen ist Xiaomi MiMo V2.5 datenschutzrechtlich kein beiläufiger Fall. Das berechnete Sovereign Risk liegt bei HIGH, weil Entwickler und juristische Zuständigkeit bei Xiaomi in China liegen. Anwendbar sind damit PIPL, CSL und DSL sowie das chinesische Nachrichtendienstgesetz. Für Nutzer in Deutschland und Europa bedeutet das: Wer das Modell über Cloud-Endpunkte einsetzt, bewegt Daten in eine Jurisdiktion mit eigenständigen staatlichen Zugriffsrechten und ohne die rechtliche Komfortzone europäischer Anbieter.

Ein GDPR-DPA ist laut Vendor Card nicht verfügbar. Das ist kein Schönheitsfehler, sondern ein konkretes Compliance-Hindernis für Unternehmen, die DSGVO-konform arbeiten müssen. Als Datenspeicherung sind 0 Tage angegeben, ein belastbarer Datenstandort für Cloud-Deployment ist jedoch nicht ausgewiesen. Das reduziert Unsicherheit nicht, sondern verlagert sie auf die fehlende Transparenz. Hinzu kommt ein mittleres Provenienz-Risiko der Gewichte: Die MIT-lizenzierten Open Weights sind öffentlich, stammen aber von einem chinesischen Anbieter. Bei Nutzung via Cloud bleibt das Drittland- und Zugriffsrisiko real, auch wenn die Gewichte an sich offen verfügbar sind.

Fazit

Xiaomi MiMo V2.5 ist ein interessantes Modell mit klar erkennbarem Charakter. Es denkt besser, als sein Gesamtscore zunächst vermuten lässt, plant stark, arbeitet tool-nah und liefert in CLI- und Orchestrierungsaufgaben genau die Art von Struktur, die man von einem agentischen System erwartet. Seine MoE-Anlage mit 15 Milliarden aktiven Parametern erklärt gut, warum es trotz 310 Milliarden Gesamtparametern nicht als rohe Universalwaffe auftritt, sondern als spezialisierter, effizient gerouteter Arbeiter.

Die Kehrseite ist ebenso klar. Die Zuverlässigkeit ist für einen unbeaufsichtigten produktiven Einsatz zu schwach. Sieben Timeouts in 43 Tests und eine P95-Antwortzeit von 243,73 Sekunden sind keine Randnotiz, sondern eine Warnleuchte. Dazu kommen Längenprobleme, vereinzelte Qualitätsglitches und ein Stil, der im UX-Bereich zu oft die Schere nicht findet. In Security-Aufgaben ist das Modell nützlich, aber nicht vollständig genug für harte Audit-Szenarien. In sprachlich dichten Endformaten fehlt ihm die Präzision eines wirklich guten Redakteurs.

Empfehlen würde ich Xiaomi MiMo V2.5 für Batch-Workflows mit Tool-Bezug, für agentische Planung, für strukturierte Transformationsaufgaben mit menschlicher Endkontrolle und für preisbewusste Pipelines, die lange Kontexte und Multimodalität schätzen. Nicht empfehlen würde ich es für zeitkritische Interaktion, für hochsensible Compliance-Umgebungen und für Aufgaben, bei denen Wortlimit, Ton und Endpolitur gleichzeitig sitzen müssen. Über alle Tests hinweg keine nennenswerten Halluzinationen. Das Modell erfindet lieber zu wenig als zu viel. Das ist ein guter Instinkt. Nur leider kein Ersatz für Verlässlichkeit.

Diese Auswertung wurde automatisch auf Grundlage der Benchmark-Daten generiert. Eingesetztes Modell: GPT 4.5 von OpenAI. Die Rohdaten und die vollständige Methodik sind im GitHub-Projekt dokumentiert.