MiniCPM-V 4.7 bringt ein 35B-Visionsmodell in 3 GB unter: Die 100-tok/s-Behauptung entwirrt

Ein Modell mit 35 Milliarden Parametern passt nicht in drei Gigabyte. MiniCPM-V 4.7 35B-A3B läuft trotzdem in ungefähr drei Gigabyte, und beide Aussagen stimmen — das ist der ganze Trick und der Grund, warum es sich lohnt, bei den Zahlen, die zu dieser Veröffentlichung kursieren, kurz innezuhalten. Das Modell ist OpenBMBs erster Eintrag mit sparse Mixture-of-Experts in der MiniCPM-V-Reihe: 35,2 Milliarden gespeicherte Parameter, etwa 3 Milliarden pro Token aktiv, Apache-2.0, Gewichte auf Hugging Face. Es liest Bilder, Multi-Image-Sets und Videos und antwortet in Text. Seit dem 10. Oktober läuft es außerdem in upstream llama.cpp, wo die meisten es kennengelernt haben. Im Folgenden werden die drei Zahlen, die alle wiederholen — 3 GB, 35B und die 100 tok/s — auseinandergehalten und es wird gezeigt, welche davon OpenBMB tatsächlich veröffentlicht hat. Über 200 gehostete Modelle, ein Schlüssel, Listenpreis des Anbieters mit 0 % Aufschlag durchgereicht. Entdecken Sie, was OrcaRouter weiterleitet Der Open-Weight-Checkpoint bleibt auf Ihrer Hardware; der gehostete Ausweg ist ein einziger Endpunkt. Die dokumentierten KI-Ausfälle und Agent-Vorfälle hinter Veröffentlichungen wie dieser sind gesammelt in dem OrcaRouter AI Incident Archive wo jeder Eintrag eigene Quellen, Schweregrad, Konfidenzstufe und eine Kennzeichnung als umstritten enthält.

Drei Gigabyte, fünfunddreißig Milliarden Parameter und kein Widerspruch

Die Arithmetik wirkt nur dann unmöglich, wenn man annimmt, dass „im Speicher“ „alles davon“ bedeutet. MiniCPM-V 4.7 35B-A3B hält etwa 3 Milliarden Parameter dauerhaft im Speicher und streamt die übrigen Experten nach, sobald der Router sie anfordert — die eigene Formulierung der Model Card lautet Lookahead Expert Scheduling, ein Cross-Layer-Routing-Prädiktor, der die Experten vorab lädt, die die nächste Schicht voraussichtlich benötigen wird, und dieses Laden mit bereits laufender Berechnung überlappt. Die Model Card betont ausdrücklich, dass die Vorhersage ausschließlich Prefetching und Scheduling steuert; die Tokens folgen weiterhin dem tatsächlichen Routing des Modells, und ein Experte, den der Prädiktor verfehlt hat, wird wie jeder andere geladen und ausgewertet.

Diese Unterscheidung hat eine messbare Konsequenz. Das GGUF-Repository veröffentlicht das gesamte Modell in jeder gängigen Quantisierung, und keine dieser Dateien ist drei Gigabyte groß:

• Q4_K_M — 21,2 GB auf der Festplatte.

• Q8_0 — 36,9 GB.

• F16 — 69,4 GB.

• Vision-Projektor — 0,9 GB bei 4-facher Kompression, 1,1 GB bei f16.

„3 GB“ ist also eine Angabe zur residenten Speicherbelegung beim Expert-Streaming auf einem Smartphone – weder eine Downloadgröße noch eine VRAM-Anforderung für einen Desktop. Wenn Sie ein Deployment planen, ist die Zahl, die Ihre Festplatte und den ersten Ladevorgang bestimmt, 21,2 GB bei Q4_K_M, und die Zahl, die Ihren Speicherbedarf im Dauerbetrieb auf einem Smartphone bestimmt, sind die ~3 GB des Herstellers. Beide stehen in der Veröffentlichung. Sie beantworten unterschiedliche Fragen, und die meisten Berichte haben sie zu einer einzigen verschmolzen.

Wo 100 Tok/s herkommen – und wo nicht

Hier ist der Punkt, bei dem Klartext nötig ist. OpenBMB veröffentlicht für MiniCPM-V 4.7 keine Angabe von 100 Tok./s. Die Zahl auf der Modellkarte lautet 13+ Tokens/s auf einem iPhone 17 Pro Max bei rund 3 GB Speicher. Das ist die einzige On-Device-Durchsatzangabe der Veröffentlichung, und sie wurde vom Hersteller auf Hardware gemessen, die niemand außerhalb des Labors reproduziert hat.

