Durch das Streaming wirkt eine KI-Schnittstelle reaktionsschnell, da der Benutzer den Fortschritt bereits erkennen kann, bevor die vollständige Antwort vorliegt. Außerdem wird eine einzelne Anfrage so zu einem Lebenszyklus, der den Modellanbieter, den Anwendungsserver, den Reverse-Proxy und den Browser umfasst.
Ich möchte, dass dieser Lebenszyklus definierte Zustände aufweist. Das Schließen einer Verbindung, das Beenden eines Providers und eine Antwort, die die Validierung besteht, sind unterschiedliche Ereignisse. Wenn man alle drei als „abgeschlossen“ behandelt, lassen sich Fehler nur schwer erklären.
Wählen Sie eine Transportart, die zur Interaktion passt
Server-Sent-Events eignen sich gut für einen Strom von Aktualisierungen vom Server zum Client. Das Ereignisformat unterstützt benannte Ereignisse, IDs und Datenfelder, wie im SSE-Leitfaden von MDN beschrieben.
Die native EventSource-Schnittstelle des Browsers eignet sich gut zum Empfangen eines Datenstroms, doch Anwendungen, die einen POST-Body oder benutzerdefinierte Request-Header benötigen, können stattdessen einen auf „fetch“ basierenden Streaming-Client verwenden. Diese Wahl hat Auswirkungen darauf, welches Parsing- und Wiederverbindungsverhalten die Anwendung selbst implementieren muss.
Ich stelle die Authentifizierung, die Übermittlung von Anfragen und das Abonnieren von Streams explizit dar. Anmeldedaten sollten nicht allein deshalb in einer URL platziert werden, weil dies für den Aufbau einer Verbindung praktisch ist.
Das Anwendungsprotokoll definieren
Ein nützlicher Datenstrom könnte zwischen Akzeptanz, Fortschritt, Text, Validierungsstatus, Abschluss und Fehler unterscheiden. Die Namen der Ereignisse werden von der Anwendung festgelegt; sie stellen keine vom Transport bereitgestellten Garantien dar.
event: accepted
data: {"request_id":"req_example"}
event: text_delta
data: {"text":"The available sizes are"}
event: completed
data: {"request_id":"req_example","status":"complete"}
Dieses Beispiel veranschaulicht das Framing. Ein echter Parser muss Netzwerk-Chunks verarbeiten, die ein Ereignis aufteilen, mehrere Ereignisse enthalten oder ein Multibyte-Zeichen aufteilen. Ein Netzwerk-Lesevorgang ergibt nicht automatisch eine vollständige Nachricht.
Begrenzung der im Speicher wartenden Datenmenge
Wenn die Verbindung zum nachgeschalteten System langsam ist, kann der Server die Daten des Anbieters schneller empfangen, als er sie weiterleiten kann. Eine unbegrenzte Pufferung führt dazu, dass ein langsamer Client zu einem Speicherproblem wird.
Die Anwendung sollte den Druck des beschreibbaren Streams berücksichtigen und eine Puffergrenze festlegen. Wenn das vorgelagerte Protokoll nicht sinnvoll angehalten werden kann, ist eine Abbruchbehandlung unter Umständen sicherer, als zuzulassen, dass die Warteschlange unbegrenzt anwächst.
In den Erläuterungen zur Streams-API von MDN wird Backpressure als Mechanismus zur Flusssteuerung beschrieben. In einer LLM-Anwendung muss ich diesen Mechanismus noch mit der Abbruchfunktion des Anbieters und den Zeitlimit-Richtlinien des Produkts verknüpfen.
Die Stornierung auf die gesamte Anfrage anwenden
Das Schließen der Browserverbindung sollte eine Bereinigung in der Anwendung auslösen und, sofern unterstützt, die Abbruch der übergeordneten Modellanforderung bewirken. Timer, Listener und Puffer müssen freigegeben werden, auch wenn der Abbruch selbst fehlschlägt.
Die Trennung der Verbindung durch den Kunden beweist jedoch nicht, dass der Anbieter die abrechnungsfähige Arbeit eingestellt hat. Bei der Nutzungsabrechnung sollte diese Ungewissheit berücksichtigt und anhand der dem Anbieter vorliegenden Nutzungsdaten geklärt werden.
Langlebige Verbindungen laufen ebenfalls über Proxys mit Puffer- und Timeout-Einstellungen. Ich teste den bereitgestellten Pfad, da sich ein Stream, der direkt mit einem Entwicklungsserver funktioniert, hinter der Produktionsinfrastruktur möglicherweise anders verhält.
Legen Sie fest, wie Teilantworten dargestellt werden sollen
Eine Antwort, bei der die Übertragung auf halbem Weg abbricht, sollte sichtbar unvollständig bleiben. Beim erneuten Verbindungsaufbau darf nicht stillschweigend ein weiterer Modellaufruf erfolgen oder eine neue Antwort an die unvollständige angehängt werden.
Für die Wiederaufnahme sind ein gespeicherter Ereignisverlauf und ein definierter Cursor erforderlich; eine Ereignis-ID allein reicht für die Wiedergabe nicht aus. Bei einem einfacheren Produkt könnte die Bereitstellung einer expliziten Neustartfunktion das klarere Verhalten sein.
Die Validierung eröffnet eine weitere Möglichkeit. Wenn die Faktenprüfung vor der Veröffentlichung abgeschlossen sein muss, müssen die entsprechenden Inhalte zwischengespeichert werden. Den Text sofort anzuzeigen und erst danach zu prüfen, ist ein anderes Produktversprechen.
Ich überprüfe langsame Clients, abgebrochene Anfragen, Proxy-Timeouts, Ausfälle von Anbietern und fehlerhafte Ereignisgrenzen. Eine gute Streaming-Schnittstelle fühlt sich schnell an und sorgt gleichzeitig dafür, dass ihr Abschlussstatus vertrauenswürdig ist.
Aktualisiert am 25. September 2026.