Warum durchschnittliche Latenz die falsche Kennzahl für AI Agents ist

Die durchschnittliche Antwortzeit ist die falsche Kennzahl zur Optimierung von AI Agents, weil sie genau die Anfragen verbirgt, die Vertrauen zerstören: den langsamen Tool-Call, den wiederholten LLM-Schritt, die Anfrage, die einen Timeout hatte und lautlos auf einen Fallback auswich. Messen Sie stattdessen p95- und p99-Latenz pro Schritt – und verlangen Sie dasselbe von jedem Anbieter, bevor Sie einen Vertrag unterzeichnen.

Das Problem mit dem Durchschnitt

Angenommen, Ihr Agent antwortet im Durchschnitt in 800 ms. Das klingt akzeptabel. Aber wenn 90 % der Anfragen in 400 ms abgeschlossen sind und die verbleibenden 10 % sechs Sekunden benötigen – weil sie auf einen Wiederholungsversuch, ein Rate-Limit oder eine langsame nachgelagerte API treffen –, begraben Sie im Durchschnitt genau den Teil der Verteilung, den Ihre Nutzer tatsächlich spüren. Niemand erlebt den Durchschnitt. Jeder erlebt seine eigene Anfrage, und für jeden zehnten Nutzer ist diese Anfrage 15-mal langsamer, als Ihr Dashboard suggeriert.

Das ist keine neue Erkenntnis in verteilten Systemen – deshalb behandelt das Google SRE Book Perzentil-Latenz (p50, p95, p99) als Standard für das Monitoring, nicht den Mittelwert. AI Agents verschärfen dieses Problem gegenüber typischen Webdiensten, weil der Tail breiter ausfällt: LLM-Inferenzzeiten sind von Natur aus variabel, Tool-Calls können hängen, und Agents verketten häufig mehrere Aufrufe, bei denen ein langsames Glied die gesamte Anfrage aufhält.

Woher der Tail in Agent-Systemen kommt

Ein einzelner, klar abgegrenzter LLM-Aufruf hat eine einzige Quelle für Latenzvariation: die Inferenzzeit des Modells plus Netzwerk. Ein Agent, der Schritte verkettet – Kontext abrufen, ein Tool aufrufen, das Modell erneut aufrufen, die Ausgabe validieren, das Modell ein drittes Mal aufrufen – multipliziert diese Varianz an jedem Übergabepunkt. Jeder Schritt trägt zudem seine eigene Fehler- und Wiederholungswahrscheinlichkeit. Und Wiederholungsversuche addieren Latenz nicht gleichmäßig, sondern ungleichmäßig. Eine Anfrage, die in Schritt 3 einen Wiederholungsversuch benötigt, kann doppelt so lange dauern wie eine, die reibungslos durchläuft – und genau diese Ungleichmäßigkeit löscht ein Durchschnitt aus.

Wir haben das beim Aufbau unseres eigenen Outreach-Tools direkt erlebt, das die Website eines Interessenten scannt und eine individuell zugeschnittene E-Mail entwirft. Frühe Versionen verwendeten eine dreistufige Kette: Fakten aus der gescrapten Seite extrahieren, die E-Mail entwerfen, dann verfeinern. Der Extraktionsschritt war der, der vom Server des Gegenübers abhing. Manche Interessenten-Websites luden schnell, andere waren langsam oder mit Tracking-Skripten überladen – und wie lange das Laden und Parsen dieser Seite dauerte, bestimmte die Untergrenze für alles Folgende, da das Entwerfen erst nach abgeschlossener Extraktion beginnen konnte. Der Durchschnitt sah gut aus, weil die meisten Websites schnell sind. Der Tail war problematisch, weil die langsamen Seiten zwar selten, aber ungleichmäßig verteilt waren – und jede einzelne einen vollständigen Stau erzeugte, der im schnellen Durchschnitt nie sichtbar wurde. Extraktion und Entwurf in einem einzigen, gut konzipierten Aufruf zusammenzufassen, hat einzelne Seiten nicht schneller geladen, aber die sequenzielle Abhängigkeit entfernt: Es gab einen Übergabepunkt weniger, den ein langsamer Abruf blockieren konnte. Wenn Sie für Ihr eigenes Produkt zwischen einer Agent-Kette und einem einzelnen Aufruf abwägen, lohnt es sich, diesen Kompromiss vor dem Bauen durchzudenken – siehe unsere Analyse von Einzelaufruf vs. Agent-Ketten.

Was Sie stattdessen messen sollten

