Latency (Latenz) & Throughput
Latency (Latenz) und Throughput (Durchsatz) beschreiben, wie schnell und wie viel ein System im Betrieb leisten kann: Latenz ist die Zeit von der Anfrage bis zur ersten/kompletten Antwort (Antwortzeit), Throughput ist die Anzahl verarbeiteter Anfragen oder Tokens pro Zeit (z. B. Requests/s, Tokens/s). Beide Metriken sind entscheidend für Nutzererlebnis, Kosten und Skalierbarkeit von KI-Systemen.
Was ist Latency (Latenz)?
Latenz misst die Verzögerung zwischen „Request raus“ und „Response da“. In KI- und API-Setups wird oft unterschieden zwischen Time to First Byte/Token (TTFB/TTFT) und Time to Last Token (Gesamtdauer). Bei ChatGPT-ähnlichen Anwendungen ist eine niedrige TTFT besonders wichtig, weil der Nutzer schnell „Feedback“ sieht – selbst wenn die Gesamtausgabe länger dauert.
- Beispiel: Ein Large Language Model (LLM) beginnt nach 300 ms zu streamen (gute TTFT), braucht aber 6 Sekunden für 800 Tokens (Gesamtlatenz).
- Praxis-Faktoren: Netzwerk, Warteschlangen (Queueing), Modellgröße, Kontextlänge, Tool-Aufrufe (z. B. Function Calling / Tool Use), sowie Retrieval-Schritte bei RAG (Retrieval-Augmented Generation).
Was ist Throughput (Durchsatz)?
Throughput beschreibt, wie viele Einheiten ein System pro Zeiteinheit schafft. In KI sind das typischerweise Requests pro Sekunde (RPS) und/oder Tokens pro Sekunde (TPS). Hoher Throughput bedeutet, dass viele Nutzer parallel bedient werden können oder Batch-Jobs schnell durchlaufen.
- Beispiel: Ein Inference-Server schafft 50 RPS bei kurzen Prompts, aber nur 5 RPS bei langen Kontexten und großen Antworten.
- Wichtig: Throughput kann steigen, während Latenz für einzelne Nutzer schlechter wird (z. B. durch aggressives Batching).
Wie funktionieren Latenz & Throughput zusammen (Trade-off)?
Latenz und Throughput hängen eng zusammen und stehen oft in einem Zielkonflikt: Optimierungen für maximalen Durchsatz (z. B. Batch-Verarbeitung, längere Warteschlangen) erhöhen häufig die Latenz. Umgekehrt kann man Latenz senken (z. B. weniger Batching, kleinere Modelle), verliert aber Durchsatz oder zahlt mehr Infrastrukturkosten.
- Interaktive Chats: Priorität auf niedrige TTFT und stabile Latenz (P95/P99), damit die UX „snappy“ bleibt.
- Backoffice/Automation: Priorität auf hohen Throughput, z. B. in n8n-Flows oder bei Automatisierung (Automation), wo 2–5 Sekunden extra oft akzeptabel sind.
Warum sind Latency & Throughput wichtig in KI-Systemen?
Sie beeinflussen direkt Conversion (Wartezeit senkt Abschlussraten), Stabilität (Überlast führt zu Timeouts), und Kosten (mehr Hardware/GPUs oder höhere API-Tarife). In produktiven KI-Architekturen gehören Latenz- und Throughput-Ziele daher in Monitoring und MLOps (z. B. P95-Latenz, Error-Rate, TPS pro GPU).
- RAG-Stacks: Retrieval über Embeddings und Vektordatenbank (Vector Database) kann Latenz hinzufügen, senkt aber oft Halluzinationen und verbessert die Antwortqualität.
- Agenten-Workflows: AI Agents (KI-Agenten) mit mehreren Tool-Schritten erhöhen häufig die End-to-End-Latenz, können aber komplexe Aufgaben zuverlässiger lösen.
Typische Stellhebel zur Optimierung (mit Beispielen)
- Prompt & Kontext reduzieren: Kürzere Kontexte → weniger Rechenzeit, bessere Latenz und höherer TPS. Prompt Engineering hilft, präziser und kompakter zu fragen.
- Modellwahl: Kleineres Modell oder quantisierte Variante → bessere Latenz/Throughput, ggf. Qualitätsverlust. Alternativ: Fine-Tuning oder LoRA für domänenspezifische Leistung ohne riesiges Basismodell.
- Streaming & UX: Token-Streaming senkt gefühlte Latenz (TTFT), auch wenn die Gesamtdauer ähnlich bleibt.
- Caching: Wiederkehrende Antworten/Embeddings cachen → drastische Latenzreduktion und höherer Durchsatz.
- Parallelisierung: Tool-Calls oder Retrieval parallel ausführen, wenn möglich, statt sequenziell.
Was kostet „gute“ Latenz und hoher Throughput?
Es gibt keinen Fixpreis: Kosten hängen von Modell, Hosting (API vs. self-hosted), Kontextlänge, Parallelität und SLOs (z. B. P95 < 1,5 s) ab. Niedrige Latenz erfordert oft Überprovisionierung (mehr Reserven), während maximaler Throughput eher optimierte Auslastung (Batching, Queueing) braucht. In der Praxis definiert man Zielwerte (z. B. P95-Latenz, RPS) und dimensioniert Infrastruktur sowie Inference-Setup darauf.