Tokens pro Sekunde: Was der Wert bei lokalen LLMs wirklich bedeutet

Kurz gesagt: „Tokens pro Sekunde“ beschreibt bei lokalen Sprachmodellen zwei verschiedene Dinge. Beim Einlesen deiner Eingabe arbeitet das Modell viele Tokens gleichzeitig ab und erreicht hohe Werte; beim Schreiben der Antwort entsteht ein Token nach dem anderen, und der Wert ist deutlich kleiner. Wer Benchmarks vergleicht, muss deshalb zuerst wissen, welche Phase gemessen wurde — und unter welchen Bedingungen.

Ein Token ist ein Wortstück, die Grundeinheit, in der ein Modell liest und schreibt; ausführlich erklärt im Guide LLM-Grundlagen. Warum die Generierung überhaupt eine harte Obergrenze hat — grob Speicherbandbreite geteilt durch Modellgröße —, steht in Warum kostet lokale KI so viel Hardware?. Hier geht es um die Frage danach: Was sagt eine Zahl wie „120 t/s“ eigentlich aus, und was nicht?

Zwei Phasen, zwei Geschwindigkeiten #

Wenn du einem lokalen Modell eine Frage stellst, passieren nacheinander zwei sehr unterschiedliche Dinge:

1. Prefill (Prompt-Verarbeitung): Das Modell liest deine komplette Eingabe — Systemprompt, bisherigen Chatverlauf, eingefügtes Dokument.
2. Decode (Generierung): Das Modell erzeugt die Antwort, Token für Token. Jedes neue Token hängt vom vorherigen ab.

Der Unterschied ist grundsätzlich: Weil beim Prefill alle Eingabe-Tokens von Anfang an vorliegen, kann das Modell sie in einem einzigen Durchlauf parallel verarbeiten; die Ausgabe dagegen entsteht in einer Schleife, ein Rechendurchlauf pro TokenBelegt. Deshalb analysiert die Forschung beide Phasen getrennt — und du solltest es bei Benchmarks auch tun.

Daraus folgt, was jeweils bremst:

• Der Prefill lastet die Rechenwerke einer GPU schon bei kleinen Batchgrößen voll aus; die Generierung nutzt sie nur schwach, weil pro Anfrage nur ein Token auf einmal entstehtBelegt. Prefill ist also eher rechengebunden: Mehr Rechenleistung hilft direkt.
• Die Generierung ist eher speichergebunden: Bei kleinen Batchgrößen und kurzen Sequenzen dominiert die Zeit, die Gewichte aus dem Speicher zu ladenBelegt. Für jedes Token werden die Gewichte erneut gelesen, und die Rechenwerke warten.

„Batchgröße“ meint hier, wie viele Anfragen oder Tokens gleichzeitig durch das Modell laufen. Im Homelab mit einer Person am Chat ist sie bei der Generierung meist eins.

Zwei Wartezeiten, die du spürst #

Aus den zwei Phasen entstehen zwei Kennzahlen, die sich im Alltag völlig unterschiedlich anfühlen. Die Serving-Forschung unterscheidet die Time to First Token (TTFT) für die Prefill-Phase und die Time per Output Token (TPOT) für die GenerierungBelegt.

• Time to First Token: Wie lange du nach dem Absenden wartest, bis das erste Wort erscheint. Sie wächst mit der Länge der Eingabe — ein eingefügtes 30-seitiges PDF spürst du hier, nicht beim Schreiben.
• Generierungsrate: Wie schnell die Antwort danach über den Bildschirm läuft. Sie ist der Kehrwert der Zeit pro Ausgabe-Token: 50 ms pro Token entsprechen 20 Tokens pro Sekunde.

Die meisten Angaben „das Modell schafft X Tokens pro Sekunde“ meinen die Generierungsrate. Für eine kurze Chatfrage ist das die relevante Zahl. Wer aber lange Dokumente zusammenfassen lässt oder Code-Assistenten mit großem Kontext füttert, wartet oft länger auf das erste Token als auf den Rest.

