Eine Voxel-Pagode, 10 % weniger Tokens und der eine Satz, hinter dem OpenBMB tatsächlich steht

Der meistzitierte Satz über MiniCPM-V 4.7 35B-A3B in dieser Woche steht nicht auf seiner Modellkarte. Es ist ein Tweet, veröffentlicht am 13. Oktober 2026, der lautet: „MiniCPM-V 4.7 35B-A3B hat nicht nur weniger Tokens verbraucht, sondern auch eine bessere Voxel-Pagode erzeugt als Qwen 3.6 35B-A3.“ Die Demonstration, auf die er verweist, ist ein Video, in dem zwei Sprachmodelle jeweils den Code für eine japanische 3D-Voxel-Pagode schreiben, Seite an Seite gerendert. Es ist ein wirklich interessantes Artefakt – es zeigt ein Vision-Language-Modell, das eine gebaute Struktur in drei Dimensionen anhand eines Bild-Prompts reproduziert, was eine schwierigere Aufgabe ist, als ein Bild zu beschriften. Aber es lohnt sich, zu trennen, was dieser Tweet ist, von dem, was er nicht ist, denn drei verschiedene Behauptungen wurden in einer Zeile zusammengeführt, und sie haben drei unterschiedlich starke Belege. MiniCPM-V 4.7 35B-A3B ist ein echter Checkpoint von OpenBMB und etwa eine Woche alt; Qwen3.6-35B-A3B ist ein neun Monate alter Open-Weights-Konkurrent, ebenfalls Apache-2.0, ebenfalls ein sparse Mixture-of-Experts mit derselben nominellen Größe. Alles Folgende dreht sich darum, welche der Effizienzbehauptungen rund um sie überprüfbar ist und welche ein JPEG eines Diagramms ist.

Drei Behauptungen in einem Satz

Der Tweet bündelt drei trennbare Dinge, und sie verdienen es, getrennt zu werden, weil nur eines davon dokumentiert ist.

• „Weniger Tokens verbraucht“ — das ist eine messbare Aussage über den Tokenverbrauch für eine Aufgabe. Die Zahl, die zusammen mit der Demo kursiert, ist 10 % weniger Tokens als Qwen3.6 35B-A3B. Diese Zahl stammt von dem externen Creator, der den Vergleich durchgeführt hat, nicht aus OpenBMBs Evaluation, und sie bezieht sich auf ein einzelnes Prompt-Paar, nicht auf einen Benchmark.

• „Eine bessere Voxel-Pagode erzeugt“ — das ist ein Urteil, das man durch Betrachten zweier gerenderter Pagoden fällt. Es gibt kein Bewertungsraster, kein Scoring-Harness und keine unabhängige Instanz. Es ist die Art von Behauptung, die ein Mensch in drei Sekunden aufstellt und ein Benchmark überhaupt nicht aufstellen kann, weil „bessere Pagode“ keine Ground Truth hat.

• „Effizienz plus Qualität ist das eigentliche Schlachtfeld“ — dieser Teil ist eine These, und sie ist zufällig diejenige, die OpenBMB tatsächlich schriftlich vertritt, mit Zahlen unterlegt, in der Modellkarte. Es ist nur nicht der Satz, der die Runde gemacht hat.

Das ist wichtig, weil die ersten beiden Behauptungen die einprägsamen sind und die dritte die belastbare. Wenn Sie abwägen, ob Sie 70 GB Download in einen Checkpoint investieren, wollen Sie die dritte.

Was OpenBMB tatsächlich geschrieben hat, und wann

Zuerst die Chronologie, denn sie wurde durch das Nacherzählen komprimiert. Die Gewichte wurden still hochgeladen: openbmb/MiniCPM-V-4.7-1Bwurde am 6. Oktober 2026 um 17:40 UTC erstellt,openbmb/MiniCPM-V-4.7-35B-A3Bam 7. Oktober um 07:07 UTC. Keines der beiden trug zu diesem Zeitpunkt eine Modellkarte, ein Lizenz-Tag oder einen Benchmark — darüber wurde hier damals berichtet, und es war ein seltsamer Zustand für einen Upload mit 35 Milliarden Parametern. Sechs Tage später, am 12. Oktober 2026, committete OpenBMB die Dokumentation in einem Rutsch: Modellkarte, Apache-2.0-Lizenz, Evaluationsdiagramme, eine neu geschriebene Repository-README, die mit der neuen Serie beginnt, und eine Ankündigung. Die Parameter änderten sich an diesem Tag nicht. Die Erklärung schon.

