6月2日凌晨，我正在赶一个功能
Claude API突然返回502，接着503，然后干脆超时。
打开Twitter一看，炸了。不是只有我一个人。
DownDetector的数据显示，故障从美东时间凌晨2点19分开始蔓延。Claude网页版、Console、API、甚至Claude Code全部趴窝。几万个开发者的自动化流水线同时停转，CI/CD卡死，构建报告发不出来，客户的消息堆积在队列里。
Anthropic在几个小时后修复了问题。但那天晚上我失眠了，一直在想一件事。
你的AI流水线有多脆弱
我审视了自己的项目依赖链。代码生成靠Claude，文档摘要靠Claude，测试用例也靠Claude。整个产品的AI能力绑死在一个供应商上。
Stanford AI Index 2026的报告提到，开发者可用的AI模型数量在暴涨，但实际使用集中度反而在上升。大家都觉得”万一出问题再说”，结果就是出问题的时候一起出问题。
这种心态很普遍，我自己也是。
我做的几件事
第一件，加了fallback。API调用失败后自动切到备选模型，比如GPT-4o或者本地的Llama 4。切换逻辑不复杂，就是try-catch外面多包一层。但效果立竿见影，后续几次小规模抖动我基本无感。
第二件，本地化关键路径。不是所有功能都需要最强模型。文档分类、格式转换这种简单任务，用一个7B的本地模型完全够用，速度还更快。Microsoft最近开源了7个MAI模型，覆盖了各种尺寸，其中几个轻量级模型跑在普通笔记本上也没问题。
第三件，做了告警而不是日志。以前出错了往日志文件一丢就不管了。现在API失败率超过5%直接触发通知，我能第一时间知道。
独立开发者的现实
大公司有专门的SRE团队盯着可用性，独立开发者只有自己。
我没有能力保证99.99%的SLA，但至少可以做到出问题时不受致命打击。多模型架构听起来复杂，实际操作就是多写几行配置。Sub2API、OpenRouter这类API聚合服务把这件事变得特别简单。
说到底，AI API也是一种基础设施。你不会把网站只部署在一个节点上，那凭什么把核心功能只挂在一个模型上？
6月2日那次故障之后，我把自己的依赖整理成了一张表。哪些功能可以降级，哪些必须高可用，哪些可以直接走本地。这张表后来成了我做技术选型的第一步。
常见问题
Q: 多模型方案会不会增加成本？
会，但不多。大部分流量还是走主力模型，fallback只在故障时触发。算下来每月多出的费用不到总账单的5%。
Q: 本地模型性能够用吗？
看你用来做什么。Llama 4在推理任务上已经接近GPT-4早期版本的水平，日常文本处理绑绑有余。重活儿还是交给大模型。
Q: API聚合服务本身挂了怎么办？
确实有这个风险。所以我的做法是关键路径直连，非关键路径走聚合。两种方式都有，总有一种能用。
写在最后
那天晚上故障修复后，我在GitHub上看到一个issue，标题是”我们需要讨论AI API的单点依赖问题”。底下三百多条评论，大家都在分享各自的惨痛经历和解决方案。
这种讨论早就该有了。
