Die Physik der Tokens pro Sekunde

Die Geschwindigkeit der Tokengenerierung ist kein Mysterium: Beim Decode verlangt jedes einzelne Token im Wesentlichen das einmalige Lesen aller aktiven Gewichte aus dem Speicher. Das macht den Decode speicherbandbreitenlimitiert, und es heißt, dass Sie Ihre tok/s per Division vorhersagen können. Alles, worüber Leute streiten — Quantisierung, MoE, Offloading, Batching —, ist diese Formel mit verschiedenen Hüten.

Die eine Formel

tokens/sec ≈ effective memory bandwidth ÷ bytes of weights read per token

RTX 4090, 8B Q4_K_M:
  1008 GB/s ÷ 4.9 GB ≈ 205 tok/s theoretische Decke
  beobachtet: ~120–150 tok/s (Overhead, Attention, KV-Lesen)

Plausibilitätstabelle für einen verbreiteten Fall (8B bei Q4_K_M, ein Stream — Größenordnungszahlen, keine Spezifikationen; messen Sie Ihre eigenen):

Warum die Lücke zwischen Decke und Realität? Kernel-Start-Overhead, Attention-Arbeit, die mit dem Kontext wächst, und KV-Cache-Lesen obendrauf auf die Gewichte. Die Formel gibt Ihnen die Decke; Sie realisieren typischerweise 60–75% davon im Single-Stream.

Eine Karte, vier Modelle

Die Formel sagt auch voraus, wie Modellgröße auf fester Hardware gegen Geschwindigkeit getauscht wird. Decke auf einer ~1.000-GB/s-Karte, dann 60–75% realisiert (illustrativ):

Zwei Lehren fallen ab. Parameterverdopplung halbiert die Geschwindigkeit auf derselben Karte ungefähr. Und ein 32B auf einer 24-GB-Karte ist für Chat noch schnell genug — speicherlimitiert ist nicht hoffnungslos. Diese Paarung ist der Grund, warum 24-GB-Karten und 32B-Q4-Quants ständig zusammen auftauchen (siehe GPU-Klassen).

Quantisierung ist eine Geschwindigkeitsfunktion, nicht nur Kompression

Dieselbe Formel, weniger Bytes: Ein 8B-Modell bei fp16 liest ~16 GB pro Token; bei Q4_K_M liest es ~4,9 GB. Auf derselben Karte fährt Q4 grob die dreifache fp16-Geschwindigkeit und passt, wo fp16 nicht passt. Deshalb sind Q4-Klasse-Quants die Standardempfehlung für lokale Nutzung (siehe Quantisierung) — der Qualitätsverlust ist klein, und der Geschwindigkeitsgewinn ist strukturell, nicht zufällig.

Kontext bremst Sie aus

Mit wachsender Konversation muss jedes neue Token auch den KV-Cache für jedes vorherige Token lesen — diese Lesevorgänge skalieren mit der Kontextlänge. Nahe einem leeren Kontext schafft ein 8B Q4 vielleicht 140 tok/s auf einer Karte der 4090-Klasse; tief in einer 64k-Token-Sitzung kann dasselbe Setup auf die Hälfte oder ein Drittel davon einsacken. Attention-Kernel passen auch nicht mehr in cache-freundliche Formen. Langkontext-Workloads sind dort, wo Flash Attention und KV-Quantisierung sich bezahlt machen (siehe KV-Cache und Engine-Regler).

Eine verbreitete Verwirrung: „Das Model wurde langsamer, je länger der Chat lief“ ist meist KV-Wachstum, nicht ein degradierender Server (siehe KV-Cache).

MoE: schnell für die Fähigkeit

Mixture-of-Experts-Modelle aktivieren nur wenige Expertenblöcke pro Token, also folgen die pro Token gelesenen Bytes den aktiven Parametern, nicht der Gesamtzahl. Ein Model mit 30B gesamt/3B aktiv bei Q4 liest nur ein paar Gigabyte pro Token — es decodiert wie ein kleines Model und trägt dabei das Wissen eines großen. Das ist der ganze Reiz der MoE-Familien für lokale Nutzung (siehe Modellfamilien): Sie zahlen Speicher, um die Experten zu speichern, aber Bandbreite nur für die, die Sie nutzen.

Konkrete Gestalt zum Zeitpunkt dieses Textes: Die Klasse Qwen3-30B-A3B liest pro Token nur ihre ~3B aktiven Parameter — Großmodell-Wissen zu Kleinmodell-Geschwindigkeit, für ~18 GB VRAM bei Q4.

