MiniCPM-V 4.7 35B-A3B vs. PixelUMM: Eine Lizenz entscheidet das, bevor die Benchmarks es tun

Es gibt eine Entscheidung, die Sie zwischen MiniCPM-V 4.7 35B-A3B und PixelUMM treffen können, ohne auch nur einen einzigen Benchmark zu lesen, und sie ist wahrscheinlich die Entscheidung, die am wichtigsten ist. MiniCPM-V 4.7 35B-A3B ist Apache-2.0. Der Modell-Checkpoint von PixelUMM ist es nicht – er wird unter NVIDIAs One-Way Noncommercial License vertrieben, die ausschließlich Forschung und Evaluierung erlaubt, und zwar für einen Checkpoint, von dem NVIDIA selbst sagt, dass er „nicht für Produktions- oder Hochrisikoeinsatz validiert wurde“. Wenn Sie etwas bauen, das Sie verkaufen möchten, ist eines dieser beiden Modelle ein Nichtstarter, und der Rest des Vergleichs ist akademisch. Wenn Sie Forschung betreiben, öffnet sich das Feld, und die interessante Frage wird, wogegen NVIDIAs encoderfreies Design tatsächlich wettet – denn es wettet genau gegen die Architektur, die MiniCPM-V 4.7 verwendet.

Beide Modelle wurden still und leise veröffentlicht. PixelUMMs Gewichte landeten am 1. Oktober 2026 um 21:40 UTC auf Hugging Face – ohne Blogbeitrag, ohne Pressemitteilung und ohne Keynote; die URL der Projektseite lautet nach wie vor „preview“. MiniCPM-V 4.7 erschien am 6. Oktober auf dieselbe Weise, und OpenBMB stellte erst am 12. Oktober eine Modellkarte, eine Lizenz oder einen Abschnitt mit Leistungsangaben dazu. Keines der beiden wurde von irgendjemandem unabhängig evaluiert, und keines hat eine Benchmark-Tabelle, die ein Leser zitieren kann – PixelUMMs Karte nennt überhaupt keine Scores, und die Leistungsangaben von MiniCPM-V 4.7 stecken in Diagrammbildern statt im Text. Was folgt, trennt das, was die Repositories angeben, von dem, was niemand außerhalb der beiden Labore bisher bestätigt hat.

Was PixelUMM ist, in einem Absatz

PixelUMM ist ein Decoder-only-Transformer mit 15.199.672.064 Parametern und einem iterativen Pixelgenerierungs-Head, aufgebaut auf einem Qwen3-8B-Backbone, der auf eine bestimmte Revision festgelegt ist. Seine These steht in der ersten Zeile der Modellkarte und ist wirklich konträr: kein VAE und kein Vision-Encoder. Wo ein konventionelles vereinheitlichtes Modell zwei visuelle Schnittstellen besitzt – einen Vision-Transformer, der semantische Merkmale für das Verstehen erzeugt, und einen variationalen Autoencoder, der Rekonstruktions-Latents für die Generierung erzeugt –, besitzt PixelUMM keine von beiden. Bilder werden in 16×16-Pixel-Patches zerschnitten, Videos in raumzeitliche Tubelets aus vier Frames, und beide erreichen das Backbone durch nichts weiter als einlagige lineare Projektionen, wobei iteratives Denoising die Generierungsarbeit übernimmt. Das Paper beschreibt es als Mixture-of-Transformers, das geteilte Attention mit aufgabenspezifischen Parametern kombiniert. Es beherrscht Text-zu-Bild, bildkonditionierte Textgenerierung, videokonditioniertes Verstehen und Videogenerierung, einschließlich Text-zu-Video mit 96 Frames, 24 fps und vier Sekunden.

Die Spur darum herum erstreckte sich über etwa vier Wochen, und es blieb durchweg ruhig. Das GitHub-Repository nv-tlabs/PixelUMM wurde am 4. September 2026 unter Apache-2.0 angelegt und blieb den größten Teil des Monats mit einem einzigen Commit stehen. Am 28. und 29. September wurde der Initial-Commit gepusht, und arXiv vergab den Preprint 2609.38597, dessen Autorenliste NVIDIA und die University of Waterloo umfasst. Das Modell-Repository selbst erschien am 1. Oktober um 21:40 UTC, acht Minuten nach einem letzten GitHub-Commit, der die Zitationsangabe zum Paper hinzufügte. Das Paper trägt keine Venue-Angabe – keine Konferenz, kein „accepted to“ –, was eher so wirkt, als würde ein Forschungsteam ein Artefakt live schalten, denn als handele es sich um einen Produktlaunch, wobei dies eine Beobachtung über die Belege und keine Aussage über die Absicht ist.

