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

Jeder Inference-Anbieter spricht von Geschwindigkeit. Marketing-Seiten zeigen beeindruckende Zahlen. Aber was bedeutet "schnell" eigentlich?

Zwei Probleme erschweren die Interpretation. Erstens: Wenn ein Anbieter mit 400 Tokens pro Sekunde wirbt und ein anderer mit unter 200ms Latenz, messen sie völlig unterschiedliche Dinge. Beide Behauptungen können stimmen - und keine davon ist vielleicht relevant für Ihren Anwendungsfall.

Zweitens: "Schnell" ist immer relativ - aber relativ zu was? Wenn ein GPU-basierter Anbieter behauptet, schnell zu sein, meint er normalerweise schnell im Vergleich zu anderen GPU-Anbietern. Das ist eine vernünftige Baseline innerhalb dieser Kategorie, sagt aber nichts über die absolute Leistung aus. Ein Anbieter mit spezialisierter Inference-Hardware könnte 5-10x schneller sein, was den GPU-Vergleich irrelevant macht. Dieser Artikel erklärt die drei Metriken, die Inference-Geschwindigkeit definieren, wann welche wichtig ist, und gibt Ihnen echte Zahlen zum Vergleich. Wenn Sie auch nach Preis bewerten, lesen Sie den Begleitartikel: Was 'Preis pro Token' Ihnen nicht verrät.

Die drei Metriken, die Geschwindigkeit definieren

Wenn Sie eine Anfrage an eine LLM-API senden, kommt die Antwort nicht auf einmal. Sie fließt in Phasen, und jede Phase hat ihre eigene Leistungscharakteristik.

Die vollständige Latenz-Aufschlüsselung:

Für einen europäischen Entwickler, der einen US-basierten Anbieter nutzt:

• Netzwerk-Roundtrip: 80-150ms (Lichtgeschwindigkeit durch Glasfaser - keine Software kann das beheben)
• TLS-Handshake: 1-3 zusätzliche Roundtrips bei neuen Verbindungen (nutzen Sie Connection Pooling, um dies bei Folgeanfragen zu vermeiden)
• Gateway-Overhead: 10-50ms (Authentifizierung, Rate Limiting, Routing)
• Wartezeit in der Queue: 0ms bis Sekunden (abhängig von Last und Kapazität)
• Prefill: variiert je nach Prompt-Länge
• Decode: variiert je nach Output-Länge und Durchsatz

Prefill vs Decode - warum sie separat betrachtet werden müssen:

Prefill verarbeitet Ihren gesamten Input-Prompt parallel. Das Modell liest alle Ihre Tokens auf einmal und erstellt eine interne Repräsentation (den KV-Cache). Diese Phase ist compute-bound - die reine Rechengeschwindigkeit zählt am meisten.

Decode generiert Output-Tokens einzeln nacheinander. Jedes neue Token hängt von allen vorherigen ab, daher ist es sequenziell. Diese Phase ist memory-bound - der Chip verbringt die meiste Zeit damit, Modellgewichte und Cache aus dem Speicher zu lesen und auf Daten zu warten, bevor er das nächste Token berechnen kann.

Verschiedene Hardware-Architekturen handhaben diese Phasen unterschiedlich:

GPUs sind exzellent bei Prefill - parallele Berechnung ist das, wofür sie entwickelt wurden - kämpfen aber mit Decode. Während Decode sinkt die GPU-Auslastung auf 20-40%, da die Recheneinheiten untätig auf Speicher warten.

Spezialisierte Inference-Chips wie SambaNova's RDU, Groq's LPU und Cerebras WSE sind für die memory-bound Decode-Phase architektiert. Sie halten Daten auf dem Chip, reduzieren Speicher-Roundtrips und erhalten hohe Auslastung auch während der sequenziellen Token-Generierung. Das Ergebnis: 3-10x schnelleres Decode bei großen Modellen.

Die Netzwerklatenz trifft Sie zweimal - Anfrage und Antwort. Ein Anbieter, der 300ms TTFT aus Virginia bewirbt, liefert 400ms+ nach München. Bevor überhaupt Inference stattfindet, haben Sie bereits 100ms auf der Leitung verbraucht.

