AI-API-Latenzmetriken: TTFT, erste Antwort und Ausgabegeschwindigkeit

AI-API-Latenz ist keine einzelne Zahl. Bei einem Streaming Request sollten Upstream-Headers, erstes nicht leeres SSE Event, erster wirksamer Inhalt oder Action, erster sichtbarer Text und Completion getrennt erfasst werden. Diese Meilensteine beantworten unterschiedliche Fragen und dürfen nicht alle „TTFT“ heißen.

Für einen Text-Chat ist Time to First Visible Text meist die Nutzerlatenz. In Reasoning- oder Tool-Workflows können Function Arguments schon früher ein wirksames Ergebnis darstellen. Generation Speed wird erst nach Ausgabebeginn gemessen.

Vor der Benennung eine Request-Timeline erstellen

Alle Zeitpunkte müssen denselben monotonen Clock und Origin verwenden:

t0  Gateway empfängt Request
t1  Gateway startet Upstream Request
t2  Upstream Response Headers treffen ein
t3  Erstes nicht leeres SSE Event
t4  Erster wirksamer Inhalt oder Action
t5  Erster sichtbarer Text Delta
t6  Upstream Body endet oder schließt
t7  Gateway Handler endet

Nicht jeder Request besitzt alle Punkte. Fehlende Werte bleiben absent und werden nicht als 0 gespeichert.

Feld	Messung	Wichtige Grenze
auth_ms	Token- und Nutzerprüfung	Lokale Phase
distribution_ms	Channel Selection und Routing	Lokale Phase
body_read_ms	Lesen des Request Body	Erkennt langsamen Upload vor Routing
upstream_headers_ms	Upstream Start bis Headers	Origin ist Upstream Start
first_sse_event_ms	Gateway Receipt bis erstes Event	Kann nur Metadata sein
first_response_ms	Bis zu wirksamem Inhalt oder Action	Text, Reasoning, Function Arguments
first_text_delta_ms	Bis zu sichtbarem Text	Fehlt bei reinen Tool Calls
upstream_done_ms	Bis Upstream Body schließt	Close ist nicht zwingend Erfolg
total_handler_ms	Bis letzter Relay-Punkt	Gateway-nahe E2E-Dauer
visible_output_tps	Tokens / sichtbares Fenster	Nutzerdiagnose, kein System-TPS

Dauern mit verschiedenen Origins dürfen nicht voneinander abgezogen werden.

TTFT hat mehrere praktische Bedeutungen

Der NVIDIA-NIM-Benchmarking-Guide zählt Netzwerk, Queueing und Prompt Prefill typischerweise zu TTFT und schließt leere Initialantworten aus. Moderne Streams können vor sichtbarem Text Metadata, Reasoning, Function Arguments, Tool Input oder Heartbeats senden.

Name	Empfohlene Bedeutung	Zweck
Time to Headers	Request Start bis Upstream Headers	Netzwerk und Admission
Time to First Event	Bis erstes nicht leeres SSE Event	Transport-Liveness
Time to First Effective Response	Bis nützlicher Inhalt oder Action	Agent- und Reasoning-Reaktion
Time to First Visible Text	Bis renderbarer Text	Chat-Nutzererlebnis

Ein Dashboard mit „TTFT“ muss offenlegen, welche Definition gemeint ist.

Reaktionszeit und Generierung trennen

end_to_end_latency = final_response_time - request_start_time
visible_generation_window = final_response_time - first_visible_text_time
visible_output_tps = output_tokens / visible_generation_window_seconds

Inter-token Latency schließt TTFT aus und teilt die Restzeit meist durch output_tokens - 1. SSE Events dürfen nicht als Tokens gezählt werden: Ein Event kann null, einen oder mehrere Tokens enthalten.

Früher Text mit niedrigem TPS startet schnell und wird dann zäh; später Text mit hohem TPS wirkt blockiert und endet schnell. Per-user TPS und Aggregate Throughput sind ebenfalls verschieden.

Reasoning und Tools können vor Text erscheinen

