MiniCPM-V-4.7-1B-DSpark: Ein 213M-Draft-Modell, ohne Ankündigung veröffentlicht

MiniCPM-V-4.7-1B-DSpark ist ein Checkpoint mit 213.547.777 Parametern, der keine Frage beantworten kann. Er liest keine Bilder, er führt keine Unterhaltung, und für sich allein betrieben erzeugt er nichts Lesenswertes. Seine ganze Aufgabe besteht darin, vor einem Modell – MiniCPM-V-4.7-1B – zu sitzen und die nächsten fünfzehn Tokens zu erraten, damit ein kleines Vision-Language-Modell der Handyklasse einen Block davon in einem einzigen Forward Pass verifizieren kann, statt sie eines nach dem anderen zu generieren.

Die Datei ist 0,85 GB groß und steht unter Apache-2.0, und sie erschien am 8. Oktober 2026 um 04:26 UTC auf Hugging Face, im selben Batch wie der Entwurf für das größere Schwestermodell 35B-A3B. Vier Tage später behandelt die übergeordnete Karte sie noch immer als Fußnote: Der Entwurf erscheint einmal, als Zeile in der Gewichtstabelle und hinter einem eingeklappten Umschalter „Spekulative Dekodierung (DSpark)“. Es gibt keinen OpenBMB-Blogbeitrag dazu, keinen technischen Bericht und keinen Eintrag in der projekteigenen GitHub-Dokumentation.

Das Schweigen ist der interessante Teil, und zwar wegen dessen, was genau diese Datei möglich macht. Sie ist das erste Artefakt in der MiniCPM-V-4.7-Familie, dessen zentrale Behauptung – dass ein 1B-Vision-Modell auf einem Telefon akzeptabel läuft – von jemandem außerhalb von OpenBMB überprüft werden kann. Alles Folgende hält zwei Stapel getrennt: das, was eine Datei auf der Festplatte ist, die man öffnen kann, und das, was eine Zahl ist, die der Anbieter daneben gedruckt hat.

Was ist eigentlich im Repository?

Vier Dateien. Das ist alles: .gitattributes, README.md, config.json, und eine einzige model.safetensors mit 854.204.052 Bytes an BF16-Gewichten. Im Repository gibt es keinen Tokenizer, weil es keinen geben muss – der Draft leiht sich den des Targets, und das Vokabular in seiner Config sind exakt die 248.094 Tokens des Parents. Ein Drafter, dessen Tokens nicht eins zu eins auf die des Targets abbilden, kann nichts vorschlagen, was das Target akzeptieren würde, daher ist das Teilen des Vokabulars eine Voraussetzung und nicht nur eine Bequemlichkeit.

Die Hub API verzeichnet das Repository als erstellt am 2026-10-08T04:26:19Z und zuletzt geändert am 2026-10-12T14:29:57Z, getaggt für Englisch und Chinesisch, lizenziert unter Apache-2.0, mit drei Likes und einem Download zum Zeitpunkt des Schreibens. Die letzte Zahl ist die, an der man sich festhalten sollte. Ein Download, vier Tage nach Veröffentlichung, bei einer Datei, die klein genug ist, um sie über eine Telefonverbindung abzurufen.

Das Architekturfeld liest Qwen3DSparkModel mit einem model_type von qwen3, was eher schlüssig als seltsam ist: Der Sprach-Backbone von MiniCPM-V 4.7 stammt aus der Qwen3-Reihe ab, also ist ein fünfschichtiger Stub, der aus derselben Familie geschnitten ist, genau das, was man erwarten würde. Was keine kleinere Kopie des Elternmodells ist, ist die Art, wie der Stub mit ihm spricht. Die Konfiguration versieht eine dflash_config mit projector_type: "dspark", enable_confidence_head: true, confidence_head_alpha: 1.0, confidence_head_with_markov: true, markov_head_type: "vanilla" und markov_rank: 256. Dieser Confidence-Head ist der Teil, der aus der DSpark-Methode übernommen wurde: Er ist die Maschinerie, um abzuschätzen, wie viel von einem vorgeschlagenen Block es wert ist, verifiziert zu werden, was der eigentliche Grund dafür ist, dass die Serving-Konfiguration einen Schalter bietet, um die adaptive Verifikation abzuschalten.

