LLM-Benchmark: Tokens pro Sekunde richtig einordnen

Was misst ein LLM-Benchmark in Tokens pro Sekunde?

Die Ausgaberate in Tokens pro Sekunde beschreibt, wie schnell ein LLM nach dem Eintreffen des ersten Tokens weitere generierte Tokens liefert. Ein großes Sprachmodell, kurz LLM, verarbeitet Text in Tokens. Das können ganze Wörter, Wortteile oder Satzzeichen sein. Eine Tokenzahl lässt sich deshalb nicht pauschal mit einer Wortzahl gleichsetzen. Die Definition von Cerebras macht diesen Unterschied ausdrücklich deutlich.

Das lässt sich mit einem Bibliotheksbesuch vergleichen, bei dem mehrere Bücher abgeholt werden. Die Wartezeit vor der verschlossenen Tür ist etwas anderes als das Tempo, in dem die Bücher anschließend ausgegeben werden. Beides bestimmt, wann man mit allen benötigten Büchern gehen kann. Eine schnelle Ausgabe macht die lange Wartezeit vor der Tür nicht rückgängig.

Für eine Anwendung sollten diese Messgrößen getrennt erfasst werden:

Diese Messgrenzen folgen den Metrikdefinitionen von Artificial Analysis. Das erste Reasoning-Token kann vor dem ersten Antwort-Token eintreffen. Die beiden Zeitmessungen brauchen deshalb eigene Bezeichnungen.

Die Ende-zu-Ende-Latenz einer Anwendung beginnt mit der Nutzeraktion und endet mit einem nutzbaren Ergebnis. Bei einem Sprachassistenten kann das hörbare Sprache sein, bei einem Agenten eine abgeschlossene Aktion. Informationsabruf, Tool-Ausführung, Sprachsynthese und die Aktualisierung der Oberfläche können außerhalb der Modellanfrage liegen. Auch dieser gesamte Ablauf muss messtechnisch erfasst werden.

Die zugrunde liegenden Phasen heißen Prefill, also die Verarbeitung des Prompts, und Decode, die Generierung der Fortsetzung. Der Erklärartikel zur LLM-Inferenz zeigt, wie diese Arbeit im Inferenzsystem abläuft.

Warum eine einzelne Geschwindigkeitsangabe täuscht

Ein Geschwindigkeitswert beschreibt eine bestimmte Arbeitslast an einem Endpunkt. Er ist keine bedingungslos geltende Eigenschaft eines Modells. Ändern sich die Aufgabe oder die Betriebsbedingungen, ändert sich auch die Vergleichsgrundlage.

Promptlänge und zwischengespeicherter Kontext

Ein Supportchat mit einer kurzen Frage stellt andere Anforderungen als derselbe Chat mit einem langen Gesprächsverlauf und zusätzlich abgerufenen Richtliniendokumenten. Mehr Eingabe verändert den Aufwand vor der Antwort. Groq nennt die Eingabegröße in seinem Leitfaden zur Latenz als Einflussfaktor auf die TTFT.

Promptlänge und Cache-Zustand gehören ins Testprotokoll. Der Erklärartikel zum KV-Cache erläutert die während der Generierung gespeicherten Attention-Zustände und den Zusammenhang zwischen Promptwiederverwendung und Caching. Ein wiederholter Prompt mit bereits gefülltem Cache darf nicht stillschweigend als Ersatz für ein neues Kundengespräch dienen.

Reasoning vor der eigentlichen Antwort

Ein Reasoning-Modell kann zunächst Zwischentokens erzeugen, bevor es seine Antwort ausgibt. Eine hohe Generierungsrate sagt nichts darüber aus, wie umfangreich dieses Reasoning ausfällt. Entscheidend ist, ob die gemeldete Geschwindigkeit auch diesen Teil des Streams erfasst und ob die Zeitmessung für das erste Token bei Reasoning- oder erst bei Antworttext endet.

