1.000 Token pro Sekunde? Was schnelle Diffusions-Sprachmodelle wirklich schaffen

Darum geht es

Fast alle Chatbots schreiben wie eine Schreibmaschine: ein Token (ein Wortstück) nach dem anderen, jedes abhängig von allen vorherigen. Fachleute nennen das autoregressiv. Seit Juni 2026 sind mehrere Modelle erschienen, die anders arbeiten. Diffusions-Sprachmodelle starten mit einem Block aus Platzhaltern und füllen ihn in mehreren Durchgängen gleichzeitig aus, ähnlich wie Bildgeneratoren ein Bild aus Rauschen herausarbeiten. Dazu gehören Googles DiffusionGemma (10. Juni), Inceptions Mercury 3 (19. Oktober) und DiffuSpaces Clover-35B-A3B-Preview (Ende Oktober). Hinzu kommt Next-Concept Modeling (NCM) von Stanford und Together AI (9. Oktober). Es erzeugt Text erst grob und dann immer feiner.

Alle werben mit Tempo: viermal, achtmal, bis zu 31-mal schneller. Wir sind der Frage nachgegangen, woher diese Zahlen stammen. Unsere These: Der Vorsprung gilt vor allem bei einzelnen Anfragen auf großen Rechenzentrums-GPUs und gegen schwache Vergleichsmodelle. Er schrumpft, sobald viele Anfragen gleichzeitig laufen, auf normaler Hardware gerechnet wird oder klassische Modelle mit spekulativem Decoding antreten. Dabei schlägt ein kleiner Helfer mehrere Token auf einmal vor, und das große Modell prüft sie in einem einzigen Durchgang.

Eine eigene Messung von DiffusionGemma gegen Gemma 4 auf einer Consumer-Grafikkarte konnten wir für diesen Artikel nicht durchführen. Wir stützen uns auf die Technical Reports, auf öffentliche Messdaten und auf Erfahrungsberichte aus der Community.

Die Versprechen im Überblick

Die Tabelle zeigt das Grundproblem: Jede Zahl wurde unter anderen Bedingungen gemessen, und fast keine wurde von Dritten nachgeprüft.

DiffusionGemma: Der Vergleich mit dem eigenen Geschwister

Googles Technical Report ist das gründlichste Dokument der vier. Er legt den Messaufbau offen: eine H100, FP8-Präzision, Batch-Größe 1 (also eine einzige Anfrage), 4.096 Token Eingabe und 1.024 Token Ausgabe.

Drei Dinge fallen auf.

Erstens die Vergleichsbasis. Die „stark optimierte“ Gemma-4-Variante mit MTP (Multi-Token-Prediction, eine Form des spekulativen Decodings) schafft im Schnitt nur 1,4 Token pro Rechendurchlauf. Der Report selbst nennt für spekulatives Decoding typische Werte von 3 bis 6. Wie viel mehr möglich ist, zeigt das Verfahren DFlash beim ähnlich aufgebauten Qwen3.6-35B-A3B. Laut der Modellkarte von z-lab steigt das Tempo auf einer B200 bei einer Anfrage von rund 307 auf bis zu 1.116 Token/s, das 2,2- bis 3,6-Fache. Unsere Rechnung, keine Messung: Würde Gemma 4 ähnlich stark profitieren, läge es bei etwa 470 bis 740 Token/s. DiffusionGemma wäre dann noch zwei- bis dreimal so schnell und nicht knapp fünfmal.

Zweitens die Last. Laut Report hat DiffusionGemma nur bis etwa 32 gleichzeitige Anfragen die Nase vorn, danach ist das klassische Gemma 4 mit MTP im Vorteil. Google schreibt im Blogbeitrag selbst, bei Cloud-Diensten mit vielen Anfragen bringe paralleles Decoding wenig und könne die Kosten sogar erhöhen. Die Autoren betonen, dass sie die Batch-Verarbeitung noch nicht optimiert haben, und nennen eine Analyse unter realer Last „zukünftige Arbeit“.

Drittens die Qualität. In fast allen Benchmarks liegt DiffusionGemma hinter seinem Geschwister, am deutlichsten bei Mathematik (AIME: 69,1 statt 88,3) und bei Agenten-Aufgaben (Tau2). Außerdem fallen die Antworten kürzer aus: im Denkmodus durchschnittlich 4.001 Token gegenüber 7.207 bei Gemma 4 mit MTP. Das verkürzt die Wartezeit zusätzlich, kostet laut Report aber auch einen Teil der Vorteile, die längeres „Nachdenken“ bringt.

