minicpm small-language-models benchmarks agents quantization

MiniCPM5-2B gegen 4B Rivalen: Warum ein agiler Harness eine andere Geschichte erzählt

MiniCPM5-2B schneidet bei Einzelversuchen besser ab als seine 4B-Konkurrenten, fällt aber bei agierenden Frameworks zwei- bis dreimal zurück. Der Benchmark-Test sowie die Durchsatzleistung von Ollama.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 202610 Min. Lesezeit2397 Wörter

Quellen: The 2B Model That Beats 4B Rivals — Until You Test It as an Agent

Ein Modell mit 2,5 Milliarden Parametern, das angeblich bei elitären Programmier-Benchmarks besser abschneidet als Konkurrenten mit 4 Milliarden Parametern, klingt nach einem guten Deal. Wenn man dieses Modell jedoch in ein echtes, mehrstufiges agierendes System integriert, sinkt seine Leistung um bis zu das Dreifache. Einzelne Bewertungen sagen wenig über die komplexen Realitäten der Softwareentwicklung in der Praxis aus. Wenn man über die Gesamtwertungsscores hinausgeht und die Leistung lokal nachvollzieht, erhält man einen konkreten Rahmen dafür, wann dieses Modell das richtige Werkzeug ist.

Die Behauptung

OpenBMB veröffentlichte MiniCPM5-2B am 7. September 2026. Es handelt sich um ein dichtes kausales Sprachmodell mit 2,516 Milliarden Parametern, einer Apache 2.0-Lizenz sowie einem nativen Kontext von 131.072 Tokens. Laut der Veröffentlichung ist es das beste offene Modell unter 4 Milliarden Parametern, mit einem Durchschnittswert von 53,9 bei 34 Benchmarks, und liegt damit vor mehreren Konkurrenten der 4B-Klasse, einschließlich Qwen3.5-4B, mit folgenden Ergebnissen: MATH-500 bei 94,6, AIME 2026 bei 86,5, LiveCodeBench v6 bei 69,1 und SWE-bench Verified bei 46,4.

Hier wedelt niemand mit einem ausgewählten Screenshot der Leaderboard-Liste herum. Der Release war geordnet und ernsthaft durchgeführt: Acht Artefakte landeten gleichzeitig. Die Sammlung umfasst Kontrollpunkte für die Basisphase, die mittlere Trainingsphase sowie die SFT-Phase allein, anschließend das finale Modell, das mit RL und OPD optimiert wurde, sowie Konvertierungen in GGUF und MLX-Format. Dazu gehört auch eine 4-Bit-Version von GPTQ sowie ein experimenteller Dekodierungsmodellentwurf namens MiniCPM5-2B-DSpark. Ein Labor, das stillschweigend Benchmarks ausprobiert, bringt seine Ergebnisse nicht auf diese Weise heraus. Dieses Projekt scheint Kritik zu erwarten und liefert Dateien für jede mögliche Ausführungsumgebung – von llama.cpp und Ollama über LM Studio, vLLM und SGLang bis hin zu Transformers, MLX sowie FlagOS für mehrere Chips.

Unter voller Leistungsfähigkeit behauptet man, dass ein Modell, das etwa 44 Prozent kleiner ist als Qwen3.5-4B, bei Tests in Mathematik, Programmierung und Softwareentwicklung besser abschneidet. Würde das ohne Einschränkungen zutreffen, wäre das ein bedeutender Indikator für die Skalierbarkeit bei nach dem Training durchgeführten, auf logisches Denken ausgerichteten Aufgaben. Das trifft jedoch nicht ohne Einschränkungen zu, und das Interessante ist genau, an welchen Stellen es versagt und warum.

Was steckt dahinter

Das Wissen darüber, was tatsächlich ausgeführt wird, ist hilfreich, denn die Architektur berücksichtigt sowohl Stärken als auch Schwachstellen. MiniCPM5-2B ist ein Dekoder, der ähnlich wie LlamaForCausalLM konstruiert wurde: 42 Transformer-Schichten mit gruppiertem Abfrageschutz, wobei 16 Abfrageköpfe 2 Schlüssel/Wert-Köpfe teilen. Ein Verhältnis von 8 zu 1 ist für ein Modell dieser Größe bemerkenswert. Dadurch wird der KV-Cache pro Token erheblich verkleinert, was vorteilhaft ist, wenn lange Historien von Tool-Aufrufen aufbewahrt werden müssen oder mehrere Agentensitzungen eine einzige GPU teilen. Es werden keine exotischen, spärlichen oder linearen Abfragemechanismen verwendet, obwohl verwandte Modelle aus der MiniCPM-Familie, MiniCPM-SALA und MiniCPM4, mit Hybriden experimentiert haben. Das Team blieb beim vertrauten Mechanismus und investierte stattdessen an anderen Stellen.