Gateway-Overhead ist meist klein, aber immer vorhanden. Die Queue-Zeit ist die versteckte Variable - auf geteilter Infrastruktur warten Sie hinter den Anfragen anderer Kunden. Dieselbe API kann sich um 3 Uhr morgens sofort anfühlen und um 15 Uhr träge. Dedizierte Kapazität eliminiert die Konkurrenz durch andere Kunden und macht die Performance vorhersehbar.

Time to First Token (TTFT)

TTFT misst die Latenz vom Senden einer Anfrage bis zum Beginn des Token-Streamings. Sie bestimmt die wahrgenommene Reaktionsfähigkeit. Eine 200ms TTFT fühlt sich sofort an. Ein 2-Sekunden-leerer-Bildschirm fühlt sich kaputt an, selbst wenn die Gesamtantwortzeit am Ende gleich ist.

Für kurze bis mittlere Prompts um 1K Tokens fühlt sich alles unter 300ms exzellent für interaktiven Chat an. Zwischen 300-600ms ist für die meisten Anwendungen akzeptabel. Über 600ms beginnen Nutzer, die Verzögerung zu bemerken. Über einer Sekunde nehmen sie an, dass etwas nicht stimmt.

Aber TTFT skaliert mit der Input-Länge, und hier werden Benchmarks irreführend. Ein 100-Token-Prompt könnte in 200ms zurückkommen. Ein 10K-Token-Prompt braucht länger für Prefill - erwarten Sie 400-800ms selbst auf schneller Infrastruktur. Ein 100K-Token-Prompt? Mehrere Sekunden sind normal. TTFT-Benchmarks ohne Input-Länge sind bedeutungslos. "300ms TTFT" bei einem kurzen Prompt ist unspektakulär. "300ms TTFT" bei 10K Tokens ist beeindruckend.

Drei Faktoren bestimmen TTFT:

• Prefill-Compute - das Modell muss Ihren gesamten Input verarbeiten, bevor es Output generiert, also bedeuten längere Prompts längere TTFT.
• Queue-Zeit - wenn der Anbieter überlastet ist, wartet Ihre Anfrage, bevor die Verarbeitung überhaupt beginnt.
• Netzwerklatenz - ein EU-Nutzer, der einen US-Anbieter nutzt, fügt 100-150ms hinzu, bevor Inference beginnt. Physik fügt Latenz hinzu, die Sie nicht wegoptimieren können, weshalb Datenresidenz für Performance wichtig ist, nicht nur für Compliance.

TTFT ist am wichtigsten für interaktive Anwendungen, bei denen ein Mensch auf den Bildschirm schaut: Chat-Interfaces, Coding-Assistenten in IDEs, Voice AI, alles Echtzeitige.

Output-Durchsatz (Tokens pro Sekunde)

Durchsatz misst, wie schnell Tokens nach dem ersten streamen. Er bestimmt, wie schnell Sie die vollständige Antwort erhalten. Bei einer 1.000-Token-Antwort ist der Unterschied zwischen 100 tok/s und 400 tok/s 10 Sekunden versus 2,5 Sekunden. Diese Lücke vergrößert sich bei längeren Outputs.

Durchsatz hängt stark von der Modellarchitektur ab, was Modellvergleiche irreführend macht. Ein 70B Dense-Modell liest 70B Parameter für jedes Token. Ein 671B MoE-Modell wie DeepSeek aktiviert möglicherweise nur 37B Parameter pro Token - weniger aktive Parameter bedeutet schnelleres Decode trotz größerer Gesamtgröße. Hardware ist auch wichtig: GPUs kämpfen mit memory-bound Decode, während spezialisierte Inference-Chips wie SambaNova's RDU, Groq's LPU und Cerebras WSE speziell dafür entwickelt sind. Und innerhalb derselben Architektur sind größere Modelle immer langsamer - ein 7B-Modell wird ein 70B-Modell auf identischer Hardware übertreffen.