Die ehrliche Formulierung lautet also nicht „MiniCPM-V 4.7 35B-A3B ist diese Woche erschienen.“ Sie lautet: „MiniCPM-V 4.7 35B-A3B wurde diese Woche lesbar.“ Alles daran, was jetzt zitierfähig ist, wurde entweder am 6. und 7. hochgeladen, aber nicht dokumentiert, oder am 12. geschrieben und ist eine Herstellerangabe.

Die Behauptung, die die Modellkarte tatsächlich aufstellt

Hier ist der Satz, wörtlich aus der Modellkarte, und er ist enger gefasst als der Tweet: Im Instruct-Modus erzielt die 35B-A3B-Variante „einen höheren Gesamtscore in kürzerer Inferenzzeit als Qwen3.6 35B-A3B“. Das ist alles. Keine Token-Anzahl, kein Vorsprung, keine Aufschlüsselung nach Benchmarks im Fließtext. Der Beleg dahinter ist ein Streudiagramm – durchschnittlicher Evaluationsscore auf der vertikalen Achse, Inferenzzeit in Sekunden auf einer logarithmischen Skala auf der horizontalen Achse –, auf dem MiniCPM-V 4.7 35B-A3B oberhalb und links von Qwen3.6-35B-A3B liegt. Die Fußnote des Diagramms selbst definiert den Durchschnitt als Mittelwert aus fünf Benchmarks: MMStar, MMMU-Pro, CharXiv reasoning, BLINK und MathVista. Kreise stehen für den Instruct-Modus, Rauten für den Thinking-Modus.

Das ist eine echte und konkrete Aussage über einen zweidimensionalen Trade-off, und sie ist das stärkste Element in der Veröffentlichung. Es ist auch erwähnenswert, was das Diagramm nicht verraten kann: An den eingezeichneten Punkten gibt es keine numerischen Beschriftungen, man kann also weder eine Punktzahl noch eine Zeit ablesen, sondern nur eine Richtung. Die Richtung, so wie sie gezeichnet ist, begünstigt MiniCPM gleichzeitig auf beiden Achsen.

Und sie wurde vom Anbieter gemessen. Die Evaluationszahlen der Modellkarte enthalten den Satz „Die Ergebnisse stammen aus öffentlichen Berichten und unserer lokalen Evaluierung unter Verwendung offizieller Checkpoints.“ Lokale Evaluierung bedeutet OpenBMBs Hardware, OpenBMBs Testumgebung, OpenBMBs Modusauswahl. Das ist eine normale Sache für eine Modellkarte – und eine abnorme Sache, sie zu einem Faktum zu waschen. Keine unabhängige Partei hat diese beiden Checkpoints gegen eine gemeinsame Testumgebung laufen lassen. Keine Bestenliste hat eines der beiden Ergebnisse erfasst. Zum Zeitpunkt dieses Schreibens hat die Behauptung genau eine Quelle, und die Quelle verkauft das Modell.

Woher die Token-Effizienz kommen soll

Das Effizienzargument stützt sich nicht auf das Benchmark-Diagramm. Es stützt sich auf drei technische Entscheidungen, und sie sind es wert, verstanden zu werden, denn sie bestimmen, ob sich der Vorteil auf Ihre Hardware überträgt oder nicht.

• Lookahead Expert Scheduling (LES) – die zentrale Technik. Ein Sparse-Mixture-of-Experts-Modell speichert weit mehr Parameter, als es pro Token aktiviert, und auf einem Gerät, das nicht alle Experten im Speicher halten kann, werden die Gewichte ein- und ausgelagert, und die Dekodierung stockt. LES nutzt schichtübergreifende Routing-Vorhersage, um Experten vorzuladen, die wahrscheinlich von der nächsten Schicht benötigt werden, und priorisiert die Berechnung für Experten, die der tatsächliche Router ausgewählt hat und die zufällig bereits geladen sind. OpenBMB betont ausdrücklich, dass die Vorhersage nur Prefetching und Scheduling steuert; das Routing des Modells auf Token-Ebene bleibt unverändert, und Experten, die der Prädiktor übersehen hat, werden weiterhin geladen und ausgewertet. Die Karte behauptet dadurch eine 5-fache Beschleunigung auf echten Geräten ohne Verlust an Fähigkeiten.

• Feingranulare schichtweise Quantisierung — verkleinert den Speicherbedarf der Expertengewichte und den Speicherverkehr, was die andere Hälfte davon ist, ein On-Device-Lademuster passend zu machen.

• DSpark Speculative Sampling — ein gepaarter Draft-Modell-Pfad, separat veröffentlicht als openbmb/MiniCPM-V-4.7-35B-A3B-DSpark und integriert neben der Scheduling- und Quantisierungsarbeit.

