在分布式系统设计中，有一条铁律：任何依赖第三方外部服务的部分，都是不可信的。 这点在当下的 AI 开发中被体现得淋漓尽致。Foundation model 的提供商们，即使是行业巨头，也经常会在毫无征兆的情况下遭遇算力熔断（503 Service Unavailable）或者由于并发突增直接给你甩出 429。更不用说，当你在开发一个多模态（文生图、图生视频）工作流时，链路中任何一个模型的短暂宕机，都会导致整条业务线瞬间卡死。
作为后端负责人，如果你的系统里没有一套优雅的重试与降级防线，那么你的系统可用性就完全取决于别人的服务器心情。
盲目重试：引发系统自残的罪魁祸首
很多刚接触 AI 开发的同学，在捕获到 API 失败后，最直接的反应就是在 catch 块里写一个 for 循环，连续重试 3 次。
// 这种硬编码的暴力重试是生产环境的毒药
for (let i = 0; i < 3; i++) {
try { return await callAIModel(); } catch (e) { ... }
}
在真实的分布式高并发场景下，这种无等待的立即重试非常致命。如果上游服务器是因为流量过载而报错，你的连续暴力重试无异于火上浇油，会导致对方更加坚决地熔断你。正确的做法，必须引入带随机抖动的指数退避算法 。
指数退避与熔断降级架构设计
一个具备健壮性的 AI 调用路由层，应当包含以下三个核心组件：
- 动态退避重试 ：每次重试的间隔时间随重试次数呈指数级增长（例如 1s, 2s, 4s, 8s...），并在其中加入一个随机微调值，防止多并发任务在同一时间协同重试，形成新的流量波峰。
- 断路器 ：如果某个大模型 API 在过去 10 秒内的错误率超过了 50%，断路器必须自动切断所有发往该模型的流量，直接在本地拦截，防止拖慢整体响应响应时间。
- 多模态平替降级 ：当主力模型被熔断时，路由层应无缝将请求切换到备用模型。例如，当首选的高清生图模型遭遇算力瓶颈时，系统自动平滑切换到另一个响应速度较快的备用模型，虽然画质有细微差异，但确保了业务的连续性。
工程落地的最优解
手写这套容灾路由和心跳检测机制不仅容易踩坑，而且后期多模型的动态配置极为繁琐。为了不重复造轮子，我们现在的做法是直接使用 Crun 服务中继层。它内部原生集成了跨供应商的自动灾备路由和请求配额管控。
作为业务开发，我们只需要调用一个终点，背后的重试、降级和模型平滑切换全部由底层中继自动完成。面对不可控的第三方 AI 服务，把灾备防线做进架构里，才是高级工程师该有的底线思维。