Der Grund dafür liegt in der Länge des Kontexts sowie in der Auswahl der Trainingsdaten. 131.072 Tokens sind bei Modellen mit weniger als 3 Milliarden Parametern ungewöhnlich, da die meisten Modelle dieser Größe bei etwa 32.000 bis 64.000 Tokens an Qualität verlieren. Bei agierenden Anwendungen, bei denen das Modell ein immer länger werdendes Protokoll von Aufrufen, Unterschieden und Shell-Ausgaben verwalten muss, ist dieser Puffer wichtiger als die reine Anzahl der Parameter.

Das Modell verarbeitet ausschließlich Englisch und Chinesisch, ohne visuelle oder auditive Funktionen. Das ist eine bewusste Einschränkung und kein Versehen, denn jeder Parameter, der für die multimodale Abstimmung verwendet wird, fehlt für das Schlussfolgern und die Nutzung von Werkzeugen. OpenBMB hat außerdem die Nachtrainingsdaten veröffentlicht: UltraData-SFT-Agent-2609 mit 500.000 Agenten-Verhaltensbeispielen sowie UltraData-RL-2609 mit mehr als 80.000 RL-Beispielen. Das ist wahre Transparenz, da das im Modell integrierte Agentenverhalten überprüft werden kann, anstatt aus Benchmark-Differenzen geschätzt zu werden.

Sobald die Architektur verstanden ist, verwandeln sich die Angaben der Benchmarks von abstrakten Zahlen in überprüfbare Hypothesen bezüglich eines bestimmten Dekoders und eines bestimmten Trainingsverfahrens.

Die erste Durchbruch: 23 gegen 15

Bereits innerhalb eines Tages nach dem Start traten Probleme auf. In der Ankündigung von OpenBMB wurde für das Modell ein Wert von 23 im Artificial Analysis Intelligence Index angegeben, während der unabhängige Tracker von Artificial Analysis einen Wert von 15 zeigte. Eine spätere Überarbeitung des Index lag bei etwa 13. Die vorhersehbare Reaktion bestand darin, zu fragen, ob OpenBMB seine eigenen Zahlen aufgebläht habe.

Das war nicht der Fall, und der Fall verdient eine sorgfältige Prüfung, denn reflexhafte Empörung ist die falsche Reaktion auf eine Diskrepanz bei den Benchmarks – und zugleich die häufigste. Die Methodenbeschreibung von Artificial Analysis erklärt die Lücke. Kurz gesagt: Der Unterschied rührt nicht davon her, dass das Modell schlechter geworden wäre. Die Bewertungsmethode hat sich geändert: Private Testmengen haben nun 40 Prozent des Gesamtgewichts, im Vergleich zu früheren Versionen, und Version 4.2 fügte zwei neue Komponenten hinzu – die AA-Briefcase agentic Evaluation sowie einen Test mit langem Kontext.

Die von OpenBMB angegebene Zahl 23 wurde mit dem Intelligence Index v4.1.1 ermittelt. Als die Leute die Zahlen verglichen, war die öffentliche Version bereits auf v4.2 aktualisiert worden, wobei eine andere Gewichtung sowie zwei Komponenten vorhanden waren, die bei Erstellung der ursprünglichen Zahl noch nicht existierten. Der Vergleich von 23 in einer Version mit 15 in einer anderen offenbart keinen Betrug – es werden lediglich zwei unterschiedliche Messinstrumente verglichen, wobei anschließend überrascht wird, dass sie unterschiedliche Ergebnisse liefern.

Der eigentliche Fehler liegt bei frühen Berichten, die beide Zahlen nebeneinander abdruckten, ohne anzugeben, dass sie von verschiedenen Indexversionen stammten. Dadurch entstand eine falsche Schlussfolgerung, die von den Daten nie gestützt wurde. Ein Bericht, der einen Gesamtwert des Index angibt, sollte die zugehörige Version ebenfalls nennen. Fällt dies aus, können 23 und 15 nicht miteinander verglichen werden – es handelt sich dabei tatsächlich um zwei verschiedene Fragen, die lediglich denselben Namen teilen.

Diesen Fehler lässt sich beheben. Einen anderen hingegen nicht annähernd so einfach beseitigen.

Die eigentliche Lücke: agierende Werkzeuge