Zusammengenommen ergeben diese die Aushängeschild-Zahl des Releases: 13-plus Token pro Sekunde bei rund 3 GB Speicher auf einem iPhone 17 Pro Max. Das ist eine Herstellerangabe, auf Herstellerhardware, mit Herstellersoftware – einer App, die OpenBMB geschrieben hat. Es ist die Art von Behauptung, die entweder das ganze Produkt ausmacht oder gar nichts, und derzeit gibt es für niemanden außerhalb des Unternehmens eine Möglichkeit, sie zu überprüfen, weil ihre Reproduktion den On-Device-Stack erfordert, auf dem die Telefon-Demo läuft.

Token-Effizienz ist real, doch hier ist sie eine Matrix, kein Skalar

In dieser Veröffentlichung gibt es ein Detail, das aus jeder Zusammenfassung davon herausgeglättet wurde, und genau dieses bestimmt tatsächlich die Token-Ökonomie.

• MiniCPM-V 4.7 35B-A3B unterstützt gemischte 4x- und 16x-Visual-Token-Kompression, pro Anfrage auswählbar. Die 16x-Einstellung führt visuelle Tokens für Geschwindigkeit zusammen; 4x behält viermal so viele, für Details. Der Standard der Karte ist 16x, und der Parameter muss sowohl an das Chat-Template als auch an den Generate-Aufruf übergeben werden, sonst stimmen die Platzhalteranzahl und der Vision-Encoder nicht überein.

• Die eigene Vision-Language-Vergleichstabelle des Anbieters verzeichnet die für die Zeile jedes Modells verwendete Komprimierungseinstellung. In dieser Tabelle steht die Zeile für MiniCPM-V 4.7 35B-A3B bei 4x – der detailerhaltenden Einstellung, also der teuren – und die Zeile für Qwen3.6 35B-A3B bei 16x. Eine Zeile für Gemma 4 31B ist mit 9x aufgeführt; die beiden Qwen-Zeilen mit 27B mit 4x.

• Eine Fußnote stellt unmissverständlich fest, dass MiniCPM-V 4.7 beide Einstellungen unterstützt, während die anderen Modelle in der Tabelle nur ein festes Komprimierungsverhältnis unterstützen.

Liest man das zusammen, ändert sich das Bild. Wenn die MiniCPM-Zeile ihre Vision-Language-Werte bei der token-hungrigen Einstellung erzielt, während die Qwen-Zeile ihre Werte bei der token-sparsamen erzielt, dann vergleichen die beiden Spalten unterschiedlich viel visuelles Detail, und die Effizienzgeschichte lautet nicht „gleicher Input, weniger Tokens“ – sie lautet „anpassbarer Input, und hier ist die Spalte, die bei der Qualität gewinnt“. Das ist eine interessantere und ehrlichere Behauptung als die des Tweets, und OpenBMB hat sie in einer Fußnote veröffentlicht, statt sie in den Vordergrund zu stellen.

Außerdem bedeutet es, dass die Zahl, die dir eigentlich wichtig ist – Tokens pro Einheit visueller Details –, sich aus dieser Tabelle überhaupt nicht ablesen lässt. Dafür müsste man beide Modelle mit derselben Einstellung laufen lassen, was niemand veröffentlicht hat.

Die Tabelle, mit den beigefügten Vorbehalten

Die Karte wird mit zwei Anbietertabellen ausgeliefert, eine für Vision-Language und eine für Sprache, beide im Instruct-Modus, beide im Vergleich mit einem Feld, das zwei Qwen-Modelle der 35B-A3B-Klasse, ein 31B-Gemma und zwei 27B-Qwens umfasst. Die folgenden Zahlen wurden aus dem eigenen PNG-Diagramm des Anbieters abgelesen, und der Vorbehalt ist struktureller Natur: Die Zahlen existieren nur als Pixel in diesem Diagramm, nicht als Tabelle, daher wurde das Folgende durch maschinelles Lesen extrahiert, und kleine Transkriptionsfehler sind möglich.

• OCRBench — MiniCPM-V 4.7 35B-A3B 91,20 gegenüber Qwen3.6 35B-A3B bei 90,40. Ein Abstand von 0,8 Punkten, beim eigenen Durchlauf des Herstellers.

• OmniDocBench v1.6 — ungefähr 98,2 für MiniCPM gegenüber ungefähr 93,3 für das Qwen-Modell, was der größte einzelne Unterschied in der Tabelle ist und der am wichtigsten wäre, wenn er reproduziert würde, da Dokumentenparsing der Bereich ist, in dem Token-Budgets normalerweise verbraucht werden.

• MMMU — ungefähr 80,2 gegenüber 80,0, ein Kopf-an-Kopf-Rennen bei der Auflösung eines Diagrammbilds.

