Start → Hilfe

Eine Streaming-Antwort bricht mitten im Satz ab

Was Sie sehen

• The answer ends mid-word with no exception
• No [DONE] marker in the raw stream
• Works on short answers, fails on long ones
• chunked encoding ended prematurely / IncompleteRead
• Retrying produces a different cut-off point each time

Warum das passiert

Streaming-Antworten legen sich auf 200 OK fest, sobald das erste Byte rausgeht. Alles danach ist Body. Stirbt die Verbindung bei Token 900 von 1200, hat der Client schon eine erfolgreiche Statuszeile gesehen und meldet keinen Fehler – es sei denn, er prüft zufällig die Endmarkierung des Streams.

Deshalb wirkt der Fehler zufällig. Kurze Antworten werden innerhalb des Fensters fertig, das die schwächste Station zulässt; lange nicht. Die Abbruchstelle wandert, weil sie vom Timing abhängt, nicht vom Inhalt.

Meist sind Leerlauf-Timeouts von Proxys die Ursache, und die vertragen sich schlecht mit Reasoning-Modellen: In einer langen Denkphase werden gar keine Tokens gesendet, also kann eine Zwischenstation, die Stille statt Gesamtdauer misst, die Verbindung für tot halten, während das Modell noch nachdenkt.

Prüfen, ob es daran liegt

Lesen Sie den rohen Stream statt des geparsten SDK-Objekts und schauen Sie aufs Ende:

curl -N -s 'YOUR_BASE_URL/chat/completions' \
  -H 'Authorization: Bearer YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"model":"YOUR_MODEL","stream":true,
       "messages":[{"role":"user","content":"Count slowly from 1 to 400."}]}' \
  | tail -5

Ein vollständiger Stream endet mit einem Chunk mit "finish_reason":"stop", gefolgt von data: [DONE]. Ist die letzte Zeile ein gewöhnliches Content-Delta, wurde der Stream gekappt.

So beheben Sie es

1. Auf den Abschluss prüfenMerken Sie sich, ob Sie [DONE] oder einen Chunk mit nicht-leerem finish_reason gesehen haben. Ohne eins von beiden behandeln Sie das Ergebnis als fehlgeschlagen, nicht als kurz. Diese eine Änderung macht das Problem sichtbar.
2. Die Verbindung in langen Pausen warm haltenSchließt eine Zwischenstation bei Leerlauf, verhindern Heartbeat-Kommentare im SSE-Stream das. Anbieter, die sie senden, machen Reasoning-Modelle über denselben Netzweg deutlich zuverlässiger.
3. Nicht blind von vorn wiederholenEin gekappter Stream hat die erzeugten Tokens bereits abgerechnet. Den ganzen Prompt zu wiederholen verdoppelt die Kosten. Wo sich die Antwort stückeln lässt, setzen Sie fort; wo nicht, loggen Sie wenigstens den Teil, damit die Ausgabe nachvollziehbar bleibt.
4. Mit einer absichtlich langsamen, langen Generierung testenKurze Prompts verbergen das vollständig. Verlangen Sie etwas, das eine Minute dauert, und Sie wissen nach einem Versuch, ob Ihr Weg stabil ist.

Verwandte Themen

Zuletzt geprüft am 2026-10-01. Geschrieben aus Problemen, die auf einem laufenden OpenAI-kompatiblen Gateway diagnostiziert wurden – nicht von anderen Seiten zusammengetragen.