Die Zahl, die die Wahrnehmung dieses Modells verändern sollte, stammt von Terminal-Bench v2.1. MiniCPM5-2B erzielt dort Werte zwischen 8,6 und 9, während Qwen3.5-4B 25,8 erreicht. Das bedeutet einen Unterschied von etwa dem Dreifachen, wodurch MiniCPM5-2B auf dieser Messgröße den achten Platz belegt, obwohl es im Intelligence Index unter den Modellen seiner Größe an erster Stelle steht. SWE-bench Pro zeigt ein ähnliches Bild: MiniCPM5-2B erzielt 14,4 Punkte gegenüber 28,2 bei Qwen3.5-4B, was einem Unterschied von etwa dem Zweifachen entspricht.

Setzen Sie das neben die Behauptung zur Veröffentlichung. Das von OpenBMB mit SWE-bench verifizierte Ergebnis von 46,4, das als Überlegenheit gegenüber Qwen3.5-4B angegeben wird, ist einer der Eckpfeiler der Schlagzeile „Überlegenheit gegenüber 4B“. Doch SWE-bench Pro ist nicht derselbe Test mit nur einem beängstigenderen Namen. Es verwendet eine umfangreichere und anspruchsvollere Sammlung echter Repository-Probleme und läuft über ein echtes agiles Framework, wobei die Verifizierung eher der Einzelschuss-Patch-Generierung entspricht. Terminal-Bench liegt noch weiter entfernt von einer Einzelschuss-Bewertung – es handelt sich um eine echte Terminalumgebung, in der das Modell planen, Befehle ausführen, die Ausgabe lesen und nach vielen Schritten von eigenen Fehlern wieder auf die Beine kommen muss.

Eine unabhängige Bewertung durch MindStudio formulierte es unverblümt: Das Modell zeigt auf einigen agilen Benchmarks Potenzial, liegt aber bei den schwierigeren agilen Tests, SWE-bench Pro und Terminal-Bench, deutlich hinter Qwen zurück.

Dieses Ergebnis sollte die Erwartungen weitaus stärker beeinflussen als das Problem der Index-Version-Unterschiede. Es belohnt das Schreiben eines korrekten Patches für eine ordentlich strukturierte Aufgabe, wobei die einmalige Generierung als ingenieurtechnische Leistung dargestellt wird. Terminal-Bench und SWE-bench Pro belohnen außerdem das konsequente Handeln über mehrere Nutzungsschritte hinweg, das Überwinden eines fehlgeschlagenen Shell-Befehls sowie das Vermeiden eines Scheiterns bereits nach drei Schritten in einem Plan. Das Modell ist offensichtlich gut bei der ersten Art von Aufgabe, aber deutlich schwächer bei der zweiten. Jeder, der es als autonomen Codingsub-Agent anstelle eines Ein-Schritt-Patch-Schreibers verwendet, wird mit den Schwächen der zweiten Art konfrontiert werden.

Diese Lücke ist real und ungelöst, und kein methodisches Phänomen kann sie erklären; daher sollte sie manuell überprüft werden, anstatt sich auf die Gesamtwerte einer der Seiten zu verlassen.

Lokal nachvollziehen

Scheinbar hat niemand eine systematische Untersuchung der Tokens pro Sekunde je nach Quantisierungsstufe auf echter Hardware veröffentlicht. Die vorliegenden Angaben wiederholen meist die Benchmark-Tabelle aus der Veröffentlichung oder eine einzelne, anekdotische Geschwindigkeitsangabe. Es handelt sich dabei um Werte aus einem einzigen Lauf, nicht um kontrollierte Tests mit verschiedenen Einstellungen, weshalb sie lediglich als Anregung zur lokalen Messung dienen und keine endgültigen Schlussfolgerungen zulassen.

Speicherverbrauch bei Quantisierung im 8K-Kontext:

Q4_K_M: etwa 2,78 GB
Q8_0: etwa 3,7 GB
BF16/FP16: etwa 6,3 GB

von unabhängigen Quellen gemeldete Durchsatzrate: etwa 144,23 Tokens pro Sekunde auf einer RTX 3070 Ti mit 8 GB VRAM, unter Verwendung der Q4-Quantisierung in LM Studio mit einem einzigen Stream – es handelt sich dabei um eine eher einfache Verbraucher-Karte. In einer Diskussion auf Hacker News zum Release wurde erwähnt, dass auf einem DGX Spark gleichzeitig 32 Sub-Agenten laufen, was insgesamt eine Durchsatzrate von 931 Tokens pro Sekunde ergibt und Spitzenwerte von 1.364 erreicht. Diese zweite Zahl entspricht dem vorgesehenen Einsatzgebiet. Es geht nicht darum, ein Rennen um die geringste Latenz bei einem einzigen Stream zu gewinnen. Das GQA-Verhältnis sowie die geringe Größe sind darauf ausgelegt, viele Sessions gleichzeitig zu bedienen, und 32 Agenten, die einen Knoten teilen, eignen sich hervorragend dafür.

