Claude全球崩了90分钟,单点依赖它的AI全部瘫痪

admin 商品展示 23

Claude全球崩了90分钟,单点依赖它的AI全部瘫痪-第1张图片-开云手机入口官网下载-开云app官方最新下载--V3.6.9

6月23日上午10点,Claude全球崩了。

并非是某一个模型出现降级情况, 并非是某一个地区处于不可用状态。而是整个线路——claude.ai聊天界面、开发者API、Claude Code、Claude Cowork, 同时陷入瘫痪状态。Downdetector的报告数量在第一个小时就已经突破8000, 并且还在持续上涨。Anthropic状态页上的一行字挂了将近一个小时: 「正在调查中」。

这自身并非新闻, AI服务出现宕机状况, 于今年可是已有无数回发生了, 真正应当予以留意的, 乃是这条新闻背后存在着的一个更为残酷的数字, ——。

Claude崩溃失常的那90分钟时段历程当中开云app官方最新下载地址,每一个仅仅单独依靠它的Agent, 以及Copilot, 还有自动化流水线, 另外AI客服, 加上Coding助手, 竟然没有任何瞬间能够成功支撑住, 一秒钟全都未能顽强坚持住。

你耗费三个月时间搭建而成的AI Agent系统, Claude一旦出现崩溃状况, 它便会随之一同崩溃。既不存在降级处理, 也不存在兜底预备, 甚至都未曾给你哪怕仅仅一个表示「服务暂时不可用, 请稍候」的得体提示。

这不是技术故障。这是架构失误。

单点依赖,正在吃掉AI工程的真实可用性

先看一组时间线。

这并非Anthropic头一回崩掉了。在6月2日的时候, Claude也曾出现过一次崩掉的情况, 彼时发生的状况更为糟糕, 那便是整个平台陷入瘫痪状态长达数小时之久。事情过后进行复盘, 根源原因乃是Claude Code的sub - agent系统引发了一个漏洞程序, 子agent呈现出指数级别的增殖态势, 陷入无限循环之中, 直接将后端资源消耗殆尽。有60%的用户提出来的投诉集中在聊天界面那里, 24%是在移动端方面, 8%是在Claude Code这儿。

先是6月5日, 出现了又一回大规模中断。紧接着到了6月23日, 有8000多份报告, 整个区域完全陷入困境。

一个月崩了三次。

并且, 在6月23日的这一回, 处于一个极其微妙的时间节点之上, 三周之前, Anthropic才刚刚秘密递交了IPO申请, 其估值超过万亿美元, 你晓得这意味着什么吗? 世界上最具价值的AI公司当中的一个, 也无法防止自身的服务出现崩盘。

那你凭什么觉得,你的系统单点挂在一个AI API上会没事?

回溯到第一性原理, 外部依赖的本质究竟是什么? 它意味着你系统的一条腿踏在了别人家的地基之上, 而别人家的地基何时会坍塌, 你根本无法掌控。你唯一能够把控的仅有一件事, 那便是在其坍塌之后, 你的系统是否还能够稳稳立足。

,这可不是啥新鲜出炉的问题。数据库它, 是会出现故障挂掉的, Redis, 同样也会出现挂掉的情况, 还有消息队列也是会挂掉的。你看, 微服务架构可是花费长达足足十年的时间, 针对每一种外部依赖都专门精心设计了容错机制。连接池要是满了的话, 那就会有熔断措施, 响应要是变得慢了, 就会实行限流, 主库要是挂掉了, 就会有从库切换, 要是整个机房都断电了, 还设置了多活的应对方式。

唯独AI API,大家好像忘了这件事。

占据绝大多数比例的、预计在2026年才会上线的AI应用, 其调用链路呈现这样的状况: 先是用户发起请求, 接着传递至你的业务服务, 随后到达你的Agent编排层, 之后调用Claude/GPT API, 再之后处于等待响应的状态, 最后进行返回。并且, 在这一过程当中, 不存在熔断机制, 不存在降级处理, 不存在兜底的模型, 也不存在语义缓存。

这不是在接API,这是把所有筹码押在一张牌上。

三个最常见的致命假设

回顾我亲眼见过以及亲自经手处理过的几十次AI系统故障情况, 其根本原因可谓千奇百怪, 但探寻源头却只有三种假设, 然而每一种假设都无法经受住仔细的琢磨与考量。

假设一:「大厂的API不会崩,至少不会同时崩。」

六月的数据, 打脸打得极其响亮, Claude一个月之内崩了三次, 而且每次都是全面性地崩溃, 使得全球范围内的开发者, 只能干瞪着眼, 毫无办法开云真人app官方版入口,开云真人app官网入口开云手机入口app下载,你说GPT稳定? 今年GPT - 5.6出现过不止一回区域性无法使用的状况, Gemini也曾出现过崩溃的情况。

知名大厂所提供的 API 具备稳定性, 然而这并不意味着其就完全可靠。它们在所制定的 SLA 当中明确表明为 99.9%, 这样的数据听起来似乎很高, 经过换算之后可知, 一年的宕机时长为 8.76 小时。

假设你的系统是由AI Agent驱动的自动化流水线, 每日要进行几十万次调用, 那么8.76小时代表着什么呢? 这表示一年当中至少会有若干天, 你的系统会完全停工。不存在降级途径, 用户所见到的将是白屏、报错以及超时。随后他们便不会再回来了。

假设二:「崩了就重试,多试几次总会通的。」