Bei einem Buchungsassistenten zählt eine verwertbare Antwort oder ein nutzbarer Tool-Aufruf. Eine sichtbare Denk-Anzeige kann den Eingang der Anfrage bestätigen. Die Buchung ist damit noch nicht erledigt.

Batching und gleichzeitige Anfragen

Batching bündelt Arbeit, um die Hardware besser auszulasten. Der Gesamtdurchsatz zählt die Ausgabe über mehrere Anfragen hinweg. Die Geschwindigkeit pro Nutzer beschreibt dagegen den Stream einer einzelnen Anfrage. Cerebras weist darauf hin, dass Batching den Durchsatz steigern und zugleich zusätzliche Wartezeit verursachen kann. Quelle: Cerebras zur Bedeutung von Durchsatz.

Für den Betrieb lautet die entscheidende Frage: Läuft jedes Gespräch weiter, wenn neue Gespräche hinzukommen? Die Messung muss repräsentative gleichzeitige Zugriffe abbilden, einschließlich fehlgeschlagener Anfragen und Wiederholungsversuche. Ein guter Wert an einem ansonsten unbeschäftigten Endpunkt beantwortet diese Frage nicht.

Region und Übertragungsweg

Der Standort der Anwendung und der des Inferenzendpunkts beeinflussen die Netzwerkverzögerung. Groq unterscheidet in seinen Hinweisen zur Netzwerkanalyse zwischen serverseitigen Laufzeiten und der beim Client wahrgenommenen Latenz.

Gemessen werden sollte aus der Region, in der das Backend läuft. Leitet die Anwendung den Stream über einen Proxy an einen Browser weiter, braucht es zusätzlich eine Messung im Browser. Puffer auf diesem Weg können dazu führen, dass eine gleichmäßige Antwort des Anbieters nur schubweise erscheint. Diesen Übertragungsweg zu verbessern kann mehr bewirken als ein Modellwechsel.

Wie viele Tokens pro Sekunde schafft eine GPU?

Eine GPU, also der für die Inferenz eingesetzte Beschleuniger, hat keinen einzelnen aussagekräftigen Tokens-pro-Sekunde-Wert, der unabhängig von Modell und Arbeitslast gilt. Zu einem Hardwarevergleich gehören deshalb neben dem Ergebnis auch Modell, numerische Präzision, Kontext, Inferenzkonfiguration und gleichzeitige Last.

Quantisierung verringert die numerische Präzision, um Speicher zu sparen. Wie sich das auf Geschwindigkeit und Qualität auswirkt, hängt von der Implementierung ab. Cerebras beschreibt diesen Zusammenhang in seiner Erklärung zur Modellkompression. Beim Vergleich komprimierter Bereitstellungen hilft der Leitfaden zur LLM-Quantisierung. Neben der Zeitmessung muss auch die Antwortqualität geprüft werden.

Wie Anbieter ihre Geschwindigkeit angeben

Veröffentlichte Geschwindigkeitswerte sollten als Angaben des jeweiligen Anbieters behandelt werden, stets mit dem zugehörigen Modell und Datum. Die folgenden Herstellerseiten wurden am 24. Oktober 2026 geprüft. Die Werte stammen von den Herstellern; für diesen Artikel wurden sie nicht selbst gemessen.

Cerebras: Geschwindigkeitsangabe mit Einschränkungen beim Einsatz

Der Inferenzanbieter Cerebras führt OpenAI GPT-OSS 120B in seiner Developer-Tabelle mit „~3000 tokens/s“ auf. Dieselbe Seite weist darauf hin, dass die Leistung je nach Modell und Konfiguration variiert. Der Developer-Zugang ist laut Beschreibung für die Evaluierung und nicht für den Produktivbetrieb vorgesehen. Quelle: Cerebras-Preise.

Entscheidend ist, ob die tatsächlich buchbare Bereitstellung die eigene Arbeitslast mit der benötigten Reaktionsgeschwindigkeit und Kapazität bewältigt. Die Tabelle allein beantwortet das nicht.

