很多 AI API 的演示只测“最后有没有返回完整答案”。但在聊天、代码生成和 Agent 场景里，用户先看到什么、网络中断后能不能恢复、已经返回的部分是否有用，同样决定体验。流式输出应该被当成一条持续变化的连接来测，而不是普通的 200 响应。
先把五个时间点记下来
第一项是首字节时间，也就是请求发出到第一个有效事件抵达的时间。它反映鉴权、排队、模型准备和网关转发的总开销。第二项是令牌间隔，平均值不够，还要看 P95、P99 是否出现长停顿。第三项是完整结束时间，应该和输出长度一起记录，避免把“回答更短”误判为“接口更快”。
第四项是断流位置。断在开头、中间或工具调用事件之后，恢复策略并不相同。第五项是取消后的行为：客户端停止读取后，上游是否仍然继续消耗额度，网关是否及时关闭连接，都要通过账单和日志核对。
用故障样本代替单次体验
至少准备四组样本：短回答、长回答、包含工具调用的回答，以及主动取消的回答。每组重复多次，记录状态码、事件类型、最后一个合法事件、usage 字段和连接关闭原因。不要只看文本是否完整，因为有些 SDK 会把协议错误吞掉，最终只留下一个看似正常的字符串。
断线恢复也要分级。若协议支持事件 ID，可以从最后一个已确认事件继续；如果不支持，就应该把重试标记为新请求，避免客户端把两段内容无条件拼接。对有副作用的工具调用，重连前必须确认工具是否已经执行，不能仅凭文本判断。
网关层应该做什么
网关可以统一补充 request_id、stream_id、首字节时间和结束原因，同时限制单次连接时长、输出速率和最大缓冲区。日志不必保存全部提示词和答案，保留事件计数、哈希、错误类型和必要的脱敏片段即可。对不同上游使用同一套样本，就能比较真实的流式稳定性。
如果需要同时测试多个模型，可以在 top-api.cc 这类统一入口上复用同一套请求和样本，重点对比首字节、断流率和取消后的资源消耗，而不是只比较最终文案。统一入口的价值是让协议、鉴权和采样方式保持一致。
一份可执行的检查清单
- 是否记录首字节和令牌间隔的分位数；
- 是否能识别正常结束、主动取消、上游错误和网络断开；
- 断流后是否会重复执行工具；
- usage 和账单是否包含被取消的部分请求；
- 长连接是否有超时、限速和最大输出保护；
- 日志是否做到可排障但不把敏感正文长期落盘。
流式 API 的测评结果应该最终落到“什么情况下可恢复、什么情况下必须人工介入”。在生产环境中，部分结果、断流和取消都是正常事件，真正的风险是系统把它们伪装成成功，或者在恢复时重复执行了用户动作。
参考资料：OpenAI Cookbook 的流式响应示例、Portkey Gateway 的可靠路由说明。发布前应以实际供应商协议为准。
需要把多家上游放在同一套样本下比较时，可从 top-api.cc 的统一 API 入口开始，再把流式指标接入自己的监控系统。
Leave a Reply