Auf Consumer-Hardware ist die Datenlage dünn. Die Angabe von über 700 Token/s auf einer RTX 5090 stammt von Google. Im Nvidia-Blog stehen Werte für H100 (1.000), DGX Spark (150) und DGX Station (2.000), aber keiner für die 5090. Unsloth nennt über 2.000 Token/s auf einer RTX 6000, allerdings ohne Messbedingungen. Auf Apple Silicon fallen die Berichte ernüchternd aus. Ein Tester von XDA fand DiffusionGemma auf einem M4 Pro nicht schneller als Gemma 4. In einem llama.cpp-Issue maß ein Nutzer auf einem M3 Max zunächst 6 bis 28 Token/s und nach eigenen Optimierungen 48 bis 61 Token/s. Google warnt selbst, dass Rechner mit gemeinsamem Speicher wie Macs nicht dieselbe Beschleunigung sehen. Eine sauber dokumentierte Messung gegen Gemma 4 auf einer RTX 4090 oder 5090, mit einer und mit 16 Anfragen, haben wir nicht gefunden.

Wie parallel ist „parallel“?

DiffusionGemma schreibt Blöcke von 256 Token. Im Schnitt legt es pro Durchgang aber rund 20 Token fest und nicht 256. Dank adaptivem Stopp braucht es etwa 12 Durchgänge pro Block. Die Blöcke selbst entstehen weiterhin nacheinander.

Eine Interpretierbarkeits-Studie von Asaria, Salomone und Gandhi zeichnet nach, wann das Modell welches Token festlegt. Getestet wurde mit 686 Prompts aus sechs Aufgabentypen. Ergebnis: Die Decodierung ist „weder parallel noch blockweise sequenziell“. Es gibt eine teilweise Links-nach-rechts-Tendenz, die auf Token-Ebene schwach ist und bei gröberer Betrachtung stärker wird. JSON legt das Modell in nahezu beliebiger Reihenfolge fest. Googles Report bestätigt das Muster in Anhang G.2: Bei Aufgaben mit strengen Abhängigkeiten löse das Modell die Logik „überwiegend von links nach rechts“ und brauche mehr Durchgänge. Unsere Einschätzung: Je stärker ein Text auf vorher Gesagtem aufbaut, etwa bei Rechenwegen oder längeren Argumentationen, desto weniger kann das Modell parallel arbeiten.

Mercury 3: 1.068 im Labor, rund 200 im Alltag

Inception nennt 1.068 Token/s „auf Nvidia-GPUs“. Modellgröße, Batch-Größe und Prompt-Länge stehen nicht dabei. Unabhängige Messungen zeigen ein anderes Bild. Laut einer Auswertung von eesel.ai lag der Median bei OpenRouter im Wochenmittel bei 221 Token/s, die langsamsten 10 Prozent der Anfragen kamen auf 79 Token/s oder weniger. OpenRouter leitet alle Anfragen direkt an Inception weiter. Auf Hacker News berichteten Tester von 300 bis 400 Token/s, ein anderer von rund 160 Token/s bei einem großen Programmierauftrag. Simon Willison nannte das Tempo dort „ein bisschen enttäuschend“. Mehrere Nutzer bemängelten außerdem eine lange Time to First Token, also die Wartezeit bis zum ersten Wort.

Diese Zahlen spiegeln echten Betrieb mit beliebigem Denkaufwand und schwankender Serverlast wider. Sie sind also nicht direkt mit einer Labormessung vergleichbar. Aber genau das erleben Nutzer. Artificial Analysis führt Mercury 3 bisher nicht, sondern nur Mercury 2 (zuletzt 292 Token/s, inzwischen eingestellt) und Mercury 2.5 (557 Token/s). Laut einer Digg-Zusammenfassung warnte Artificial Analysis zudem, dass die von Inception veröffentlichten Werte zu den Tests AA-Omniscience und GDPval-AA nicht nach seiner Methodik ermittelt wurden. Googles Team schätzte Mercury 2 über OpenRouter auf durchschnittlich 600 Token/s, Artificial Analysis maß damals einen Median von rund 987 Token/s. Die Spanne zeigt, wie stark solche Werte von Hardware, Last und Testdaten abhängen.

