LLM-Latenz-Benchmark nach Anwendungsfällen
We benchmarked 11 top large language models with a total of 1,320 requests, splitting reasoning and non-reasoning models, and measured first-token latency, per-token latency, and overall response time.
Details zur Messung der Latenz finden Sie hier.
End-to-End-Antwortzeit nach Modell
LLM-Latenz-Benchmark-Ergebnisse
Wir berichten getrennt über Reasoning- und Nicht-Reasoning-Modelle. 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 auch je nach Aufgabe: GPT-5.2 beantwortet Q&A ohne Reasoning, denkt aber bei den Coding-Prompts nach.
Kurzantwort-Fall (Q&A)
Im Kurzfall kommt es darauf an, wie schnell das erste Antwort-Token erscheint, da die gesamte Antwort nur aus ein oder zwei Sätzen besteht. 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 brauchten selbst hier länger, bis das erste Antwortwort erschien, weil 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 überwiegend Overhead, da die Antwort selbst kurz ist.
Langantwort-Fall (Codegenerierung)
Im Langfall spielt die Verzögerung bis zum ersten Token eine geringere Rolle, und Streaming-Geschwindigkeit sowie Gesamtantwortzeit übernehmen. claude-haiku-4-5 führte beides an, streamte mit etwa 180 Token pro Sekunde und war in etwa 5,5 Sekunden fertig. Die übrigen Nicht-Reasoning-Modelle waren in etwa 10 bis 13 Sekunden fertig: claude-sonnet-5 in 10 Sekunden, claude-opus-4-8 in 10.8, und claude-opus-4-7 in 12.7.
Reasoning-Modelle erzeugten längere Gesamtzeiten, weil sich Denken und die lange Ausgabe addieren:
- 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 beginnen (hy3-preview läuft mit etwa 200 Token pro Sekunde), aber das vorausgehende Nachdenken hält die Gesamtzeit hoch.
Die Ausgabelänge wurde begrenzt statt offen gelassen, sodass die Modelle nicht hinsichtlich ihrer Ausführlichkeit verglichen werden: etwa 128 Token für kurze Antworten und 1.024 für lange Antworten. Reasoning-Modellen wurde über dieses Limit hinaus zusätzliches Budget für ihre Denk-Token eingeräumt, 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 Kurzfall antworteten die schnellsten Modelle in unter einer Sekunde, und die Streuung war gering.
- Im Langfall 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 bei kurzen Prompts einer von mehreren Sub-Sekunden-Startern, zieht aber bei langen Ausgaben dank seiner Streaming-Geschwindigkeit deutlich davon.
Latenz im 90th Perzentil
Das Hauptmuster ist, dass sich der Tail bei Reasoning-Modellen vervielfacht statt nur zu verschieben. Bei der Coding-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 Denken, und die Denkdauer variiert von Anfrage zu Anfrage, sodass diese Modelle nicht nur langsamer, sondern auch weniger vorhersehbar sind.
Einige Punkte fallen auf:
- MiMo ist die Ausnahme unter den Reasoning-Modellen. Es denkt bei jeder Anfrage nach, aber nur kurz, sodass sein p90 bei etwa 3,7 Sekunden blieb. Reasoning allein macht ein Modell nicht unvorhersehbar; die Menge des Nachdenkens tut es.
- GPT-5.2 zeigt nur dort einen Tail, 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 auf 8 bei p90), blieb weit unter der Reasoning-Gruppe.
Der praktische Punkt ist, dass der Median dies verbergen kann. Der Median von MiniMax 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 schlechten Anfrage so langsam ist wie alles andere Gemessene.
LLM-Reasoning und seine Auswirkung auf die Geschwindigkeit
Reasoning-Modelle brauchen 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 Zeit bis zur ersten Antwort, 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 nachdachte:
GPT-5.2 zeigt dies direkt: Es beantwortete kurze Q&A-Prompts ohne Reasoning, dachte aber bei den meisten Coding-Prompts nach. Bei einem Hybridmodell wie diesem ist „Reasoning“ kein festes Etikett; das Modell entscheidet anhand der Aufgabe, und seine Latenz verschiebt sich mit dieser Entscheidung. Deshalb liegt 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 nachdenken können, aber mit deaktiviertem Denken ausgeliefert werden: Claude Opus 4.8 unterstützt beispielsweise erweitertes Denken, aber es ist standardmäßig deaktiviert, sodass es in unseren Läufen nie Reasoning-Token erzeugte und schnell blieb, ebenso wie die anderen Claude-Modelle (Opus 4.7, Sonnet 5, Haiku 4.5).
Die übrigen dachten bei fast jeder Anfrage nach, weshalb sie langsamer bis zur ersten Antwort erscheinen. „Denkt nie“ bedeutet hier also nicht standardmäßig, nicht dass die Fähigkeit fehlt. GPT-5.2 sticht hervor, weil es diese Entscheidung selbst traf und das Reasoning für die schwierigeren Coding-Prompts einschaltete, während es für Q&A ausgeschaltet blieb.
Endpoint-Effekt auf die Latenz für LLMs
Die Latenz eines gehosteten Modells ist nicht nur das Modell. Sie umfasst auch den Serving-Stack des Anbieters, Warteschlangen, den Netzwerkpfad und die Geografie. Unsere Liste 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.
Es handelt sich um unterschiedliche Versionen, daher ist der Abstand nicht rein auf den Endpoint zurückzuführen, 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 Messclient lief in Europa, sodass der europäische Vertex-Endpoint einen kürzeren Netzwerkpfad hatte, was teilweise erklärt, warum er besser abschnitt.
Um zu erfahren, wie wir den Anbieter für jedes Modell ausgewählt haben, lesen Sie unsere Benchmark-Methodik.
Maximales Token-Limit und Reasoning-Modelle
Um die Latenz fair zu messen, haben wir eine feste maximale Ausgabelänge festgelegt, damit kein Modell für mehr Schreiben belohnt oder bestraft wird. Diese Obergrenze ist das Token-Budget für die gesamte Antwort, und hier entstanden die meisten Fehler:
- Reasoning-Modelle geben einen Teil des Budgets für das Denken aus, 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 Erkenntnis ist, dass das maximale Token-Limit ein Parameter ist, den man im Auge behalten sollte: Setzt man es zu niedrig, kann ein Reasoning-Modell alles für das Denken verbrauchen und nie zu einer Antwort gelangen. Wir haben das Budget für Reasoning-Modelle erhöht, zusätzlichen Raum für das Denken über die Antwortlänge hinaus gewährt und die fehlgeschlagenen Anfragen erneut versucht. Die meisten Lücken wurden gefüllt, obwohl einige wenige immer noch fehlschlugen, 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 gebenchmarkt und gemessen, wie schnell jedes Modell antwortet.
Modelle
Wir nahmen die fünf am häufigsten verwendeten Modelle auf OpenRouter und fügten sechs weitere aktuelle Modelle hinzu:
- Standardmäßig nicht-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, sodass die Ergebnisse die Geschwindigkeit widerspiegeln und nicht, wie lang ein Prompt oder eine Antwort zufällig war:
- Kurze Antwort (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?“
- Lange Antwort (Codegenerierung): kurze Eingabe (etwa 512 Token), lange Ausgabe (begrenzt auf 1.024 Token). Beispiel: „Erstellen Sie einen multithreadfähigen URL-Downloader in Python, der eine Liste von Bild-URLs entgegennimmt und diese 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 haben jede Antwort gestreamt und aufgezeichnet, wann die Anfrage gesendet wurde, wann das erste Token ankam, wann das erste Antwort-Token ankam (nach etwaigem Denken) und wann das letzte Token ankam. Daraus haben wir die Zeit bis zum ersten Token, die Zeit bis zum ersten Antwort-Token, die Latenz pro Token und die Ausgabegeschwindigkeit sowie die End-to-End-Zeit abgeleitet.
Reasoning vs. Nicht-Reasoning
Jede Antwort liefert eine Nutzungszusammenfassung, die eine Anzahl von Reasoning-Token enthält. Wir haben diese für jede Anfrage gelesen und die Anfrage als Reasoning markiert, wenn die Anzahl über null lag, und als Nicht-Reasoning, wenn sie null war, anstatt uns auf das Etikett des Modells zu verlassen. So haben wir festgestellt, dass GPT-5.2 bei Coding nachdenkt, aber nicht bei Q&A.
Wie wir Anbieter ausgewählt haben
Dasselbe Modell wird von verschiedenen Anbietern mit unterschiedlichen Geschwindigkeiten bereitgestellt, daher haben wir jedes Modell an einen Anbieter gebunden, anstatt die Anfragen frei routen zu lassen. OpenRouter listet für jeden Anbieter Uptime, Latenz und Durchsatz auf, und wir verwendeten diese Zahlen für die Auswahl. Wir verwarfen jeden Anbieter mit weniger als etwa 98 Prozent Uptime und wählten dann den schnellsten der übrigen nach Latenz und Durchsatz. Wir banden diesen Anbieter für jede Anfrage und protokollierten den Anbieter, der tatsächlich jede Antwort auslieferte, um zu bestätigen, dass die Bindung hielt. Einige der schnellsten Anbieter waren mit unserem Konto nicht erreichbar und lieferten Rate-Limit-Fehler, daher verwendeten wir den schnellsten zuverlässig liefernden Anbieter.
Die gebundenen Anbieter 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 aus einer einzigen Client-Region.
- Die Ausgabelänge wurde begrenzt (128 für kurze, 1.024 für lange), damit Ausführlichkeit die Latenz nicht verzerrt. Reasoning-Modellen wurde über dieses Limit hinaus zusätzliches Budget für das Denken eingeräumt.
- Jeder Prompt begann mit einem eindeutigen Textblock, um Prompt-Caching zu unterbinden, und wir haben überprüft, dass keine Eingabe-Token aus dem Cache stammten.
- Alle Token-Zählungen verwenden einen einzigen Tokenizer, damit 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 = aug,
howpublished = {\url{https://aimultiple.com/llm-latency-benchmark}},
note = {AIMultiple. Abgerufen am 6. August 2026}
}Ergebnisse und Zeitstempel von 1.3 Tausend Datenpunkten. Laden Sie die Zusammenfassungsdaten aus den Diagrammen und Tabellen dieses Artikels als ZIP-Datei herunter, die 2 CSV-Dateien und eine README enthält.
Möchten Sie die granularen Daten dahinter? Premium beitreten
Änderungsprotokoll
5 AktualisierungenUngefähre Latenzbereiche im Latenz-Benchmark durch präzise modellspezifische Zeitwerte ersetzt.
Die verglichene Modellliste wurde durch 11 aktuelle Reasoning- und Nicht-Reasoning-Modelle ersetzt.
Erweiterter Abschnitt „LLM-Latenz-Benchmark-Ergebnisse“ mit detaillierten Benchmark-Ergebnissen für die erste Token-Latenz und die Pro-Token-Latenz.
Cems Arbeit bei AIMultiple wurde von führenden globalen Publikationen wie Business Insider, Forbes, Morning Brew und Washington Post, von globalen Unternehmen wie Deloitte und HPE, von NGOs wie dem World Economic Forum und von supranationalen Organisationen wie der European Commission zitiert. [1], [2], [3], [4], [5]
Im Laufe seiner Karriere war Cem als Tech-Berater, Tech-Einkäufer und Tech-Unternehmer tätig. Er beriet Unternehmen bei ihren Technologieentscheidungen bei McKinsey & Company und Altman Solon über mehr als ein Jahrzehnt. Er veröffentlichte außerdem einen McKinsey-Bericht zur Digitalisierung.
Er leitete Technologiestrategie und -beschaffung eines Telekommunikationsunternehmens und berichtete dabei direkt an den CEO. Außerdem verantwortete er das kommerzielle Wachstum des Deep-Tech-Unternehmens Hypatos, das innerhalb von zwei Jahren von 0 einen siebenstelligen jährlich wiederkehrenden Umsatz und eine neunstellige Bewertung erreichte. Cems Arbeit bei Hypatos wurde von führenden Technologiepublikationen wie TechCrunch und Business Insider aufgegriffen.
Cem spricht regelmäßig auf internationalen Technologiekonferenzen. Er absolvierte die Bogazici University als Computeringenieur und hat einen MBA von der Columbia Business School.
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.