Der einzig faire Vergleich ist dasselbe Modell bei verschiedenen Anbietern. DeepSeek R1 671B läuft mit 30-80 tok/s bei GPU-basierten Anbietern, aber SambaNova's RDU liefert 250+ tok/s - der schnellste von Artificial Analysis für dieses Modell gemessene Wert. Llama 3.3 70B zeigt eine noch stärkere Lücke: 50-150 tok/s auf GPUs versus 2.100 tok/s auf Cerebras WSE und 1.200+ tok/s auf Groq's LPU.

Durchsatz ist am wichtigsten, wenn etwas auf die vollständige Antwort wartet, bevor es handelt. Agentic Workflows sind das klarste Beispiel - siehe warum Durchsatz für Agentic Coding wichtig ist. Batch-Verarbeitung, Langform-Content-Generierung, jeder Workflow, bei dem die Gesamtabschlusszeit die Produktivität bestimmt.

End-to-End-Latenz

End-to-End-Latenz ist die Gesamtzeit von der Anfrage bis zur vollständigen Antwort: TTFT plus die Zeit, um alle Output-Tokens zu generieren.

Die Mathematik ist einfach. Für einen 1.000-Token-Output bei 100 tok/s mit 500ms TTFT warten Sie 0,5 Sekunden auf das erste Token, dann 10 Sekunden für den Rest - 10,5 Sekunden insgesamt. Bei 400 tok/s mit 600ms TTFT dauert derselbe Output 3,1 Sekunden. Die langsamere TTFT wird durch 4x schnelleren Durchsatz mehr als ausgeglichen.

End-to-End-Latenz ist am wichtigsten, wenn kein Mensch den Zwischen-Output beobachtet. Batch-Processing-Pipelines, Backend-API-Aufrufe, SLA-gebundene Anwendungen mit Gesamtantwortzeit-Anforderungen - diese interessieren sich dafür, wann der Job fertig ist, nicht wann er beginnt.

Warum diese Metriken in Konflikt stehen

Optimierung für eine Metrik schadet oft einer anderen.

TTFT vs. Durchsatz-Tradeoff:

Die Prefill-Phase (Verarbeitung Ihres Inputs) und Decode-Phase (Generierung des Outputs) konkurrieren um dieselben Hardware-Ressourcen. Ein Anbieter kann seine Infrastruktur konfigurieren für:

1. Optimierung für TTFT: Mehr Ressourcen für Prefill dedizieren, schnell mit der Generierung beginnen, aber langsamer decoden
2. Optimierung für Durchsatz: Mehr Anfragen zusammen batchen, höherer Durchsatz pro Anfrage, aber längere Queue-Zeiten

Dieser Tradeoff ändert sich. Die Branche bewegt sich in Richtung disaggregierte Inference - Prefill und Decode auf separater, spezialisierter Hardware. GPUs handhaben compute-bound Prefill effizient; speicheroptimierte Chips handhaben Decode. Auf der GTC 2026 kündigte NVIDIA diese Richtung an, und SambaNova partnerte mit Intel für eine heterogene Architektur: GPUs für Prefill, RDUs für Decode, Xeon für Orchestrierung. Erste Ergebnisse zeigen 50%+ Durchsatzgewinne ohne TTFT-Einbußen.

Vorerst allerdings laufen bei den meisten Anbietern beide Phasen auf derselben Hardware. Dasselbe Modell von verschiedenen Anbietern performt unterschiedlich. Anbieter A ist günstiger, hat aber variable Geschwindigkeit. Anbieter B kostet mehr, liefert aber konsistente Performance. Das zugrundeliegende Modell ist identisch; die Infrastruktur-Entscheidungen unterscheiden sich.

Kontextlänge verstärkt alles:

Die meisten Anbieter berechnen denselben Preis pro Token unabhängig von der Kontextlänge. Aber die Compute-Kosten sind nicht linear.

Prefill skaliert ungefähr quadratisch mit der Kontextlänge. Das Modell berechnet Attention zwischen jedem Token-Paar:

• 1.000 Tokens: 1 Million Attention-Berechnungen
• 10.000 Tokens: 100 Millionen Attention-Berechnungen

