LLM Inference-Geschwindigkeit erklärt: TTFT, Durchsatz und was wirklich zählt

Zwei Probleme erschweren den Vergleich. Zum einen messen die Anbieter ganz Unterschiedliches: Wer mit 400 Token pro Sekunde wirbt, meint etwas anderes als jemand, der eine Latenz unter 200ms verspricht. Beide Angaben können stimmen, und trotzdem ist womöglich keine davon für Ihren Anwendungsfall entscheidend.

Zum anderen ist "schnell" immer relativ. Die Frage ist nur: im Vergleich wozu? Ein GPU-basierter Anbieter meint mit "schnell" meist: schneller als andere GPU-Anbieter. Innerhalb dieser Kategorie ist das ein fairer Maßstab, über die absolute Leistung sagt es aber nichts. Ein Anbieter mit spezialisierter Inferenz-Hardware kann 5-10x schneller sein, und dann spielt der Vergleich unter GPUs keine Rolle mehr. Dieser Artikel erklärt die drei Metriken, die die Geschwindigkeit der LLM-Inferenz bestimmen, zeigt, wann welche davon zählt, und liefert echte Messwerte zum Vergleich. Wenn Sie auch den Preis bewerten, lesen Sie dazu den Begleitartikel Was 'Preis pro Token' Ihnen nicht verrät.

Die drei Metriken der Geschwindigkeit

Wenn Sie einen Request an eine LLM-API senden, kommt die Antwort nicht in einem Stück zurück. Sie durchläuft mehrere Phasen, und jede Phase hat ihr eigenes Leistungsprofil.

Die Latenz im Einzelnen:

Ruft ein Entwickler in Europa einen Anbieter in den USA auf, setzt sich die Latenz so zusammen:

• Netzwerk-Roundtrip: 80-150ms (Lichtgeschwindigkeit in der Glasfaser, daran ändert keine Software etwas)
• TLS-Handshake: 1-3 zusätzliche Roundtrips bei jeder neuen Verbindung (mit Connection Pooling entfallen sie bei allen folgenden Requests)
• Gateway-Overhead: 10-50ms (Authentifizierung, Rate Limiting, Routing)
• Wartezeit in der Warteschlange: 0ms bis mehrere Sekunden (je nach Last und Kapazität)
• Prefill: abhängig von der Länge des Prompts
• Decode: abhängig von der Länge der Ausgabe und vom Durchsatz

Warum Prefill und Decode getrennt zählen:

Im Prefill verarbeitet das Modell Ihren gesamten Prompt parallel. Es liest alle Token auf einmal und baut daraus eine interne Repräsentation auf, den KV-Cache. Diese Phase ist rechengebunden (compute-bound): Hier entscheidet die reine Rechenleistung.

Im Decode erzeugt das Modell die Ausgabe Token für Token. Jedes neue Token hängt von allen vorherigen ab, deshalb läuft diese Phase streng sequenziell. Sie ist speichergebunden (memory-bound): Der Chip liest die meiste Zeit Modellgewichte und Cache aus dem Speicher und wartet auf die Daten, bevor er das nächste Token berechnen kann.

Verschiedene Hardware-Architekturen kommen mit diesen beiden Phasen unterschiedlich gut zurecht:

GPUs sind im Prefill stark, denn für parallele Berechnungen wurden sie gebaut. Im Decode tun sie sich schwer: Die Auslastung sinkt auf 20-40%, weil die Recheneinheiten untätig auf den Speicher warten.

Spezialisierte Inferenz-Chips wie die RDU von SambaNova, die LPU von Groq und die WSE von Cerebras sind für die speichergebundene Decode-Phase ausgelegt. Sie halten die Daten auf dem Chip, sparen Roundtrips zum Speicher ein und bleiben auch bei der sequenziellen Token-Erzeugung hoch ausgelastet. Bei großen Modellen läuft das Decode dadurch 3-10x schneller.

Diese Netzwerklatenz fällt zweimal an, einmal für den Request und einmal für die Antwort. Ein Anbieter, der mit 300ms TTFT aus Virginia wirbt, kommt in München auf 400ms und mehr. Bevor die Inferenz überhaupt beginnt, sind bereits 100ms in der Leitung vergangen.

