MiniCPM-V 4.7-35B-A3B-DSpark: OpenBMBs 389M-Draft erscheint mit einer Modellkarte, die sein Basismodell nie bekam

MiniCPM-V-4.7-35B-A3B-DSpark ist ein Draft-Modell mit 389.223.169 Parametern. Es beantwortet keine Fragen, es sieht keine Bilder, und für sich allein genommen ist es nutzlos. Seine gesamte Aufgabe besteht darin, die nächsten fünfzehn Tokens zu erraten, damit MiniCPM-V-4.7-35B-A3B einen ganzen Block in einem einzigen Forward-Pass verifizieren kann, anstatt ein Token nach dem anderen zu erzeugen. Das ist spekulatives Decoding, und OpenBMB hat vor elf Tagen einen Draft für sein neues 35B-Vision-Language-Modell veröffentlicht, ohne öffentlich ein Wort darüber zu sagen.

Was es wert ist, eine Seite zu bekommen, ist nicht der Entwurf. Es sind die Unterlagen, die mit ihm kamen. Der DSpark-Checkpoint hat eine Modellkarte: eine Lizenz, eine Spezifikationstabelle, ein Trainingsrezept und eine Akzeptanzlängentabelle für sieben Aufgabenkategorien. Sein Elternmodell mit 35 Milliarden Parametern hatte nichts davon, als es erschien. Zum ersten Mal gibt es also konkrete Zahlen zu einem Release von MiniCPM-V 4.7 – und es sind Zahlen über das Elternmodell, indirekt gemessen von einer 0,78 GB großen Datei, deren erklärter Zweck es ist, es schneller zu machen.

Alles Folgende trennt das, was auf der Karte steht, von dem, was die Karte nicht belegt. Die Akzeptanzzahlen stammen von OpenBMB selbst, und niemand außerhalb des Labors hat sie reproduziert. Die Benchmark-Tabelle des Basismodells existiert nach wie vor nicht.

Was der DSpark-Checkpoint tatsächlich ist

Das Repository openbmb/MiniCPM-V-4.7-35B-A3B-DSpark stammt vom 8. Oktober 2026. Es ist ein Single-File-Checkpoint – model.safetensors, plus eine config.json und ein README – unter Apache-2.0, getaggt für Englisch und Chinesisch. Ein zweiter Entwurf, openbmb/MiniCPM-V-4.7-1B-DSpark, wurde eine Sekunde früher erstellt, sodass die beiden im selben Batch auf den Hub gepusht wurden, statt einzeln entdeckt zu werden.

Jedes Draft-Modell steht vor genau einem Target – und nur vor diesem. Auf der Karte steht es unmissverständlich: Dieser Checkpoint ist „für die exakte Paarung mit MiniCPM-V-4.7-35B-A3B und dessen Tokenizer trainiert“. Das Vokabular stammt vom Elternmodell, alle 248.144 Tokens davon, was eine Voraussetzung und nicht eine Optimierung ist – ein Drafter, dessen Tokens sich nicht eins zu eins auf die des Targets abbilden lassen, kann nichts vorschlagen, was das Target akzeptieren könnte. Dieselbe Einschränkung ist der Grund, warum das Geschwister-Draft separat existiert, statt dass ein einziger Drafter die Familie bedient.

Die Architektur ist keine verkleinerte Kopie des übergeordneten Modells. Sie ist ein fünfschichtiger Attention-Stack, 2.048 Hidden-Breite, 8 Query-Heads gegenüber 2 Key/Value-Heads, eine Intermediate-Size von 6.144 und RoPE mit einem Theta von 10.000.000. Das Feld architectures hat den Wert Qwen3DSparkModel — dasselbe Backbone der Qwen3-Familie, aus dem der Sprach-Stack des übergeordneten Modells stammt, zu einem Stub reduziert.

Das Interessante daran ist, wie der Stub mit dem Target kommuniziert. Er liest nicht die letzte Schicht des Targets. Er zapft Hidden States aus fünf intermediären Schichten ab — [3, 11, 19, 27, 35] von den 40 des Parents — und projiziert sie durch einen dspark-Typ-Projektor. Dass aus der Mitte des Stacks statt vom Ende gezogen wird, ist Absicht: Zustände aus der Netzwerkmitte sind günstiger auszurichten und tragen Informationen, die die letzte Schicht bereits in Next-Token-Logits komprimiert hat. Die Konfiguration versieht außerdem einen Confidence-Head mit einer Markov-Komponente vom Rang 256, was der Mechanismus aus dem DSpark-Paper ist, um zu entscheiden, wie viel eines vorgeschlagenen Blocks es wert ist, verifiziert zu werden.

Die Abnahmetabelle ist eine Karte, keine Messung.

Hier ist alles Numerische, das OpenBMB darüber veröffentlicht hat, wie gut dieses Paar funktioniert, ausgedrückt als akzeptierte Tokens pro Verifikationsschritt, mit natürlicher EOS-Terminierung und max_new_tokens=8192:

