Latenz, Streaming & Caching

Szenario

Support meldet: „Der Assistent ist seit dem letzten Release träge.“ Euer Dashboard zeigt eine einzige Metrik request_duration_seconds, deren p95 von 6,0 s auf 6,4 s gestiegen ist — statistisch kaum auffällig. Die Beschwerden sind trotzdem eindeutig und häufen sich. Das Release enthielt eine neue synchrone Eingabeprüfung vor dem Modellaufruf.

Anforderungen

• Was ist der nächste Schritt, um die Klage zu erklären?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: TTFT als eigene Metrik erheben und die Gesamtdauer über Spans auf die Pipeline-Stufen aufteilen, bevor irgendetwas geändert wird. Richtig. Die Klage betrifft Reaktivität, die Metrik misst Gesamtdauer — das sind verschiedene Größen. Erst die Zerlegung zeigt, ob die neue Vorprüfung die Zeit bis zum ersten Token verschoben hat.
2. Plausibler Fehlweg: Auf ein kleineres, schnelleres Modell wechseln, weil die Inferenz der größte Latenzblock ist. Das ist eine Annahme ohne Messung. Eine synchrone Vorprüfung liegt vor der Inferenz und würde die TTFT anheben, ohne dass ein Modellwechsel daran etwas ändert — und du zahlst die Qualitätsminderung umsonst.
3. Plausibler Fehlweg: Das p95-Ziel auf 7 s anheben, da die Änderung im Rauschen liegt und das SLO sonst dauernd flappt. Das definiert die Beschwerde weg. Die Nutzer erleben eine reale Verschiebung, die deine Metrik nicht abbildet — ein angepasstes Ziel macht dich nur blinder.
4. Plausibler Fehlweg: Streaming aktivieren, damit die Antwort sofort erscheint. Plausibel, aber verfrüht. Streaming kann die TTFT nicht unter die Vorlaufzeit drücken, die vor dem ersten Token liegt — läuft die Prüfung synchron davor, bleibt genau die gemeldete Trägheit bestehen.

Szenario

Ein interaktives Chat-Feature soll spürbar reaktiver werden. Messung: TTFT p95 liegt bei 4,2 s, davon entfallen rund 3 s auf einen Retrieval-Schritt mit anschließendem Reranking, der Rest auf die Vorlaufphase der Inferenz. Die Gesamtdauer p95 liegt bei 11 s, die Antwortqualität gilt als gut und darf nicht sinken.

Anforderungen

• Welche Maßnahme greift die gemeldete Reaktivität am direktesten an?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Die Stufen vor dem ersten Token angehen — Retrieval und Reranking parallelisieren oder in ein Zeitbudget mit Teilergebnis zwingen — und den Fortschritt sichtbar machen, solange noch kein Token fließt. Richtig. Reaktivität hängt an dem, was vor dem ersten Token liegt. Ein Zeitbudget mit Teilergebnis begrenzt genau diesen Block, und sichtbarer Fortschritt trägt die verbleibende Wartezeit.
2. Plausibler Fehlweg: max_tokens senken, damit die Antworten kürzer und damit schneller werden — als einheitliche Gateway-Vorgabe für interaktive und asynchrone Arbeitsklassen ausgerollt und ohne getrennte Qualitäts- oder Deadline-Gates als globaler Standard beibehalten. Das verkürzt die Gesamtdauer, nicht die TTFT — der Nutzer wartet unverändert lange auf das erste Zeichen. Zusätzlich beschneidest du die Antwortqualität, die laut Vorgabe erhalten bleiben soll.
3. Plausibler Fehlweg: Auf ein größeres Modell mit höherer Token-Rate wechseln. Die Token-Rate wirkt erst nach dem ersten Token. Ein Modellwechsel adressiert die falsche Größe und ändert obendrein das Qualitäts- und Kostenprofil, das gerade stabil ist.
4. Plausibler Fehlweg: Die Antworten vollständig serverseitig fertigstellen und erst dann in einem Stück ausliefern, das wirkt ruhiger als ein zeilenweise wachsender Text. Das verschlechtert die gemeldete Größe direkt: Der Nutzer sieht dann erst nach der vollen Generationsdauer etwas. Ruhige Darstellung ist ein Layout-Problem, kein Grund, die Ausgabe zurückzuhalten.