Echte Zahlen aus Produktionssystemen zeigen die Auswirkung. Ein 128K-Kontext-Prompt braucht ~4 Sekunden für Prefill auf optimierter Infrastruktur. Ein 1M-Kontext-Prompt braucht ~77 Sekunden. Gleiches Modell, gleiche Hardware - nur mehr Input.

Metriken auf Anwendungsfälle abstimmen

Interaktiver Chat priorisiert TTFT über Durchsatz. Nutzer lesen, während Tokens streamen, also ist die erste Antwort am wichtigsten - sie verzeihen langsamere Generierung, wenn die Antwort schnell beginnt. Agentic Workflows kehren das um: Agenten warten auf vollständige Antworten, bevor sie handeln, kein Mensch beobachtet zwischen den Schritten, also dominiert Durchsatz. Voice AI braucht beides - die initiale Antwortzeit beeinflusst den Gesprächsfluss, aber das Sprechtempo ist auch wichtig. Batch-Processing kümmert sich fast ausschließlich um Durchsatz und Gesamtabschlusszeit. RAG-Pipelines liegen irgendwo in der Mitte und balancieren Reaktionsfähigkeit mit der Retrieval-Latenz, die ohnehin meist dominiert.

Der Agentic-Anwendungsfall

Agentic Coding Tools wie Cursor, Cline oder Codex CLI illustrieren, warum Durchsatz bei manchen Workloads dominiert. Eine einzelne Coding-Aufgabe könnte 50-200+ LLM-Aufrufe erfordern, während der Agent Dateien liest, Kontext aufbaut, einen Ansatz plant, Code generiert, Tests ausführt, Fehler debuggt und iteriert, bis er fertig ist.

Jeder Aufruf generiert Hunderte von Tokens. Bei 100 tok/s dauert eine 300K-Token-Session - üblich für komplexes Refactoring - etwa 50 Minuten Inference-Zeit. Bei 400 tok/s dauert dieselbe Session 12 Minuten. Das sind 38 Minuten gespart, der Unterschied zwischen im Flow bleiben und zu Slack wechseln, während man wartet.

Der versteckte Faktor: Konsistenz unter Last

Benchmarks zeigen Spitzenleistung. Produktionssysteme erleben variable Last.

Was Sie Anbieter fragen sollten:

• P50 vs P99 Latenz: Das 99. Perzentil zeigt die Worst-Case-Performance. Wenn P99 5x höher als P50 ist, werden Sie frustrierte Nutzer haben.
• Rate Limits: Können Sie die beworbenen Geschwindigkeiten tatsächlich erreichen, oder drosseln Limits Sie zuerst?
• Performance-Degradation bei Skalierung: Hält der Durchsatz, wenn Sie 100 Anfragen/Sekunde senden?

Artificial Analysis veröffentlicht unabhängige Benchmarks, die diese Varianz erfassen. Ihre Methodik testet Anbieter kontinuierlich und zeigt nicht nur Spitzenleistung, sondern Konsistenz über Zeit.

Wie Sie selbst benchmarken

Vertrauen Sie nicht auf Marketing-Zahlen. Führen Sie eigene Benchmarks mit Ihren tatsächlichen Workloads durch.

Testen Sie mit Ihren echten Prompt-Längen - Performance variiert erheblich zwischen 1K und 100K Input-Tokens, und die meisten Marketing-Benchmarks nutzen kurze Prompts, die die Ergebnisse schmeicheln. Testen Sie auch Ihre erwarteten Output-Längen, da kurze Completions und Langform-Generierung unterschiedliche Performance-Profile haben. Wenn Sie parallele Anfragen senden, benchmarken Sie dieses Muster spezifisch, statt einzelne Anfragen isoliert zu testen. Am wichtigsten: Testen Sie während Spitzenzeiten. Off-Peak-Benchmarks zeigen Best-Case-Performance, die Sie in Produktion selten sehen werden. Artificial Analysis veröffentlicht unabhängige Anbietervergleiche, wenn Sie eine neutrale Baseline wollen, aber nichts ersetzt Timing-Instrumentierung in Ihrer eigenen Produktionsumgebung.