Der schnellste Weg, irgendetwas nachzuvollziehen, ist Ollama:

# macOS
brew install ollama

# Linux
curl -fsSL https://ollama.com/install.sh | sh

# Recommended flags for flash attention + quantized KV cache
OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve &

# Run directly from Ollama's registry
ollama run openbmb/minicpm5-2b

Für eine spezifische Quantisierung, die von Hugging Face in llama.cpp übernommen wurde:

huggingface-cli download openbmb/MiniCPM5-2B-GGUF \
  MiniCPM5-2B-Q4_K_M.gguf \
  --local-dir ./minicpm5-2b-gguf

Und für skalierbaren Betrieb, der mit OpenAI kompatibel ist, vLLM:

pip install vllm

vllm serve openbmb/MiniCPM5-2B \
  --max-model-len 131072 \
  --dtype bfloat16 \
  --port 8000

# Query it like any OpenAI chat completion endpoint
curl http://localhost:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model": "openbmb/MiniCPM5-2B", "messages": [{"role": "user", "content": "Write a quicksort in Rust"}]}'

Die Qualität variiert je nach Aufgabe auf Weise, die aggregierte Benchmarks nicht zeigen. Die praktischen GGUF-Tests von MindStudio ergaben, dass das Q8_0-Modell selbstständiges Programmieren sowie überprüfbares mathematisches und physikalisches Denken gut bewältigte, bei einer schema-spezifischen SQL-Debugging-Aufgabe sowie bei mehrsprachiger Übersetzung jedoch stark versagte und dabei zu selbstbewussten, aber faktisch falschen Antworten kam.

Ein selbstbewusst falsches Verhalten wiegt schwerer als jedes Genauigkeitsprozent. Offensichtliche Fehler sind bei der Überprüfung leicht zu erkennen, doch ein mit Sicherheit gelieferter Fehler ist der Weg, wie eine fehlerhafte SQL-Migration in die Produktion gelangt. Die Reproduzierbarkeit birgt außerdem eine weitere Falle: llama.cpp verhält sich je nach Build-Version sowie je nachdem, wie die Benutzeroberfläche das Chat-Template anwendet, recht unterschiedlich. Wenn lokale Werte von denen anderer abweichen, prüfen Sie vor dem Schluss, dass sich das Modell geändert hat, zunächst den Build.

Insgesamt stimmen die lokalen Erkenntnisse mit den Unterschieden bei Terminal-Bench und SWE-bench Pro überein. Begrenzte, überprüfbare Aufgaben laufen reibungslos, während die Situation unzuverlässiger wird, sobald ein präzises Wissen über ein externes Schema oder ein offenes, mehrstufiges Urteilsvermögen erforderlich ist. Unabhängige Quellen bestätigen dieses Muster einheitlich genug, um darauf vertrauen zu können – was letztendlich zur Entscheidung führt, die tatsächlich von Bedeutung ist.

Wann dieses Modell die richtige Wahl ist

Sobald der Benchmark-Streit beiseitegelassen wird, bleibt ein nützliches Entscheidungsframework übrig, das jedoch keine Bewertung als gut oder schlecht darstellt.

Starke Passungen:

Gruppen von vielen Unteragenten, die gleichzeitig arbeiten. Die Speichereffizienz durch GQA sowie die 931 Tokens pro Sekunde in Kombination mit 32 Agenten auf einem DGX Spark sind die entscheidenden Faktoren – weitaus wichtiger als der Indexwert.

Einbetriebliche und Edge-Einsatzmöglichkeiten. Eine Q4-Größe von 2,78 GB läuft problemlos auf Consumer-Hardware, Smartphones und Mini-PCs über GGUF oder MLX.

Workflows, die lange Tool-Logs oder Dokumente speichern und tatsächlich das 131K-Fenster nutzen, ohne eine separate Abrufschicht.

Lokaler Inferenzbetrieb, bei dem die Latenz entscheidend ist, wobei MiniCPM5-2B-DSpark als Entwurfsmodell für spekulative Dekodierung verwendet wird.

Einschränkungen:

