概述
流式会逐步交付输出。只有模型公开 Responses 原生契约且存在同协议 service 路径时,才使用 Responses streaming;否则请使用 Chat Completions 或模型公开的原生协议。推荐:Responses 流式传输
Responses 与 Gemini 流式边界
Responses SSE 会保留 service 事件名称、顺序和字段,只在旁路读取 usage 和终态,不改写 wire。第一个事件交付后,绝不重试该请求。 Responses WebSocket 只接受官方response.create 事件。stream 是隐含行为;该 transport 不提供 background 或 response.cancel,background 只通过 HTTP 运行。每个连接串行处理、不做 multiplexing,最长 60 分钟。
Gemini SSE 保留原生 chunk。只有 metadata 的事件、没有 finishReason 的中间 chunk,以及自然 EOF 都合法;AI Sonar 不会添加 Chat [DONE].
Chat Completions 流式传输
如果你的框架仍然需要来自/v1/chat/completions 的 SSE 分块,这同样可行:
流结束条件
典型的完成条件:- Responses API 流使用
response.completed - Chat Completions 流使用
finish_reason: "stop" - 当达到 token 限制时使用
finish_reason: "length" - 当模型希望使用工具时,会出现 tool/function call 事件
Web 应用模式
最佳实践
新构建项目优先使用 Responses 流式传输
新构建项目优先使用 Responses 流式传输
如果你的 SDK 或应用已经支持
/v1/responses,请使用它。将 /v1/chat/completions 流式传输保留给出于兼容性需求的集成。增量刷新输出
增量刷新输出
在 delta 分块到达时将其追加到 UI 或终端,而不是等待完整响应返回后再处理。
处理断连与重试
处理断连与重试
将网络和服务断连视为正常故障模式,并在长时间运行的会话中谨慎地重新连接。