MiniCPM5-2B-DSpark: OpenBMB gibt im Stillen die MiniCPM5-2B-Gewichte frei, mit einem für Geschwindigkeit gebauten Draft-Modell

Vor sechs Wochen war MiniCPM5-2B ein Versprechen. Enthüllt am 19. Juli 2026 auf der WAIC-Konferenz in Shanghai als das Sub-4B-Modell an der Spitze des Artificial Analysis Index, kam es mit der Roadmap-Notiz, dass es „bald“ offene Gewichte geben würde. Dieses „bald“ wurde diese Woche wahr – ganz ohne Aufsehen. Am 6. September 2026 lud OpenBMB das Flaggschiff-Repository MiniCPM5-2B unter einer Apache-2.0-Lizenz auf Hugging Face hoch, und einundzwanzig Minuten später folgte MiniCPM5-2B-DSpark – ein Draft-Checkpoint mit 323,8 Millionen Parametern, dessen einzige Aufgabe darin besteht, MiniCPM5-2B mithilfe des spekulativen Dekodierungsalgorithmus DSpark schneller dekodieren zu lassen. Am 7. September 2026 folgte ein GPTQ-Build. Zum Zeitpunkt des Schreibens konnten wir weder eine Ankündigung, einen Launch-Post noch einen Changelog-Eintrag finden; die Veröffentlichung vollzog sich still und leise, als Repositories über einen Zeitraum von elf Tagen hinweg öffentlich geschaltet wurden.

Dies ist ein Beitrag vom Typ „Was wir bisher wissen“, und der Rahmen ist entscheidend. MiniCPM5-2B-DSpark ist kein eigenständiger Chatbot und kein neues Flaggschiff – es ist ein Beschleuniger: ein kleines, schnelles Modell, das Token vorschlägt, die MiniCPM5-2B dann parallel verifiziert. Ohne sein Zielmodell ist es nutzlos, und genau dieses Zielmodell ist der Grund, warum es relevant ist. Die Open-Weight-Veröffentlichung von MiniCPM5-2B, die OpenBMB für Juli angekündigt hatte, ist jetzt tatsächlich auf Hugging Face verfügbar, und das zusammen mit ihr veröffentlichte Draft-Modell ist der Mechanismus, den der Anbieter für den Betrieb mit brauchbarer Geschwindigkeit empfiehlt. Alles, was im Folgenden nicht ausdrücklich anders zugeordnet wird, ist direkt von den beiden Modellkarten und ihren Repositories abgelesen.

Was wurde veröffentlicht, und wann?

Die 2B-Familie wurde als ein fortlaufender, unangekündigter Drop veröffentlicht, die neuesten Einträge zuerst:

• 2026-08-27 — MiniCPM5-2B-Base und MiniCPM5-2B-SFT erscheinen, die rohen, vortrainierten und überwacht feinabgestimmten Checkpoints.

• 2026-09-01 — MiniCPM5-2B-Midtrain, die agentische Mid-Training-Phase.

• 2026-09-05 — MiniCPM5-2B-MLX und MiniCPM5-2B-GGUF, die Apple-Silicon- und llama.cpp-Formate.

• 2026-09-06 — das Flaggschiff-Repo MiniCPM5-2B, dann MiniCPM5-2B-DSpark einundzwanzig Minuten später.

• 2026-09-07 — MiniCPM5-2B-GPTQ, das quantisierte Serving-Format.

Alle tragen die Apache-2.0-Lizenz, die ModelBest bereits im Mai für die MiniCPM5-1B-Familie verwendet hat, und die früheren Checkpoints in der Sequenz zeigen weiterhin praktisch kein Community-Signal – jeweils eine Handvoll Downloads und Likes. Das ist ein Zeichen für einen laufenden Weight-Drop und nicht für einen koordinierten Launch: Die Artefakte erscheinen in Abhängigkeitsreihenfolge (zuerst Base und SFT, zuletzt quantisierte und Draft-Formate), wobei kein einzelner Tag als Veröffentlichungsdatum fungiert.

Was MiniCPM5-2B-DSpark wirklich ist

