流式聊天 API 的首字超时陷阱：一次 40 秒无首字导致的误判与重试实测

流式聊天 API 的首字超时陷阱：一次 40 秒无首字导致的误判与重试实测
现象：一个把网页版对话服务封装成 OpenAI 兼容接口的中转服务，在一次真实调用中返回了 500，报错大意是“等待助手首字响应超时”。客户端看到的是服务端错误，但真正的问题不在模型，而在中转层对“首字到达时间”的硬性阈值：从请求发出起 40 秒内没有收到第一个 token，就判定整次请求失败。这次调用最终并没有失败到用户不可用的地步——中转服务内部切到池子里的第二个账号重试，第二次同样在 40 秒内无首字，于是再次超时。两次超时叠加，用户侧感知到的就是一次彻底的失败。而同一服务在平时正常情况下，首字通常在 20 秒左右到达。
为什么首字会慢：1.冷标签页切换：中转服务用无头浏览器复用已登录的网页会话。一次调用如果轮到一个久未使用的标签页，页面需要重新激活、重建连接，首字自然来得晚。2.账号轮换的冷启动：池子里多个账号轮流接请求，某个账号上一次使用已是数小时前，它的会话状态、页面上下文都需要重新热身。3.网页端本身的排队：网页对话服务对高成本能力有更严格的调度，文本对话相对轻，但高峰期仍可能排队。40 秒这个阈值的问题在于：它把“慢”等同于“死”。一次 40 秒无首字的请求，未必是死请求——它可能在第 45 秒就正常出字。阈值一刀切，等于把尾部延迟全部转化成错误。
实测数据：正常情况下的首字时间约 21 秒。故障当次：第一个账号 40 秒无首字被切断；第二个账号重试后同样 40 秒无首字，服务返回 500。故障的偶发性：同一服务、同一账号池，在其他时段的实跑均成功，说明这不是账号失效或额度问题，而是冷启动叠加阈值过严。
给中转服务设计者的三点建议：第一，首字超时要分层。首字等待和整体等待应该是两个阈值：首字可以放宽到 90–120 秒，而整体响应再设一个更大的上限。第二，重试要换维度，不要只换账号。当次故障里重试只换了账号，但两个账号走的是同一条冷启动路径、同一个出口网络，换号没有换掉真正的瓶颈。更有效的重试是：复用最近刚成功过的热标签页，或者先发一次轻量探活确认页面状态，再发正式请求。第三，超时错误要带上可观测信息。这次 500 只说了“首字超时”，没有说明轮到了哪个账号、等了多久、页面处于什么状态。如果日志里有这三项，排查方向会立刻收敛到“冷标签页”而不是“账号坏了”。
给调用方的建议：客户端侧同样可以做两件事：一是把中转服务的 500 区分对待——明确标注为“首字超时”的 500 值得重试一次，而不是直接向用户报错；二是给自己的调用设一个比服务端阈值更宽松的超时，避免客户端先断、服务端后断的双重超时互相掩盖。
结论：流式 API 的健壮性不在平均延迟，而在尾部。一次 40 秒的硬性首字阈值，在正常 21 秒的服务上看起来绰绰有余，却会在冷启动那天连续击穿两次。把首字阈值放宽、重试换维度、错误带上下文，这三处改动都不大，但能把偶发失败变成可恢复的慢请求。