很多关于大模型 API 的文章，读起来都很顺：接口清晰、示例简单、效果稳定。但真正上线后你会发现，它和数据库、缓存、消息队列一样，并不是“调用了就一定有结果”的基础设施。这次事故发生在一次业务流量明显抬升的时间段，我们的系统开始大量并发调用大模型接口，原本只是一次普通的能力接入，最终却演变成了一次完整的接口雪崩。
-
高并发下的第一次异常，其实早有征兆
一开始只是响应变慢，平均耗时从几百毫秒拉到了几秒钟。监控里还能看到成功返回，只是慢了一点，于是大家都以为扛一会儿就过去了。但很快，超时开始出现，而且比例在持续上升。后来复盘才意识到，大模型服务本身并不保证在高并发下稳定响应，请求一多，内部排队和限流就会把问题直接暴露出来。 -
自动重试，本来是兜底，结果成了推手
为了减少失败率，我们在调用层加了自动重试。单看逻辑没什么问题：失败就再试一次。但当下游已经在高负载状态时，这种重试只会制造更多请求。短时间内，失败请求和重试请求叠加在一起，流量不降反升，模型接口彻底被压垮，系统也随之进入恶性循环。 -
线程被拖死，问题开始“蔓延”
真正让事故失控的，是线程阻塞。模型调用在同步链路中，一旦超时，线程就被长时间占用。线程池很快被打满，后续请求排队，哪怕是和模型无关的接口，也开始响应变慢甚至直接失败。这时候问题已经不再是“某个接口慢”，而是整个服务都在被拖下水。 -
没有熔断，系统只能硬扛
回头看，最致命的缺陷其实很简单：没有熔断。系统无法判断“下游已经不值得再调用”，于是只能不断尝试、不断失败。直到人工介入，把相关功能直接关掉，服务才慢慢恢复。这一刻大家才意识到，熔断并不是为了性能，而是为了让系统在出问题时还能保命。 -
让系统学会“退一步”，而不是硬撑
事故之后，我们做的第一件事不是换模型，而是重新定义失败时该怎么办。模型结果不再是强依赖，失败时可以返回简化结果；重试次数被严格限制，失败率一高就直接触发熔断；部分非核心场景，允许完全跳过模型调用。这些改动并没有让功能更“智能”，但系统在压力下明显更稳定了。
复盘之后才发现，问题不在模型
这次事故最大的收获，是对大模型 API 的定位发生了变化。它并不是一个“随叫随到”的能力，而是一个需要被严格约束的外部依赖。只要把它当成一定会失败的组件来设计，很多问题其实在上线前就能避免。
后来在做压测和演练时，我会顺手用支持多模型切换的 AI model APIs 平台（比如 GPT Proto）去模拟不同厂商在限流、超时场景下的表现，提前把兜底和降级逻辑跑一遍，心里也更有底。