Kreative oder freiformige Codegenerierung. In externen Tests erzielte das Modell schlechtere Ergebnisse als spezialisierte Codierungsmodelle bei Aufgaben wie der Erstellung von HTML-Seiten oder SVG-Kunstwerken, da die Stärke des Modells in Logikvermögen, Mathematik, Tool-Nutzung und Funktionsaufrufen liegt.
SQL-Debugging für schema-spezifische Strukturen sowie mehrsprachige Übersetzung – hier versagte das Modell oft unzuverlässig anstatt elegant.
Alles, was über ein komplexeres agentes-basiertes Framework geleitet wird. Ein Produktions-Coding-Agent, der mit mehrstufigen Terminal-Sitzungen oder Pro-Tier SWE-Bench-Aufgaben konfrontiert ist, weist im Vergleich zu Qwen3.5-4B ein Zwei- bis Dreifach-Defizit auf – und das ist kein Rundungsfehler.

Um Fairness willen, da manche Überzeugungen dies überspringen: Der Einwand, dass Vergleiche veraltete Baselines wie Qwen2.5-2B oder Gemma-2B verwenden, gehört zu sekundären Kommentaren und nicht zur offiziellen Modellbeschreibung. In dieser werden aktuelle Modelle wie Qwen3.5-2B, Gemma-4-E2B-it, granite-4.2-3B und LFM2.5-2.6B verglichen. Kritik an dieser Version sollte sich auf ihren wahren Schwachpunkt, das Defizit im agentes-basierten Framework, richten und Verweise auf veraltete Baselines vermeiden, die von der Quelle selbst widerlegt werden.

Benchmark-Ansprüche sind benchmark-spezifisch

Wenn man über dieses eine Modell hinausblickt, ist die allgemeine Erkenntnis der wichtige Punkt, den man beibehalten sollte. Die Behauptung bezüglich Beats-4B ist zwar richtig, aber begrenzt. Sie stützt sich auf die Mathematik von OpenBMB sowie auf die Einzelversuchskodierungs-Tools AIME, LiveCodeBench und SWE-bench Verified, außerdem auf die Artificial Analysis-Daten, sobald die Version korrigiert ist. Auf Terminal-Bench und SWE-bench Pro hingegen versagt sie, wobei Qwen3.5-4B zwei- bis dreimal besser abschneidet. All das ist gleichzeitig richtig.

Die Vorgehensweise für zukünftige Behauptungen bezüglich Modellen unter 4B: Man sollte sie zunächst durch mindestens einen adversarialen Benchmark führen, der realen Anwendungen entspricht – wie Terminal-Bench, SWE-bench Pro oder etwas Ähnliches –, bevor man eine Einzelversuchslösung nutzen lässt, um vorherzusagen, wie sich das Modell schlagen wird. Das Erstellen eines Patches und das Ausführen einer mehrstufigen Aufgabe sind unterschiedliche Fähigkeiten; ein Modell kann in der einen Aufgabe hervorragend sein, in der anderen jedoch durchschnittlich abschneiden. Die im Twitter veröffentlichten Zusammenfassungen geben nie an, welche dieser Fähigkeiten gezeigt werden.

Bei jedem auf einer bestimmten Version fixierten aggregierten Index, egal ob von Artificial Analysis oder einer anderen Quelle, ist die Versionsnummer keine optionale Metadatenangabe. Sie unterscheidet echte Abweichungen von künstlich erzeugten. Die Geschichte mit 23 gegen 15 sah etwa einen Tag lang wie ein Skandal aus, bis die Methodenbeschreibungen einen gewöhnlichen Versionswechsel zeigten. Die nächste Kontroverse bezüglich von Benchmarks könnte sich auf dieselbe Weise lösen oder auch nicht – der einzige Weg, das herauszufinden, ist, nachzuprüfen.

Was man daraus lernen kann

Angesichts seiner Größe ist MiniCPM5-2B tatsächlich gut konzipiert: Er verfügt über 42 Schichten, ein GQA-Verhältnis von 8 zu 1, 131 K an nativem Kontext, offene Trainingsdaten sowie acht koordinierte Artefakte, die Zielgeräte von einem DGX Spark bis zu einem Laptop abdecken. Die Tatsache, dass er in einigen Benchmarks erfolgreich ist und in anderen nicht, ändert daran nichts. Benchmarks sind eng gefasste Instrumente, die jeweils nur etwas Bestimmtes messen, und eine Gesamtpunktzahl sagt niemals die ganze Wahrheit.

Bevor Sie das nächste kleine Modell wählen, das zu gut klingt, um wahr zu sein, führen Sie zumindest einen adversarialen Agentic-Benchmark durch und überprüfen Sie die zugrunde liegende Version jedes aggregierten Indexwerts. Ein einzelner Schlagzeilenwert sollte nicht über die Wahl einer Architektur entscheiden.