• MMMU-Pro — ungefähr 69,7 gegenüber 67,7, in einer Zeile, in der ein 27B Qwen höher steht als beide.

• Sprachtabelle — dieselbe Form, wobei die auffälligeren Zellen auf Instruction-Following und Code entfallen. IFBench wird mit etwa 47,7 gegenüber 35,3 aufgeführt, und LiveCodeBench-v6 mit etwa 97,0 gegenüber 54,3. Diese beiden sind groß genug, dass sie als die am wenigsten glaubwürdigen Zellen in der Veröffentlichung behandelt werden sollten, bis jemand anderes sie selbst laufen lässt: eine Spanne von 43 Punkten bei einem Code-Benchmark zwischen zwei ähnlich großen offenen MoE-Modellen, gemessen von einer der beiden Parteien, ist eine Behauptung, die ein zweites Instrument erfordert.

Vom Hersteller gemeldet, mit Hersteller-Harness gemessen, nicht reproduziert. Das ist alles. Wenn diese Werte einem unabhängigen Harness standhalten, ist die Pareto-Frontier-Behauptung korrekt und das Pagoden-Video eine Fußnote. Wenn nicht, ist das Pagoden-Video alles, was es gibt.

Was die Adoptionszahlen sagen, sagt nichts über die Qualität aus.

Eine Zahl in diesem Vergleich wird von niemandem bestritten, und sie ist kein Benchmark. Der Hugging-Face-Download-Zähler, abgelesen am 13. Oktober 2026, zeigt 630 für openbmb/MiniCPM-V-4.7-35B-A3Bgegenüber ungefähr 3,6 Millionen fürQwen/Qwen3.6-35B-A3B — ein Repository, das am 15. April 2026 erstellt wurde und daher etwa neun Monate weiter auf der Adoptionskurve liegt. Diese Lücke misst Zeit, nicht Verdienst, und sie ist der Grund, warum die Effizienzfrage überhaupt in diese Richtung gestellt wird: Der Neuankömmling muss sich auf Pro-Token-Basis behaupten, gerade weil er nicht neun Monate Zeit hatte, der Standard zu sein.

Es gibt außerdem einen kleinen internen Widerspruch im Listing, der erwähnenswert ist. Das Repository trägt das Tag „On-Device Model“, das vom Rest der Familie geerbt wurde, und ein Sparse-MoE mit 35,2 Milliarden Parametern in 70,4 GB BF16-Gewichten ist in keiner Weise on-device, die ein Downloader erkennen würde. Die On-Device-Story ist real, aber sie läuft über Quantisierung und Expert-Streaming, die auf dem Checkpoint aufsetzen, nicht über den Checkpoint selbst. Kalkuliere mit dem quantisierten Build und der App, nicht mit dem Tag.

Was diese Woche dagegen zu tun ist

Die praktische Position ist eng und klar. Wenn Sie die Effizienzbehauptung verifiziert haben möchten, gibt es noch nichts zu verifizieren – es ist das Diagramm eines einzelnen Anbieters, und die eine Zahl, an die eine aufgabenbezogene Angabe geknüpft ist (10 % weniger Tokens, eine Pagode), stammt aus einer einzigen Demo eines Drittanbieters. Wenn Sie das Modell ausführen möchten, stehen die Gewichte unter Apache-2.0, die Architektur ist dokumentiert, und die Downsampling-Einstellung können Sie selbst wählen, was ein echter und unterschätzter Hebel ist: 16x, wenn Durchsatz zählt, 4x, wenn das Diagramm Ihnen ein Dokument zeigt.

Die eine Hälfte dieses Vergleichs ist heute über eine gehostete API erreichbar, die andere nicht, und es lohnt sich, genau zu sein, welche welche ist. qwen/qwen3.6-35b-a3bist ein gehostetes Modell auf OrcaRouter – es steht im Katalog hinter einem einzigen Schlüssel, zu Qwens eigenem Listenpreis, ohne dass etwas obendrauf kommt, und leitet an den jeweils gesunden Anbieter weiter statt an einen, den du festgelegt hast. MiniCPM-V 4.7 wird nicht von uns gehostet; es ist ein Open-Weights-Checkpoint, den du selbst bereitstellst. Diese Asymmetrie ist das Nützliche daran. Du kannst die Qwen-Seite dieses Vergleichs heute Nachmittag in eine Baseline verwandeln, OpenBMBs Harness mit deinen eigenen Daten dagegen laufen lassen und die Grafik des Anbieters zur Hypothese statt zur Antwort machen.

Was, da es in der gesamten Argumentation um Effizienz auf deiner Hardware geht, die einzige Messung ist, die das jemals hätte klären können.