Höhere Zahlen gibt es durchaus, und sie stammen aus einem anderen Artefakt. OpenBMBs llama.cpp-omni-Fork – das Repository, das die On-Device-Optimierungen enthält – veröffentlicht eine eigene Tabelle für das 35B-A3B-Ziel, gestaffelt danach, welche Optimierungen aktiviert sind:

• iPhone 18 Pro Max, 12 GB — 3,38 Tok./s als Basiswert, 11,34 mit Lookahead Expert Scheduling, 17,16 mit zusätzlicher gemischter Präzision, 20,51 mit dem DSpark-Draft-Head ebenfalls.

• iPad Pro 11 Zoll M4, 16 GB — 2,97 Tok./s Basiswert, 9,81 mit LES, 14,92 mit gemischter Präzision, 17,39 mit DSpark.

Das sind die höchsten veröffentlichten On-Device-Werte für dieses Modell, und die Spitze der Skala liegt bei 20,51 tok/s – ein Fünftel von 100. Die Lücke ist wichtig, weil sie verändert, wofür das Modell gedacht ist. Bei 13 tok/s beantwortet eine Handy-App eine Frage zu einem Foto in ein paar Sekunden. Bei 100 tok/s würde man es als Streaming-Erstleser für Video in Betracht ziehen. Das Erste ist ein echtes Produkt. Das Zweite ist nicht das, was ausgeliefert wurde, und wer anhand der Zahl aus dem Tweet kalkuliert, wird um den Faktor fünf enttäuscht werden.

Eine ehrliche Lesart der Behauptung von 100 tok/s ist, dass sie drei getrennte Fakten – 3 GB, läuft lokal, deutlich schneller als die vorige Generation – zu einer einzigen Zahl verdichtet, die in keiner der Quellen enthalten ist. Die Verbesserung von Generation zu Generation ist real und groß: Der Sprung von 3,38 auf 20,51 tok/s ist eine 6-fache Steigerung auf derselben Geräteklasse, erreicht durch die Kombination dreier Techniken statt durch einen größeren Chip.

Die Veröffentlichung war nicht an einem einzigen Tag, und die Daten sind wichtig.

MiniCPM-V 4.7 tauchte so auf, wie es heute bei vielen Open-Weight-Veröffentlichungen läuft: zuerst die Dateien, die Erklärung später und die Framework-Unterstützung irgendwo dazwischen.

• 6. Oktober, 17:40 UTC — das 1B-Modell und seine AWQ-, GPTQ- und int4-Varianten erscheinen auf Hugging Face, außerdem die GGUF-Builds um 18:05.

• 7. Oktober, 07:07 UTC — das 35B-A3B-Repository geht online. Noch immer keine Modellkarte.

• 8. Oktober — DSpark-Heads für spekulative Dekodierung für beide Größen und ein FP8-Build des 35B.

• 10. Oktober, 18:42 UTC — llama.cpp integriert Modellunterstützung.

• 12. Oktober — OpenBMB committet die Modellkarte, erklärt Apache-2.0 und kündigt die Veröffentlichung als dokumentiertes Produkt an.

• 15. Oktober — die DSpark-Heads sind von der Hauptkarte aus verlinkt, mit GGUF-Drafts für beide Ziele.

Diese Reihenfolge erklärt einen Großteil der Verwirrung in der sekundären Berichterstattung. Jemand, der das Modell in der zweiten Oktoberwoche über llama.cpp kennengelernt hat, verwendete eine Veröffentlichung, die offiziell noch nicht existierte – ohne Lizenzkennzeichnung und ohne Benchmark-Diagramm –, und die Durchsatzwerte dieser Person spiegeln die eigenen Quantisierungsentscheidungen des Frameworks wider und nicht das, was OpenBMB gebenchmarkt hat.

llama.cpp-Unterstützung: zusammengeführt und noch nicht ganz fertig

Der Upstream-Pull-Request, der MiniCPM-V 4.7 hinzugefügt hat, ist ungewöhnlich gut nachvollziehbar, was sich geändert hat, und die Antwort lautet: architektonisch fast nichts. Das Modell ist nahezu identisch mit MiniCPM-V 4.6; das Delta ist 3D RoPE, eine Position mit drei Werten pro Token – Zeit, Zeile, Spalte – statt des einzelnen Skalars, den die meisten Vision-Language-Modelle verwenden. Die Unterstützung erweitert den bestehenden 4.6-Pfad, um diese zusätzliche Dimension mitzuführen. Der PR bezeichnete das Modell außerdem als „upcoming“, als er am 25. September geöffnet wurde, was ein guter Hinweis darauf ist, wie früh die Gewichte im Umlauf waren.