Spekulative Dekodierung teilt die Generierung in einen günstigen Proposer und einen teuren Verifizierer. Ein kleines Entwurfsmodell rät die nächsten mehreren Token; das große Modell prüft alle Vermutungen in einem einzigen Forward-Pass und akzeptiert diejenigen, mit denen es übereinstimmt. Wenn der Entwurf gut kalibriert ist, erhält man die Ausgabe des großen Modells zu einem Bruchteil der Kosten, und wenn er falsch ist, verschwendet man nur einen einzigen Verifikationsschritt. DSpark ist ein spezifisches Rezept für diese Idee, aus einem Paper, das am 06.07.2026 veröffentlicht wurde (arXiv 2607.05147, „Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation“). Zwei Designentscheidungen zeichnen es aus: Es koppelt ein paralleles Entwurfs-Backbone mit einem leichtgewichtigen sequenziellen Modul, sodass Tokens innerhalb eines vorgeschlagenen Blocks voneinander abhängen, anstatt gegen Ende des Blocks an Genauigkeit zu verlieren, und es bemisst jeden Verifikationslauf pro Anfrage anhand von Konfidenzschätzungen und Engine-Durchsatz, anstatt immer einen Block fester Länge zu verifizieren.

Das von OpenBMB veröffentlichte DSpark-Draft-Modell ist ein fünfschichtiger Transformer mit 323,8 Millionen Parametern in BF16 (etwa 648 MB). Es gehört zur Qwen3-Architekturfamilie, enthält aber DSpark-spezifische Erweiterungen: einen Projektor, der die versteckten Zustände von MiniCPM5-2B aus fünf der Zielschichten (1, 10, 20, 30 und 39) liest, einen Konfidenz-Head sowie einen kleinen Markov-Head, der die Verteilung des nächsten Tokens modelliert. Seine Konfiguration sieht einen Block aus sieben Tokens pro Vorwärtsdurchlauf vor. Mit etwa einem Achtel der 2,5 Milliarden Parameter von MiniCPM5-2B ist es eines der kleinsten Draft-Modelle, die je für einen gängigen offenen Checkpoint veröffentlicht wurden – und genau das ist der Punkt bei einem edge-orientierten Modell, bei dem das Draft-Modell billig genug sein muss, dass der Betrieb von zwei Modellen auf einem Gerät immer noch besser ist, als nur ein Modell auszuführen.

Das obige Repository ist die gesamte öffentliche Oberfläche des Entwurfsmodells: eine README, eine Konfiguration, eine einzelne Safetensors-Datei und eine Modellkarte, deren Trainingsbeschreibung 1.959.525 Sequenzen (7,05B Token) zeigt, die von MiniCPM5-2B aus allgemeinen, mathematischen und Code-Prompts erzeugt wurden, trainiert über sechs Epochen mit einer kombinierten Kreuzentropie-, L1- und Konfidenz-Zielfunktion. Der Checkpoint wird nicht als eigenständiges generatives Modell verwendet.

Die Zahlen, die OpenBMB veröffentlicht hat, ehrlich gekennzeichnet.

Die Karte des Draft-Modells weist eine entscheidende Kennzahl aus – die Akzeptanzlänge, also die durchschnittliche Anzahl vorgeschlagener Tokens, die das Zielmodell aus jedem Sieben-Token-Block akzeptiert. Die Auswertung erfolgte anhand von Ausgaben von MiniCPM5-2B in drei Bereichen mit bis zu 4.096 generierten Tokens:

• Mathematik — durchschnittlich 6,05 Token bei Greedy (T=0) akzeptiert; 4,61 bei T=1,0-Sampling.

• Code — 6,11 Greedy; 4,44 Sampling.

• Allgemein — 4,16 greedy; 3,10 sampled.

• Aggregat — 5,52 greedy; 4,05 gesampelt, von maximal sieben.

Bei diesen Zahlen handelt es sich um Herstellerangaben aus dem Model Card; sie wurden nicht unabhängig reproduziert. Sie beschreiben außerdem die Trefferquote des Draft-Modells, nicht eine Beschleunigung der realen Laufzeit (Wall-Clock-Zeit): Geschwindigkeit ist eine Serving-Messgröße, die davon abhängt, was der Verifikationsdurchlauf des Zielmodells gegenüber dem Vorschlagsdurchlauf des Draft-Modells kostet, von der Batch-Auslastung und davon, dass der Confidence-Scheduler von DSpark die Verifikationslänge verkürzt. OpenBMB hat für das Paar keine Tokens-pro-Sekunde-Angabe veröffentlicht. Um eine Vorstellung von der Leistungsgrenze der Methode zu bekommen, berichtet das DSpark-Papier von einer um 60–85 % schnelleren Generierung pro Nutzer bei gleichem Durchsatz gegenüber der MTP-1-Baseline im Live-Serving-System von DeepSeek — ein nützlicher Referenzpunkt dafür, was der Algorithmus andernorts erreicht hat, aber keine Aussage über MiniCPM5-2B auf Ihrer Hardware.

