概覽
串流會逐步交付輸出。只有模型公開 Responses 原生契約且存在同協議 upstream 路徑時,才使用 Responses streaming;否則請使用 Chat Completions 或模型公開的原生協議。建議:Responses Streaming
Responses 與 Gemini 串流邊界
Responses SSE 會保留 upstream 事件名稱、順序與欄位,只在旁路讀取 usage 與終態,不改寫 wire。第一個事件交付後,絕不再嘗試其他 channel 或 credential。 Responses WebSocket 只接受官方response.create 事件。stream 是隱含行為;此 transport 不提供 background 或 response.cancel,background 只透過 HTTP 執行。每個連線採序列處理、不做 multiplexing,最長 60 分鐘。
Gemini SSE 保留原生 chunk。只有 metadata 的事件、沒有 finishReason 的中間 chunk,以及自然 EOF 都合法;TokenLab 不會加入 Chat [DONE].
Chat Completions 串流
如果您的框架仍預期從/v1/chat/completions 接收 SSE 區塊,這同樣可行:
串流結束條件
典型的完成條件:- Responses API streams 的
response.completed - Chat Completions streams 的
finish_reason: "stop" - 當達到 token 限制時的
finish_reason: "length" - 當模型想要使用工具時的 tool/function call 事件
Web App 模式
最佳實務
新建專案優先使用 Responses streaming
新建專案優先使用 Responses streaming
如果您的 SDK 或應用程式已支援,請使用
/v1/responses。將 /v1/chat/completions streaming 保留給以相容性為導向的整合。逐步刷新輸出
逐步刷新輸出
在 delta 區塊到達時立即將其附加到 UI 或終端機,而不是等待完整回應。
處理中斷連線與重試
處理中斷連線與重試
將網路中斷與上游連線中斷視為正常的失敗模式,並在長時間執行的工作階段中謹慎地重新連線。