Skip to content

AI API 流式响应中途断开?SSE 长连接对丢包与中间设备的敏感 ​

AI API 流式响应中途断开,根源是它用的是一条持续几十秒甚至几分钟的长连接(多数实现为 SSE,即服务端持续推送的 HTTP 响应),这条连接对三样东西特别敏感:节点丢包、出口 IP 变化、以及链路上任何会缓冲或掐断空闲连接的中间设备。流式响应一直开着,任何一处抖动都会体现为输出截断。

超时与 403 的通用排查见API 超时排查。

速读要点

  • 三大敏感点:丢包、出口 IP 变化、中间设备空闲超时或缓冲
  • 固定时段断是丢包,随机断是出口轮换,长思考时断是空闲超时
  • curl -N 正常而程序不正常,问题在程序或其代理层

SSE 长连接和普通请求的区别 ​

维度普通请求流式响应
连接时长毫秒到几秒几十秒到几分钟
数据传输方式一次性返回分块持续推送,中间有空闲间隔
对丢包的容忍重传后几乎无感重传延迟累积,严重时连接被重置
对 IP 变化的容忍几乎不受影响出口变了连接立即失效
对中间设备的容忍高空闲超时、响应缓冲都会破坏流

AI API 流式响应中途断开的四类原因:丢包、IP 变化与中间设备 ​

  1. 节点丢包。 晚高峰普通线路丢包率上升,重传累积到一定程度连接会被断开。表现为固定时段容易断、白天正常。
  2. 出口 IP 轮换。 策略组设为自动测速、负载均衡或故障转移时,节点切换会让正在进行的连接直接失效。表现为随机断开,与时段无关。
  3. 中间设备的空闲超时。 一些 NAT 设备、企业网关、代理软件会在连接几十秒没有数据时主动关闭。流式响应在模型思考阶段可能有较长的空闲间隔,正好踩中。表现为长思考任务更容易断。
  4. 响应缓冲。 个别代理层会把整个响应攒齐再转发,客户端看起来是「很久没输出然后一次性出来」或者直接超时。表现为流式与非流式耗时几乎相同。

四类原因的 10 秒自检:丢包看是否只在晚高峰断;出口轮换连续 curl ifconfig.me 看 IP 是否变;空闲超时看是否总在模型长时间思考后断;缓冲对比流式与非流式总耗时是否几乎相同。

从网络侧减少断开 ​

  1. 固定单出口节点。 策略组改为手动选择,连续查三次 IP 一致。
  2. 换丢包低的线路。 IEPL/IPLC 专线在晚高峰的丢包通常明显低于普通中转线路。
  3. 缩短空闲间隔的影响。 部分 SDK 支持 TCP keep-alive 或心跳设置,开启后能减少中间设备误判空闲。无法设置的,让客户端的读取超时略长于服务端的最长思考时间。
  4. 排除本地代理层的缓冲。 怀疑时用 curl -N 直接请求流式接口对比,curl 下正常、程序里不正常就是程序或其代理层的问题。
  5. 代码里做断点重试。 对流式响应做幂等重试,已经输出的部分不重复提交。

和节点选择的关系 ​

流式场景下节点的三条优先级依次是:单出口、低丢包、延迟。延迟只影响首字节时间,不影响流能否跑完。看节点时重点看丢包与晚高峰表现,不看 ping 值。

推荐机场 ​

常见问题 ​

非流式调用正常,一开流式就断? ​

典型的长连接问题。先固定单出口节点,再换专线;仍断的检查是否有代理层在缓冲响应。

为什么断开总发生在模型「思考」很久的时候? ​

思考阶段流上没有数据,中间设备把连接当作空闲掐掉。开启 keep-alive 或调整客户端超时,换节点也有帮助。

断开后 SDK 报的是超时还是连接重置,有区别吗? ​

有。超时多与丢包、缓冲有关;连接重置多与出口 IP 变化、节点重连有关。按错误类型分别排查。

下一步 ​

相关阅读 ​

本站内容仅供参考,部分链接含推广说明,详见各优惠页。关于本站