Spekulatives Dekodieren

Paaren Sie ein kleines Draft-Modell mit dem großen Ziel: Der Draft schlägt günstig k Tokens vor, das Ziel verifiziert alle k in einem Forward-Pass, akzeptierte Tokens kommen in der Qualität des Ziels heraus. Bei Greedy-artigen Workloads — Code-Vervollständigung, JSON, Extraktion bei niedriger Temperatur — erwarten Sie 2–3× Decode-Beschleunigung. Bei hoher Temperatur rät der Draft öfter falsch, und der Gewinn schrumpft. llama.cpp legt das über --model-draft und Draft-Length-Flags frei; exakte Flag-Namen driften zwischen Versionen, prüfen Sie --help.

Kosten: Der Draft muss den Tokenizer des Ziels teilen, und beide Modelle sitzen im Speicher.

Parallelismus: die Realität

Zwei GPUs geben Ihnen nicht das Doppelte eines einzelnen Streams. Tensor-Parallelismus (vLLM -tp 2) teilt jeden Layer für den Durchsatz über Karten, um den Preis von Interconnect-Verkehr; llama.cpps Standard-Aufteilung ist Pipeline (Layer-weise), was der Kapazität mehr hilft als der Single-Stream-Latenz. Realistische Erwartung für eine gute Zwei-Karten-Aufteilung: 1,2–1,6× Single-Stream, nicht 2×. Verspricht jemand lineare Skalierung pro GPU, verkauft er etwas.

Karten hinzuzufügen skaliert allerdings die Kapazität schön — das ist die Servergeschichte in Parallelität.

Die CPU-Offload-Klippe

Bleiben Layer auf der CPU, hüpft der Forward-Pass jedes Tokens über PCIe (~10–25 GB/s) in den System-RAM und zurück. Die Schleife läuft mit der Geschwindigkeit ihres langsamsten bewohnten Teils: Ein Model mit 80% der Layer auf der GPU läuft viel näher an CPU-Geschwindigkeit als an „80% GPU-Geschwindigkeit“. Passt ein Model fast, gehen Sie einen Quant-Schritt runter, statt halb zu offloaden — siehe Engine-Regler. Das Erkennungszeichen versehentlichen Partial-Offloads ist 3–10 tok/s auf Hardware der GPU-Klasse.

Prefill ist rechenlimitiert: TTFT ist eine andere Messung

Die Verarbeitung Ihres Prompts ist über Tokens parallel und durch Rechenleistung begrenzt, nicht durch Bandbreite — eine Karte der 4090-Klasse kann ein 8B Q4 mit ein paar tausend tok/s im Prefill verarbeiten. Also kostet ein 12k-Token-Einfügen ~3–5 s vor dem ersten Ausgabe-Token, obwohl der Decode danach mit 140 tok/s läuft. Time-to-First-Token und Dauerlauf-tok/s sind verschiedene Zahlen, die verschiedene Flasenhälse messen; wenn Sie einen Benchmark lesen, prüfen Sie, welchen von beiden er zeigt.

Messen Sie selbst

Zahlen auf Seiten (diese eingeschlossen) sind Decken und Bereiche. Ihr Setup ist in zwei Minuten gemessen:

1. Generieren Sie ~200 Tokens aus einem kurzen Prompt; ignorieren Sie den allerersten Lauf (Kaltladung).
2. Nehmen Sie den Dauerlauf-Decode: generierte Tokens ÷ Sekunden nach dem ersten Token.
3. Notieren Sie separat das Time-to-First-Token bei einem langen Einfügen — es ist ein anderer Flaschenhals.

llama-server druckt Prompt-Eval- und Eval-tok/s pro Anfrage; LM Studio zeigt Decode-tok/s live; nvidia-smi bestätigt, dass die GPU beim Testen wirklich beschäftigt ist.

Wie sich Geschwindigkeit anfühlt

Die Schwellenwerte sind überraschend niedrig, weil die Lesegeschwindigkeit beim Menschen nur ~5–10 tok/s beträgt — aber auf eine Vervollständigung bei 5 tok/s zu warten ist Elend. Fühlen Sie es selbst: Der Simulator rendert dieselbe Antwort mit verschiedenen Token-Raten, und eine Minute dort lehrt mehr als jede Tabelle.

Unter ~2–3 tok/s fühlt sich eine Streaming-UI kaputt an statt langsam — Leute schließen den Tab, also behandeln Sie das als harten Boden für interaktive Nutzung.

Verwandt: Hardware-Überblick · VRAM-Mathematik · GPU-Klassen · Engine-Regler