Der Gateway-Overhead ist meist gering, fällt aber immer an. Die große Unbekannte ist die Wartezeit: Auf geteilter Infrastruktur steht Ihr Request hinter den Requests anderer Kunden an. Dieselbe API kann um 3 Uhr nachts sofort antworten und um 15 Uhr träge wirken. Mit dedizierter Kapazität konkurrieren Sie nicht mehr mit anderen Kunden, und die Leistung wird planbar.

Time to First Token (TTFT)

TTFT misst die Zeit vom Absenden eines Requests bis zum ersten Token, das zurückgestreamt wird. Sie bestimmt, wie reaktionsschnell eine Anwendung wirkt. Bei 200ms TTFT scheint die Antwort sofort da zu sein. Bleibt der Bildschirm dagegen 2 Sekunden leer, wirkt die Anwendung kaputt, auch wenn die gesamte Antwortzeit am Ende gleich ist.

Bei kurzen bis mittleren Prompts um 1K Token fühlt sich im interaktiven Chat alles unter 300ms hervorragend an. 300-600ms sind für die meisten Anwendungen akzeptabel. Ab 600ms bemerken Nutzer die Verzögerung, und nach mehr als einer Sekunde gehen sie davon aus, dass etwas nicht stimmt.

Die TTFT wächst allerdings mit der Länge der Eingabe, und hier werden Benchmarks irreführend. Ein Prompt mit 100 Token kommt vielleicht nach 200ms zurück. Ein Prompt mit 10K Token braucht länger für das Prefill, selbst auf schneller Infrastruktur sind 400-800ms zu erwarten. Bei 100K Token sind mehrere Sekunden normal. Ein TTFT-Benchmark ohne Angabe der Eingabelänge ist deshalb wertlos: "300ms TTFT" bei einem kurzen Prompt sind nichts Besonderes, bei 10K Token dagegen beeindruckend.

Drei Faktoren bestimmen die TTFT:

• Rechenaufwand im Prefill - das Modell muss die gesamte Eingabe verarbeiten, bevor es mit der Ausgabe beginnt. Je länger der Prompt, desto höher die TTFT.
• Wartezeit - ist der Anbieter überlastet, wartet Ihr Request, bevor die Verarbeitung überhaupt beginnt.
• Netzwerklatenz - ruft ein Nutzer in der EU einen Anbieter in den USA auf, kommen 100-150ms hinzu, bevor die Inferenz beginnt. Diese Latenz ist Physik und lässt sich nicht wegoptimieren. Deshalb ist Datenresidenz auch eine Frage der Leistung, nicht nur der Compliance.

Am meisten zählt TTFT bei interaktiven Anwendungen, bei denen ein Mensch auf den Bildschirm schaut: Chat-Oberflächen, Coding-Assistenten in der IDE, Voice AI und alles, was in Echtzeit läuft.

Output-Durchsatz (Token pro Sekunde)

Der Durchsatz misst, wie schnell die Token nach dem ersten nachkommen. Er bestimmt, wann die vollständige Antwort vorliegt. Eine Antwort mit 1000 Token dauert bei 100 tok/s 10 Sekunden, bei 400 tok/s nur 2,5 Sekunden. Bei längeren Ausgaben wächst der Abstand entsprechend.

Der Durchsatz hängt stark von der Modellarchitektur ab, deshalb führen Vergleiche zwischen verschiedenen Modellen in die Irre. Ein Dense-Modell mit 70B Parametern liest für jedes Token alle 70B Parameter. Ein MoE-Modell mit 671B Parametern wie DeepSeek aktiviert pro Token womöglich nur 37B davon. Weniger aktive Parameter bedeuten schnelleres Decode, obwohl das Modell insgesamt größer ist. Auch die Hardware spielt eine Rolle: GPUs tun sich mit dem speichergebundenen Decode schwer, während spezialisierte Inferenz-Chips wie die RDU von SambaNova, die LPU von Groq und die WSE von Cerebras eigens dafür entwickelt wurden. Innerhalb derselben Architektur gilt außerdem, dass größere Modelle immer langsamer sind. Auf identischer Hardware hängt ein 7B-Modell ein 70B-Modell ab.