Clover und NCM: Mit starker Gegnerschaft schrumpft der Abstand

DiffuSpace hat Clover aus dem klassischen Qwen3.6-35B-A3B abgeleitet und vergleicht immerhin mit einem starken Gegner. Laut Hugging-Face-Blog erreicht Clover auf einer H200 bei Agenten-Aufgaben 515 Token/s, ein Qwen-Modell mit dem spekulativen Verfahren DFlash2 kommt auf 365. Das ist ein Faktor von etwa 1,4, nicht 4. Der Spitzenwert von 680 Token/s stammt von einer GB300 bei einer Anfrage mit internen Aufgaben. Auf einer RTX 5070 Ti nennt DiffuSpace 101,8 gegenüber 48,5 Token/s, ohne genau zu sagen, gegen welches Modell. Lokal ist das Tempo ohnehin noch Theorie: Laut der GGUF-Seite von AtomicChat wurde die llama.cpp-Unterstützung am 2. November nur für den klassischen Wort-für-Wort-Modus übernommen. Der ungemergte parallele Modus lieferte auf einer A100 0,6 bis 0,7 Token/s, der normale Modus rund 53.

Bei NCM sind die 10- bis 31-fachen Beschleunigungen echt gemessen: auf einer H100 bei Batch 16. Laut Paper treten aber nur andere Diffusionsmodelle wie DUO oder AURORA-LM gegen NCM an, und die Modelle haben rund 100 Millionen Parameter (im Skalierungstest bis 725 Millionen). Klassische Modelle tauchen nur beim Zählen der Rechendurchläufe auf, nicht in der Zeitmessung. Die Autoren nennen selbst Grenzen: Auch kurze Texte durchlaufen die volle Hierarchie, der Tokenizer wird separat trainiert, und an Übergängen zwischen den Ebenen entstehen gelegentlich Fehler.

Was die Forschung selbst noch als Baustelle sieht

Neue Paper aus dem November zeigen, wo es hakt. SpecCTMC beschreibt das Grunddilemma: Werden Token unabhängig voneinander parallel gezogen, gehen Abhängigkeiten zwischen ihnen verloren. Exaktes Sampling braucht dagegen eine Modellauswertung pro Token. Measured Coupling misst, welche Token gefahrlos zusammen festgelegt werden können, und kostet dabei im Schnitt 1,1 Punkte Genauigkeit. Mix-FT setzt am Training an, weil es nicht zu wenigen, parallelen Schritten passt. Zusammen zeigt das: Wer mehr parallel schreibt, bezahlt bisher meist mit Qualität.

Einordnung

Unsere Einschätzung: Die These hält weitgehend. Der Tempovorteil von Diffusions-Sprachmodellen ist real, aber er ist ein Vorteil für bestimmte Bedingungen. Am größten ist er bei einer einzelnen Anfrage auf einer schnellen Rechenzentrums-GPU und gegen klassische Modelle ohne gutes spekulatives Decoding. Tritt ein starkes Verfahren wie DFlash an, schrumpft er nach den vorliegenden Zahlen auf grob das 1,4- bis 3-Fache. Bei vielen gleichzeitigen Anfragen kehrt er sich um, und auf Macs ist er bisher nicht nachweisbar. Hinzu kommen Qualitätsverluste, die bei Mathematik und Agenten-Aufgaben deutlich ausfallen.

Fair ist auch: Google legt Messaufbau, Schwächen und den Umschlagpunkt bei 32 Anfragen offen. Das ist mehr, als Inception für Mercury 3 liefert. Für lokale Einzelnutzer, Code-Ergänzung und strukturierte Ausgaben kann das Prinzip sinnvoll sein.

Offen bleibt das Wichtigste: unabhängige, gleich aufgebaute Messungen. Dazu gehören dieselbe Grafikkarte, dieselben Prompts, eine und 16 Anfragen, kurze und lange Antworten, und als Gegner das klassische Modell mit seinem besten spekulativen Decoding. Bis es diese Messungen gibt, sind „1.000 Token pro Sekunde“ ein Laborwert, kein Alltagswert.