Accueil → Aide

Une réponse en streaming s'arrête au milieu d'une phrase

Un flux sain se termine par un marqueur explicite : un fragment portant finish_reason, puis data: [DONE]. Si votre dernier fragment n'a ni l'un ni l'autre, la connexion a été coupée et la réponse dont vous disposez est partielle. Le statut HTTP ne vous le dira pas, car il a été envoyé avant que le corps ne commence.

Ce que vous voyez

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

Pourquoi cela arrive

Les réponses en streaming s'engagent sur un 200 OK dès que le premier octet part. Tout ce qui suit est du corps. Si la connexion meurt au token 900 sur 1200, le client a déjà vu une ligne de statut réussie et ne lèvera rien, sauf s'il vérifie le marqueur de fin du flux lui-même.

C'est pourquoi la panne semble aléatoire. Les réponses courtes se terminent dans la fenêtre qu'autorise le maillon le plus faible ; les longues, non. Le point de coupure varie parce qu'il dépend du temps, pas du contenu.

Les délais d'inactivité des proxies sont la cause habituelle, et ils s'accordent mal avec les modèles de raisonnement : pendant une longue phase de raisonnement, aucun token n'est émis, donc un intermédiaire qui mesure le silence plutôt que la durée totale peut déclarer la connexion morte alors que le modèle réfléchit encore.

Vérifiez si c'est bien la cause

Lisez le flux brut plutôt que l'objet déjà analysé par un SDK, et regardez la fin :

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

Un flux complet se termine par un fragment contenant "finish_reason":"stop" suivi de data: [DONE]. Si la dernière ligne est un fragment de contenu ordinaire, le flux a été coupé.

Comment le corriger

Vérifiez le marqueur de finNotez si vous avez vu [DONE] ou un fragment avec un finish_reason non nul. Sans l'un des deux, traitez le résultat comme un échec, pas comme une réponse courte. C'est le seul changement qui rend le problème visible.
Gardez la connexion active pendant les longues pausesSi un intermédiaire ferme pour inactivité, des commentaires heartbeat dans le flux SSE l'en empêchent. Les fournisseurs qui en envoient rendent les modèles de raisonnement bien plus fiables sur le même chemin réseau.
Ne relancez pas aveuglément depuis le débutUn flux coupé a déjà facturé les tokens qu'il a produits. Relancer tout le prompt double le coût. Là où la réponse peut être découpée, reprenez ; sinon, journalisez au moins la partie reçue pour que la dépense soit comptabilisée.
Testez avec une génération volontairement lente et longueLes prompts courts masquent complètement le problème. Demandez quelque chose qui prend une minute à produire et vous saurez en une tentative si votre chemin est stable.

APICLAN transmet le flux amont sans le mettre en mémoire tampon, donc finish_reason et [DONE] arrivent exactement tels que le fournisseur les a envoyés. La configuration de chaque client est dans le démarrage rapide.

Voir aussi

Unexpected token '<' lors d'un appel à une API compatible OpenAI 401 invalid API key : quand la clé semble correcte mais échoue quand même

Dernière vérification le 2026-10-01. Rédigé à partir de problèmes diagnostiqués sur une passerelle compatible OpenAI en production, pas compilé à partir d'autres sites.