北京
去年某个周三早上9点，我的内容流水线准时启动。前三个请求正常返回，第四个弹出429，第五个还是429。一小时后，页面依然空白。服务商状态页显示"运行正常"——确实正常，只是我的当日配额用完了。
这是单点故障最阴险的形态：系统没崩，只是不再理你。免费层的配额消耗是隐形的。面板写着"每日1500次请求"，但这个数字会随全球流量动态压缩。早上9点半收到429，不是你的错，是配额 worldwide 已满，你被挤到了队尾。
更麻烦的是，崩溃和拒绝服务是两回事。状态页只报告前者，后者在你的可用性指标上凿了个洞，却无处可查。
我最初的修复方案是按成本排序：便宜的先用，贵的兜底。这在实战中惨败——基础设施相似的供应商会同时倒下。两家用同一家GPU厂商的推理公司，配额可能在同一小时内耗尽。这不是故障转移，是延迟故障。
现在的链路完全按风险相关性排列：Gemini（Google）打头，性价比最优；Groq其次，自研LPU芯片，独立于Google生态；Cerebras第三，晶圆级芯片、不同数据中心、不同配额策略；最后OpenRouter做经纪，前三家全挂时它能路由到其他后端。
这套架构还埋了另外六个现场教训：配额监控必须独立于状态页；质量验收不能只看HTTP状态码；要警惕"静默衰减"——模型输出慢慢变糟，系统却报告一切正常；链式调用超时需要指数退避；不同供应商的token计数方式差异巨大；以及，永远保留一条人工降级通道。
最反直觉的发现：多供应商不是备份思维，是投资组合思维。你不是在找"更可靠的Plan B"，而是在构建互不相关的风险敞口。当Google、Groq、Cerebras三家同时失效的概率，低于任何一家单独失效的概率时，系统才真正健壮。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