Die obige Anzeigetafel ist das eigene Spezifikationsblatt des Releases. Verstehen Sie die Akzeptanzzahl als vorläufige Trefferquote; den Multiplikator auf den tatsächlichen Durchsatz muss ein unabhängiger SGLang-Lauf noch messen.

Das Modell, das der Entwurf beschleunigt

MiniCPM5-2B ist ein dichter Transformer mit 2,5 Milliarden Parametern – insgesamt 2.516.756.480 – mit 42 Schichten, 16 Query-Heads und 2 KV-Heads, einem Vokabular von 130.560 Token und einem Kontextfenster von 131.072 Token; im BF16-Format belegt er etwa 5 GB. Architektonisch ist er bewusst langweilig: ein standardmäßiger LlamaForCausalLM ohne benutzerdefinierte Kernel und ohne Modellcode-Abspaltung – genau das ist der Grund, warum er sich auf so viele Laufzeitumgebungen und Chip-Zielplattformen portieren lässt. In OpenBMBs eigener interner Benchmark-Suite erhält er laut Datenblatt einen Durchschnitt von 53,9 über Aufgaben in den Bereichen Reasoning, Instruktionsbefolgung, Wissen, Langkontext, Tool-Nutzung, Codierung und Such-Agenten – in derselben Tabelle liegt er damit vor Qwen3.5-4B mit 51,1 und granite-4.2-3B mit 42,7, wobei mehrere Zellen (GPQA-Diamond 70,2, HLE 8,9 sowie verschiedene Langkontext- und Agentik-Zeilen) als von Artificial Analysis stammend und nicht als hausintern reproduziert gekennzeichnet sind. Die wichtigsten Zellen je Aufgabe umfassen MATH-500 mit 94,6, AIME 2025 und 2026 mit 86,5, IFEval mit 86,7, MMLU-Pro mit 70,8 und SWE-bench Verified mit 46,4. Dies sind die Zahlen des Anbieters in der Suite des Anbieters, und das Datenblatt weist ausdrücklich darauf hin, dass einige Zeilen aus Drittquellen stammen; behandeln Sie die Mischung entsprechend.

Bei der Vorstellung im Juli führten die Startmaterialien von ModelBest einen Artificial Analysis Index von 17 an – den ersten unter Modellen mit weniger als 4B Parametern – und die Berichterstattung vom Juli verwies auf ein Fenster von 512K-Token. Die tatsächlich ausgelieferten Checkpoints sind für einen Kontext von 131.072 Token konfiguriert. Wenn eine Marketingzahl vom Starttag und eine ausgelieferte Konfiguration voneinander abweichen, ist die Konfiguration die Zahl, die bestimmt, was Sie ausführen können, und die Lücke sollte man kennen, bevor man eine Arbeitslast mit langem Kontext um die Marketingzahl herum plant.

Ausführen von MiniCPM5-2B mit seinem Draft

Der vorgesehene Weg ist SGLang, das den DSpark-Algorithmus seit v0.5.16 im Upstream unterstützt — die Mindestversion, die die Modellkarte verlangt. Der vollständige Serving-Befehl aus der Karte:

python -m sglang.launch_server --model-path openbmb/MiniCPM5-2B --speculative-algorithm DSPARK --speculative-draft-model-path openbmb/MiniCPM5-2B-DSpark --speculative-dspark-block-size 7

Unter Greedy-Decoding (T=0) ist die DSpark-Verifikation verlustfrei: Die Ausgabe ist identisch mit dem alleinigen Serving von MiniCPM5-2B, wodurch der Draft eine reine Latenzoptimierung darstellt. Bei aktiviertem Sampling verwendet SGLang's DSpark standardmäßig reines Target-Sampling, optional mit Rejection Sampling. OpenBMB dokumentiert außerdem das einfache Laden über Transformers (transformers ≥ 5.6) sowie das eigenständige Serving des Targets über vLLM ≥ 0.21, dazu einen minicpm5-Tool-Call-Parser für agentische Workloads; der spekulative DSPARK-Pfad gehört ausdrücklich zu SGLang.

