大模型线上业务，稳定性永远是绕不开的话题。即便各大模型厂商对外宣传服务具备高可用能力，落地真实生产环境，依然会频繁遇到接口超时、429 限流、服务临时维护、流式分片异常截断、模型内部推理报错等各类问题。 如果业务代码直接对接模型厂商原始 API，上游服务一旦出现故障，错误会直接透传到前端，造成用户请求失败。不少开发人员遇到报错第一反应就是写简单重试逻辑，但不加约束的重试，反而会放大故障，引发次生问题。
想要做好容错，第一步要对异常做精细化分类，不能所有错误都无脑重试。 可重试异常：网络抖动、连接超时、上游临时限流、503 服务不可用、短时服务过载。这类属于瞬时故障，服务短时间内有概率恢复，可以纳入重试范围。 不可重试异常：鉴权失败、入参格式错误、模型不存在、请求内容违规、参数越界。这类错误根源在请求本身，无论重试多少次都不会成功，继续重试只会无谓消耗算力与 Token 资源。
确定哪些错误可以重试之后，还要控制重试行为。不能循环无限制重试，否则流量突增会给上游厂商造成更大压力，引发雪崩效应。行业普遍采用指数退避策略：第一次重试等待 200ms，第二次 400ms，第三次 800ms，间隔逐步拉长，同时配置最大重试次数，一般生产环境设置 2 3 次即可。
单纯重试只能解决瞬时抖动，当某一个模型持续大面积报错，就要启动熔断降级机制。我们可以统计一段时间窗口内的错误率，当错误占比超过预设阈值，就触发熔断，临时切断流向该模型的新请求流量，自动将请求调度到能力相近的备选模型。整个切换过程对上层业务透明，业务代码无需做任何修改。熔断同时设置半开探测窗口，隔少量时间发送少量探测请求，判断服务商是否恢复正常，恢复之后再逐步恢复流量。
流式 SSE 场景，是很多项目容易踩坑的盲点。请求已经返回一部分文本，中途网络中断，此时不适合完整重新发起请求。重新调用会完整生成一遍内容，出现输出重复，也会双倍消耗 Token。针对这种场景，业务侧需要做交互层处理，向用户提示 “生成过程中断”，或者在业务允许的条件下实现上下文断点续接。
重试还会带来成本隐患。每一次重试都会产生新的 Token 消耗，故障期间大量重试会让成本短时间暴涨。网关层面需要统计每一次重试产生的消耗，同时配置单请求最大重试消耗上限。
配套监控告警同样不可或缺。持续观测各个模型服务商的错误率、超时占比、限流频次。很多时候服务质量是缓慢下滑，而不是直接完全宕机，通过指标趋势变化，可以提前感知服务商能力衰减，而不是等到大量用户投诉之后才发现问题。
总结落地关键点：对异常做精细化区分，只对瞬时故障执行重试；配置指数退避与最大重试次数；设计熔断与自动路由降级逻辑；针对流式请求做特殊处理；增加成本防护与监控告警。一套完善的容错体系，是大模型业务稳定运行的重要保障。
