Observability für gestreamte LLM-Antworten

Streaming ist eine andere Failure-Oberfläche

Batch-Inferenz versteckt Latenz hinter einem Completion-Event. Streaming legt Teilfehler offen: langsames erstes Token, stockende Chunks oder abgeschnittenes JSON.

Behandeln Sie den Stream als First-Class-Workload von Client-Render bis Tool-Nebenwirkungen.

Den Stream spannen, nicht nur den Socket

Ein Trace pro User-Turn mit Child-Spans für Retrieval, Routing, First Token, Tools und Finalisierung.

Trace-Context durch SSE/WebSocket propagieren oder mit stabiler Turn-ID an Chunk-Grenzen korrelieren.

• Provider-TTFT und Gateway-Overhead getrennt metrieren
• Client-Disconnect-Rate und Billing-Fortlauf tracken
• Volle Transkripte für Eval sampeln
• Stall-Gaps vor harten Timeouts alarmieren

Qualitätssignale gehören auf dieselbe Timeline

Leichte Checks während des Streams: Zitationsabdeckung, Refusal-Muster, Tool-Form, Retrieval-Treffer.

Streaming-Kohorten mit Batch-Baselines bei A/B-Routing vergleichen.

Streams wie ein Produkt-SLO betreiben

SLOs auf TTFT p95, stall-freie Completion und Tool-Finalisierung definieren.

Messen Sie die nutzersichtbare Erfahrung, nicht nur 5xx.

• OpenTelemetry — Semantic conventions
• MDN — Server-sent events
• Vercel AI SDK — Streaming