LLM-Antworten mit Server-Sent Events streamen

Setzen Sie in der Anfrage stream auf true. Die API hält die HTTP-Verbindung offen und sendet Server-Sent Events: Zeilen, die mit data: beginnen und ein JSON-Objekt enthalten. Bei Chat Completions ist jedes Objekt ein chat.completion.chunk, dessen choices[0].delta das neue Textstück in content trägt. Der Stream endet mit der Zeile data: [DONE].

Die offiziellen SDKs übernehmen das Parsen. In Python iterieren Sie über den zurückgegebenen Stream, in JavaScript nutzen Sie for await. Rufen Sie die API mit einem eigenen HTTP-Client auf, lesen Sie den Antwortkörper zeilenweise, überspringen leere Zeilen und Kommentare und parsen jede data:-Nutzlast als JSON.

Standardmäßig enthalten gestreamte Chunks keinen Tokenverbrauch. Mit stream_options: {"include_usage": true} trägt der letzte Chunk vor [DONE] ein Objekt usage und ein leeres Array choices. Deshalb prüft das Beispiel chunk.choices, bevor es darauf zugreift.

Der Chunk, der die Antwort beendet, enthält einen finish_reason wie stop oder length. Auch Tool Calls werden gestreamt: delta.tool_calls kommt in Stücken, zuerst der Funktionsname, dann die JSON-Argumente verteilt auf mehrere Chunks. Fügen Sie die Argument-Strings pro index zusammen und parsen Sie sie erst, wenn finish_reason tool_calls lautet. Reasoning-Modelle streamen ihr Nachdenken unter Umständen vorab in einem eigenen Feld.

Die Responses API streamt typisierte Events statt Chunks. Text kommt in Events vom Typ response.output_text.delta, Tool Calls und andere Ausgabeelemente haben eigene Events, und response.completed liefert das fertige Antwortobjekt samt Verbrauch. Reagieren Sie auf die Typen, die Sie brauchen, und ignorieren Sie den Rest.

Der Messages-Endpunkt nutzt die Abfolge von Anthropic: message_start, dann content_block_start, eine Reihe von content_block_delta-Events mit text_delta oder input_json_delta, content_block_stop, ein message_delta mit stop_reason und Verbrauch und zuletzt message_stop. Die Anthropic-SDKs bieten Hilfen wie text_stream, die nur den Text liefern.

Fehler vor Beginn der Generierung, etwa ein falscher Schlüssel oder ein unbekanntes Modell, kommen als normaler HTTP-Fehler ohne Stream. Fehler während der Generierung erscheinen als Fehler-Event im Stream, danach schließt sich die Verbindung; Ihre Schleife sollte das abfangen und über eine Wiederholung entscheiden.

Proxys und Load Balancer puffern Antworten manchmal, dann wird aus dem Stream ein später Textblock. Schalten Sie Pufferung für diese Routen ab, bei nginx etwa mit X-Accel-Buffering: no, und setzen Sie Leerlauf-Timeouts länger als die Pausen zwischen Tokens bei langsamen Reasoning-Modellen. Schließt ein Nutzer die Seite, brechen Sie die Anfrage ab, damit die Generierung endet.