这是生产环境里最危险的直觉。

Claude出现崩溃状况之际, 要是你的重试逻辑属于简单野蛮的那种「失败之后等待1秒钟随后再次尝试」, 后果会是什么模样? 数千个并发请求一同进入重试循环之中, 朝着已然崩溃的API发起新一轮凶悍攻击, 当API稍微恢复些许之时, 又被你这一波重试风暴给打回到崩溃状态, 如此一来你的系统就充当了帮凶这一角色。

正确的做法是, 采用指数退避并伴有抖动机制。第一次失败时, 需等待1秒钟, 第二次失败时, 等2秒钟, 第三次失败时, 等4秒钟, 其最长等待时间上限为30秒。而且, 对于每个请求的退避时间, 要加上一个随机偏移量, 以此来防止所有请求在同一毫秒同时苏醒。更为关键的一点是, 在重试N次过后, 一定要走向兜底路径, 而绝非一直无休止地死等。

假设三:「AI返回的内容没法缓存,只能实时调。」

这话有一半是对的, 需要进行实时推理的任务, 也就是复杂分析以及多步Agent推理, 确实并不适宜简单缓存, 然而大量AI API调用所处理的却是高度重复的内容, 像FAQ客服回答、文档摘要、代码审查建议以及常规翻译。

在这些场景当中, 语义缓存能够将重复调用所产生的命中率提升至40%更多。当请求到来之时, 首先应计算向量相似度结果如下, 若命中缓存便直接进行返回如此这般, 要是未命中就要再次调用API这般操作。仅仅一个简单的缓存层而已, 便能够阻挡住将近一半的外部依赖风险了。

一个能撑住的架构长什么样

不画大图,核心就三层。

第一层:多供应商路由。

你所拥有的Agent, 不应当仅仅知晓一个模型的名称, 它需要面对的是一个模型池, 这个模型池当中, 至少存在两条源自不同供应商的链路, 举例来说, 像是Claude以及GPT , 又或者再增添一个Gemini , 路由层会依据当前的可用性、延迟、成本、任务类型来进行动态选路。

Claude出现故障不能正常运行了, 流量顺势自动切换至GPT。GPT实施了流量限制, 于是又切换到Gemini。路由进行切换的时间精准把控在毫秒这个级别, 用户所发起的请求不会因此而中断。

然而, 此处存在一个关键的细节, 不同模型的 API 格式并非相同, Claude 采用的是 Anthropic 的格式, GPT 运用的是 OpenAI 的格式, Gemini 使用的是 Google 的格式, 你并不希望在每一个业务代码里面书写三套适配逻辑, 所以, 需要——。

第二层:协议适配层。

于路由层的下方, 添加一层统一的协议转换, 业务侧仅仅认可一种标准格式, 此格式最简单的情形是OpenAI兼容格式, 而适配层会负责将标准请求翻译成为各个供应商的原生格式, 之后再把不同供应商返回的原生格式翻译回标准格式。

最容易被低估的是这个适配层, 草率去做, 会丢掉Claude的原生长下文解析能力, 或者会丢掉Gemini的多模态分块, 正确的策略是, 核心参数进行标准化映射, 特殊能力进行透传, Claude能处理20万token上下文, GPT只能处理12.8万, 在这种情况之前, 路由层在请求到达时就该判断, 超长上下文请求直接不通过短上下文供应商。

第三层:降级与缓存。

这层存在着所有的兜底逻辑。要是多供应商都出现挂掉的情况该如何处理? 不可以返回一个冰冷的500错误。降级路径至少存在三种:

将其置于三层架之上, 倘若Claude出现崩溃状况, 即便Claude崩溃了才致使你的系统随之崩溃, 然而用户在你这里甚至全然无法察觉Claude的崩溃, 你的系统也会跟着崩溃。

架构师的价值不在堆功能,在兜底

写这篇文章的时候,我想起一件事。

去年, 有一个团队, 做出了一个AI面试官产品, 其Demo运行得极其令人惊艳。上线首日, GPT进行区域性限流, 致使整个产品白屏了一个下午。期间, HR部门打了十几个电话, 而且技术总监在群里发了三条消息, 这三条消息全部都是问号。

上线前一周, 产品的全部精力, 都用在了调整prompt, 优化效果, 打磨交互上。没有一个人问过这样一句: 「要是GPT挂掉了该如何是好? 」。

这不单单是某个团队所出现的疏忽, 更为确切滴说, 这是整个行业于AI狂热阶段系统性遗漏的一个问题, 在那段时期内, 大家都在忙着去验证AI究竟具备怎样的功能, 却并没有任何人会去思考, 当AI无法完成指定任务之时, 到底应该拿什么办法去应对, 此情况持续存在着。

架构师该做的事,恰恰是后者。

2026年, 只要有一个依赖AI API的应用增加, 就会有一个系统可能因AI宕机而崩溃。并且, 这些系统的用户, 不会去在意到底是哪家的API出现了问题。他们仅仅清楚, 你的产品无法打开了。

架构师最终的护城河, 并非比旁人更擅长去调整prompt, 并非比他人更通晓模型参数。而是在所有人都朝着同一个方向迅猛奔跑之际, 你伫立在后方问道:

「万一它崩了,我们怎么兜?」

然后把答案写进了架构里。

标签: AI服务 架构失误 单点依赖 容错机制 降级策略

发布评论 0条评论)

还木有评论哦,快来抢沙发吧~