去年某个周三早上9点，我的内容流水线准时启动。前三个请求正常返回，第四个弹出429，第五个还是429。一小时后，页面依然空白。服务商状态页显示"运行正常"——确实正常，只是我的当日配额用完了。

这是单点故障最阴险的形态：系统没崩，只是不再理你。免费层的配额消耗是隐形的。面板写着"每日1500次请求"，但这个数字会随全球流量动态压缩。早上9点半收到429，不是你的错，是配额 worldwide 已满，你被挤到了队尾。

打开网易新闻 查看精彩图片

更麻烦的是，崩溃和拒绝服务是两回事。状态页只报告前者，后者在你的可用性指标上凿了个洞，却无处可查。

打开网易新闻 查看精彩图片

我最初的修复方案是按成本排序：便宜的先用，贵的兜底。这在实战中惨败——基础设施相似的供应商会同时倒下。两家用同一家GPU厂商的推理公司，配额可能在同一小时内耗尽。这不是故障转移，是延迟故障。

现在的链路完全按风险相关性排列：Gemini（Google）打头，性价比最优；Groq其次，自研LPU芯片，独立于Google生态；Cerebras第三，晶圆级芯片、不同数据中心、不同配额策略；最后OpenRouter做经纪，前三家全挂时它能路由到其他后端。

打开网易新闻 查看精彩图片

这套架构还埋了另外六个现场教训：配额监控必须独立于状态页；质量验收不能只看HTTP状态码；要警惕"静默衰减"——模型输出慢慢变糟，系统却报告一切正常；链式调用超时需要指数退避；不同供应商的token计数方式差异巨大；以及，永远保留一条人工降级通道。

最反直觉的发现：多供应商不是备份思维，是投资组合思维。你不是在找"更可靠的Plan B"，而是在构建互不相关的风险敞口。当Google、Groq、Cerebras三家同时失效的概率，低于任何一家单独失效的概率时，系统才真正健壮。