Fair ist nur der Vergleich desselben Modells bei verschiedenen Anbietern. DeepSeek R1 671B läuft bei GPU-basierten Anbietern mit 30-80 tok/s, auf der RDU von SambaNova mit 250+ tok/s. Das ist der höchste Wert, den Artificial Analysis für dieses Modell gemessen hat. Bei Llama 3.3 70B ist der Abstand noch größer: 50-150 tok/s auf GPUs gegenüber 2100 tok/s auf der WSE von Cerebras und 1200+ tok/s auf der LPU von Groq.

Der Durchsatz zählt am meisten, wenn ein System erst mit der vollständigen Antwort weiterarbeiten kann. Das deutlichste Beispiel sind agentische Workflows, wie unser Artikel zum Durchsatz beim Agentic Coding zeigt. Dasselbe gilt für Batch-Verarbeitung, lange generierte Texte und jeden Workflow, dessen Produktivität von der gesamten Bearbeitungszeit abhängt.

End-to-End-Latenz

Die End-to-End-Latenz ist die Gesamtzeit vom Request bis zur vollständigen Antwort, also die TTFT plus die Zeit für alle Output-Token.

Die Rechnung ist schnell gemacht. Bei 1000 Output-Token, 100 tok/s und 500ms TTFT warten Sie 0,5 Sekunden auf das erste Token und weitere 10 Sekunden auf den Rest, zusammen 10,5 Sekunden. Bei 400 tok/s und 600ms TTFT dauert dieselbe Ausgabe 3,1 Sekunden. Der 4x höhere Durchsatz gleicht die langsamere TTFT mehr als aus.

Die End-to-End-Latenz zählt am meisten, wenn niemand die Zwischenausgabe verfolgt. Bei Batch-Pipelines, Backend-API-Aufrufen und Anwendungen mit SLA-Vorgaben für die Gesamtantwortzeit kommt es darauf an, wann der Job fertig ist, nicht wann er beginnt.

Warum sich die Metriken in die Quere kommen

Wer eine Metrik optimiert, verschlechtert oft eine andere.

Zielkonflikt zwischen TTFT und Durchsatz:

Die Prefill-Phase (Verarbeitung der Eingabe) und die Decode-Phase (Erzeugung der Ausgabe) konkurrieren um dieselbe Hardware. Ein Anbieter kann seine Infrastruktur auf eines von zwei Zielen auslegen:

1. Optimierung auf TTFT: mehr Ressourcen für das Prefill, damit die Ausgabe schnell beginnt, dafür ein langsameres Decode
2. Optimierung auf Durchsatz: mehr Requests pro Batch und damit höherer Durchsatz pro Request, dafür längere Wartezeiten

Das ändert sich gerade. Die Branche bewegt sich hin zu disaggregierter Inferenz, bei der Prefill und Decode auf getrennter, jeweils spezialisierter Hardware laufen. GPUs erledigen das rechengebundene Prefill effizient, speicheroptimierte Chips übernehmen das Decode. NVIDIA hat diese Richtung auf der GTC 2026 angekündigt, und SambaNova hat sich mit Intel für eine heterogene Architektur zusammengetan: GPUs für das Prefill, RDUs für das Decode, Xeon für die Orchestrierung. Erste Ergebnisse zeigen 50% und mehr zusätzlichen Durchsatz, ohne dass die TTFT leidet.

Noch lassen die meisten Anbieter beide Phasen auf derselben Hardware laufen. Dasselbe Modell verhält sich daher je nach Anbieter unterschiedlich. Anbieter A ist günstiger, aber seine Geschwindigkeit schwankt. Anbieter B kostet mehr und liefert dafür eine gleichbleibende Leistung. Das Modell ist identisch, nur die Entscheidungen bei der Infrastruktur unterscheiden sich.

Die Kontextlänge verschärft das Ganze:

Die meisten Anbieter berechnen denselben Preis pro Token, unabhängig von der Kontextlänge. Der Rechenaufwand bleibt dabei aber nicht gleich.

Der Aufwand für das Prefill wächst ungefähr quadratisch mit der Kontextlänge, weil das Modell die Attention zwischen allen Token-Paaren berechnet:

• 1000 Token: 1 Million Attention-Berechnungen
• 10.000 Token: 100 Millionen Attention-Berechnungen

Messwerte aus Produktionssystemen zeigen, was das bedeutet. Ein Prompt mit 128K Kontext braucht auf optimierter Infrastruktur rund 4 Sekunden für das Prefill, ein Prompt mit 1M Kontext rund 77 Sekunden. Modell und Hardware sind dieselben, nur die Eingabe ist länger.

Welche Metrik zu welchem Anwendungsfall passt

Im interaktiven Chat hat TTFT Vorrang vor dem Durchsatz. Nutzer lesen mit, während die Token hereinkommen, deshalb zählt vor allem der Beginn der Antwort. Eine langsamere Generierung verzeihen sie, solange die Antwort schnell startet. Bei agentischen Workflows ist es umgekehrt: Agenten warten auf die vollständige Antwort, bevor sie handeln, und zwischen den Schritten schaut kein Mensch zu. Hier entscheidet der Durchsatz. Voice AI braucht beides, denn die erste Reaktionszeit prägt den Gesprächsfluss, und auch das Sprechtempo muss stimmen. Bei der Batch-Verarbeitung zählen fast nur Durchsatz und Gesamtlaufzeit. RAG-Pipelines liegen dazwischen: Sie sollen reaktionsschnell sein, doch meist dominiert ohnehin die Latenz des Retrievals.

Anwendungsfall: agentische Workflows

Tools für Agentic Coding wie Cursor, Cline oder Codex CLI zeigen, warum bei manchen Workloads der Durchsatz entscheidet. Eine einzige Programmieraufgabe kann 50 bis über 200 LLM-Aufrufe erfordern: Der Agent liest Dateien, baut Kontext auf, plant sein Vorgehen, erzeugt Code, führt Tests aus, behebt Fehler und wiederholt das, bis die Aufgabe erledigt ist.

Jeder Aufruf erzeugt Hunderte Token. Eine Session mit 300K Token, wie sie bei einem komplexen Refactoring üblich ist, braucht bei 100 tok/s rund 50 Minuten reine Inferenzzeit. Bei 400 tok/s sind es 12 Minuten. Die 38 Minuten Unterschied entscheiden darüber, ob Sie konzentriert im Flow bleiben oder beim Warten zu Slack wechseln.

Der unterschätzte Faktor: Konsistenz unter Last

Benchmarks zeigen die Spitzenleistung, in der Produktion schwankt dagegen die Last.

Diese Fragen sollten Sie Anbietern stellen:

• Latenz bei P50 und P99: Das 99. Perzentil zeigt, wie sich der Dienst im ungünstigsten Fall verhält. Liegt P99 5x höher als P50, werden Ihre Nutzer frustriert sein.
• Rate Limits: Erreichen Sie die beworbene Geschwindigkeit überhaupt, oder bremsen die Limits Sie vorher aus?
• Leistung unter hoher Last: Hält der Durchsatz, wenn Sie 100 Requests pro Sekunde senden?

Artificial Analysis veröffentlicht unabhängige Benchmarks, die diese Schwankungen erfassen. Die Anbieter werden dort fortlaufend getestet, sodass nicht nur die Spitzenleistung sichtbar wird, sondern auch die Konsistenz über die Zeit.

So benchmarken Sie selbst

Verlassen Sie sich nicht auf Marketingzahlen, sondern messen Sie mit Ihren eigenen Workloads nach.

Testen Sie mit den Prompt-Längen, die Sie im Betrieb verwenden. Zwischen 1K und 100K Input-Token unterscheidet sich die Leistung erheblich, und die meisten Marketing-Benchmarks schönen ihre Ergebnisse mit kurzen Prompts. Testen Sie auch die zu erwartenden Ausgabelängen, denn kurze Completions und lange Texte haben unterschiedliche Leistungsprofile. Wenn Sie parallele Requests senden, messen Sie dieses Muster gezielt und nicht einzelne Requests isoliert. Testen Sie vor allem zu Spitzenzeiten. Außerhalb davon sehen Sie den günstigsten Fall, der in der Produktion selten eintritt. Für einen neutralen Ausgangswert bieten sich die unabhängigen Anbietervergleiche von Artificial Analysis an. Die Zeitmessung in Ihrer eigenen Produktionsumgebung ersetzen sie aber nicht.