Was MiniCPM-V 4.7 35B-A3B ist

MiniCPM-V 4.7 35B-A3B ist OpenBMBs erster MoE-Eintrag in der MiniCPM-V-Serie: 256 Experten mit 8 aktiven pro Token, 40 Schichten, ein Kontextfenster von 262.144 Token und ein Vokabular von 248.144 Token, was etwa 3B aktive Parameter von insgesamt 35,2B ergibt. Die Vision läuft über ein SigLIP2-Modul mit LLaVA-UHD v4 Intra-ViT-Frühkompression und einem wählbaren gemischten 4x/16x-Modus zur Kompression visueller Token — standardmäßig 16x für den Durchsatz, 4x, wenn feine Details wichtig sind. Es versteht einzelne Bilder, mehrere Bilder und Video und antwortet in Text. Es generiert keine Bilder.

Die zentrale Behauptung der Karte ist, dass dies das erste Open-Source-MoE-Modell mit verlustfreier, reibungsloser On-Device-Inferenz sei, ermöglicht durch Lookahead Expert Scheduling, feingranulare schichtweise Quantisierung und spekulatives Sampling über die separaten DSpark-Drafts, bei gemeldeten 13-plus Tokens pro Sekunde auf einem iPhone 17 Pro Max. Diese Zahl ist vom Anbieter angegeben, nicht reproduziert und ohne nähere Qualifizierung. Die Karte behauptet außerdem einen höheren Gesamtwert im Instruct-Modus als Qwen3.6 35B-A3B bei kürzerer Inferenzzeit – eine Behauptung, die in einem Diagrammbild erscheint, was bedeutet, dass sie keine zitierfähige Zahl ist und nicht als solche behandelt werden sollte.

Wo MiniCPM-V 4.7 eindeutig vorne liegt, ist nicht auf irgendeiner Rangliste, sondern im unterstützenden Umfeld, das alles real und herunterladbar ist: Base-, FP8-, int4-, AWQ-, GPTQ- und GGUF-Gewichte; Unterstützung für SGLang, vLLM, llama.cpp, Ollama und OpenVINO; iOS-, Android- und HarmonyOS-Apps; und Rockchip, Houmo, Intel, AMD und weitere für Day-Zero-Silizium aufgeführt. Sechs Jahre später war die ehrliche Kritik an diesem Modell, dass es ein undokumentierter Checkpoint war. Das ist nicht mehr so – es ist ein dokumentierter Checkpoint ohne Benchmarks. Eine andere, kleinere.

Das Architekturargument, das sich hinter dem Vergleich versteckt

Die beiden Modelle sind sich über etwas Grundlegendes uneinig, und es lohnt sich, dies zu benennen, denn es ist der Teil dieses Vergleichs, der länger Bestand haben wird als jedes der beiden Modelle.

• Wie Vision das Sprachmodell erreicht — PixelUMM verwendet rohe Pixel und eine einzelne lineare Projektion, wobei im gesamten Stack kein vortrainierter Vision-Encoder zum Einsatz kommt; MiniCPM-V 4.7 verwendet einen SigLIP2-Encoder mit früher Komprimierung innerhalb des ViT und einem konfigurierbaren Downsampling-Verhältnis.

• Wie die Generierung funktioniert — PixelUMM sagt Pixel iterativ durch einen Flow-Matching-Head voraus, der gemeinsam mit autoregressiver Textvorhersage trainiert wird; MiniCPM-V 4.7 erzeugt Text und nichts anderes.

• Was das bringt — PixelUMM erhält einen einzigen Satz Gewichte, der sowohl ein Bild beschreibt als auch eines erzeugt, zum Preis einer Lizenz nur für Forschungszwecke und ohne Validierung für den Produktionseinsatz; MiniCPM-V 4.7 erhält ein kleines, quantisierbares, auf dem Smartphone einsetzbares Modell, das die Welt lesen, aber nicht neu zeichnen kann.

• Parameteranzahl — 15,2B dense-ähnlich gegenüber 35,2B gesamt mit 3B aktiven Parametern. Die Anzahl der aktiven Parameter ist diejenige, die die Inferenzkosten vorhersagt, und in dieser Hinsicht ist das MiniCPM-Modell das um eine Größenordnung kleinere der beiden.

• Gewichte auf der Festplatte — PixelUMMs Repository umfasst 491 Dateien über vier Checkpoint-Varianten hinweg; der Basis-Build von MiniCPM-V 4.7 besteht aus sechzehn BF16-Shards mit ungefähr 70 GB.