Groq: Tokens pro Sekunde gelten für die jeweilige Modellzeile

Der Inferenzanbieter Groq nennt für OpenAI GPT-OSS 120B in seiner Tabelle der unterstützten Modelle den Wert „500“ in der Spalte „SPEED (T/SEC)“. Das ist die von Groq veröffentlichte Angabe für genau diese Zeile. Quelle: Von Groq unterstützte Modelle.

Aus diesen Tabellen lässt sich kein Geschwindigkeitsverhältnis zwischen den Anbietern für eine konkrete Anwendung ableiten. Dafür müssen zunächst Prompts, Reasoning-Einstellungen, Tokenzählung, Last und Messgrenzen übereinstimmen.

Bei der Abwägung zwischen Geschwindigkeit und Kosten zählen der Preis einer erfolgreich erledigten Aufgabe und die benötigte Kapazität. Dafür bieten sich der Preisleitfaden zu Cerebras und der Preisleitfaden zu Groq an.

Wo gibt es unabhängige Messwerte?

Der unabhängige Benchmarkdienst Artificial Analysis bietet einen hilfreichen Einstieg in den Vergleich von Modellen und Inferenzanbietern. Ausgangspunkt ist die Anbieterrangliste. Anschließend sollten der konkrete Endpunkt und die Arbeitslast hinter einem Ergebnis geprüft werden.

Die Methodik der Leistungsmessung sieht derzeit Folgendes vor:

• Eine Standardarbeitslast mit ungefähr 10,000 Eingabetokens und mindestens 1,500 Antworttokens.
• Für die üblichen Arbeitslasten werden die Ergebnisse als Median der vergangenen 72 Stunden angegeben.
• Der primäre Testserver steht in der Google-Cloud-Zone us-central1-a.
• Die Tokenzahlen für die Leistungsmessung werden mit o200k_base vereinheitlicht, statt den jeweiligen modellspezifischen Tokenizer zu verwenden.

Damit entsteht eine gemeinsame Vergleichsgrundlage, aber keine Zusage für die eigene Anwendung. Vor einem Vergleich müssen Promptgröße, Endpunkt, Reasoning-Modus und Datum geprüft werden. Längere Prompts können sowohl die Wartezeit auf das erste Token als auch die Ausgaberate verändern.

Bei Reasoning-Modellen, die einen Teil ihrer Reasoning-Tokens verbergen, berechnet Artificial Analysis die Ausgaberate anhand der letzten 80% der Antwort-Chunks. Das einfache Skript weiter unten bildet weder dieses Verfahren noch die vollständige Benchmarkarbeitslast nach. Es misst den beim Client beobachteten Textstream.

Den eigenen Stream messen

Die Messung gehört an den empfangenden Client. Gezählt werden Texttokens, keine Streamereignisse. Ein Ereignis kann ganz ohne Text eintreffen oder ein ganzes Textpaket enthalten. Wer Ereignisse zählt, misst Chunks pro Sekunde.

Das folgende Python-Beispiel verwendet die Streaming-API von Groq und den Text-Tokenizer tiktoken. Es gibt die Wartezeit auf den ersten Text-Chunk, die Zeit von der Anfrage bis zum letzten Text, die Zeit bis zum Streamabschluss und einen Schätzwert für die normalisierte Ausgaberate in Tokens pro Sekunde aus.

Zunächst die Abhängigkeiten installieren:

python3 -m pip install groq tiktoken

In der Umgebung muss GROQ_API_KEY gesetzt sein. GROQ_MODEL wird auf ein Textmodell ohne Reasoning gesetzt, das laut Groqs Liste unterstützter Modelle für das eigene Konto verfügbar ist. Ein repräsentativer Prompt aus der Anwendung kommt in prompt.txt. Das folgende Skript als measure_stream.py speichern und anschließend mit python3 measure_stream.py ausführen.

import os
from pathlib import Path
from time import perf_counter

import tiktoken
from groq import Groq