Die Spezifikation und warum jede Zahl dort steht

Draft-seitig, aus der Karte und der Konfiguration, die beide übereinstimmen:

• Draft-Parameter — 213.547.777, alle in BF16, in einem Single-File-Checkpoint von 0,85 GB

• Draft-Tiefe — 5 Schichten, durchgängig Full Attention, Hidden-Size 1.024, Intermediate-Size 3.584, SiLU-Aktivierung

• Attention-Geometrie — 8 Query-Heads gegenüber 2 Key-/Value-Heads, Head-Dimension 256, Grouped-Query-Attention

• Tokens pro Vorwärtsdurchlauf — 15, in der Konfiguration angegeben als block_size: 15

• Positionsbereich — RoPE-Theta 10.000.000 mit einem 256-dimensionalen rotierenden Embedding und max_position_embeddings auf 262.144 gesetzt, passend zum 256K-Fenster des übergeordneten Modells

• Layer antippen — [3, 7, 11, 15, 19], von den 24 des übergeordneten Layers (num_target_layers: 24)

• Vokabular — 248.094, an den Tokenizer des Zielmodells gebunden, mit einem dedizierten Mask-Token bei 248.076 für den semi-autoregressiven Drafting-Schritt

Zwei dieser Zeilen sind mehr als einen Blick wert. Die erste betrifft die Tap-Layer. Das Draft-Modell liest nicht die letzte Schicht des Parent-Modells; es liest Hidden States aus fünf über die Tiefe des Parent-Modells verteilten Schichten und projiziert sie durch einen dspark-Projektor. Zustände aus mittleren Netzwerkschichten sind günstiger abzugleichen und tragen dennoch Informationen, die die letzte Schicht bereits in Next-Token-Logits verdichtet hat. Die zweite ist die Head-Dimension von 256 gegenüber einer Hidden-Size von 1.024. Das ist ein bewusst breiter Head bei einem schmalen Modell, und die Konfiguration setzt tie_word_embeddings: false — die Embedding-Matrix wird getrennt gehalten, statt mit der Ausgabeprojektion geteilt zu werden, sodass die Parameteranzahl beide einschließt.

Alles in allem ist es ein Draft-Modell, das etwa ein Fünftel der Größe des Zielmodells hat und dabei eine völlig andere Form aufweist. Zum Vergleich: Das Draft-Modell des 35B-A3B-Geschwistermodells umfasst 389.223.169 Parameter, die auf Schichten [3, 11, 19, 27, 35] von 40 zugreifen. Zwei Draft-Modelle, eines pro Zielmodell, denn ein Draft-Modell ist stets nur für das Vokabular und die Zwischenrepräsentation gültig, gegen die es trainiert wurde.

Die Akzeptanztabelle ist eine Modellkarte, keine Messung.

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

• Vision, MMMU — 3,452 akzeptierte Tokens pro Schritt

• Vision, MathVista — 4,333

• Vision, CharXiv-Schlussfolgerung (Validierung) — 4.452

• Vision, OCRBench — 4.752

• Text, Mathematik — 5.891

• Text, Code — 5.347

• Text, allgemein — 3.370

Die Spanne reicht von 5,891 bis hinunter zu 3,370, ein Faktor von etwa 1,75 zwischen der einfachsten Kategorie und der schwierigsten. Diese Reihenfolge ist auf eine Weise wenig überraschend, die etwas über die Zahlen aussagt: Mathematik ist die regelmäßigste Oberfläche, die ein Sprachmodell erzeugt, allgemeiner Text die am wenigsten regelmäßige, und die Erfolgsquote eines Drafters richtet sich nach der Vorhersagbarkeit der Ausgabe des Ziels, nicht nach deren Qualität.

Drei Vorbehalte gehören auf diese Tabelle, und die Karte nennt keinen davon von sich aus.

Es ist eine Selbstauskunft, und es gibt genau einen Download für das Repository. Niemand außerhalb von OpenBMB hat eine Akzeptanzzahl für diesen Checkpoint vorgelegt, die sonst jemand einsehen kann. Die Zahlen stammen vom Anbieter, gemessen im Test-Harness des Anbieters, auf dem Aufgabensatz des Anbieters.

