LLM-Latenz-Benchmark nach Anwendungsfällen
Wir haben 11 führende große Sprachmodelle mit insgesamt 1.320 Anfragen einem Benchmark unterzogen, wobei wir zwischen Reasoning- und Nicht-Reasoning-Modellen unterschieden und die Time to First Token, die Latenz pro Token sowie die gesamte Antwortzeit gemessen haben.
LLM-Latenz-Benchmark
Details zur Messung der Latenz finden Sie hier.
End-to-End-Antwortzeit nach Modell
LLM-Latenz-Benchmark-Ergebnisse
Wir berichten über Reasoning- und Nicht-Reasoning-Modelle getrennt. Reasoning-Modelle verbringen mehrere Sekunden mit „Nachdenken“, bevor die erste sichtbare Antwort erscheint. Ein direkter Vergleich ihrer Latenz mit Nicht-Reasoning-Modellen wäre daher irreführend. Einige Modelle ändern ihr Verhalten je nach Aufgabe: GPT-5.2 beantwortet Q&A ohne Reasoning, verwendet aber Reasoning bei den Coding-Prompts.
Kurzantwort-Fall (Q&A)
Im kurzen Fall kommt es darauf an, wie schnell das erste Antwort-Token erscheint, da die gesamte Antwort nur einen oder zwei Sätze umfasst. Nicht-Reasoning-Modelle gruppieren sich im Bereich niedriger Latenz:
- claude-opus-4-8: 0,75 Sekunden
- gpt-5-2: 0,8 Sekunden
- claude-haiku-4-5: 0,96 Sekunden
- claude-sonnet-5: 1,5 Sekunden
- claude-opus-4-7: 2 Sekunden
Reasoning-Modelle erreichten selbst hier das erste Antwortwort langsamer, da sie zuerst nachdenken:
- mimo-v2-5: 1,2 Sekunden
- minimax-m3: 2,4 Sekunden
- deepseek-v4-flash: 3,6 Sekunden
- gemini-3-1-pro-preview: 9 Sekunden
- hy3-preview: 14,6 Sekunden
Bei kurzen Fragen ist der Denkschritt meist Overhead, da die Antwort selbst kurz ist.
Langantwort-Fall (Codegenerierung)
Im langen Fall spielt die Verzögerung des ersten Tokens eine geringere Rolle, und die Streaming-Geschwindigkeit und die Gesamtantwortzeit übernehmen die Führung. claude-haiku-4-5 führte in beidem, streamte mit etwa 180 Token pro Sekunde und war in etwa 5,5 Sekunden fertig. Die anderen Nicht-Reasoning-Modelle benötigten etwa 10 bis 13 Sekunden: claude-sonnet-5 bei 10 Sekunden, claude-opus-4-8 bei 10,8 und claude-opus-4-7 bei 12,7.
Reasoning-Modelle erzielten längere Gesamtzeiten, weil das Nachdenken und die lange Ausgabe zusammenkommen:
- gemini-3-1-pro-preview: 18,5 Sekunden
- hy3-preview: 23,1 Sekunden
- deepseek-v4-flash: 24,3 Sekunden
- minimax-m3: 28,1 Sekunden
- mimo-v2-5: 35 Sekunden
Einige streamen schnell, sobald sie anfangen (hy3-preview läuft mit etwa 200 Token pro Sekunde), aber das vorherige Denken hält die Gesamtzeit hoch.
Die Ausgabelänge wurde begrenzt, statt offen gelassen, sodass Modelle nicht hinsichtlich der Ausführlichkeit verglichen werden: etwa 128 Token für kurze Antworten und 1.024 für lange Antworten. Reasoning-Modelle erhielten ein zusätzliches Budget über dieses Limit hinaus, um ihre Denk-Token unterzubringen, sodass ihre End-to-End-Zeiten das Denken plus die Antwort widerspiegeln und nicht eine mitten im Gedanken abgeschnittene Antwort.
Kurze Antworten versus lange Antworten
Der Kontrast zwischen den beiden Fällen ist die wichtigste Erkenntnis:
- Im kurzen Fall antworteten die schnellsten Modelle in unter einer Sekunde und die Spanne war schmal.
- Im langen Fall blieben Nicht-Reasoning-Modelle nahe der Spitze (Haiku am schnellsten mit etwa 5,5 Sekunden), während Reasoning-Modelle deutlich zurückfielen mit 18 bis 35 Sekunden.
- Die Reihenfolge innerhalb der Nicht-Reasoning-Gruppe verschiebt sich ebenfalls: Haiku war eines von mehreren Subsekunden-Startern bei kurzen Prompts, zieht aber bei langen Ausgaben aufgrund seiner Streaming-Geschwindigkeit deutlich davon.
Latenz im 90. Perzentil
Das Hauptmuster ist, dass der Tail bei Reasoning-Modellen nicht nur nach oben verschoben, sondern vervielfacht wird. Bei der Codegenerierungs-Aufgabe stieg MiniMax von etwa 13 Sekunden im Median auf 42 Sekunden bei p90, und Hunyuan von etwa 16 auf 46 Sekunden. Die zusätzliche Zeit ist Denkzeit, und die Denkdauer variiert von Anfrage zu Anfrage, daher sind diese Modelle nicht nur langsamer, sondern auch weniger vorhersehbar.
Einige Punkte stechen hervor:
- MiMo ist die Ausnahme unter den Reasoning-Modellen. Es denkt bei jeder Anfrage, aber nur kurz, sodass sein p90 bei etwa 3,7 Sekunden blieb. Reasoning allein macht ein Modell nicht unberechenbar; die Menge des Nachdenkens tut es.
- GPT-5.2 zeigt einen Tail nur dort, wo es nachdenkt. Bei Q&A lag sein p90 unter 2 Sekunden, aber bei Coding, wo es das Reasoning einschaltet, stieg sein p90 auf etwa 11 Sekunden.
- Nicht-Reasoning-Modelle blieben eng beieinander. Haiku 4.5 und Opus 4.8 hielten p90 innerhalb von etwa 2 bis 2,5 Sekunden. Selbst Sonnet 5, das bei langen Ausgaben breiter wurde (etwa 4 Sekunden im Median gegenüber 8 bei p90), blieb weit unter der Reasoning-Gruppe.
Praktisch gesehen kann der Median dies verdecken. MiniMax‘ Median bei Coding, etwa 13 Sekunden, ist nicht der schlechteste in der Gruppe, aber sein p90 von etwa 42 Sekunden entspricht Hunyuan, sodass es bei einer ungünstigen Anfrage genauso langsam ist wie alles Gemessene.
LLM-Reasoning und seine Auswirkung auf die Geschwindigkeit
Reasoning-Modelle benötigen länger, um ihr erstes Antwort-Token zu erzeugen, weil sie vor der sichtbaren Antwort interne Chain-of-Thought-Token generieren. Dieser Denkschritt erhöht ihre Time to First Answer von etwa einer Sekunde bei Nicht-Reasoning-Modellen auf mehrere Sekunden oder mehr.
Ob ein Modell nachdenkt, ist nicht immer festgelegt. Wir haben das Reasoning pro Anfrage anhand der Anzahl der von jeder Antwort zurückgegebenen Reasoning-Token erkannt und die Ergebnisse dann nach Aufgabe gruppiert. Der Anteil der Anfragen, bei denen jedes Modell Reasoning verwendet hat:
GPT-5.2 zeigt dies direkt: Es beantwortete kurze Q&A-Prompts ohne Reasoning, wendete jedoch bei den meisten Coding-Prompts Reasoning an. Für ein Hybridmodell wie dieses ist „Reasoning“ kein festes Etikett; das Modell entscheidet aufgabenabhängig, und seine Latenz verschiebt sich entsprechend dieser Entscheidung. Deshalb sitzt GPT-5.2 bei Q&A in der schnellen Gruppe, fällt aber bei Coding zurück.
Wir haben jedes Modell in seinem Standardzustand gemessen. Mehrere sind Hybride, die auf Anforderung Reasoning aktivieren können, aber standardmäßig ohne Denkmodus ausgeliefert werden: Claude Opus 4.8 unterstützt beispielsweise erweitertes Denken, aber es ist standardmäßig deaktiviert, sodass es in unseren Durchläufen niemals Reasoning-Token erzeugte und schnell blieb, ebenso wie die anderen Claude-Modelle (Opus 4.7, Sonnet 5, Haiku 4.5).
Die übrigen dachten bei nahezu jeder Anfrage nach, weshalb sie bei der ersten Antwort langsamer erscheinen. „Denkt nie“ bedeutet hier also nicht standardmäßig, nicht dass die Fähigkeit fehlt. GPT-5.2 sticht hervor, weil es diese Wahl selbst getroffen hat, indem es das Reasoning für die schwierigeren Coding-Prompts einschaltete und für Q&A ausließ.
Endpoint-Effekt auf die Latenz von LLMs
Die Latenz eines gehosteten Modells ist nicht nur das Modell. Sie umfasst auch den Serving-Stack des Providers, Warteschlangen, den Netzwerkpfad und die Geografie. Unser Testfeld zeigt dies innerhalb einer einzigen Modelllinie. Claude Opus 4.8, bereitgestellt über Google Vertex in Europa, lieferte sein erstes Token in etwa 0,75 Sekunden, während Claude Opus 4.7, bereitgestellt über die eigene API von Anthropic, etwa 2 Sekunden benötigte.
Dies sind unterschiedliche Versionen, die Kluft ist also nicht rein der Endpoint, aber das Muster entspricht einem bekannten Effekt: Dieselben Gewichte können je nach Ort und Art der Bereitstellung um ein Vielfaches schneller oder langsamer sein. Unser Mess-Client lief in Europa, sodass der europäische Vertex-Endpunkt einen kürzeren Netzwerkpfad hatte, was teilweise erklärt, warum er vorne lag.
Wie wir den Provider für jedes Modell ausgewählt haben, lesen Sie in unserer Benchmark-Methodik.
Max-Token-Limit und Reasoning-Modelle
Um die Latenz fair zu messen, haben wir eine feste maximale Ausgabelänge gesetzt, damit kein Modell dafür belohnt oder bestraft wird, mehr zu schreiben. Dieses Limit ist das Token-Budget für die gesamte Antwort, und daran scheiterten die meisten:
- Reasoning-Modelle verbrauchen einen Teil des Budgets für das Denken, bevor die Antwort beginnt.
- Bei schwierigen Coding-Prompts denken einige viel und unvorhersehbar (MiniMax verbrauchte etwa 2.500 bis 3.700 Denk-Token bei einem einzigen Prompt).
- Wenn das Denken das gesamte Budget füllt, bleiben keine Token für die Antwort übrig, und die Antwort kommt leer zurück.
- Dies traf MiniMax bei Coding am härtesten, wo der erste Durchlauf weniger als die Hälfte seiner Anfragen abschloss.
Die Lehre daraus: Das Max-Token-Limit ist ein Parameter, den man im Auge behalten sollte – setzt man es zu niedrig an, kann ein Reasoning-Modell das gesamte Budget zum Denken verbrauchen und nie zu einer Antwort gelangen. Wir haben das Budget für Reasoning-Modelle erhöht, ihnen Denkraum zusätzlich zur Antwortlänge gegeben und die fehlgeschlagenen Anfragen wiederholt. Die meisten Lücken füllten sich, obwohl einige immer noch scheiterten, wenn das Denken eines Modells selbst das größere Budget überschritt.
Als bevorzugte Quelle hinzufügenLLM-Latenz-Benchmark-Methodik
Wir haben 11 Sprachmodelle mit 1.320 Anfragen einem Benchmark unterzogen und gemessen, wie schnell jedes Modell antwortet.
Modelle
Wir nahmen die fünf meistgenutzten Modelle auf OpenRouter und fügten sechs weitere aktuelle Modelle hinzu:
- Standardmäßig kein Reasoning: Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5, Claude Haiku 4.5, GPT-5.2
- Standardmäßig Reasoning: DeepSeek V4 Flash, Xiaomi MiMo v2.5, MiniMax M3, Gemini 3.1 Pro, Tencent Hunyuan HY3, Claude Fable 5
Anwendungsfälle und Beispiel-Prompts
Wir verwendeten zwei Anwendungsfälle mit festen Eingabe- und Ausgabelängen, damit die Ergebnisse die Geschwindigkeit widerspiegeln und nicht, wie lang ein Prompt oder eine Antwort zufällig war:
- Kurzantwort (Q&A): kurze Eingabe (etwa 256 Token), kurze Ausgabe (begrenzt auf 128 Token). Beispiel: „Was ist der Zweck eines Primärschlüssels in einer Datenbank?“
- Langantwort (Codegenerierung): kurze Eingabe (etwa 512 Token), lange Ausgabe (begrenzt auf 1.024 Token). Beispiel: „Erstellen Sie einen mehrfädigen URL-Downloader in Python, der eine Liste von Bild-URLs entgegennimmt und sie gleichzeitig herunterlädt.“
Jeder Anwendungsfall verwendete 20 Prompts, und jeder Prompt wurde 3 Mal pro Modell gesendet, was 60 Messungen pro Modell und Anwendungsfall ergibt. Wir berichten den Median (p50) und das p90.
Was wir gemessen haben
Wir streamten jede Antwort und zeichneten auf, wann die Anfrage gesendet wurde, wann das erste Token eintraf, wann das erste Antwort-Token eintraf (nach eventuellem Denken) und wann das letzte Token eintraf. Daraus leiteten wir die Time to First Token, die Time to First Answer Token, die Latenz pro Token und die Ausgabegeschwindigkeit sowie die End-to-End-Zeit ab.
Reasoning vs. Nicht-Reasoning
Jede Antwort liefert eine Nutzungszusammenfassung, die eine Reasoning-Token-Anzahl enthält. Wir lasen diese für jede Anfrage aus und markierten die Anfrage als Reasoning, wenn die Anzahl über null lag, und als Nicht-Reasoning, wenn sie null war, anstatt uns auf die Modellbezeichnung zu verlassen. Auf diese Weise fanden wir heraus, dass GPT-5.2 bei Coding nachdenkt, aber nicht bei Q&A.
Wie wir die Provider auswählten
Dasselbe Modell wird von verschiedenen Providern mit unterschiedlicher Geschwindigkeit bereitgestellt, daher haben wir jedes Modell an einen Provider gebunden, anstatt die Anfragen frei routen zu lassen. OpenRouter listet für jeden Provider die Betriebszeit, Latenz und den Durchsatz auf, und wir nutzten diese Zahlen zur Auswahl. Wir schlossen jeden Provider mit weniger als etwa 98 Prozent Betriebszeit aus und wählten dann den schnellsten der übrigen nach Latenz und Durchsatz. Wir fixierten diesen Provider für jede Anfrage und protokollierten den Provider, der tatsächlich jede Antwort lieferte, um die Bindung zu bestätigen. Einige der schnellsten Provider waren mit unserem Konto nicht erreichbar und lieferten Rate-Limit-Fehler, sodass wir den schnellsten zuverlässig bedienenden Provider verwendeten.
Die festgelegten Provider waren Claude Opus 4.8 auf Google Vertex (Europa), Claude Opus 4.7 auf Anthropic, Claude Sonnet 5 und GPT-5.2 auf Azure, Claude Fable 5 und Claude Haiku 4.5 auf Amazon Bedrock, DeepSeek V4 Flash auf Novita, MiMo v2.5 auf DeepInfra, MiniMax M3 auf Together, Gemini 3.1 Pro auf Google Vertex und Hunyuan HY3 auf GMICloud.
Kontrollen
- Alle Anfragen liefen von einer einzigen Client-Region aus.
- Die Ausgabelänge wurde begrenzt (128 für kurz, 1.024 für lang), damit Ausführlichkeit die Latenz nicht verzerrt. Reasoning-Modelle erhielten ein zusätzliches Budget für das Denken zusätzlich zu diesem Limit.
- Jeder Prompt begann mit einem eindeutigen Textblock, um Prompt-Caching zu verhindern, und wir überprüften, dass keine Eingabe-Token aus dem Cache stammten.
- Alle Token-Zählungen verwenden einen einzigen Tokenizer, sodass die Geschwindigkeit über Modelle hinweg vergleichbar ist.
Zitieren Sie diesen Benchmark
Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Şipi, Nazlı},
title = {{LLM-Latenz-Benchmark nach Anwendungsfällen}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/llm-latency-benchmark}},
note = {AIMultiple. Abgerufen am 8. Juli 2026}
}Ergebnisse und Zeitstempel von 1.3 Tausend Datenpunkten. Laden Sie die in diesem Artikel verwendeten Daten als ZIP-Datei herunter, die eine CSV-Datei und eine README enthält.
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.