调用大模型 API 总超时，还经常断在半路？从超时、重试到流式输出的三层做法

最近不少人在应用里接大模型时都会遇到同一个现象：平时调用好好的，一到高峰就超时，回答写到一半就断掉。很多人第一反应是换更大的模型，或者把超时时间调到几分钟，结果问题还在，费用反而上去了。其实大多数超时不是模型太慢，而是调用方式没有分层处理。下面这三层做法，改动不大，但能把大部分超时和中断挡在外面。

一、先分清是哪一种超时

动手改之前，先把超时分成三类，改错方向只会越改越乱。

第一类是连接超时：请求发出去很久都没有建立连接，多半是网络、代理或者服务地址本身有问题，先看网络和配置，重试也没有意义。

第二类是读取超时：连接建好了，模型迟迟不返回，常见于提示词太长、要求一次生成几千字，或者高峰期排队。

第三类是业务超时：接口本身返回了，但上游网关或者你自己的服务先断了连接，日志里看起来像模型没有回应。

二、第一层：把超时时间设对

很多人只设一个超时时间，结果连接问题和生成问题混在一起。更稳的做法是分开设置。

连接超时可以设得短一些，比如 5 秒到 10 秒，连接不上就快速失败，不要让请求一直挂着。读取超时则要根据任务来定：短问答可以设 30 秒，总结、翻译这类长输出可以放宽到 120 秒，但不要无限制地放宽。

三、第二层：重试要有节制

超时之后要不要重试，取决于失败的类型。连接失败、网关返回 502 或者 503、明确的限流提示，这些都可以重试；但已经返回部分内容、或者模型已经开始计费的请求，就不要盲目重试，否则一次调用可能变成两次扣费。

重试最多两次，第一次等 1 秒，第二次等 2 秒到 4 秒，间隔逐渐拉长。不要在循环里立刻重试，那样只会把高峰期的压力翻倍。

四、第三层：长回答改用流式输出

如果你的场景是写文章、写代码、做总结，一次性等完整回答是最容易超时的。改成流式输出，模型每生成一小段就返回一小段，前端可以边收边显示，用户几秒钟就能看到内容，体感会好很多。

做流式的时候要注意两点：一是前端要处理断开重连，断在半路时不要直接报错，可以提示已生成部分内容，并提供重新生成按钮；二是后端要把已生成的内容及时落盘或者缓存，避免用户刷新页面后又要重新生成一次。

五、兜底：降级和观测不能少

再稳的调用也难免遇到服务波动，所以要提前准备降级方案。比如高峰期自动切换到响应更快的轻量模型做摘要类任务，或者在模型不可用时返回缓存的常见回答，并明确告诉用户这是缓存结果。

观测同样重要。至少要记录成功率、平均耗时、超时次数和重试次数这四个指标。每周看一次趋势，比出了问题再去翻日志要省事得多。

小结

调用大模型超时，多数时候不是某一个环节出了大问题，而是超时、重试、输出方式这三层都没有分开处理。先分清超时类型，再把连接超时和读取超时分开设置，重试只做两次并且间隔拉长，长回答改用流式输出，最后留好降级和观测。这样改下来，接口会稳很多。