Die Akzeptanzlänge ist eine Eigenschaft des Paares, nicht des Modells. Ein Ziel, das sich selbst wiederholt, verschafft seinem Drafter einen leichten Sieg, daher ist eine höhere Zahl hier kein Beweis dafür, dass MiniCPM-V 4.7-1B in irgendetwas gut ist. Sie ist ein Beweis dafür, wie vorhersagbar seine Ausgabe ist, was eine andere Frage mit einer anderen Antwort ist.

Und es ist keine Beschleunigung. Ein Drafter, der 15 Tokens vorschlägt und bei dem 3,4 davon verifiziert werden, bewegt immer noch mehrere Tokens pro Vorwärtsdurchlauf des Zielmodells, aber die Verifizierung eines 15-Token-Blocks kostet mehr als die Generierung eines Tokens, und jeder abgelehnte Vorschlag wird bezahlt und verworfen. Um eine Akzeptanzlänge in einen Wall-Clock-Wert umzurechnen, braucht man die Verifizierungskosten, die Batch-Größe und die Hardware, von denen die Karte keines liefert. Das einzige Serving-Rezept, das sie überhaupt liefert, setzt --max-num-seqs 1, eine Konfiguration, die darauf ausgelegt ist zu funktionieren, statt darauf, schnell zu sein.

Im Vergleich zum Schwestermodell wird die Tabelle nützlicher. Der 35B-A3B-Draft erzielt 7,387 bei Code und 5,098 bei MMMU; dieser 1B-Draft erzielt 5,347 und 3,452. Kleinere Targets mit kleineren Draftern akzeptieren deutlich weniger Token pro Schritt, was genau die Art von familienübergreifendem Detail ist, das eine einzelne Karte nicht zeigen kann und zwei Karten schon.

Training und das Detail, das das gesamte Design erklärt

Das Rezept ist vier Zeilen lang: zwei Millionen Trainingssequenzen, sechs Epochen, AdamW und eine kombinierte Zielfunktion aus Kreuzentropie, einem L1-Term und einem Konfidenzverlust. Die Zeile, auf die es ankommt, ist die darüber, woher die Trainingsdaten stammen — die Antworten wurden von MiniCPM-V-4.7-1B selbst generiert, aus einer Mischung aus Vision- und Text-Prompts.

Das ist Selbst-Destillation, und sie legt die Untergrenze dafür fest, was der Bau eines solchen Drafters kostet. Man kann einen nicht trainieren, ohne zuvor das Zielmodell in großem Umfang laufen zu lassen, und zwar über beide Modalitäten hinweg, was bedeutet, dass das 0,85 GB große Artefakt, das man herunterladen kann, der billige Rückstand eines teuren Prozesses ist. Es erklärt auch, warum der Drafter eins zu eins zugeordnet und nicht geteilt wird: Das Verhalten, das er nachahmt, ist das Verhalten dieses Modells, und die Ausgaben eines anderen Ziels würden einen anderen Drafter trainieren.

Das Paper der Methode selbst, arXiv 2607.05147, stammt nicht von OpenBMB. Es ist ein Paper mit 33 Autorinnen und Autoren, eingereicht am 6. Juli 2026, das DSpark als ein Speculative-Decoding-Framework beschreibt, das ein paralleles Backbone mit einem leichten sequenziellen Modul kombiniert und die Verifikationslänge anhand geschätzter Präfix-Überlebenswahrscheinlichkeiten plant. Es berichtet über den Einsatz in einem DeepSeek-V4-Serving-System, verwendet eine Produktions-Baseline namens MTP-1 und behauptet, dass die Generierung pro Nutzer bei gleichem Durchsatz 60 bis 85 Prozent schneller ist. Diese Behauptungen gehören zu dem Paper und zu jenem Deployment. Nichts Veröffentlichtes verbindet sie mit einem fünfschichtigen 213M-Draft auf einem 1B-Vision-Modell, und die obige Akzeptanztabelle ist die einzige Brücke, die jemand angeboten hat.

