LLM Latenz-Benchmark nach Anwendungsfällen
Wir haben 11 führende große Sprachmodelle mit insgesamt 1.320 Anfragen gebenchmarkt, dabei zwischen Reasoning- und Nicht-Reasoning-Modellen unterschieden und die First-Token-Latenz, die Per-Token-Latenz und die Gesamtantwortzeit gemessen.
LLM Latenz-Benchmark
Details dazu, wie wir die Latenz gemessen haben, finden Sie hier.
End-to-End-Antwortzeit nach Modell
LLM Latenz-Benchmark-Ergebnisse
Wir berichten Reasoning- und Nicht-Reasoning-Modelle getrennt. Reasoning-Modelle verbringen mehrere Sekunden mit Nachdenken vor der ersten sichtbaren Antwort; daher wäre ein direkter Vergleich mit Nicht-Reasoning-Modellen hinsichtlich der Latenz irreführend. Einige Modelle ändern ihr Verhalten je nach Aufgabe: GPT-5.2 antwortet auf Q&A ohne Reasoning, reasoniert aber bei Coding-Prompts.
Fall kurze Antworten (Q&A)
Im kurzen Fall 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 waren selbst hier langsamer beim ersten Antwortwort, weil sie zuerst denken:
- 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 größtenteils Overhead, da die Antwort selbst kurz ist.
Fall langer Antworten (Codegenerierung)
Im langen Fall spielt die Verzögerung des ersten Tokens weniger eine Rolle, und Streaming-Geschwindigkeit sowie Gesamtantwortzeit übernehmen. claude-haiku-4-5 führte in beiden, streamte mit etwa 180 Tokens pro Sekunde und beendete in etwa 5.5 Sekunden. Die anderen Nicht-Reasoning-Modelle beendeten in 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 erzeugten längere Gesamtzeiten, da Nachdenken und die lange Ausgabe sich 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 starten (hy3-preview läuft mit etwa 200 Tokens pro Sekunde), aber das vorausgehende Denken hält die Gesamtzeit hoch.
Die Ausgabelänge wurde begrenzt und nicht offen gelassen, sodass Modelle nicht hinsichtlich Ausführlichkeit verglichen werden: etwa 128 Tokens 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-Tokens unterzubringen, sodass ihre End-to-End-Zeiten das Denken plus die Antwort widerspiegeln und nicht eine mitten im Gedankengang abgebrochene Antwort.
Kurze Antworten versus lange Antworten
Der Unterschied zwischen den beiden Fällen ist die wichtigste Erkenntnis:
- Im kurzen Fall antworteten die schnellsten Modelle in unter einer Sekunde und die Streuung war gering.
- Im langen Fall blieben Nicht-Reasoning-Modelle vorne (Haiku am schnellsten mit etwa 5.5 Sekunden), während Reasoning-Modelle weit zurückfielen mit 18 bis 35 Sekunden.
- Die Reihenfolge innerhalb der Nicht-Reasoning-Gruppe verschiebt sich ebenfalls: Haiku war einer von mehreren Sub-Sekunden-Startern bei kurzen Prompts, zieht aber bei langen Ausgaben aufgrund seiner Streaming-Geschwindigkeit deutlich davon.
Latenz im 90th Perzentil
Das Hauptmuster ist, dass der Schwanz bei Reasoning-Modellen sich 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 Nachdenken, und die Denkzeit variiert von Anfrage zu Anfrage, daher sind diese Modelle nicht nur langsamer, sondern auch weniger vorhersehbar.
Ein paar Punkte fallen auf:
- MiMo ist die Ausnahme unter den Reasoning-Modellen. Es reasoniert bei jeder Anfrage, denkt aber kurz, sodass sein p90 bei etwa 3.7 Sekunden blieb. Reasoning an sich macht ein Modell nicht unberechenbar; die Menge des Denkens tut es.
- GPT-5.2 zeigt einen Schwanz nur dort, wo es reasoniert. Bei Q&A lag sein p90 unter 2 Sekunden, aber beim Coding, wo es 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. MiniMax‘ Median beim 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 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, da sie interne Chain-of-Thought-Tokens vor der sichtbaren Antwort generieren. Dieser Denkschritt erhöht ihre Zeit bis zur ersten Antwort von etwa einer Sekunde für Nicht-Reasoning-Modelle auf mehrere Sekunden oder mehr.
Ob ein Modell reasoniert, ist nicht immer festgelegt. Wir haben Reasoning pro Anfrage anhand der Anzahl der Reasoning-Tokens ermittelt, die jede Antwort zurückgab, und dann die Ergebnisse nach Aufgabe gruppiert. Der Anteil der Anfragen, bei denen jedes Modell reasonierte:
GPT-5.2 zeigt dies direkt: Es beantwortete kurze Q&A-Prompts ohne Reasoning, reasonierte aber bei den meisten Coding-Prompts. Für ein Hybridmodell wie dieses ist „Reasoning“ kein festes Etikett; das Modell entscheidet basierend auf der Aufgabe, und seine Latenz verschiebt sich mit dieser Entscheidung. Deshalb ist GPT-5.2 in der schnellen Gruppe bei Q&A, fällt aber beim Coding zurück.
Wir haben jedes Modell in seinem Standardzustand gemessen. Mehrere sind Hybride, die bei Bedarf reasonieren können, aber mit ausgeschaltetem Denken ausgeliefert werden: Claude Opus 4.8 zum Beispiel unterstützt erweitertes Denken, aber es ist standardmäßig deaktiviert, sodass es in unseren Durchläufen nie Reasoning-Tokens erzeugte und schnell blieb, ebenso wie die anderen Claude-Modelle (Opus 4.7, Sonnet 5, Haiku 4.5).
Der Rest reasonierte bei fast jeder Anfrage, weshalb sie langsamer bei der ersten Antwort erscheinen. „Reasoniert nie“ bedeutet hier also nicht standardmäßig, nicht dass die Fähigkeit fehlt. GPT-5.2 sticht hervor, weil es diese Wahl selbst traf und Reasoning für die schwierigeren Coding-Prompts einschaltete, während es für Q&A ausgeschaltet blieb.
Endpoint-Effekt auf die Latenz von LLMs
Die Latenz eines gehosteten Modells ist nicht nur das Modell. Sie umfasst auch die Serving-Infrastruktur des Anbieters, Warteschlangen, den Netzwerkpfad und die Geografie. Unsere Aufstellung zeigt dies innerhalb einer Modellreihe. Claude Opus 4.8, bereitgestellt über Google Vertex in Europa, gab sein erstes Token in etwa 0.75 Sekunden zurück, während Claude Opus 4.7, bereitgestellt über die eigene API von Anthropic, etwa 2 Sekunden benötigte.
Es handelt sich um verschiedene Versionen, daher ist der Unterschied nicht rein auf den Endpoint zurückzuführen, aber das Muster entspricht einem bekannten Effekt: Die gleichen 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 mit ein Grund dafür ist, dass er vorne lag.
Um zu erfahren, wie wir den Anbieter für jedes Modell ausgewählt haben, lesen Sie unsere Benchmark-Methodik.
Max-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 verbrauchen einen Teil des Budgets für das Denken, bevor die Antwort beginnt.
- Bei schwierigen Coding-Prompts denken einige viel und unvorhersehbar (MiniMax verwendete etwa 2.500 bis 3.700 Thinking-Tokens bei einem einzigen Prompt).
- Wenn das Denken das gesamte Budget füllt, bleiben keine Tokens für die Antwort übrig und die Antwort kommt leer zurück.
- Dies traf MiniMax am stärksten beim Coding, wo der erste Durchlauf weniger als die Hälfte seiner Anfragen abschloss.
Die Erkenntnis ist, dass das Max-Token-Limit ein zu beachtender Parameter ist: Setzt man es zu niedrig an, kann ein Reasoning-Modell alles fürs Denken verbrauchen und nie zu einer Antwort gelangen. Wir haben das Budget für Reasoning-Modelle erhöht, Denkraum zusätzlich zur Antwortlänge gewährt und die fehlgeschlagenen Anfragen erneut versucht. Die meisten Lücken wurden geschlossen, obwohl einige immer noch fehlschlugen, wenn das Denken eines Modells selbst das größere Budget überstieg.
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 meistgenutzten 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 haben zwei Anwendungsfälle mit festen Eingabe- und Ausgabelängen verwendet, 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 Tokens), kurze Ausgabe (begrenzt auf 128 Tokens). Beispiel: „Was ist der Zweck eines Primärschlüssels in einer Datenbank?“
- Lange Antwort (Codegenerierung): kurze Eingabe (etwa 512 Tokens), lange Ausgabe (begrenzt auf 1.024 Tokens). Beispiel: „Erstellen Sie einen multithread-fähigen URL-Downloader in Python, der eine Liste von Bild-URLs entgegennimmt und sie parallel 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 Per-Token-Latenz und Ausgabegeschwindigkeit sowie die End-to-End-Zeit abgeleitet.
Reasoning vs. Nicht-Reasoning
Jede Antwort gibt eine Nutzungszusammenfassung zurück, die eine Anzahl von Reasoning-Tokens enthält. Wir haben dies 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 herausgefunden, dass GPT-5.2 beim Coding reasoniert, aber nicht bei Q&A.
Wie wir Anbieter ausgewählt haben
Dasselbe Modell wird von verschiedenen Anbietern mit unterschiedlicher Geschwindigkeit bereitgestellt, daher haben wir jedes Modell an einen Anbieter gebunden, anstatt Anfragen frei routen zu lassen. OpenRouter listet die Betriebszeit, Latenz und den Durchsatz jedes Anbieters auf, und wir haben diese Zahlen zur Auswahl verwendet. Wir haben jeden Anbieter mit weniger als etwa 98 Prozent Betriebszeit ausgeschlossen und dann den schnellsten der verbleibenden nach Latenz und Durchsatz ausgewählt. Wir haben diesen Anbieter für jede Anfrage festgelegt und protokolliert, welcher Anbieter tatsächlich jede Antwort bedient hat, um die Bindung zu bestätigen. Einige der schnellsten Anbieter waren mit unserem Konto nicht erreichbar und gaben Rate-Limit-Fehler zurück, daher haben wir den schnellsten zuverlässig bedienenden Anbieter verwendet.
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-Modelle erhielten zusätzliches Budget fürs Denken oberhalb dieses Limits.
- Jeder Prompt begann mit einem eindeutigen Textblock, um Prompt-Caching zu unterbinden, und wir haben überprüft, dass keine Eingabe-Tokens 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 = aug,
howpublished = {\url{https://aimultiple.com/llm-latency-benchmark}},
note = {AIMultiple. Abgerufen am 12. August 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.
Cems Arbeit wurde von führenden globalen Publikationen zitiert, darunter Business Insider, Forbes, Washington Post, globalen Unternehmen wie Deloitte, HPE und NGOs wie dem World Economic Forum sowie supranationalen Organisationen wie der European Commission.
Während seiner Karriere war Cem als Tech-Berater, Tech-Einkäufer und Tech-Unternehmer tätig. Er beriet Unternehmen über ein Jahrzehnt lang bei McKinsey & Company und Altman Solon in Technologieentscheidungen. Er veröffentlichte auch einen McKinsey-Bericht zur Digitalisierung.
Er leitete die Technologiestrategie und Beschaffung eines Telekommunikationsunternehmens und berichtete dabei direkt an den CEO. Zudem führte er das kommerzielle Wachstum des Deep-Tech-Unternehmens Hypatos an, das innerhalb von 2 Jahren von null auf einen siebenstelligen jährlich wiederkehrenden Umsatz und eine neunstellige Bewertung anwuchs. Cems Arbeit bei Hypatos wurde von führenden Technologiepublikationen wie TechCrunch und Business Insider aufgegriffen.
Cem spricht regelmäßig auf internationalen Technologiekonferenzen. Er schloss sein Studium an der Bogazici University als Computer-Ingenieur ab 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.