• Vision, MMMU — 5,098 akzeptierte Tokens pro Schritt.

• Vision, MathVista — 6.126.

• Vision, CharXiv-Reasoning (Validierung) — 5.479.

• Vision, OCRBench — 5.407.

• Text, Mathe — 6.687.

• Text, – 7.387.

• Text, Allgemein — 3.501.

Drei Dinge an dieser Tabelle sind es wert, laut ausgesprochen zu werden. Erstens: Sie beruht auf Selbstauskunft. Niemand außerhalb von OpenBMB hat diesen Checkpoint ausgeführt und eine Zahl veröffentlicht, und bei einem einzigen im Repo verzeichneten Download hat ihn außerhalb von OpenBMB überhaupt niemand ausgeführt. Zweitens ist die Akzeptanzlänge eine Eigenschaft des Paares, nicht des Modells – sie misst, wie vorhersagbar die Ausgabe von MiniCPM-V-4.7-35B-A3B ist, nicht, wie gut diese Ausgabe ist. Ein Target, das sich selbst wiederholt, verschafft einem Drafter einen leichten Sieg. Drittens ist die Spannweite die eigentliche Aussage: 7,387 bei Code gegenüber 3,501 bei allgemeinem Text ist ein Faktor zwei zwischen der besten und der schlechtesten Kategorie, und dass Code am einfachsten ist, spiegelt eher die niedrig-entropische, hochrepetitive Oberfläche von Code wider als irgendeine Stärke der Modelle.

Es gibt außerdem eine rein rechnerische Lesart, die in der Karte nur implizit bleibt. Ein Drafter, der 15 Token vorschlägt und bei dem 5 bis 7 akzeptiert werden, befördert pro Target-Vorwärtsdurchlauf weiterhin mehrere Token, die Obergrenze ist hier also ein großer Durchsatzgewinn – aber es ist nicht die naive Behauptung „5× schneller“, denn die Verifikation eines 15-Token-Blocks kostet mehr als die Generierung eines Tokens, und die abgelehnten Vorschläge werden bezahlt und verworfen. Genau um diese Lücke geht es im DSpark-Paper, und deshalb bietet die Konfiguration einen Schalter, um die adaptive Verifikation abzuschalten.

Was der Entwurf uns versehentlich über das Basismodell verrät

MiniCPM-V 4.7 bezeichnete sein Release als still ausgeliefert — Gewichte, kein Launch-Post. Das hat sich nun geändert, auf eine kleine, aber reale Weise. Das übergeordnete Repository unter openbmb/MiniCPM-V-4.7-35B-A3B wurde am 7. Oktober 2026 erstellt. Bis zum 12. Oktober enthielt es eine vollständige Modellkarte mit einer README, einer Release-Seite im Hugging-Face-Stil, einer Liste von Behauptungen, einem On-Device-Abschnitt und einer Gewichtstabelle. Seitdem ist im Repository eine Quantisierungsfamilie entstanden — FP8-, int4-, AWQ-, GPTQ- und GGUF-Builds, jeweils in einem eigenen Repository, alle am 12. Oktober bearbeitet — und 27 Likes gegenüber 166 Downloads.

Das zutreffende Bild ist also eine zweistufige Veröffentlichung, keine stille. Die Gewichte erschienen am 6. und 7. Oktober. Die Draft-Checkpoints folgten am 8. Oktober. Die Dokumentation, die Quantisierungen und die On-Device-Story waren bis zum 12. Oktober verfügbar. OpenBMB hat für die Modellfamilie noch immer weder einen Blogbeitrag noch einen technischen Bericht veröffentlicht, und auf der übergeordneten Modellkarte gibt es weiterhin keine Benchmark-Tabelle – die Leistungsbehauptungen stecken in verlinkten Diagrammabbildungen statt als Text, den man zitieren kann.

Die Behauptung, die im Text tatsächlich auftaucht, ist die aus der Schlagzeile: Mit Lookahead Expert Scheduling, schichtweiser Quantisierung und „DSpark speculative sampling integration“ wird das 35B-A3B-Modell als das erste Open-Source-MoE-Modell beschrieben, das auf dem Gerät reibungslos läuft, mit mehr als 13 Tokens pro Sekunde auf einem iPhone 17 Pro Max. Diese Zahl ist vom Anbieter gemeldet, nicht reproduziert und ohne nähere Angaben — kein Quantisierungsformat, kein Build, kein Prompt, keine Messmethode. Der DSpark-Checkpoint ist eine der drei Techniken, auf denen diese Behauptung beruht, was ihn zur einzigen der drei macht, die man herunterladen und untersuchen kann. Er ist außerdem derjenige, dessen Beleg eine einzige ungelesene Benchmark-Zeile pro Aufgabe ist.

Es ausführen, wenn du möchtest