Warum diese Datei wichtiger ist, als ihre Größe vermuten lässt

Die zentrale Behauptung in der MiniCPM-V 4.7-Familie betrifft den On-Device-Einsatz. Die 1B-Karte enthält ein Diagramm zu Leistung gegenüber Inferenzzeit, ein Gesamtleistungsdiagramm für den 1B-Instruct-Build, eine ungeschnittene Bildschirmaufnahme, aufgenommen auf einem iPhone 17 Pro Max, und einen qualitativen Satz, der besagt, dass die 1B-Variante Qwen3.5 0.8B sowohl beim Gesamtwert als auch bei der Inferenzeffizienz deutlich übertrifft. Außerdem listet sie eine Quantisierungsfamilie – int4, AWQ, GPTQ, GGUF sowie FP8-Unterstützung – und Day-0-Hardwareziele auf, die iOS, Android, HarmonyOS, Rockchip, Houmo, Intel, AMD und Arm umfassen.

Jede davon ist eine Herstellerangabe, an die keine unabhängige Zahl geknüpft ist, und eine davon ist intern unsauber: Der Text auf der Karte bezeichnet es als 1B-Modell, während die Seitenleiste auf dem Hub eine Modellgröße von 2B Parametern angibt. Der DSpark-Checkpoint unterscheidet sich grundlegend von alldem. Es ist 0,85 GB groß, steht unter Apache-2.0 und bringt einen Serving-Befehl mit – was bedeutet, dass eine externe Partei mit einer Consumer-GPU es diese Woche ausführen und die erste extern gemessene Zahl der Familie produzieren kann. Kein Benchmark-Ergebnis, aber etwas fast ebenso Nützliches: eine reproduzierte Acceptance-Length.

Wenn jemand 3,45 auf MMMU und 3,37 bei allgemeinem Text erreicht, ist die Karte glaubwürdig und die On-Device-Story hat ihren ersten externen Datenpunkt. Fällt die Akzeptanz deutlich niedriger aus, wurde die Tabelle unter Bedingungen gemessen, die das veröffentlichte Rezept nicht reproduziert, und das Leistung-pro-Inferenzzeit-Diagramm erbt diesen Zweifel. Jedes der beiden Ergebnisse ist mehr wert als ein weiteres Herstellerdiagramm, und dies ist der einzige Teil der Familie, bei dem man einen günstig bekommt.

Es auszuführen und was ein Versuch kostet

Die Karte enthält genau ein Rezept, und es ist ein vllm serve-Aufruf, kein bloßes Gerede. Sie lädt das Zielmodell openbmb/MiniCPM-V-4.7-1B, serviert es unter dem Namen MiniCPM-V-4.7-1B, setzt --max-model-len 40960 und --max-num-batched-tokens 40960, legt --attention-backend FLASH_ATTN und --mm-encoder-attn-backend FLASH_ATTN fest, übergibt als Kwarg für den multimodalen Prozessor {"downsample_mode": "4x"}, vertraut multimodalen Kwargs pro Anfrage und richtet eine spekulative Konfiguration auf den DSpark-Checkpoint aus, mit "method": "dspark", "num_speculative_tokens": 15 und abgeschalteter adaptiver Verifikation. Standardmäßige Chat-Template-Kwargs lassen das Denken deaktiviert.

Zwei Details in dieser Zeile lohnen es, zweimal gelesen zu werden. --max-num-seqs 1 bedeutet, dass das veröffentlichte Setup jeweils eine Sequenz auf einmal bedient, sodass das Rezept eine Konfiguration für Latenz bei einem einzelnen Stream beschreibt, nicht eine Konfiguration für Durchsatz. Und der visuelle 4x-Downsample-Modus ist der günstigere der beiden, die die übergeordnete Karte anbietet — dieselbe Karte bietet ein gemischtes 4x/16x-Schema, das Detail gegen Geschwindigkeit eintauscht, und das Rezept wählt die Seite dieses Kompromisses, die Geschwindigkeit bevorzugt.