Bei reinem Text liegen first_response_ms und first_text_delta_ms nahe beieinander. Function Arguments nach 1,8 Sekunden und sichtbarer Text nach 6,4 Sekunden bedeuten: Das System hat früh eine Action, der Nutzer aber noch keine Prosa.

• Terminal Agents können First Effective Action verwenden;
• reine Chat-UIs sollten First Visible Text messen;
• Tool APIs benötigen eventuell keinen sichtbaren Text;
• frühe SSE Envelopes beweisen Verbindung, nicht nützlichen Fortschritt.

Der AI API Streaming Guide erklärt Parsing, Cancellation und Idle Timeout. Erst nach der Unterscheidung von Envelope und Output sind Metriken sinnvoll.

Langsame Phasen in fester Reihenfolge diagnostizieren

Symptom	Metrik	Prüfen
Langsam vor Headers	upstream_headers_ms	Netzwerk, Admission, Queue, Route, Region
Headers schnell, Output spät	first_response_ms	Model Queue, Prefill, Reasoning, Inflight
Event schnell, Output spät	SSE→Response Gap	Metadata, Heartbeat, Reasoning Startup
Action schnell, Text spät	Response→Text Gap	Tool/Reasoning, Composition
Text schnell, Generierung langsam	visible_output_tps	Decode, Contention, Long Context
Upstream normal	Lokale Felder	Auth, Policy, Client Upload

Keine einzelne Metrik beweist die Ursache; Route, Region, Provider und Load werden gemeinsam benötigt.

Drei synthetische Traces lesen

Trace A: Warten auf Upstream Headers

Metrik	Wert
upstream_headers_ms	6.100 ms
first_response_ms	6.350 ms
first_text_delta_ms	6.400 ms
total_handler_ms	9.200 ms
visible_output_tps	42

Der Großteil liegt vor den Headers. Route, Admission, Netzwerk, Region und Last sind vor der UI zu prüfen.

Trace B: Action vor sichtbarem Text

Metrik	Wert
upstream_headers_ms	240 ms
first_response_ms	2.900 ms
first_text_delta_ms	8.700 ms
total_handler_ms	10.200 ms
visible_output_tps	55

Eine Action existiert nach 2,9 Sekunden, Text 5,8 Sekunden später. Reasoning oder Tools sind zu untersuchen; ein längerer Header Timeout hilft nicht.

Trace C: Schneller Start, langsame Generierung

Metrik	Wert
upstream_headers_ms	260 ms
first_response_ms	420 ms
first_text_delta_ms	430 ms
total_handler_ms	20.430 ms
visible_output_tps	9,8

Der Text startet schnell, läuft aber fast 20 Sekunden. Output Length, Context, Channel, Inflight und Provider vergleichen. Ein First-output Timeout erkennt dieses Muster nicht.

Latenz nur unter kontrollierten Bedingungen vergleichen

Modell und Route, Token-Verteilungen, Streaming, Reasoning Effort, Tools, Region, Network Path, Concurrency, Sampling, Max Output, Warmup, Retry Policy, Sample Size und Percentile Method dokumentieren.

p50, p95 und p99 statt eines Durchschnitts vergleichen und Fehler sichtbar lassen. Verschiedene Prompts, Ausgabelängen oder Parallelität dürfen nicht als Modell-Speed-Ranking dargestellt werden.

Diagnostic Metadata statt Inhalt speichern

Request ID, Timestamp, Model, Group, Channel Reference, Status, Token Counts, Timing Fields, Event Counts, Inflight, grobe Region und Klassifikatoren wie upstream_headers_slow reichen häufig aus.

Prompts, Responses, API Keys oder Klartextidentitäten sind nicht erforderlich. Auch Metadata braucht Retention und Access Control.

Eine Untersuchung beginnt mit der Timeline, verwendet Reliable AI API Routing für die Route jedes Attempts und AI API Error Troubleshooting für den Endstatus. So lassen sich Admission, Model Startup, Reasoning/Tool, sichtbare Generierung und lokaler Overhead trennen.