Szenario

Ein Batch-Job erzeugt nachts Zusammenfassungen und schreibt sie in eine Datenbank; kein Mensch wartet auf eine einzelne Antwort. Der Job läuft an die Grenze seines Zeitfensters. Ein Kollege schlägt vor, die Aufrufe auf Streaming umzustellen, „weil das schneller ist“.

Anforderungen

• Wie bewertest du den Vorschlag?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Ablehnen: Streaming senkt die Gesamtdauer nicht, sondern nur die Zeit bis zum ersten Token — für einen Job ohne wartenden Menschen bringt es keinen Durchsatz, sondern nur mehr Verbindungs- und Fehlerkomplexität. Richtig. Der Engpass ist Durchsatz im Zeitfenster, nicht Reaktivität. Streaming adressiert eine Größe, die hier niemanden betrifft, und bringt zusätzlich Teilantwort- und Timeout-Fälle mit.
2. Plausibler Fehlweg: Zustimmen: Streaming reduziert die Wartezeit pro Aufruf und damit auch die Gesamtlaufzeit des Jobs — als einheitliche Gateway-Vorgabe für interaktive und asynchrone Arbeitsklassen ausgerollt und ohne getrennte Qualitäts- oder Deadline-Gates als globaler Standard beibehalten. Die Prämisse stimmt nicht. Der letzte Token kommt beim Streaming nicht früher; nur der erste. Die Summe der Generationszeiten bleibt gleich.
3. Plausibler Fehlweg: Zustimmen, weil Streaming durch frühere Freigabe der Verbindung Kapazität spart. Umgekehrt: Beim Streaming bleibt die Verbindung über die volle Generationsdauer offen. Kapazität wird nicht früher frei.
4. Plausibler Fehlweg: Zustimmen, weil du beim Streaming abbrechen kannst, sobald die Zusammenfassung lang genug ist. Verlockend, aber es löst das genannte Problem auf riskante Weise: ein Abbruch nach Zeichenzahl kappt die Zusammenfassung mitten im Satz. Wenn die Länge das Problem ist, ist das Ausgabelimit beziehungsweise der Antwortvertrag der richtige Hebel — nicht das Transportverfahren.

Szenario

Eine Anwendung schickt bei jedem Aufruf einen umfangreichen, immer gleichen Systemkontext (Richtlinien, Formatvorgaben, Beispiele) und hängt hinten die kurze Nutzerfrage an. Die TTFT ist hoch, die Ausgaben sind kurz. Aus historischen Gründen wird der Systemkontext bei jedem Aufruf leicht anders zusammengebaut — etwa mit einem eingebetteten Zeitstempel am Anfang.

Anforderungen

• Welche Änderung senkt die Vorlaufzeit am wirksamsten?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Den gleichbleibenden Teil des Kontexts zeichengenau stabil und an den Anfang stellen, Variables ans Ende — damit ist der unveränderte Anfang über Aufrufe hinweg wiederverwendbar. Richtig. Prefix-Wiederverwendung greift nur, solange der Anfang identisch ist; ein wechselnder Zeitstempel ganz vorn macht jeden Aufruf zu einem neuen Präfix und verschenkt genau diesen Effekt.
2. Plausibler Fehlweg: Einen ähnlichkeitsbasierten Antwort-Cache vor den Aufruf setzen. Das adressiert eine andere Ebene: Es hilft nur, wenn sich die Fragen wiederholen. Hier wiederholt sich der Systemkontext, nicht notwendigerweise die Nutzerfrage — die Vorlaufzeit bleibt bei jeder neuen Frage bestehen.
3. Plausibler Fehlweg: max_tokens senken, um die Vorlaufzeit zu reduzieren. Das Ausgabelimit wirkt auf die Generierungsphase, nicht auf die Verarbeitung der Eingabe. Die Ausgaben sind laut Szenario ohnehin kurz.
4. Plausibler Fehlweg: Den Systemkontext radikal kürzen, bis die Vorlaufzeit passt. Ein legitimer Hebel, aber hier der teurere: Er opfert Richtlinien und Beispiele, die die Antwortqualität tragen, obwohl die Kosten der Wiederholung durch stabile Anordnung ohne Qualitätsverlust vermeidbar sind.