Token-Geschwindigkeit: Warum KI-Inferenz plötzlich 10-15× schneller wurde
Diese Woche stellte OpenAI GPT-5.6 Sol vor, ein Frontier-Modell, das auf Cerebras Wafer-Scale-Hardware mit bis zu 750 Ausgabe-Tokens pro Sekunde bedient wird — ungefähr das 5–10-Fache der 70–150 Tokens/Sekunde pro Nutzer, die GPU-bediente Frontier-Modelle typischerweise liefern. Schlagzeilen nannten es Magie. Ist es nicht. Es ist die Auszahlung einer Engpass-Verschiebung, die sich seit zwei Jahren aufgebaut hat, und fast niemand außerhalb des Inference-Engineerings versteht den Mechanismus. Diese Lektion ist die klare Version: Was die Token-Geschwindigkeit tatsächlich begrenzt, das Rennen um spezialisierte Hardware, das die Grenze gerade durchbrochen hat, die Software-Tricks, die sie weiter vervielfachen, und warum schnelle Tokens leise verändern, was KI-Produkte sein können.
- Erklären, warum LLM-Inferenz durch die Speicherbandbreite begrenzt wird, nicht durch rohe Rechenleistung — und was das physikalisch bedeutet
- Beschreiben, wie Cerebras Wafer-Scale-Chips, Groq LPUs und SambaNova RDUs jeweils die Memory Wall angreifen
- Die drei Software-Multiplikatoren benennen — speculative decoding, quantization, batching — und den Kompromiss, den jeder eingeht
- Vorhersagen, welche Produkte schnelle Tokens zuerst verwandeln: Agents, Reasoning-Modelle und Sprache
- Inferenzgeschwindigkeit für deine eigene Workload korrekt benchmarken: Tokens/Sek UND Time-to-First-Token, niemals nur eines
Der Engpass, den niemand erwartet: Speicherbandbreite, nicht Rechenleistung
Hier ist die Tatsache, die alles andere neu ordnet: um ein einziges Token zu generieren, muss das Modell im Wesentlichen alle seine (aktiven) Gewichte aus dem Speicher lesen. Nicht einige davon — alle, einmal pro Token.
Ein 70B-Parameter-Modell mit 16-Bit-Präzision umfasst etwa 140 GB an Gewichten. Ein Token generieren: 140 GB vom Speicher zu den Recheneinheiten streamen. Das nächste Token generieren: dieselben 140 GB erneut streamen. Die Matrizenmathematik selbst ist im Vergleich fast trivial — moderne Chips haben Rechenleistung im Überfluss. Die Leitung zwischen Speicher und Rechenwerk ist das, was gesättigt ist.
Rechne es durch, und die Erfahrung der "langsamen KI" erklärt sich von selbst. Die HBM-Speicherbandbreite einer NVIDIA H100 beträgt etwa 3,35 TB/s. Teile 3,35 TB/s durch 140 GB pro Token, und du erhältst eine harte Obergrenze von etwa 24 Tokens pro Sekunde für einen einzelnen Nutzer auf einer GPU, vor jedem weiteren Overhead. Das ist der Grund, warum Chatbots in Lesegeschwindigkeit tippen: nicht weil der Chip nicht schnell genug multiplizieren kann, sondern weil er nicht schnell genug sein eigenes Gehirn lesen kann. Inference-Ingenieure nennen das die Memory Wall, und sowohl Cerebras als auch Groq beschreiben sie als die fundamentale Beschränkung generativer KI.
Und es potenziert sich: Neben den Gewichten liest jedes neue Token auch den KV cache — die gespeicherten Attention-Keys und -Values für jedes Token, das bereits im Kontext ist. Lange Kontexte machen jedes nachfolgende Token teurer in der Erzeugung.
- Der gesamte Prompt wird in einem parallelen Durchlauf verarbeitet. Diese Phase ist compute-bound (viel Mathematik, Gewichte einmal für viele Tokens gleichzeitig gelesen) und bestimmt deine Time-to-First-Token.
- Um Token N+1 zu erzeugen, streamt die Hardware jedes aktive Gewicht vom Speicher durch die Recheneinheiten. Für ein 70B-Modell bei FP16 sind das ~140 GB an Lesevorgängen — für EIN Token.
- Attention liest außerdem die gecachten Keys/Values jedes vorherigen Tokens. Je länger die Unterhaltung, desto mehr Bytes pro Token. Diese Phase ist memory-bandwidth-bound, und hier geht fast die gesamte Generierungszeit hin.
- Das neue Token wird an die Sequenz angehängt und die Schleife läuft erneut. Von Natur aus sequenziell — Token N+1 kann nicht beginnen, bevor Token N existiert. Die Geschwindigkeit dieser Schleife IST deine Tokens/Sekunde.
Das Rennen um schnelle Inferenz ist also in Wirklichkeit ein Rennen darum, Gewichts-Bytes schneller zu bewegen. Es gibt genau zwei Wege zu gewinnen: einen radikal schnelleren Speicher bauen oder die Anzahl der zu bewegenden Bytes verkleinern. Die Hardware-Unternehmen wählten den ersten Weg. Die Software-Tricks (unten) wählten den zweiten. Die aktuelle Geschwindigkeitsexplosion ist beides zugleich.
Das Hardware-Rennen: die Gewichte AUF den Chip legen
Der schnellste Speicher in jedem Computer ist SRAM — der Speicher auf demselben Die wie das Rechenwerk. Er ist um Größenordnungen schneller als das HBM, das neben einer GPU gestapelt ist, aber winzig: Megabytes, nicht Gigabytes. Die drei Unternehmen für spezialisierte Inferenz gingen alle dieselbe kühne Wette ein — den On-Chip-Speicher groß genug (oder die Chip-Anzahl hoch genug) machen, um das ganze Modell im SRAM zu halten — und jedes konstruierte es anders.
Cerebras: ein Chip von der Größe eines Essenstellers
Cerebras baut die Wafer-Scale Engine (WSE-3): statt einen Silizium-Wafer in Hunderte kleiner Chips zu zerteilen, ist der gesamte 300-mm-Wafer ein Chip — 46.225 mm², 4 Billionen Transistoren, 900.000 Kerne, 44 GB On-Chip-SRAM und ungefähr 21 Petabyte/Sekunde Speicherbandbreite. Cerebras vermarktet das als etwa das 7.000-Fache der Speicherbandbreite einer H100, und das ist der ganze Trick: Gewichte, die im SRAM leben, überqueren nie einen langsamen Off-Chip-Bus. Öffentliche Ergebnisse umfassen Llama 3.1-405B mit 969 Tokens/Sekunde bei einer Time-to-First-Token von 240 ms und Llama 3.1 70B mit über 2.100 Tokens/Sekunde.
Die GPT-5.6-Sol-News, entschlüsselt
Das ist die Maschinerie hinter der Ankündigung dieser Woche. OpenAIs GPT-5.6 Sol Preview kombiniert ein Frontier-Modell mit Cerebras-Serving bei bis zu 750 Tokens/Sekunde — gegenüber den ~70 Tokens/Sekunde, die dieselbe Modellklasse pro Nutzer beim GPU-Serving auf H100-Niveau schafft, ein 10-facher Sprung (~15× gegenüber den langsamsten Mainstream-Deployments). Sol startet zu $5 Input / $30 Output pro Million Tokens als Flaggschiff einer Drei-Modell-Familie (Sol, Terra, Luna), mit frühem Zugang, der auf eine kleine Gruppe von Organisationen beschränkt ist, bevor Mitte Juli 2026 die allgemeine Verfügbarkeit folgt. Community-Analysten schätzen, dass Sol über etwa 70–100 Wafer bedient wird — ungefähr eine Transformer-Schicht pro Wafer — auch wenn OpenAI die Topologie nicht bestätigt hat, also behandle dieses Layout als informierte Spekulation. Was es in jedem Fall signalisiert: Zum ersten Mal wird ein Frontier-Class-Modell, nicht nur ein Open-Weights-Modell, mit spezialisierter Hardware-Geschwindigkeit bedient.
Groq: Hunderte kleiner deterministischer Chips
Groqs LPU (Language Processing Unit) nimmt die entgegengesetzte Form an. Jede LPU hat überhaupt kein externes DRAM — nur ein paar hundert Megabyte On-Chip-SRAM bei ~80 TB/s (gegenüber den 3,35 TB/s der H100). Ein großes Modell wird über Hunderte von Chips verteilt (sharded): Llama 3 70B bei FP8 erstreckt sich über ein Rack von 300+ LPUs, von denen jede ein ~230-MB-Segment hält. Die magische Zutat ist Determinismus: es gibt keine Caches, kein dynamisches Scheduling — der Compiler plant die gesamte Ausführung, einschließlich der Chip-zu-Chip-Kommunikation, bis auf den einzelnen Taktzyklus, sodass nichts jemals auf etwas Unvorhersehbares wartet. Groqs Formel dafür lautet "determinism is speed", und mit speculative decoding haben sie Llama 3 70B mit über 1.660 Tokens/Sekunde gezeigt.
SambaNova: drei Speicherebenen, riesige Modelle
SambaNovas RDU (Reconfigurable Dataflow Unit) vermischt Ansätze mit einem dreistufigen Speichersystem (SRAM + HBM + DRAM), womit es die größten Modelle effizient bedient: das vollständige 671B-Parameter-DeepSeek-R1 mit ~198–250 Tokens/Sekunde auf nur 16 SN40L-Chips — ein Modell, das beim typischen GPU-Serving 30–80 Tokens/Sekunde schafft — und Llama 3 8B mit 1.000 Tokens/Sekunde, unabhängig validiert von Artificial Analysis.
| Ansatz | Kernidee | Speicher für Gewichte | Verifiziertes Geschwindigkeitsbeispiel |
|---|---|---|---|
| GPU (H100-Klasse) | Allzweck, durchsatzorientiert | Off-Chip-HBM, ~3,35 TB/s | ~70–150 Tok/s pro Nutzer, Frontier-Modelle |
| Cerebras WSE-3 | Ganzer Wafer = ein Chip | 44 GB On-Chip-SRAM, ~21 PB/s | Llama 3.1-405B mit 969 Tok/s; GPT-5.6 Sol bis zu 750 Tok/s |
| Groq LPU | Deterministischer Datenfluss, compiler-geplant | Nur SRAM (~230 MB/Chip), Modell über 300+ Chips verteilt | Llama 3 70B mit 1.660+ Tok/s (mit spec. decoding) |
| SambaNova RDU | Rekonfigurierbarer Datenfluss, 3-stufiger Speicher | SRAM + HBM + DRAM | DeepSeek-R1 671B mit ~250 Tok/s auf 16 Chips |
- Keine dieser Zahlen ist magische Rechenleistung: jeder Eintrag in dieser Tabelle ist eine andere Antwort auf dieselbe Frage — wie streamen wir Gewichts-Bytes schneller zu den Recheneinheiten?
- Geschwindigkeitsrekorde sind Geschwindigkeiten pro Nutzer (pro Sitzung). Der Gesamtdurchsatz eines Rechenzentrums ist eine andere Metrik, in der GPUs weiterhin hervorragend sind — diese Unterscheidung ist der Batching-Kompromiss weiter unten.
Software-Multiplikatoren: schnellere Tokens auf JEDER Hardware
Hardware ist nicht der einzige Hebel. Drei Software-Techniken vervielfachen die Geschwindigkeit auf GPUs und spezialisierten Chips gleichermaßen — und sie erklären zu großen Teilen, warum sogar gewöhnliches GPU-Serving dieses Jahr schneller wurde.
Speculative decoding — die kontraintuitive. Ein kleines, schnelles Draft-Modell errät die nächsten mehreren Tokens; das große Modell verifiziert sie dann alle in einem einzigen Forward-Pass. Die Verifikation von N Draft-Tokens kostet ungefähr dasselbe Gewichts-Streaming wie das Generieren eines Tokens — wenn die Schätzungen also richtig sind (und bei vorhersehbarem Text sind sie es meistens), erhältst du mehrere Tokens zum Speicherpreis von einem. Der Teil, den wenige kennen: die Ausgabe ist nachweislich identisch mit dem, was das große Modell allein produziert hätte. Es ist keine Näherung — falsche Schätzungen werden einfach abgelehnt und neu generiert. Das ist die Technik hinter Groqs 1.660-Tok/s-Zahl, und jeder große Anbieter nutzt inzwischen irgendeine Variante.
Quantization — die direkte. Wenn der Engpass die pro Token bewegten Bytes sind, halbiere die Bytes: speichere die Gewichte in 8-Bit oder 4-Bit statt 16-Bit, und die Decode-Geschwindigkeit steigt nahezu proportional, weil du buchstäblich die Hälfte (oder ein Viertel) der Daten streamst. Der Kompromiss sind meist geringe, gelegentlich reale Genauigkeitskosten — miss auf deiner Aufgabe, nicht nach Bauchgefühl.
Batching — die mit dem Kompromiss. GPUs holen Effizienz zurück, indem sie viele Nutzer in einem Durchlauf bedienen: die Gewichte werden einmal gestreamt und über den gesamten Batch wiederverwendet, sodass der Gesamtdurchsatz in die Höhe schnellt. Aber die Tokens jedes einzelnen Nutzers kommen immer noch mit der gemeinsamen sequenziellen Rate heraus — große Batches bedeuten hohen Rechenzentrumsdurchsatz und mittelmäßige Geschwindigkeit pro Nutzer. Das ist die am häufigsten fehlgedeutete Zahl im Inference-Marketing: ein Anbieter, der "Tausende von Tokens pro Sekunde" nennt, meint möglicherweise den aggregierten Durchsatz, nicht das, was du in einer Sitzung erlebst.
Warum schnelle Tokens alles verändern
Geschwindigkeit klingt nach einem Komfort-Feature. Sie ist tatsächlich eine Fähigkeitsschwelle, denn mehrere Produktkategorien funktionieren nur unterhalb einer bestimmten Echtzeit-Latenz.
Agents bekommen den größten Multiplikator. Eine Agent-Schleife ist seriell: das Modell aufrufen, ein Tool ausführen, Ergebnisse zurückgeben, wiederholen — 20 Modellaufrufe in Folge sind Routine. Bei 70 Tok/s sind 20 Aufrufe mit durchschnittlich je 800 Ausgabe-Tokens ~230 Sekunden reine Generierung: eine Kaffeepause, sodass Agents zu Hintergrundjobs degradiert werden. Bei 750 Tok/s ist dieselbe Schleife ~21 Sekunden: interaktiv. Der Speedup multipliziert sich über jeden Schritt der Schleife, sodass 10× schnellere Tokens einen Agent nicht um 10 % netter machen — sie verschieben ihn über die Linie vom Batch-Werkzeug zum Gesprächspartner. (Baust du Agents? Beginne bei Ein Modell auswählen.)
Reasoning-Modelle denken mehr pro Sekunde. Die Qualität eines Reasoning-Modells skaliert mit der Anzahl der Denk-Tokens, die es ausgeben kann. Bei GPU-Geschwindigkeiten bedeutet "hoher Aufwand" Minuten des Wartens, sodass Nutzer das Denken herunterdrehen. Bei Wafer-Scale-Geschwindigkeiten wird dasselbe Denkbudget in Sekunden abgeschlossen — du bekommst mehr Intelligenz bei gleicher Echtzeit-Latenz, was wohl der eigentliche strategische Sinn der OpenAI–Cerebras-Kombination ist.
Sprache wird wirklich echtzeitfähig. Menschliche Unterhaltung toleriert ~500 ms Antwortlücke. Schnelles Serving mit einer Time-to-First-Token unter 300 ms (Cerebras demonstrierte 240 ms bei einem 405B-Modell) plus Generierung weit über Sprechgeschwindigkeit macht natürliches gesprochenes Hin und Her — mit einem Frontier-Modell, nicht einem kleinen destillierten — endlich machbar.
Die Kostendynamik wird interessant. Schnell ist nicht automatisch günstig: spezialisiertes Serving verlangt Premium-Preise (Sols $30/M Ausgabe-Tokens sind erstklassig), und dieselbe Geschwindigkeit, die Nutzer erfreut, lässt Agents auch Tokens schneller verbrennen. Aber Wafer-Scale-Anbieter argumentieren auch, dass ihre Kosten pro Token die von GPUs im großen Maßstab unterbieten, also erwarte, dass Geschwindigkeitsstufen zu einer Standard-Preisachse werden, wie Express-Versand. Kontext zur Budgetierung findest du in Was KI bei verschiedenen Anbietern kostet.
Wie man Geschwindigkeit bewertet — für DEINE Workload
Der häufigste Benchmarking-Fehler: "Tokens pro Sekunde" als die ganze Geschichte zu behandeln. Es gibt zwei Zahlen, erzeugt von zwei unterschiedlichen Engpässen:
- Time-to-First-Token (TTFT) — wie lange, bis die Ausgabe beginnt. Dominiert von der compute-bound prefill-Phase, also wächst sie mit deiner Prompt-Länge. Das ist, was Chat- und Sprachnutzer spüren.
- Ausgabe-Tokens/Sekunde — wie schnell der Text fließt, sobald er begonnen hat. Dominiert von der memory-bound decode-Phase. Das ist, was lange Generierungen und Agent-Schleifen spüren.
Ein Anbieter kann das eine gewinnen und das andere verlieren, weil sie unterschiedliche Hardware-Grenzen belasten. Eine RAG-App, die 50K-Token-Kontexte vollstopft, steht und fällt mit der TTFT; ein Agent, der lange Code-Dateien schreibt, steht und fällt mit der Decode-Geschwindigkeit. Unabhängige Bestenlisten wie Artificial Analysis berichten beides — aber deine Prompt-Formen, Kontextlängen und Traffic-Muster gehören dir, also miss mit deiner eigenen Workload. (Streaming macht die wahrgenommene Latenz ≈ TTFT statt der Gesamtzeit — siehe Streaming.)
- Wähle 10–20 echte Prompts aus deinem Produkt — echter System-Prompt, echte Kontextlänge. Die Geschwindigkeit variiert enorm mit der Eingabegröße; Spielzeug-Prompts erzeugen Spielzeug-Zahlen.
- Mit aktiviertem Streaming, erfasse (a) die Zeit bis zum ersten Content-Chunk und (b) die Ausgabe-Tokens geteilt durch die Generierungszeit nach dem ersten Chunk. Protokolliere sie als zwei Metriken, niemals als eine.
- Führe 1, dann 10, dann deine Spitzenzahl paralleler Anfragen aus. Batching bedeutet, dass die Geschwindigkeit pro Nutzer unter Last abnehmen kann — zitierte Spitzenzahlen überstehen Nebenläufigkeit selten.
- Für Agents multipliziere die Latenz pro Aufruf mit deiner typischen Anzahl serieller Aufrufe, plus Tool-Zeit. Ein 2×-TTFT-Unterschied kann in einer 20-Aufruf-Schleife mehr zählen als ein 3×-Unterschied bei Tokens/Sek.
- Geschwindigkeits-Bestenlisten mischen sich ständig neu — allein im letzten Jahr fielen Rekorde wiederholt. Automatisiere den Benchmark und prüfe erneut vor jeder Anbieter-Bindung.
Eine Benchmark-Aufgabe zum Messen der echten Generierungsgeschwindigkeit
Write a complete Python module implementing a rate limiter with three strategies (fixed window, sliding window, token bucket), a shared abstract base class, type hints throughout, docstrings, and a pytest test suite covering edge cases (burst traffic, clock skew, zero-capacity buckets). Target roughly 2,000 tokens of output. Do not truncate or summarize - produce the full code. --- How to use this prompt as a benchmark --- 1. Send it with streaming enabled and your production system prompt attached. 2. Record TTFT = time from request to first streamed chunk. 3. Record decode speed = output_tokens / (total_time - TTFT). 4. Repeat 5 times at 3 different times of day; report medians, not best runs. 5. Re-run the same prompt with 30K tokens of context pasted above it - watch what happens to TTFT. That difference is your prefill cost.
Überprüfe dich selbst
0/5- Inferenzgeschwindigkeit ist ein Speicherbandbreiten-Problem: jedes Token erfordert das Streamen aller aktiven Gewichte, sodass ein 70B-FP16-Modell ~140 GB an Lesevorgängen pro Token bedeutet — das ist der ganze Engpass.
- Das Rennen um spezialisierte Hardware (Cerebras Wafer-Scale-SRAM, Groqs deterministische DRAM-freie LPUs, SambaNovas dreistufige RDUs) überwindet die Wall, indem es die Gewichte im On-Chip-Speicher hält — und GPT-5.6 Sol mit 750 Tok/s hat diese Geschwindigkeit gerade zu einem Frontier-Modell gebracht.
- Software vervielfacht sie weiter: speculative decoding (identische Ausgabe, Multi-Token-Verifikation), quantization (weniger Bytes pro Token), batching (Durchsatz hoch, Geschwindigkeit pro Nutzer runter — lies Anbieterangaben sorgfältig).
- Schnelle Tokens sind eine Fähigkeitsschwelle, kein Komfort-Feature: serielle Agent-Schleifen werden interaktiv, Reasoning-Modelle denken mehr pro Echtzeit-Sekunde, und Frontier-Modell-Sprache wird echtzeitfähig.
- Bewerte mit zwei Zahlen — TTFT (prefill, prompt-längen-sensitiv) und Ausgabe-Tokens/Sek (decode) — gemessen auf deinen eigenen Prompts bei deiner eigenen Nebenläufigkeit, monatlich erneut geprüft.
Neu darin, wie Modelle unter der Haube funktionieren? Der Abschnitt Grundlagen behandelt Tokens, Kontextfenster und Modellgrundlagen, auf denen diese Lektion aufbaut.
Quellen & weiterführende Literatur
- OpenAI — Previewing GPT-5.6 Sol
- Cerebras — Introducing Cerebras Inference: AI at Instant Speed — der Speicherbandbreiten-Engpass, erklärt von den Menschen, die darum herum gebaut haben
- Cerebras — WSE-3 Chip-Seite und Pressemitteilung zu Llama 3.1-405B mit 969 Tok/s
- Groq — What is a Language Processing Unit? und Inside the LPU: Deconstructing Groq's Speed
- SambaNova — High-speed support for the largest models (DeepSeek-R1 671B) und TechRadar-Bericht über das 16-Chip-Ergebnis
- VentureBeat — SambaNova breaks Llama 3 speed record with 1,000 tokens per second
- arXiv — A Comparison of Cerebras Wafer-Scale Integration with NVIDIA GPU-based Systems
- Artificial Analysis — unabhängige Geschwindigkeits- und Latenz-Bestenlisten
- byteiota — Cerebras + GPT-5.6 Sol: 750 tok/s changes your agent latency
- Verwandtes auf AILmanac: Ein Modell auswählen · Was KI bei verschiedenen Anbietern kostet · Streaming · Grundlagen