Die Karte liefert ein einziges Rezept, und es ist ein vLLM-Befehl, kein bloßes Handwedeln. Es bedient das Zielmodell mit Tensor-Parallel-Größe 2, einer maximalen Modelllänge von 40.960, FLASH_ATTN sowohl für die Attention-Backends des Sprach- als auch des multimodalen Encoders, einem visuellen Downsample-Modus von 4x, enable_thinking auf false gesetzt und die spekulative Konfiguration auf den DSpark-Checkpoint verweisend, mit 15 spekulativen Tokens und deaktivierter adaptiver Verifikation. Zwei Details in dieser Zeile sind für sich genommen beachtenswert: --max-num-seqs 1 bedeutet, dass das veröffentlichte Setup jeweils nur eine Sequenz bedient, und --disable-custom-all-reduce bei deaktiviertem All-Reduce-Fusions-Pass bedeutet, dass dies eine Konfiguration ist, die eher darauf abgestimmt wurde, zu funktionieren, als maximal schnell zu sein. Betrachten Sie das Rezept als Ausgangspunkt, den OpenBMB zum Laufen gebracht hat, nicht als Durchsatzversprechen.

Der Hardware-Rahmen ist die eigentliche Barriere. Die Zielgröße liegt bei grob 70 GB BF16-Gewichten vor dem KV-Cache, und der Draft fügt obendrauf etwa 0,78 GB hinzu. Zwei Beschleuniger sind das angegebene Minimum, was dies weit außerhalb des Smartphones verortet, auf das sich das Marketing der Familie stützt — ein On-Device-Deployment für ein 35B-A3B-Modell bedeutet aggressive Quantisierung und Offloading, wofür die LES- und Layer-wise-Quantisierungsarbeit gedacht ist, und keines von beiden ist im obigen vLLM-Rezept enthalten.

Diese Asymmetrie ist für die meisten Teams die praktische Entscheidung. MiniCPM-V 4.7 selbst zu betreiben kostet zwei GPUs, die Ihnen gehören; einen vergleichbaren gehosteten multimodalen MoE aufzurufen kostet im Voraus nichts. Qwen3.6 35B A3B ist der nächstliegende direkte Vergleich – dieselbe Form mit 35B insgesamt und 3B aktiv, derselbe 262K-Kontext, Bild- und Videoeingabe – und wird über OrcaRouter ab 0,248 $ pro Million Eingabe-Tokens und 1,485 $ pro Million Ausgabe-Tokens angeboten, je nach Provider-Route, mit automatischem Failover, falls eine dieser Routen beeinträchtigt ist. MiniCPM-V 4.7 ist kein gehostetes Modell auf OrcaRouter, und dieser Artikel wird nicht so tun, als wäre es anders; die ehrliche Einordnung ist, dass die beiden Alternativen an einem Entscheidungspunkt sind, und das gehostete ist das, das Sie heute Nachmittag messen können.

Was würde das überprüfbar machen?

Der DSpark-Checkpoint steht unter Apache-2.0, ist unter einem Gigabyte groß und wird mit einem Serving-Befehl geliefert, den jemand mit zwei GPUs heute in ein Terminal einfügen könnte. Diese Kombination macht ihn zum günstigsten Weg zu einer unabhängigen Zahl auf MiniCPM-V 4.7 – keinem Benchmark-Score, sondern etwas fast ebenso Nützlichem: einer reproduzierten Akzeptanzlänge. Wenn eine externe Partei 5,1 auf MMMU und 3,5 bei allgemeinem Text erreicht, ist die Karte glaubwürdig, und die Effizienz-Story der Familie erhält ihren ersten externen Datenpunkt. Wenn die Akzeptanz deutlich niedriger ausfällt, wurde die veröffentlichte Tabelle unter Bedingungen gemessen, die das Rezept nicht reproduziert, und die Behauptung von 13 Tokens pro Sekunde erbt diesen Zweifel.

Was noch fehlt, ist genau das, wofür eine Modellkarte normalerweise da ist. Es gibt keinen MMMU-Score, keinen OCRBench-Score, kein Ergebnis zum Dokumentenverständnis, keine Grounding-Zahl und keinen Latenzwert für MiniCPM-V 4.7 selbst – nichts, was die Frage beantwortet, ob dieses Modell gut ist. Die Tabelle des Draft-Modells kann das nicht ersetzen, und eine hohe Acceptance Length als Qualitätssignal zu lesen, ist genau der Fehler, zu dem die Zahlen verleiten. Eine Vorhersage im ChatGPT-Stil ist für einen Drafter einfach und sagt nichts darüber aus, ob die Vorhersage richtig war.

So: ein echtes Artefakt, eine echte Lizenz, ein wirklich neuer veröffentlichter Beleg über ein Modell, für das es bislang keinen gab – und eine Evaluationslücke, die genau so groß ist wie am 7. Oktober. Die nächste Datei, die aktualisiert werden muss, ist nach wie vor die Modellkarte des übergeordneten Modells.