Welche Metrik zählt am meisten?

Das hängt von Ihrem Workload ab. Schauen Nutzer auf den Bildschirm, hat TTFT Vorrang: Beginnt die Antwort nach weniger als einer Sekunde, empfinden Nutzer sie als unmittelbar. Warten Agenten auf Antworten, hat der Durchsatz Vorrang, denn schnellere Token bedeuten schneller erledigte Aufgaben. Verarbeiten Sie große Mengen, zählen End-to-End-Latenz und Konsistenz: Gesamtlaufzeit und verlässliche SLAs sind dann wichtiger als die Spitzengeschwindigkeit.

Die meisten Anwendungen in der Produktion brauchen bei allen drei Metriken eine akzeptable Leistung. Rasanter Durchsatz mit 3 Sekunden TTFT frustriert interaktive Nutzer. Eine sofortige TTFT bei 50 tok/s Durchsatz bremst agentische Workflows aus. An diesen Zielkonflikten führt kein Weg vorbei.

Probieren Sie es selbst aus: Auf benchmark.infercom.ai testen Sie Ihre eigenen Prompts auf unserer Infrastruktur. Standardisierte Vergleiche finden Sie in unseren veröffentlichten Benchmarks.

Warum wir es "Ultraspeed" nennen

Aus diesen Gründen trägt unser MiniMax M2.7 den Namen Ultraspeed:

1. Dataflow-Architektur von SambaNova. Die Hardware wurde eigens für Inferenz entwickelt und ist keine umfunktionierte GPU. Die RDU beseitigt den Speicherengpass, der den Durchsatz von GPUs begrenzt. Wie Dataflow für Geschwindigkeit sorgt
2. 428 Token pro Sekunde. Mit diesem gemessenen Durchsatz werden agentische Workflows praxistauglich. Eine Programmieraufgabe mit 50 Schritten, die auf herkömmlicher GPU-Infrastruktur eine Stunde dauern würde, ist so in Minuten erledigt.
3. 690ms TTFT bei 10K Input-Token, unter 150ms bei kurzen Prompts. Gemessen wurde aus Deutschland zu unserer Infrastruktur in München. Nutzer in der EU sparen sich so die 100ms und mehr, die der Weg zu Rechenzentren in den USA zusätzlich kostet.

Ultraspeed läuft auf geteilter Infrastruktur. Sie profitieren von der Architektur und dem Hosting in der EU, die Wartezeit schwankt aber wie bei jedem geteilten Dienst mit der Auslastung der Plattform.

MiniMax M2.7 Ultraspeed testen

Das Fazit

Angaben zur Geschwindigkeit ohne Kontext sind wertlos. Fragen Sie immer nach: Welche Metrik, welche Eingabelänge, welcher Vergleichsmaßstab? "Schnellste LLM-API" kann die schnellste TTFT bei kurzen Prompts bedeuten, den höchsten Durchsatz bei einem bestimmten Modell oder die niedrigste End-to-End-Latenz unter Idealbedingungen. Ohne diese Angaben sagt die Behauptung nichts aus.

Welche Metrik zählt, bestimmt Ihr Workload. Interaktive Anwendungen brauchen eine kurze TTFT, agentische Workflows einen hohen Durchsatz und die Batch-Verarbeitung eine gleichbleibende End-to-End-Latenz. Die meisten Produktionssysteme brauchen bei allen drei eine akzeptable Leistung.

Konsistenz unter Last ist genauso wichtig wie die Spitzenleistung. Ein Anbieter, der um 3 Uhr nachts 400 tok/s liefert, während der Geschäftszeiten aber nur 150 tok/s, ist für Ihren Produktions-Workload kein 400-tok/s-Anbieter.

Netzwerklatenz ist Physik, keine Software. Für Nutzer in der EU ist ein Inferenz-Anbieter in München immer schneller als einer in Virginia, denn gegen die Lichtgeschwindigkeit hilft keine Optimierung. Datenresidenz ist deshalb nicht nur eine Frage der Compliance, sondern auch ein Leistungsvorteil.