encoder = tiktoken.get_encoding("o200k_base")
prompt = Path("prompt.txt").read_text(encoding="utf-8")
model = os.environ["GROQ_MODEL"]
parts = []
first = last = None

with Groq(max_retries=0) as client:
    start = perf_counter()
    stream = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        stream=True,
    )
    for event in stream:
        now = perf_counter()
        if not event.choices:
            continue
        text = event.choices[0].delta.content or ""
        if not text:
            continue
        if first is None:
            first = now
        last = now
        parts.append(text)
    end = perf_counter()

if first is None:
    raise SystemExit("No text received; no text-speed measurement.")

# Tokenize after timing; never count events as tokens.
count = lambda text: len(encoder.encode(text, disallowed_special=()))
total_tokens = count("".join(parts))
post_first_tokens = total_tokens - count(parts[0])
span = last - first

print(f"First text chunk / TTFT estimate (s): {first - start:.3f}")
print(f"Request to last text (s): {last - start:.3f}")
print(f"Stream complete (s): {end - start:.3f}")
print(f"Normalized output tokens: {total_tokens}")
if span > 0 and post_first_tokens > 0:
    print(f"Post-first output tok/s (estimate): {post_first_tokens / span:.1f}")
else:
    print("Output tok/s unavailable: insufficient text delivery intervals.")

Im Groq SDK lassen sich automatische Wiederholungsversuche deaktivieren. Das Beispiel nutzt diese Möglichkeit, damit Wartezeiten durch Wiederholungen nicht unbemerkt in eine ansonsten erfolgreiche Messung eingehen. Eine fehlgeschlagene Anfrage sollte als Fehler protokolliert werden.

Die Berechnung der Ausgaberate nimmt den ersten Text-Chunk sowohl aus der Tokenzahl als auch aus dem Ausgabeintervall heraus. Sie folgt damit der chunkbasierten Formel in den Definitionen von Artificial Analysis. Bei der Bestimmung des letzten Texteingangs bleiben außerdem nachfolgende Metadaten unberücksichtigt.

Das Beispiel eignet sich für reinen Text. Reasoning-Streams, Argumente für Tool-Aufrufe oder Audio brauchen eine eigene Behandlung ihrer Ereignistypen und eine Definition der ersten nutzbaren Ausgabe. Für Vergleiche müssen Prompt und Einstellungen beibehalten, die Ausgabelänge protokolliert und die Messungen aus der eigenen Betriebsregion unter repräsentativer Last wiederholt werden. Typische wie langsame Ergebnisse gehören in die Auswertung. Aus dem schnellsten Einzelwert darf keine Garantie werden.

Was Rechner und Simulatoren zeigen können

Eine Planungshilfe kann eine Annahme zum Zeitverlauf veranschaulichen. Die tatsächliche Verzögerung am eigenen Endpunkt kann sie nicht ermitteln.

Tokens pro Sekunde simulieren

Mit einem Simulator lässt sich diskutieren, ob eine Chatoberfläche Text sofort bei dessen Eintreffen anzeigen oder auf ein vollständiges Objekt warten sollte. Anschließend muss dieser Entwurf mit einem tatsächlich beobachteten Stream geprüft werden. Eine konstante simulierte Rate kann nicht zeigen, ob die reale Antwort pausiert, schubweise eintrifft oder auf ein Tool wartet.

Bei einer vollständig empfangenen Textantwort ist die Zeitrechnung einfach: Die Zeit von der Anfrage bis zum letzten Text entspricht der anfänglichen Wartezeit plus dem Intervall zwischen erstem und letztem Text. Das Skript misst beide Intervalle, statt sie aus einer beworbenen Rate abzuleiten.

Wie viele Tokens pro Sekunde sind gut?

Ein sinnvoller Zielwert ergibt sich daraus, wo bei der jeweiligen Aufgabe Wartezeiten entstehen. Maßgeblich ist das Nutzungserlebnis, das die Anwendung bieten soll.