Wie man eine Benchmark-Zeile liest #

Das Werkzeug, auf das sich viele Community-Benchmarks stützen, ist llama-bench aus dem llama.cpp-Projekt. Es kennt drei Testarten: pp (Prompt Processing, die Eingabe in Blöcken verarbeiten), tg (Text Generation, eine Folge von Tokens erzeugen) und pg (beides nacheinander). Voreingestellt sind 512 Prompt-Tokens, 128 erzeugte Tokens und fünf Wiederholungen, deren Ergebnis gemittelt wirdBelegt. Tokenisierung und Sampling sind laut Doku nicht in der Messung enthalten.

Die Doku zeigt selbst ein Beispiel mit einem 7B-Modell in Q4_K_M auf einer CUDA-GPU, die dort nicht näher beschrieben ist:

Dieselbe Hardware, dasselbe Modell — und die Prompt-Verarbeitung liegt rund 60-mal über der GenerierungDemonstriert. Beide Zahlen sind korrekt, beide heißen „Tokens pro Sekunde“. Wer sie verwechselt, liegt um mehr als eine Größenordnung daneben.

Das @ d512 bedeutet: Vor dem Test wurde der KV-Cache mit 512 Tokens vorgefülltBelegt, das Modell hat also schon Text „im Kopf“. Der KV-Cache ist das Arbeitsgedächtnis für den bisherigen Kontext. Schon bei 512 Tokens sinken beide Werte etwas. Das passt zur Theorie: Bei langen Sequenzen und großen Batches dominiert irgendwann nicht mehr das Laden der Gewichte, sondern das Laden des KV-CachesBelegt. Ein Benchmark ohne Kontexttiefe zeigt also den günstigsten Fall; in einem langen Chat wird es langsamer.

Die Checkliste für jede Benchmark-Angabe #

Bevor du zwei Zahlen vergleichst, prüfe:

1. Welche Phase? pp/Prefill oder tg/Generierung. Steht es nicht dabei, ist die Zahl kaum vergleichbar.
2. Welche Kontextlänge? Leerer Kontext oder schon Tausende Tokens im Verlauf? Mit wachsendem Kontext sinkt vor allem die Generierungsrate.
3. Welche Batchgröße, wie viele Nutzer? Weil ein Generierungsschritt pro Anfrage nur ein Token verarbeitet, lohnt sich das Bündeln vieler Anfragen enorm für den GesamtdurchsatzBelegt. Server-Benchmarks mit „Tausenden Tokens pro Sekunde“ addieren oft viele parallele Nutzer. Für dich allein am Chat zählt die Rate pro Anfrage.
4. Welche Quantisierung? Q4, Q8 oder 16 Bit verändern die Dateigröße und damit das Tempo erheblich; mehr dazu im Guide Quantisierung und GGUF.
5. Passt das Modell komplett in den VRAM? Im Beispiel der llama-bench-Doku fällt die Generierungsrate eines 7B-Modells von rund 132 auf rund 13 Tokens pro Sekunde, wenn nur 10 statt aller Schichten auf der GPU liegenDemonstriert. Ob dein Modell samt Kontext hineinpasst, rechnet der Local-AI-Rechner aus.
6. Welche Software, welche Hardware? Runtime, Version, Backend (CUDA, Metal, CPU) und die genaue Hardware gehören zu jeder ernst gemeinten Angabe.

Die eigenen Werte ablesen #

Wer Ollama nutzt, bekommt beide Phasen getrennt geliefert. Die API meldet pro Antwort eval_count und eval_duration in Nanosekunden; die Generierungsrate ist eval_count / eval_duration · 10⁹Belegt. Analog stehen prompt_eval_count und prompt_eval_duration für die Prompt-Verarbeitung. Laut Doku zählt prompt_eval_duration nur die nicht bereits zwischengespeicherten Prompt-Tokens — bei einer Folgefrage im selben Chat kann der Wert deshalb klein ausfallen, obwohl der Verlauf lang ist.

