Herausfinden, wo eine KI-Antwort ihre Zeit verbringt

Eine langsame Anfrage in Abschnitte zerlegen

Schritte, die nacheinander laufen, addieren sich. Schritte, die sich überlappen, tun das nicht, und nur die längste Kette durch sie, der kritische Pfad, bestimmt die verstrichene Zeit. Instrumentieren Sie den Anfragepfad so, dass jeder Schritt ein eigener Abschnitt mit Start- und Endzeit ist, und untersuchen Sie die langsamen Anfragen statt der typischen. Eine brauchbare Aufteilung:

• Warten vor Arbeitsbeginn: Gateway-Warteschlange, Backoff wegen Ratenlimits und Wiederholungen
• Retrieval: Einbettung der Anfrage, Vektor- oder Stichwortsuche, Reranking
• Jeder Modellaufruf, aufgeteilt in Zeit bis zum ersten Token und Generierungszeit
• Tool- und API-Aufrufe, die das Modell auslöst, und die Rundläufe dazwischen
• Nachverarbeitung: Parsing, Validierung, Moderation und etwaige Reparaturaufrufe

Geben Sie Wiederholungen einen eigenen Zähler. Der Proxy von LiteLLM etwa wiederholt einen fehlgeschlagenen Aufruf in derselben Modellgruppe, laut Dokumentation standardmäßig dreimal, bevor er auf einen Fallback ausweicht. Ein instabiler Anbieter kann deshalb wie Langsamkeit aussehen statt wie Fehler.

Ein hypothetisches Latenzbudget

Angenommen, das p95 eines Support-Assistenten liegt bei 6,1 Sekunden und der Product Owner möchte 3. In dieser hypothetischen Aufzeichnung laufen alle Schritte nacheinander, die Abschnitte ergeben also zusammen die Gesamtzeit:

• Warten im Gateway und eine Wiederholung: 0,4 s
• Umformulierung der Anfrage durch ein großes Modell: 0,9 s
• Retrieval und Reranking: 0,7 s
• Antwortmodell, Zeit bis zum ersten Token bei einem Prompt mit 9.000 Token: 1,0 s
• Antwortmodell, Erzeugung von 520 Token: 2,6 s
• Tool-Aufruf zum Bestellstatus, nach dem Retrieval und vor der Antwort: 0,5 s

Die Generierung ist der größte Posten, also kommen kürzere Antworten zuerst: Die Antworten umfassen drei Absätze, wo einer genügen würde. Die Umformulierung der Anfrage ist eine klar definierte Aufgabe, die ein kleineres Modell übernehmen kann, und die Bestellabfrage hängt nicht von der Antwort ab, kann also parallel zum Retrieval laufen. Messen Sie jede Änderung einzeln, denn jede kann auch die Antwortqualität verändern. Sobald die Abfrage parallel läuft, liegt sie nicht mehr auf dem kritischen Pfad, und sie weiter zu verkürzen bringt nichts.

Was die Zahl normalerweise bewegt

Der Latenz-Leitfaden von OpenAI ist bei der Reihenfolge eindeutig. Das Erzeugen von Token ist fast immer der langsamste Schritt, und eine halb so lange Ausgabe kann die Latenz ungefähr halbieren. Ein halb so langer Prompt bringt oft nur 1 bis 5 Prozent, außer der Kontext ist sehr groß. Jede weitere aufeinanderfolgende Anfrage kostet einen Rundlauf, also fassen Sie Schritte zusammen, die sich einen Aufruf teilen können, und lassen Sie unabhängige Schritte parallel laufen.

Zwei weitere Hebel verändern eher das, was Nutzer wahrnehmen, als das, was die Uhr zeigt. Streaming zeigt die ersten Wörter, während der Rest noch entsteht, und sichtbarer Fortschritt durch Tool-Schritte signalisiert, dass gearbeitet wird. Keines von beiden verkürzt die Gesamtzeit, messen Sie also weiterhin beide Werte.

Prefix-Caching verkürzt die Zeit bis zum ersten Token bei Anfragen, die einen langen, stabilen Anfang teilen, etwa Anweisungen und Tool-Definitionen. Die vLLM-Dokumentation weist darauf hin, dass es nur die Prefill-Phase beschleunigt und bei der Generierung nichts bringt.

Zusätzliche Signale, wenn Sie das Modell selbst betreiben

Mit einem eigenen Inferenzserver lässt sich der Modellabschnitt weiter zerlegen. vLLM stellt Prometheus-Metriken für Warteschlangenzeit, Prefill-Zeit, Decode-Zeit, Zeit bis zum ersten Token und Zeit pro Ausgabetoken jeder Anfrage bereit, dazu Kennzahlen auf Serverebene wie den belegten Anteil des KV-Cache. Die Dokumentation beschreibt den Zusammenhang treffend: Metriken auf Serverebene erklären die Metriken auf Anfrageebene.

Ein Muster, auf das Sie achten sollten, ist steigende Warteschlangenzeit bei vollem KV-Cache. Reicht der Cache nicht aus, unterbricht vLLM Anfragen und berechnet sie später neu, was laut Dokumentation die Gesamtlatenz verschlechtern kann. Abhilfe schaffen mehr Speicher pro Replika, weniger gleichzeitige Sequenzen oder mehr Repliken, und jede Option kostet etwas. Die Einstellungen für Chunked Prefill tauschen eine Latenz gegen eine andere: Ein kleineres Token-Budget pro Batch begünstigt gleichmäßiges Streaming, ein größeres die Zeit bis zum ersten Token.

Unter Last und an den Ausreißern messen

Latenz, die ein Engineer an einem ruhigen Nachmittag misst, sagt wenig über den Montagmorgen. Spielen Sie eine Stichprobe echter Prompts mit realistischen Ankunftsraten ab. Der Benchmark-Befehl von vLLM kann Anfragen mit fester Rate und einstellbarer Burstiness senden, die Parallelität begrenzen, gewählte Perzentile für erstes Token, Zeit pro Token und Gesamtlatenz ausgeben und Goodput zählen, also die Anfragen, die Ihre vorgegebenen Service-Level-Ziele erreicht haben.

Legen Sie das Ziel pro Funktion als Perzentil fest, etwa p95 für die Zeit bis zum ersten Token und p95 für die Gesamtzeit, und prüfen Sie es nach jedem Release. Eine Änderung, die den Median verbessert und die Ausreißer verschlechtert, ist für die Nutzer, die Verzögerungen bemerken, eine Verschlechterung.

Wenn kein einzelner Abschnitt das Problem ist

Manchmal sieht jeder Abschnitt vernünftig aus, und die Summe ist trotzdem zu langsam, zum Beispiel weil das Design fünf Modellaufrufe aneinanderreiht, wo zwei genügen würden. Der Leitfaden von OpenAI regt an zu fragen, ob jeder Schritt überhaupt ein Sprachmodell braucht: Bestätigungen lassen sich fest hinterlegen, eingeschränkte Auswahlen vorab berechnen, und gewöhnliches Caching oder eine Suche kann einen weiteren Aufruf ersetzen. Ein solcher Umbau ist aufwendiger als eine geänderte Einstellung, und oft liegt genau dort der größere Gewinn.