Welche Metrik ist am wichtigsten?

Ihr Workload bestimmt die Antwort. Wenn Nutzer auf den Bildschirm schauen, priorisieren Sie TTFT - unter einer Sekunde Antwortstart fühlt sich sofort an. Wenn Agenten auf Antworten warten, priorisieren Sie Durchsatz - schnellere Tokens bedeuten schnellere Task-Completion. Wenn Sie im großen Maßstab verarbeiten, priorisieren Sie End-to-End-Latenz und Konsistenz - Gesamtabschlusszeit und vorhersehbare SLAs sind wichtiger als Spitzengeschwindigkeit.

Die meisten Produktionsanwendungen brauchen akzeptable Performance in allen drei Bereichen. Blitzschneller Durchsatz mit 3-Sekunden TTFT wird interaktive Nutzer frustrieren. Sofortige TTFT mit 50 tok/s Durchsatz wird Agentic Workflows ausbremsen. Die Tradeoffs sind real.

Testen Sie es selbst: benchmark.infercom.ai lässt Sie Ihre tatsächlichen Prompts gegen unsere Infrastruktur laufen. Oder sehen Sie unsere veröffentlichten Benchmarks für standardisierte Vergleiche.

Warum wir es "Ultraspeed" nennen

Deshalb branden wir unser MiniMax M2.7 als Ultraspeed:

1. SambaNova Dataflow-Architektur. Speziell für Inference gebaute Hardware, keine umfunktionierten GPUs. Der RDU eliminiert den Speicher-Engpass, der GPU-Durchsatz begrenzt. Wie Dataflow Geschwindigkeit liefert
2. 428 Tokens pro Sekunde. Gemessener Durchsatz, der Agentic Workflows praktikabel macht. Bei dieser Geschwindigkeit schließt eine 50-Schritt-Coding-Aufgabe, die auf Standard-GPU-Infrastruktur eine Stunde dauern würde, in Minuten ab.
3. 690ms TTFT bei 10K Input-Tokens, unter 150ms bei kurzen Prompts. Gemessen von Deutschland zu unserer Münchner Infrastruktur - EU-Nutzer erhalten den Latenzvorteil ohne 100ms+ Netzwerk-Penalty zu US-Rechenzentren.

Ultraspeed ist geteilte Infrastruktur - Sie profitieren von der Architektur und dem EU-Hosting, aber die Queue-Zeit variiert mit der Plattform-Last wie bei jedem Shared Service.

MiniMax M2.7 Ultraspeed testen

Das Fazit

Geschwindigkeitsbehauptungen ohne Kontext sind bedeutungslos. Fragen Sie immer: welche Metrik, welche Input-Länge, welche Baseline? "Schnellste LLM-API" könnte schnellste TTFT bei kurzen Prompts bedeuten, höchster Durchsatz bei einem bestimmten Modell, oder niedrigste End-to-End-Latenz unter idealen Bedingungen. Ohne diesen Kontext sagt die Behauptung nichts aus.

Ihr Workload bestimmt, welche Metrik wichtig ist. Interaktive Anwendungen brauchen schnelle TTFT. Agentic Workflows brauchen hohen Durchsatz. Batch-Processing braucht konsistente End-to-End-Latenz. Die meisten Produktionssysteme brauchen akzeptable Performance in allen drei Bereichen.

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

Netzwerklatenz ist Physik, nicht Software. Für EU-Nutzer wird ein Inference-Anbieter in München immer schneller sein als einer in Virginia - keine Optimierung kann die Lichtgeschwindigkeit überwinden. Datenresidenz ist nicht nur Compliance; es ist ein Performance-Vorteil.

Quellen

• LLM API Latency Benchmarks 2026 - Kunal Ganglani
• Time to First Token (TTFT) - IBM
• Tokens Per Second: LLM Speed Benchmark Guide - Morph
• SambaNova - Artificial Analysis
• Inference Speed or Throughput? With RDUs - SambaNova
• Key metrics for LLM inference - BentoML
• Cerebras Llama 3.1 405B at 969 tokens/second