Die eigentliche Geschichte bei einem Paar der Edge-Klasse ist die Hardware-Rechnung: etwa 5 GB für MiniCPM5-2B in BF16 plus rund 0,65 GB für den Draft. Die Kombination aus Draft und Zielmodell passt bequem überall dort hinein, wo das 2B-Modell allein bereits tragfähig war – und genau das ist der gesamte Grund, einen so kleinen Draft auszuliefern statt eines zweiten, größeren Modells.

Was ist nicht bestätigt?

• Es gibt keine Ankündigung, die wir finden konnten – keinen OpenBMB- oder ModelBest-Blog, keinen Social-Media-Beitrag auf Englisch oder Chinesisch. Die Formulierung „leise veröffentlicht“ ist wörtlich zu verstehen, und die einzige öffentliche Präsenz ist die Hugging-Face-Sammlung.

• Keine unabhängige Bewertung. Die Akzeptanzlängen des Entwurfs und der 53,9er Suite-Durchschnitt von MiniCPM5-2B sind herstellerseitig gemeldet und nicht reproduziert; die AA-markierten Zellen stammen zwar von Drittanbietern, sind aber Momentaufnahmen und keine Läufe mit diesen exakten Gewichten.

• Wir können nirgendwo eine gehostete API finden, daher bedeutet die Einführung heute, die Checkpoints selbst auszuführen. Ein ModelScope-Spiegel, der in der Berichterstattung über die Enthüllung im Juli versprochen wurde, war zum Zeitpunkt des Schreibens nicht sichtbar.

• Für das DSPARK-Paar gibt es keine Zahl zur Echtzeit-Beschleunigung (Wall-Clock). Eine Akzeptanzlänge von 5,52 ist eine starke Trefferquote, aber „wie viel schneller“ auf einer bestimmten GPU ist genau die Zahl, die OpenBMB nicht veröffentlicht hat.

• Die obige Mehrdeutigkeit des Kontextfensters: Marketingmaterialien sprachen von 512K, die ausgelieferte Konfiguration gibt 131,072 an, und nichts in den Repos überbrückt die beiden.

Wo ein unauffälliger Open-Weight-Release in einen Stack passt

Die ehrliche Einschätzung von MiniCPM5-2B heute ist, dass es eine Wette ist: starke Herstellerzahlen, null unabhängige Läufe, keine Serving-Historie und ein Draft-Modell, dessen realer Speedup ungemessen ist. Genau für diese Situation gibt es eine Routing-Ebene. Ein Team, das testen möchte, ob die Ausgaben eines kleinen Open-Source-Modells ein gehostetes Modell ersetzen können, das es bereits aufruft, kann diesen Vergleich über eine einzige API laufen lassen — OrcaRouter vermittelt 200+ gehostete Modelle zum Listenpreis des Anbieters ohne Aufschlag, sodass eine Evaluationswoche nichts kostet, um sie aufzusetzen, und automatisches Failover bedeutet, dass ein einige Tage alter Checkpoint niemals einen Produktionspfad als Geisel halten muss, während er sich beweist. Nichts davon erfordert, dass MiniCPM5-2B irgendwo gehostet wird; es ist das Sicherheitsnetz um die Modelle, von denen Sie bereits abhängen, während Sie entscheiden, ob ein selbst gehostetes 2B die GPU wert ist.

Achten Sie, in dieser Reihenfolge der Wichtigkeit: auf einen unabhängigen SGLang-DSPARK-Lauf, der die echten Tokens pro Sekunde für das Paar berichtet, da die Akzeptanzlänge ein Stellvertreter und kein Benchmark ist; auf eine offizielle Ankündigung oder einen ModelScope-Spiegel, der bestätigt, dass die Veröffentlichung final ist; und auf einen Hosting-Anbieter, der MiniCPM5-2B aufnimmt – falls einer das tut, ist der Preis, den Sie bei uns zahlen, der eigene Listenpreis des Anbieters, am selben Tag, denn genau das bedeutet Pass-through. In der Zwischenzeit ist das Draft-Modell das interessantere der beiden Artefakte. Ein fünfschichtiger Proposer, dessen Vorschläge das Zielmodell fünfeinhalb von sieben Tokens akzeptiert, ist der Unterschied zwischen einem kleinen Edge-Modell, das sich klein anfühlt, und einem, das sich anfühlt wie ein größeres Modell, das auf demselben Gerät läuft.