Die Hardware-Anforderungen sind das Gegenteil des Marketings der Modellfamilie. Das 1B-Ziel umfasst in BF16 rund 2 GB plus einen KV-Cache, und der Draft fügt zusätzlich 0,85 GB hinzu, sodass dies eher ein Single-GPU-Job ist – eine Consumer-Grafikkarte oder eine Workstation mit genügend Unified Memory – als ein Smartphone-Job. Der On-Device-Pfad in der Dokumentation des übergeordneten Modells verläuft über quantisierte Builds und Frameworks, die nicht in diesem Rezept enthalten sind, und der DSpark-Checkpoint ist in der veröffentlichten Form ein serverseitiges BF16-Artefakt.

Das hinterlässt eine Lücke, in die die meisten Teams stoßen werden: Die interessante Version von MiniCPM-V 4.7-1B ist die On-Device-Variante, und die Version, die man heute ausführen kann, ohne die Phone-Toolchain zu besitzen, ist eine serverseitige. Wenn Sie jetzt tatsächlich kleine multimodale Inferenz brauchen, ist das nächstliegende gehostete Äquivalent ein anderes Modell – Qwen3 VL 8B Instruct ist auf OrcaRouter für 0,18 $ pro Million Input-Tokens und 0,70 $ pro Million Output verfügbar, mit einem 128K-Kontextfenster sowie Text-, Bild- und Videoeingabe, ohne lokale Gewichte und ohne Serving-Rezept, das man am Laufen halten muss. 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 dies zwei Wege sind, eine Aufgabe zu erledigen, und nur einer davon lässt sich heute Nachmittag aus dem Katalog heraus messen.

Wo sich etwas wie DSpark bezahlt macht, ist der Fall eines nicht bewährten Modells, und das ist eher eine Routing-Frage als eine Modell-Frage. Ein Drafter, den niemand reproduziert hat, ist genau die Art von Komponente, die man hinter einem Endpunkt haben möchte, von dem aus ein Fallback möglich ist. 200+ Modelle hinter einem Schlüssel laufen zu lassen, Listenpreise der Anbieter mit 0 % Aufschlag durchzureichen und bei einer Verschlechterung einer Route automatisch ein Failover durchzuführen, bedeutet, dass ein schiefgehendes Serving-Experiment nur einen Retry statt einen Ausfall kostet – und weil nichts aufgeschlagen wird, ist eine Preisänderung eines Anbieters bei jedem Modell im Katalog noch am selben Tag live statt erst zum nächsten Abrechnungszyklus.

Was würde das überprüfbar machen?

Drei Dinge fehlen, und nur eines davon erfordert OpenBMB.

Der Anbieter hat nichts angekündigt. Das Repository enthält eine Modellkarte, eine Lizenz und ein Trainingsrezept, aber keinen Blogbeitrag, keinen technischen Bericht und keine Zeile in der GitHub-Dokumentation des Projekts – die in der ersten Woche der Familie noch die vorherige Generation als die aktuelle beschrieb. Vier Tage, nachdem der Checkpoint eingetroffen war, verlinkt die übergeordnete 1B-Karte ihn als Tabellenzeile und nichts weiter.

Niemand hat die Akzeptanzzahlen reproduziert, und die Downloadzahl ist eins. Das ist die am günstigsten zu schließende Lücke und die, die am meisten zählt, denn es ist der einzige Ort, an dem eine externe Messung die Geschichte der Familie maßgeblich voranbringen würde.

Und die Qualitätsfrage ist völlig unberührt. Es gibt nirgendwo in der Veröffentlichung einen MMMU-Score, kein OCRBench-Ergebnis, keine Kennzahl zum Dokumentenverständnis und keinen Grounding-Wert für MiniCPM-V 4.7-1B — die Akzeptanztabelle ist eine Tabelle über das Decoding, und eine hohe Akzeptanzlänge als Qualitätssignal zu lesen, ist genau der Fehler, zu dem diese Zahlen verleiten.

Also: ein echtes Artefakt, eine permissive Lizenz, ein funktionierender Serving-Befehl und ein wirklich neuer Beleg zu einem Modell, für das es bislang keinen gab. Die nächste Datei, die es wert ist, aktualisiert zu werden, ist weiterhin die Modellkarte des übergeordneten Modells.