全部笔记
你的 AI 供应商总有一天会出问题

2026年6月10日

你的 AI 供应商总有一天会出问题

这周来了两条提醒。Anthropic 将在 6 月 15 日把 Claude Sonnet 4 和 Opus 4 从 API 下线——如果你把版本钉死在这两个上,那天起你的调用就直接开始返回错误,没有任何自动切换。而今天早上,Gemini 挂了。两件事方向相反,教训却一样:撑起你产品的那个模型,是一个第三方服务,它会按照你无法掌控的时间表,去改变、消失或者崩溃。解决办法不是什么战略,而是大多数 AI 产品都跳过的、枯燥的韧性工程。

这周有两条不起眼的新闻,说的其实是同一件事。第一条:Anthropic 将在 6 月 15 日把 Claude Sonnet 4 和 Opus 4 从 API 下线。 如果你的代码调用的是这些钉死的版本,那天之后请求就 直接返回错误——不会自动切换到更新的模型, 调用就这么失败了。第二条:今天早上,谷歌的 Gemini 挂了, 给所有依赖它的人返回「出错了」。

一个是计划内的下线,一个是计划外的宕机,但它们是同一个教训的两面:撑起你产品的那个模型是个第三方服务,它会按照你无法掌控的时间表给你掉链子。 我们谈论 AI 时,总把它当成一个永远清醒、永不改变的魔法神谕。可它现在是基础设施了—— 而基础设施也有不顺的日子。问题在于:你的基础设施出问题时,会不会把你的产品一起拖垮。

AI 是基础设施,而基础设施会宕机

这种事并不罕见。去年年底某个状态监测平台,单单一个月就记录到主流 AI 供应商发生了 47 起事故—— Anthropic 和 OpenAI 各自的 总影响时长都超过 180 小时。 OpenAI 在 2025 年有过一次长达 34 小时的宕机。哪怕在 99.76% 这样还算健康的可用率下,那也意味着 一年里大约有 16 个小时, 你产品赖以运行的那个东西干脆就不在了。再加上像 6 月 15 日这样的下线——模型不是宕机,而是消失—— 画面就很清楚了:把宝全押在一家供应商上、毫无后备方案,就等于永远赌它天天都是状态最好的那一天。

大多数 AI 产品恰恰就是这么搭的——一家供应商,一个模型字符串,直接调用,再加上一个「它总会回应」的顺风顺水的假设。 这在演示里没问题,可放到生产环境里就是颗定时炸弹。

在动手应对之前,先搞清楚你遇到的是哪种故障

韧性工程教会你的第一件事,就是故障并不都一样,而反应错了只会让情况更糟。瞬时故障—— 一个 429 限流、一次短暂的网络抖动——几秒钟就过去了,重试一下就好。持续故障—— 一次彻底的供应商宕机、一个二十分钟里一直返回垃圾结果的模型——干等是等不来恢复的, 重试只是白白烧钱烧时间。 对每个错误都盲目重试,正是把供应商一个糟糕的小时变成你账单失控的方式。所以这些手段是层层叠加的: 瞬时的就重试,持续的就降级回退,整个系统都在劣化时就触发熔断器。

让你在它们宕机时也能站住脚的四招

你不需要什么花哨的东西——这就是把标准的分布式系统卫生习惯,套用到模型调用上:

  • 带退避的重试,应对瞬时错误。限流和网络打嗝很正常;几次逐渐拉长间隔的重试,能在没人察觉的情况下消化掉大部分。
  • 一个后备模型或供应商,应对持续故障。这是最关键的一招,而且数字很惊人:两家各自可用率 99.3% 的独立供应商, 同时宕机的概率只有 0.0049%——相当于约 99.995% 的有效可用率。 多一条路,就把一次宕机从「没有答案」变成「答案稍差一点」。 (这也是为什么把模型藏在一个可替换的接缝后面, 不只是战略上划算,运维上也一样划算。)
  • 一个熔断器,这样当某家供应商明显挂掉时,你就别再死命去捶它,而是快速失败、干净地恢复,而不是堆积一大堆超时。
  • 优雅降级到一条确定性的路径。如果 AI 功能死了,别让用户永远盯着一个转圈—— 退回到某个更笨但仍然能用的东西:用关键词搜索代替语义搜索,用模板化回复代替生成式回复,用一个普通表单代替智能流程。 告诉用户「高级功能暂时离线」,并让产品继续可用。

最后这一招最重要,却最常被跳过。一个没有非 AI 后备方案的 AI 功能,意味着你整个产品的可用率, 现在被你最不靠谱的那个依赖给封顶了。

还有,把下线日期写进日历

6 月 15 日的下线是更安静的那种故障,而且专坑那些自以为很安全的人。把模型版本钉死,感觉很负责任—— 你把行为冻结住了。可一个被钉死的版本,就是一个可能被下线的版本,而它一旦被下线, 你的调用不是劣化,而是直接死掉。所以要么去追踪你钉死的每一个模型的下线通知,要么干脆别去钉一个你没准备好按供应商时间表迁移走的版本。 迁移通常只是 改一行代码—— 但前提是你在 6 月 15 日之前就知道,而不是 6 月 16 日从错误日志里才发现。

归根结底

关于 AI 的精彩故事,是它能做的一切。而那个不光鲜的故事——这一周悄悄讲了两遍的那个—— 是它就是一个远程服务,会在你没挑选的时刻变慢、宕机或消失——一个假设它不会这样的产品, 离一场事故只差一个糟糕的早晨。这些解决办法没一个是聪明的。抖动就重试,宕机就回退,降级到确定性的东西, 盯紧下线日历。这跟我们为任何关键依赖所做的、同样枯燥的可靠性工作没什么两样——而模型现在恰恰就是这样一个依赖。

所以在你上线之前,问一个演示永远不会逼你去问的问题:当我的供应商迎来它糟糕的一天时——它一定会—— 我的用户看到的是什么?如果答案是「一个错误加一个转圈」,那你并没有在 AI 之上搭出一个产品。 你搭出来的,是一个把自己的可用率借给别人去决定的产品,而人家可从没向你承诺过他们状态最好的那一天。

评论

暂无评论

登录以参与讨论。

做第一个分享想法的人。