• Lizenz — Apache-2.0 gegenüber NVIDIA One-Way Noncommercial für den Checkpoint, wobei Apache-2.0 nur für den Quellcode von PixelUMM gilt und die Qwen3-8B-Basis separat unter Apache-2.0 steht. Die PixelUMM-Karte weist außerdem darauf hin, dass sie modifizierten Code enthält, der von BAGEL abgeleitet wurde, sodass zusätzlich die Bedingungen der Upstream-Lizenz gelten.

• Öffentliche Bewertung — keine, auf beiden Seiten. MiniCPM-V 4.7 erhebt zumindest Leistungsansprüche; die Karte von PixelUMM nennt überhaupt keine Benchmark-Zahlen.

Welche kann man einem Benutzer tatsächlich vorlegen?

Betrachtet man Lizenz und Deployment-Story zusammen, fällt die Entscheidung meist von selbst.

PixelUMM ist das interessantere Forschungsartefakt und das weniger nutzbare Produkt. Ein nichtkommerzieller Checkpoint blockiert die naheliegenden kommerziellen Nutzungen von vornherein, es gibt kein Serving-Rezept auf der Model Card, keinen quantisierten Build, keine Angabe zur Kontextlänge, und 83 Likes gegenüber null erfassten Downloads bedeuten, dass im Grunde niemand außer den Autoren es je ausgeführt hat. Sein Wert liegt derzeit in einem starken, veröffentlichten Argument, dass Vision-Encoder in vereinheitlichten Modellen möglicherweise unnötig sind. Dieses Argument ist es wert, verfolgt zu werden, ob man nun die Gewichte jemals lädt oder nicht.

MiniCPM-V 4.7 ist das Modell mit einem Weg in die Produktion, und dieser Weg ist schmal, aber real. Apache-2.0 beseitigt die Lizenzfrage. Sechs Quantisierungsformate und fünf Inferenz-Runtimes bedeuten, dass Sie keine benutzerdefinierten Kernel schreiben müssen. Zwei oder mehr GPUs für den unquantisierten Build sind die Hürde; die quantisierten Builds und die On-Device-Story sind der Workaround, und die On-Device-Behauptung ist genau diejenige, die nicht unabhängig verifiziert wurde. Betrachten Sie es als ein Modell, das Sie heute ausführen können, und als eine Leistungsbehauptung, auf die Sie sich noch nicht verlassen können.

Für Teams, deren Antwort „weder noch, wir werden etwas aufrufen“ lautet, ist das nächstgelegene gehostete Äquivalent zur MiniCPM-Form Qwen3.6 35B A3B – dieselben 35B insgesamt, dieselben 3B aktiv, derselbe 262K-Kontext, derselbe Text-Bild-Video-Eingang – und es wird über OrcaRouter zum Listenpreis des Anbieters ohne Aufschlag bereitgestellt, 0,25 $ pro Million Eingabe-Tokens und 1,48 $ pro Million Ausgabe-Tokens, mit automatischem Failover, wenn eine Anbieterroute schlechter wird. Das ist kein Ersatz für eines der beiden Modelle in diesem Artikel; es ist die Kontrollgruppe, die Ihnen zeigt, was Ihnen das Selbsthosting eines 70 GB großen spärlichen multimodalen MoE tatsächlich bringt.

Wo das landet

Nimmt man die Architektur heraus, bleiben zwei leise Releases übrig, die in entgegengesetzte Richtungen weisen. NVIDIA veröffentlichte ein Artefakt auf Paper-Niveau unter einer Lizenz, die die meisten davon abhält, es zu verwenden, sowie ein Repository ohne Anleitung, ohne Benchmarks und ohne Downloads. OpenBMB veröffentlichte ein dokumentiertes, permissiv lizenziertes Multi-Runtime-Modell mit einer überzeugenden Effizienzbehauptung und ohne Evaluierungstabelle, die sie stützt.

Das Einzige, was jeweils Klärung bringen würde: für PixelUMM jede unabhängige Reproduktion überhaupt – 0 Downloads bedeuten, dass kein externer Datenpunkt existiert, und die Encoder-freie These ist genau die Art von Behauptung, die entweder standhält oder beim Kontakt mit einer zweiten Implementierung zerfällt. Für MiniCPM-V 4.7 eine Benchmark-Tabelle oder eine reproduzierte Acceptance Length beim DSpark-Draft, dem einzigen Teil der Familie mit veröffentlichten Zahlen. Beides gibt es noch nicht. Beide sind der Grund, warum diese beiden Modelle weiterhin beobachtet statt abgelegt werden sollten – sie sind früher in ihrem öffentlichen Leben, als die Berichterstattung nahelegt, und keines wurde von dem Labor, das es entwickelt hat, als Launch bezeichnet.