Bei der Entwicklung von Sprachanwendungen: Wie lange wartet ein Anrufer nach seinem Satzende auf eine hilfreiche hörbare Antwort? Kann die Sprachausgabe beginnen, bevor die gesamte Antwort geschrieben ist? Läuft der Audiopuffer leer? Kann der Anrufer unterbrechen? Entsteht die Stille schon vor Beginn der Textausgabe, kann eine höhere Decode-Rate das Hauptproblem ungelöst lassen.

Bei der Entwicklung von Chats: Wartet der Nutzer auf den ersten hilfreichen Satz, die vollständige Erklärung oder ein gültiges strukturiertes Ergebnis? Kann die Oberfläche Teilausgaben anzeigen? Eine Supportantwort und ein exportierbarer Bericht sind bei unterschiedlichen Ereignissen fertig. Gemessen werden muss das Ereignis, das die Oberfläche tatsächlich benötigt.

Beim Betrieb von Agenten: Welcher Anteil der Aufgabe entfällt auf die Modellgenerierung, welcher auf die Tool-Ausführung? Bleiben bei einer schnelleren Antwort die Tool-Argumente korrekt und wird die Aufgabe weiterhin erfolgreich erledigt? Wartet der nächste Schritt auf die vollständige Ausgabe? Wer das falsche Intervall verbessert, verkürzt die Gesamtdauer des Workflows möglicherweise kaum.

Bei der Auswahl eines Anbieters: Kann die angebotene Bereitstellung das benötigte Nutzungserlebnis unter der eigenen Last, aus der eigenen Region und mit den eigenen Prompts aufrechterhalten? Ist der genannte Messwert für diese Bereitstellung typisch? Was passiert, wenn Anfragen fehlschlagen oder die Kapazität ausgelastet ist?

Handlungsbedarf besteht, wenn Ablaufaufzeichnungen zeigen, dass Nutzer auf die Generierung oder die erste verwertbare Antwort warten. Mit einem Anbieterwechsel sollte gewartet werden, solange die vorherrschende Verzögerungsursache nicht isoliert ist. Ein Hintergrundauftrag, der seine Fertigstellungsfrist bereits einhält, profitiert von einer höheren beworbenen Geschwindigkeit kaum, sofern nicht Durchsatz oder Kosten pro erfolgreich erledigter Aufgabe die Entscheidung verändern.

Was wird bei der LLM-Geschwindigkeit überbewertet?

Die größte Übertreibung ist die Annahme, die höchste Ausgaberate kennzeichne automatisch den besten Endpunkt für eine Anwendung. Geschwindigkeit belegt weder Antwortqualität noch gültige Ausgaben oder erfolgreiche Tool-Nutzung.

Auch der schnellste Endpunkt stößt an die Grenzen der umgebenden Anwendung. Schnellerer Text behebt weder einen langsamen Datenbankaufruf noch einen unnötig langen Reasoning-Pfad oder eine Antwort, die an der Validierung scheitert. Umgekehrt kann eine hervorragende Zeit bis zum ersten Token einen Stream verdecken, der ins Stocken gerät, bevor der Nutzer etwas Verwertbares erhält.

Geschwindigkeit gehört in die Bewertung. Die Ziellinie bleibt aber ein korrektes, nutzbares Ergebnis.

Häufige Fragen

Der nächste Schritt in der Entwicklung

Für die nächste Iteration wird ein repräsentativer Gesprächsschritt einer Sprachanwendung, ein Chatprompt oder eine Agentenaufgabe ausgewählt. Zuerst ist festzulegen, wann das Ergebnis nutzbar ist. Dieses Ereignis wird gemeinsam mit der ersten Ausgabe und dem Streamabschluss gemessen. Anschließend werden mögliche Endpunkte anhand derselben Aufgabe verglichen, Fehler ausgewertet und das Intervall optimiert, in dem der Nutzer wartet.

Praxisleitfäden zur Entwicklung nützlicher KI-Anwendungen gibt es im Newsletter.