Fordern Sie für jeden AI Agent – ob Sie ihn selbst bauen oder den eines Anbieters evaluieren – diese Kennzahlen aufgeschlüsselt nach Schritt an, nicht nur für die gesamte Anfrage:

• p50 (Median): wie sich eine typische Anfrage anfühlt.
• p95: was einer von zwanzig Nutzern erlebt. Hier beginnen in der Regel die echten Produktbeschwerden.
• p99: Ihr schlechtester Tail. Für einen Support-Bot, der täglich Tausende von Gesprächen führt, ist p99 kein Randfall – das sind täglich Dutzende echter Gespräche.
• Time to First Token vs. Gesamtdauer: Wenn der Agent Ausgaben streamt, tolerieren Nutzer eine längere Gesamtdauer deutlich besser als einen langsamen Start. Messen Sie beides separat.
• Retry-Rate und wo Wiederholungsversuche auftreten: Eine Retry-Rate von 2 % bei einem Schritt klingt gering, bis es der Schritt ist, von dem jede Anfrage abhängt.

Tools wie OpenTelemetry existieren genau dafür, damit Sie Latenz durch jeden Schritt eines verteilten Aufrufs – einschließlich Agent-Ketten – nachverfolgen können, anstatt nur die Gesamtzeit zu sehen. Wenn Ihr aktueller Stack (oder der eines Anbieters) keine schrittweisen Traces liefern kann, ist das selbst ein aufschlussreicher Datenpunkt.

Wie sich das in Anbietergesprächen zeigt

Wenn Sie ein externes Team evaluieren, das einen AI Agent für Sie bauen oder betreiben soll, sind Latenzangaben einer der Bereiche, in denen Pitches am leichtesten übertreiben. „Antworten unter einer Sekunde" ist fast immer eine Aussage über den Durchschnitt – und genau die Art von Zahl, die den Stau in unserem eigenen Outreach-Tool verborgen hat, bis wir sie nach Schritten aufgeschlüsselt haben. Die richtigen Rückfragen sind:

• Wie lauten p95 und p99 unter realistischer gleichzeitiger Last – nicht bei einer einzelnen vorgewärmten Anfrage in einer Demo?
• Welcher Schritt in der Pipeline ist am langsamsten, und wie ändert sich das unter Last?
• Was passiert, wenn ein nachgelagerter Aufruf – eine Datenbank, ein Suchindex, eine andere API oder in unserem Fall die eigene Website eines Interessenten – langsam ist? Degradiert der Agent graceful oder hängt er?

Diese Fragen gehören in dasselbe Gespräch wie Preisgestaltung und Support-Bedingungen. Den Rest dieser Evaluierung – einschließlich Fragen, die nichts mit Geschwindigkeit zu tun haben – behandeln wir in unserer Checkliste zur Bewertung von AI-Agent-Anbietern.

Latenz und Kosten sind dasselbe Gespräch

Es lohnt sich, darauf hinzuweisen: Die gleiche Kette, die einen schlechten p99 erzeugt, verursacht meist auch eine schlechte Rechnung. Zusätzliche Schritte bedeuten zusätzliche Tokens, Wiederholungsversuche bedeuten, für dieselbe Arbeit doppelt zu zahlen, und zusätzliche Modellaufrufe bedeuten, für Koordinationsaufwand zu zahlen, der dem Output keinen Wert hinzufügt. Wenn Sie bereits die Latenz auditieren, auditieren Sie gleichzeitig die Kosten. Unser Leitfaden zur LLM-Kostenoptimierung behandelt dieselbe Verschlankungsübung aus der Kostenperspektive – und in der Praxis überschneiden sich die Lösungen: Weniger, besser abgegrenzte Aufrufe schlagen mehr, kleinere Aufrufe in beiden Dimensionen.

Das praktische Fazit

Lassen Sie sich nicht mit „es fühlt sich in der Demo schnell an" oder „durchschnittliche Antwortzeit: 800 ms" abspeisen. Bevor Sie einen Agent in Produktion bringen – oder bevor Sie den Abnahme für einen Agent erteilen, den jemand anderes für Sie gebaut hat – holen Sie die p95- und p99-Zahlen unter Last, aufgeschlüsselt nach Schritt. Wenn niemand diese Zahlen liefern kann, ist das Ihre Antwort darauf, wie viel Testen tatsächlich stattgefunden hat.

Wenn Sie einen AI Agent bauen und vor dem Launch ein zweites Paar Augen auf die Architektur möchten, bevor Latenz zum Produktionsproblem wird, sprechen Sie uns an.