Wer reproduzierbar vergleichen will, nimmt llama-bench mit festen Parametern und notiert sie mit. Ein Einzelwert aus einer Chat-Sitzung ist eine Momentaufnahme, kein Benchmark.

Wie schnell ist schnell genug? #

Eine allgemein gültige Schwelle, ab der sich Generierung „flüssig“ anfühlt, haben wir in der Forschung nicht belastbar gefunden — deshalb nennen wir keine. Einen Anhaltspunkt gibt die Lesegeschwindigkeit: Eine Metaanalyse über 190 Studien schätzt die durchschnittliche stille Lesegeschwindigkeit Erwachsener für englische Sachtexte auf 238 Wörter pro MinuteBelegt.

Eine Rechnung, keine Messung: 238 Wörter pro Minute sind knapp 4 Wörter pro Sekunde. Da ein Wort aus einem oder mehreren Tokens besteht, braucht ein Modell mindestens rund 4 Tokens pro Sekunde, um mit dem Lesen Schritt zu halten — bei deutschem Text mit langen Komposita eher mehr. Wer die Antwort nur überfliegt, Code kopiert oder das Ergebnis an ein Skript weitergibt, liest gar nicht mit; dann zählt die Gesamtzeit bis zur fertigen Antwort.

Eine zweite Rechnung mit den Beispielwerten aus der llama-bench-Doku, ausdrücklich nur zur Veranschaulichung: Ein Prompt mit 4.000 Tokens bei rund 6.400 Tokens pro Sekunde wäre in gut einer halben Sekunde eingelesen; eine Antwort mit 500 Tokens bei rund 117 Tokens pro Sekunde bräuchte gut vier Sekunden. Auf einer CPU oder mit ausgelagerten Schichten verschieben sich beide Werte drastisch — und oft wird dann die Wartezeit auf das erste Token zum eigentlichen Ärgernis.

Reality Check #

Stand September 2026:

• Belegt ist die Zweiteilung in Prefill und Decode mit ihren unterschiedlichen Engpässen — sie ist Grundlage mehrerer Forschungsarbeiten zu LLM-Serving.
• Demonstriert, aber nur als Beispiel aus der Projekt-Doku, sind die llama-bench-Zahlen oben. Hardware und Version sind dort nicht angegeben; sie zeigen Verhältnisse, keine Werte, die du auf deiner Maschine erwarten kannst.
• Nicht belegt ist eine feste Grenze für „angenehm schnell“. Die Lesegeschwindigkeit liefert nur eine Untergrenze fürs Mitlesen, und die Umrechnung von Wörtern in Tokens hängt von Sprache und Tokenizer ab.

Dass pp-Werte auf Grafikkarten besonders von Rechenleistung und tg-Werte besonders von Speicherbandbreite profitieren, folgt aus den Engpässen der beiden PhasenEvidenz: Theorie — wie groß der Effekt auf konkreter Homelab-Hardware ist, muss man messen.

Was heißt das fürs eigene Homelab? #

Drei praktische Folgen:

• Frag bei jeder Zahl nach der Phase. Ein „7.000 t/s“-Screenshot und ein „120 t/s“-Screenshot können von derselben Karte stammen.
• Lange Kontexte kosten Wartezeit vorne. Wenn du viel mit Dokumenten arbeitest, ist die Prompt-Verarbeitung deine wichtigere Zahl — und dort zählt Rechenleistung mehr als bei reiner Chat-Nutzung.
• Erst passen, dann rasen. Ein Modell, das nicht komplett in den schnellen Speicher passt, verliert mehr Tempo als jede Hardware-Generation zurückholen kann. Das prüfst du vorab mit dem Local-AI-Rechner.

Eigene Messungen mit dokumentierter Hardware, Version und Methodik folgen im LAB, sobald unser LLM-Benchmark steht. Bis dahin sind alle Zahlen in diesem Artikel fremde Beispiele oder ausdrücklich gekennzeichnete Rechnungen.