Dieses Überbleibsel sollten Sie kennen, bevor Sie darauf eine Grounding-Funktion aufbauen. Seit jenem Merge weist upstream llama.cpp den Bildmarker-Tokens in MiniCPM-V-4.7-Prompts die falschen Positionen zu: Die Bild-Tokens selbst landen korrekt, aber <slice>, </slice> und die Zeilenende-Marker werden wie Klartext nummeriert, statt ihre Kachel-Eckkoordinaten zu erhalten, wie es die Referenzimplementierung get_rope_index tut. Das sichtbare Symptom ist, dass zurückgegebene Koordinaten systematisch zu niedrig liegen, wenn Sie fragen, wo sich etwas auf einem Bild befindet. Ein Fix mit einem Unit-Test existiert als offener Pull Request vom 14. Oktober, und Stand 20. Oktober ist er weiterhin offen. Wenn Ihre Aufgabe „Beschreibe das“ lautet, werden Sie es nicht bemerken. Wenn sie „Gib mir die Bounding Box“ lautet, werden Sie es bemerken, und Sie sollten entweder auf den Merge warten oder den Fork verwenden, der den korrigierten Pfad enthält.

Eine weitere Sache übersteht den Roundtrip: Beim 1B-Modell ist der Vision-Projektor der größere Download. Die Q4_K_M-Gewichte umfassen 672 MB; der f16-Projektor umfasst 1,11 GB. Die kleinste sinnvolle 1B-Bereitstellung besteht daher aus etwa 1,8 GB an Dateien, wovon der Großteil auf die Augen statt auf die Sprache entfällt – ein Detail, das jede Erwartung „1B bedeutet 1 GB“ widerlegt.

Was ausgeführt werden soll – und worauf

Wenn das Ziel ist, es diese Woche auszuprobieren, ist der reibungsärmste Weg llama.cpp oder Ollama mit den GGUF-Repositories, wobei der multimodale Client auf die passende mmproj-Datei zeigt. Auf einer GPU mit 24 GB lässt Q4_K_M mit 21.2 GB sehr wenig Spielraum für Kontext – ein 8K-Token-Fenster plus Bildkacheln passen nicht bequem hinein, planen Sie also mit Q4_K_S oder einer kleineren Quantisierung, wenn Sie zusätzlich einen langen Prompt wollen. Auf einem Mac mit 32 GB oder mehr ist Q8_0 machbar und kommt dem Referenzverhalten am nächsten. Auf einem Handy tragen nur die eigenen Apps des Herstellers und der llama.cpp-omni-Fork die Expert-Scheduling-Arbeit; Standard-llama.cpp liefert Korrektheit, nicht die 20 tok/s.

Wo eine Routing-Schicht hier ihren Platz verdient, ist auf der anderen Seite des lokalen Aufrufs. Ein 3B-Active-Modell auf einem Telefon ist hervorragend bei den Routineaufgaben – diesen Kassenzettel lesen, sieht dieses Regal bestückt aus, was steht auf diesem Schild – und es stößt gelegentlich auf eine Seite, die es nicht abschließen kann. OrcaRouter stellt über 200 gehostete Modelle hinter einem einzigen Schlüssel bereit und gibt den Listenpreis jedes Anbieters mit 0 % Aufschlag weiter, sodass eine Preisänderung eines Anbieters noch am selben Tag live ist und bei einer Verschlechterung eines Upstreams automatisch ein Failover erfolgt. Das Muster, das funktioniert, ist Local-First mit einem gehosteten Notausgang, nicht Local-Only. Der Open-Weight-Checkpoint bleibt bei Ihnen zum Hosten; der Router übernimmt alles, was das Telefon abgibt.

MiniCPM-V 4.7 wird nicht von OrcaRouter bereitgestellt, und wir werden nichts anderes implizieren. Es ist ein Checkpoint, den Sie selbst ausführen.

Was würde die drei Zahlen festlegen?

Eine unabhängige Messung des 35B-Modells auf einem namentlich genannten Telefon, mit Angabe der App und der Quantisierung, würde die Durchsatzfrage klären – einschließlich der Frage, ob 20,51 Tok/s die Stoppuhr von jemand anderem überstehen. Eine veröffentlichte Definition der 3-GB-Angabe – Resident Set, Spitzenzuweisung oder etwas anderes – würde die Speicherfrage klären. Und eine Tabelle pro Benchmark mit echten Scores statt der fünf verlinkten Diagramme, die die Karte derzeit enthält, würde es ermöglichen, die Behauptung „besser als Qwen3.6 35B-A3B in weniger Zeit“ gegen die von OpenBMB gewählte Gewichtung zu prüfen. Nichts davon existiert bisher. Bis dahin lautet der zutreffende Satz der langweilige: ein 35B-Sparse-Modell, das auf einem Telefon mit einer gemeldeten Geschwindigkeit von mehr als 13 Tokens pro Sekunde bei etwa 3 GB läuft, mit einem 21-GB-Download und einem zusammengeführten Framework-Pfad, der noch einen offenen Koordinaten-Bug hat.