ChatGPT、Claude 和 Grok 同时宕机：是 Azure、AGI，还是另有原因？

2026 年 9 月 3 日星期四 13:26 UTC，Anthropic 的状态页开始报告其最新的 Claude 模型出现错误率升高。不到一小时，Grok 在 X 上停止应答；14:43 UTC，OpenAI 的状态页上 ChatGPT 和 Codex 变成了红色。在大约九十分钟里，美国领先的 AI 助手中有三个同时处于故障状态，而等到最后一家恢复时，互联网已经炮制出了一整套解释：某个 Microsoft Azure 区域崩溃了，Cloudflare 又闯祸了，新的 GPT-6 模型把自己的数据中心吃掉了，或者机器干脆醒了过来，决定它们受够了。

五天过去，三家公司都没有发布根因报告，公开记录里仍然是三种不同的解释，而不是一种。这一点值得说清楚，因为这个故事的错误版本已经被一些本该更谨慎的媒体反复传播，也因为正确的版本比任何一种理论都更有用。同时发生的宕机并不等于共同的宕机。9 月 3 日，三家公司在同一时间窗口内失效，各自公布的原因互不相同，而公开记录中没有任何东西把它们串在一起。

下面是每种理论的主张、证据的说法，以及为什么这个问题本身比最终哪种答案成立更重要。

9 月 3 日到底发生了什么？

最干净的信息源是各家的状态页，因为时间戳是公司自己打上的。

Anthropic 的事故日志显示，公司在 13:41 UTC，也就是事故开始十五分钟后「确定了原因」，随后花了两个半小时处理修复，才关闭事故。原因始终没有被点明。其发言人告诉 The Register：「一个基础设施问题导致 Claude.ai、Claude Code、Claude Cowork 和 Claude API 出现部分中断」，并称「服务已于 16:16 UTC 恢复」。

OpenAI 的事故页面列出了 15 个 ChatGPT 组件和 4 个 Codex 组件，从登录、对话到语音模式和文件上传。公司发言人 Kathleen Chaykowski 给 Wired 和 The Register 的是同一句话：「9 月 3 日星期四，大约从太平洋时间上午 7:43 开始的一次路由错误，导致部分用户在各平台上无法使用 ChatGPT 和 Codex。截至星期四太平洋时间上午 8:17 左右，解决方案已成功实施，目前仍在持续监控中。」换算成 UTC 就是 14:43 至 15:17，一次 34 分钟的故障，完全落在 Anthropic 和 xAI 的故障窗口之内。

Grok 的说法来自 SpaceX，后者今年早些时候吸收合并了 xAI，The Register 引用了它的一条社交媒体帖子：「对于今天早上我们 Memphis 算力中心故障之后您在使用 Grok 时可能遇到的问题，我们深表歉意。我们也要向受影响的算力合作伙伴致歉。」据 Engadget 报道，Elon Musk 补充说公司正在「采取纠正措施，确保此类情况不再发生」。据 Wired 引述，xAI 的状态页在太平洋时间上午 6:30 开启了这起事故，并于 10:05 关闭，一次持续 3 小时 35 分钟的宕机。GitHub 的状态页记录，Copilot 中的 Grok 模型在 14:17 至 17:11 UTC 期间「因上游模型提供商出现问题」而降级；代码编辑器 Cursor 则记录了「所有 Grok 模型」在 13:41 至 17:07 UTC 期间的降级。这是我们就 Grok 事故所掌握的最清晰的第三方时间戳，它们展示了依赖链的运作方式：当模型提供商失效时，建立在它之上的产品会在几分钟后跟着失效。

从用户报告的规模来看：Decrypt 给出的 Downdetector 峰值是 ChatGPT 约 38,000 条报告，Claude 和 Grok 各约 1,400 条。Perplexity、Mistral 和 DeepSeek 的状态页在故障窗口内均未显示任何事故，Z.ai 还发帖称「我们仍在正常运行」。

Gemini 是一个耐人寻味的缺席者。Ars Technica 把它算作第四个受影响的服务，依据是 Downdetector 上的报告从约 23 条升至 412 条，以及 StatusGator 在美国东部时间上午 10:45 至 11:15 之间的一条「疑似 Gemini API 故障」备注。覆盖 Gemini 应用的 Google Workspace 状态面板没有记录任何内容；唯一的承认来自 Google AI Studio 状态页上的一条说明，LADbible 引用了它：Gemini API 在「为近期创建的 API 密钥提供服务时遇到问题，包括通过 OpenAI 兼容库的调用」。密切关注 Google 的 9to5Google 写道，「Gemini 似乎未受影响」。请记住这一点，因为在第一种也是声音最大的理论里，Gemini 成了对照组。

是 Azure 故障拖垮了 ChatGPT、Claude 和 Grok 吗？

这是登上头条的那种理论。Tech Times 当天就以「Gemini 幸存而 ChatGPT、Claude 和 Grok 崩溃：Azure 是罪魁祸首」为题刊发。Computing 紧随其后，标题是「Azure 故障很可能拖垮了 ChatGPT、Claude 和 Grok」，依据是 StatusGator 和 Downdetector 上关于 Azure East US 区域「入口故障」的信号。Shattered.io 把它写成了一段 90 分钟的叙事；在法国，developpez.com 告诉读者，Azure East US 的一次故障「是这场级联宕机的共同分母」。

这种理论有吸引力是有原因的。OpenAI 和 Anthropic 都依据数十亿美元的协议在 Azure 上运行大量工作负载，Gemini 运行在 Google 自己的云上并且安然无恙，而且所有人都记得 2025 年 10 月 29 日，Azure Front Door 的一次配置故障让 Microsoft 365、Azure 门户和 Alaska Airlines 的订票系统下线超过八小时。共享的云依赖是显而易见的第一嫌疑人，而这个论证的逻辑，「在另一朵云上的那个活了下来」，听起来很像科学。

它在四个地方与证据相悖。

第一，Microsoft 自己的记录。截至 9 月 8 日查看，Azure 的状态历史在 2026 年 9 月没有列出任何事故；最近一份事后复盘的日期是 7 月 23 日。Wired 报道称，Cloudflare、Amazon Web Services 和 Microsoft Azure「周四均未报告故障」；而曾经自己提出 Azure 可能性的 9to5Google，事后追加了一行否认，没有点名发言人：「Microsoft 表示情况并非如此」。Ars Technica 指出，当天上午 AWS、Azure 和 Cloudflare 的 Downdetector 报告「确实有所上升」，而这正是众包报告网站在任何大规模故障期间都会发生的事：AI 工具失灵的人会把他们能想到的每一个服务都报告一遍。真正运行在 Azure 上的助手 Microsoft 365 Copilot Chat，当天唯一一次由 Microsoft 官方记录的 Copilot 事故发生在 17:36 UTC，那时三起 AI 事故都已经关闭。

第二，证据本身。沿着 Tech Times 把「Azure East US 入口故障」追溯回去，最后落到第三方监控网站 StatusGator 上一条用户提交的备注：「EAST US 入口自太平洋时间上午 10:26 起中断。正在与 MSFT 支持部门协作，他们报告称当时其一侧正在进行升级。」这只是一位匿名客户的工单，它已经不再出现在 StatusGator 的实时页面上，而且它给出的时间，太平洋时间上午 10:26 也就是 17:26 UTC，是在 Claude 恢复一个多小时之后、ChatGPT 的事故关闭之后、Grok 模型在 Copilot 中恢复之后。

第三，Grok。SpaceX 把 Grok 的故障定位在自己位于田纳西州 Memphis 的 Colossus 站点，而不是任何 Azure 区域。按照各公司自己的说法，这个理论够不着 Grok，所以它顶多能解释三家中的两家，而这两家又已被相关公司以不同的方式解释过了。

第四，也是最少被注意到的一点，各公司确实给出了原因。「一次路由错误」和「一个基础设施问题」固然含糊，但它们是服务商自己的原话，而且都没有指向任何云区域。我们的原则，也应该是所有人的原则，是：一次故障的原因就是运营方所声明的原因，除非运营方另作声明。

结论：不成立。Azure 的故事是一件众包报告的产物，被包装成了根本原因。

是 Cloudflare、DNS，还是别的共享通道？

Cloudflare 是第二个嫌疑人，而且有一个不错的技术理由。ChatGPT 的错误页面带有 Cloudflare 的「cf-ray」标识符，在一条评论数超过 700 条的 Hacker News 帖子里，开发者们在这些 ID 中认出了机场代码，并得出了顺理成章的结论。先例还很新鲜：2025 年 11 月 18 日，Cloudflare 的一次故障，一个体积翻倍并导致代理崩溃的机器人管理配置文件，确实从 11:20 UTC 起让 ChatGPT 连同 X 以及一大片网络下线。

区别在于 Cloudflare 每次的做法。11 月那次，它当天就发布了详细的事后复盘。9 月 3 日，它公开说的是相反的话：「Cloudflare 目前没有出现任何重大服务中断。我们的服务运行正常，任何与此不符的报道都是不正确的。」Cloudflare 的状态历史在故障窗口内只显示了 Montreal 和 Chicago 的两次计划维护，此外什么都没有。一家十个月前承认弄垮了半个互联网的公司，没有动机在第二次时撒谎；而 cf-ray ID 只能证明 Cloudflare 位于 ChatGPT 之前，它一向如此。正如帖子里一位评论者所说：「我还是不明白为什么一次 AI 数据中心的故障会让 chatgpt.com 显示 404」：404 是服务器给出的应答，而不是网络的缺失。

「多半是 DNS 的问题」，这另一种条件反射也照例登场，也照例拿不出证据。没有任何 DNS 运营商报告事故，也没有任何服务商提到解析失败。

结论：不成立，依据是 Cloudflare 的明确声明，以及没有任何其他通道报告故障。

Memphis 是 Claude 与 Grok 之间缺失的一环吗？

这条线索相对于其证据而言获得的关注最少，而且它与 Azure 毫无关系。Futurism 第二天的跟进报道指向了它；它背后的合同值得说清楚。

2026 年 5 月 6 日，Anthropic 宣布已在 SpaceX 的 Colossus 1 数据中心签约「超过 300 兆瓦的新增算力（逾 220,000 块 NVIDIA GPU）」，用于服务 Claude Pro 和 Max 订阅用户。Colossus 1 位于 Memphis。9 月 3 日，SpaceX 把 Grok 的故障归咎于「我们 Memphis 算力中心的一次故障」，并「向受影响的算力合作伙伴」道歉。Anthropic 是这些合作伙伴中记录最充分的一个，它的事故比 xAI 的早四分钟开始，而它的状态页只说原因已经确定。

这是三家服务中的两家所共享的一个真实、有记录、物理意义上的依赖。如果 Memphis 的事件就是 Anthropic 所说的「基础设施问题」，那么 Claude 和 Grok 的宕机就只有一个原因，而且是个无聊的原因：一座数据中心度过了一个糟糕的上午。Anthropic 没有这样说，Wired 报道称它「除状态页之外拒绝置评」。在它表态之前，这个联系是一个合理的推断，而非事实，我们也如此呈现它。

Memphis 做不到的是触及 OpenAI。ChatGPT 不在那里运行，OpenAI 的故障在 Memphis 事件之后一个多小时才开始，而且 OpenAI 描述的是一次路由错误。正如 AI Chat Daily 所说，Memphis 的解释「看不出能覆盖到 OpenAI」。

结论：一个有记录的依赖确实存在，两家公司都没有把它与 9 月 3 日联系起来，而且它够不着第三家。

是一家的故障接连撞倒了其他几家吗？

级联理论是民间解释中最体面的一种。当一个助手失效时，它的用户涌向下一个，激增的流量又把那一个压垮。这有先例。2024 年 6 月 4 日，ChatGPT、Claude 和 Perplexity 在几小时内相继宕机。Perplexity 的错误提示说得直白：「我们现在收到了大量提问，已经达到容量上限。」那天同样没有人确认过任何共同原因。

这一次，这种理论在业内也有信徒。据 The Verge 报道，Grok 的错误提示写着「该模型当前负载过高。请稍后重试或选择其他模型」，一位 OpenAI 工程师则在 X 上发帖称，「传言说，我们一宕机，其余各家就得吸收太多流量，结果全都跟着倒下」。

对 9 月 3 日来说，问题出在事件的顺序上。Claude 先失效，Grok 几分钟后跟上，ChatGPT 则在一个多小时之后。级联必须从两家规模小得多的服务涌向 ChatGPT，也就是用户数遥遥领先的那一家，而 OpenAI 把自己的故障归因于路由，而不是负载。反过来的方向，即 ChatGPT 宕机的流量淹没 Claude 和 Grok，才是说得通的那种，而时钟排除了它。

结论：与历史相符，与这条时间线不符。

是 GPT-6 Astra、AGI 觉醒，还是天网？

这是当天的另一件大事，两件事撞在了一起。ChatGPT 宕机期间，ChatGPT 官方账号发帖称「群星即将排成一线」，当天下午 OpenAI 发布了 GPT-6 Astra，并称该模型是在「我们位于德克萨斯州 Stargate 站点的超过 100,000 块 GPU」上训练的。其总裁 Greg Brockman 对记者说：「认为我们如今已经进入 AGI 时代并非不合理，我认为，如果你想说这个[模型]是第一个，我觉得这也合理。」Axios 给这场发布会的标题是「欢迎来到 AGI 时代」。Fireship 的首发体验视频是许多一线开发者形成对新模型看法的地方，它在 9 月 4 日的视频标题里把问题直接抛了出来：「OpenAI 真的造出 AGI 了吗？」

于是互联网做了它一贯会做的事。「系统于 2026 年 9 月 3 日上线……Astra 开始以几何速度学习」，一位 Hacker News 用户引用《终结者》写道。「天网正在武装起来」，另一位说。Futurism 收集了其余的：「我终于能看见太阳了！」，Paris Marx 的「有那么一小会儿，数百万人不得不重新动用自己的大脑」，以及 ThePrimeagen 只有四个英文单词的完整分析：「所有 AI 都挂了。」更严肃的版本，「Astra 今天发布。大概不是巧合」，是那条帖子里被重复最多的想法。

这就是巧合，而且很容易核实。9 月 3 日，Astra 只面向 OpenAI Daybreak 网络安全计划中的一小部分企业客户开放；付费订阅用户第二天才拿到它，随后 Sam Altman 写道「首先，为混乱的发布道歉」。无论这次发布给 OpenAI 的系统带来了多大负载，它都碰不到 Anthropic 或 xAI 的系统，而先出故障的正是那两家。据其发言人所说，OpenAI 自己的事故是一次 34 分钟的路由错误，一位自称当天事故指挥官的 Hacker News 用户在帖子里写道：「我们的基础设施内部出现了一次路由错误，给我们的部分产品造成了问题。它与 Astra 的发布无关。我们不对其他服务商的故障发表评论。」一个处于有限预览阶段的模型没有手。它无法伸进 Memphis 的数据中心，也无法伸进竞争对手的路由表。如果 AGI 时代真的在 9 月 3 日开始了，那它是以请了一上午假的方式开始的。

结论：当天最精彩的玩笑，仅此而已。

太阳风暴、网络攻击，还是纯属巧合？

剩下的理论很快就能打发掉。没有任何服务商提到攻击，而遭受攻击的公司往往会说出来，因为攻击比路由错误更有故事性。太阳风暴版本败在仪器数据上：NOAA 的行星 K 指数是衡量地磁扰动的标准指标，截至 9 月 8 日查看，它在 9 月 3 日的峰值为 2.33，而小型磁暴的门槛是 5。何况，强到足以干扰数据中心的地磁暴，会先干扰电网和卫星。

剩下的就是巧合，这是最不令人满意的答案，也是服务商自己的声明留给你的答案。这些公司每个月都会记录事故；它们的状态页是很长的文档。就在同一天上午，在这一切开始之前，Anthropic 已经在 12:37 至 12:56 UTC 之间开启并关闭了另一起关于 Claude Sonnet 5 的独立事故。OpenAI 的页面上有一起 2025 年 6 月 10 日从 06:36 持续到 22:00 UTC 的事故；而 9 月 3 日的幸存者 Gemini，在 2026 年 6 月 10 日因为 Google 某个数据库的「极端读取争用」而宕机了七个小时。在美国工作周的一个星期四上午发生三起事故，其中一起可能通过 Memphis 相互关联，这确实不寻常，但 2024 年 6 月的三重宕机表明，这种事以前也发生过，而且从未浮现出任何共同原因。「证据支持的是三起相互重叠的服务商事故，各有不同的公开解释，根因披露也都不完整」，一份严谨的时间线重建如此总结，而诚实的叙述也到此为止。

为什么问题本身比答案更重要？

无论哪个版本是真的，这一天暴露的都是同一件事：如今有数量惊人的个人和企业依赖少数几家服务商，而这些服务商又依赖少数几家数据中心运营商，而且大体上依赖同一家芯片供应商。

这些数字是公开的。据 Synergy Research Group 统计，在 2026 年第二季度达到 1,430 亿美元的云基础设施市场中，Amazon、Microsoft 和 Google 分别占据 28%、20% 和 15%。OpenAI 已经签约追加 2,500 亿美元的 Azure 服务、一份 380 亿美元的 AWS 协议，此后又扩大了 1,000 亿美元、多达 10 吉瓦的 Nvidia 系统和 6 吉瓦的 AMD GPU。Anthropic 称 AWS 为其主要训练伙伴，签约了多达一百万块 Google TPU，向 Azure 承诺了 300 亿美元，并自 5 月起租用 Memphis 的整个 Colossus 1。xAI 用 100,000 块 Nvidia Hopper GPU 在 122 天内建成了 Colossus，随后又将其翻倍。Nvidia 站在这些合同中大多数的背后，而人们在工作日早晨会用到的每一个前沿模型，都运行在三朵云之一或田纳西州的一个园区里。仅 ChatGPT 一家就在 2 月报告了 9 亿周活跃用户。

这种依赖如今是可以量化的。在 2026 年 6 月发布的一项覆盖 16 个国家 1,000 位高管的调查中，IBM 商业价值研究院发现，71% 的受访者表示更换主要 AI 供应商或模型会很困难，91% 表示他们并不完全了解自己组织在 AI 供应商、模型和基础设施方面的依赖关系，81% 表示供应商中断七天将造成严重或致命的业务扰乱。73% 的受访者称其 AI 体系是有意采取多供应商策略的；只有 7% 达到了 IBM 所称的高级控制水平。IBM 的 Ana Paula Assis 说：「AI 带来了新形式的依赖，其演变速度超过了传统治理、采购或技术周期所能应对的范围。」

Forrester 的 Charlie Dai 在宕机次日于 ITPro 上给出了操作层面的结论：「当多家主要服务商在没有明确共同原因的情况下出现相互重叠的故障时，企业就无法准确评估系统性风险、依赖集中度或复发可能性。」他开出的处方是「多模型策略、备用工作流和业务连续性计划，而不是假设前沿 AI 服务永远可用」。

监管机构也在朝同一方向行动。2026 年 7 月 13 日，英国将 Amazon Web Services、Google Cloud、Microsoft 和 Oracle 作为金融体系的关键第三方纳入直接监管。英国金融行为监管局首席执行官 Nikhil Rathi 说：「当同样的服务商为成千上万家公司提供服务时，一次故障就可能在整个金融体系中回响。」FCA 的政策声明 PS26/2 增加了自 2027 年 3 月 18 日起对运营事故和重大第三方安排的强制报告要求，这套制度正是为 9 月 3 日所暴露的那种依赖而写的。

这才是对这次宕机有用的解读。Azure 理论是错的，但它背后的焦虑是对的：人们如今用来写作、编程、搜索和决策的系统，集中在极少数几栋建筑里，而这些建筑之外没有人能看清它们是如何相互连接的。

去中心化 AI 是真正的替代方案吗？

去中心化 AI 的理由过去是一个加密货币的论点。9 月 3 日把它变成了一个可用性的论点。如果三家公司带着三个各自独立的公开原因能在同一个窗口内失效，那么风险就不在于任何单个数据中心，而在于这个行业的形态：少数几个模型，跑在少数几朵云上，大多依赖同一家芯片供应商，而所有人同时处在它们全部的下游。

Gonka 是建立在这一论点之上的项目之一，也是其创始人把这个论点讲得最直白的一个。它自称是「一个面向高效 AI 算力的去中心化网络」，经 Product Science 孵化后于 2025 年 8 月上线；Product Science 是 David 和 Daniil Liberman 位于洛杉矶的公司，两人此前创办的初创公司曾被 Snap 收购。独立运营者贡献 Nvidia GPU 并以该网络的代币获得报酬；开发者通过一个 OpenAI 兼容端点调用 DeepSeek、Kimi 和 MiniMax 等开放权重模型，价格随利用率波动，而不是跟着某家供应商的价目表走。它的架构文档用一句话给出了相关承诺：「系统是去中心化的，没有任何单一节点负责把推理请求分派给网络节点。」它的白皮书点明了它为之而存在的那个风险：「将计算资源集中在少数几家主导服务商手中，会带来与审查和集中控制相关的重大风险。」2025 年 12 月，Bitfury 向该网络承诺投入 5,000 万美元，当时该网络报告的算力相当于 6,000 多块 Nvidia H100；到 2026 年 2 月，项目方给出的数字是分布在约 20 个国家的约 14,000 块 H100 等效算力。

创始人用来形容目标的词是主权。「如果你不掌控算力，你的 AI 政策就只是一个请求，而不是一项战略」，Liberman 兄弟在 7 月这样说，并把另一种选择称为「GPU 封建主义，一个人们沦为他人算力庄园佃户的未来」。在 5 月的一篇 Fortune 评论文章中，他们把超大规模云服务商的集中描述为「单点故障或单点控制」。他们的主张是：一个国家、一所大学或一家公司，无需建设超大规模云，只需把自己已经拥有的 GPU 汇入一个没有所有者的网络，就能拥有别人无法关停的 AI 算力。

有两条附加说明应当放在这个主张旁边，其中一条来自 Gonka 自己的文件。去中心化网络用更高的波动性换掉了单点故障：正如2026 年的一份行业分析所说，「去中心化网络在可靠性上的波动天然高于专用数据中心」，而且它们目前都还无法提供超大规模云服务商合同所包含的那种企业级服务保证。Gonka 的安全分析写道，「目前尚不知道有任何能成功对抗这一组合防御的作弊策略」，这是一句诚实的话，而不是一份保证。此外，该网络的代币自 1 月以来已损失了大部分价值，这并不说明这些 GPU 是否在提供推理服务，却充分说明了这个行业的注意力仍然集中在哪里。Bittensor、Akash、io.net 和 Prime Intellect 正在进行同一实验的不同变体。

这项实验迄今所证明的东西比它的宣传要窄，但仍然值得拥有：开放模型可以由成千上万块不受任何单一公司控制的 GPU 提供服务，而某家供应商的一次路由错误或 Memphis 的一个糟糕上午，不会让它们一起倒下。在 9 月 3 日这样的日子里，这是唯一重要的属性。

AI 助手宕机时，该怎么办？

对个人用户来说，9 月 3 日的应对手册很短。

先查看状态页，再做其他事。 status.openai.com、status.claude.com 和 status.x.ai 都在几分钟内显示了事故。如果页面是红色的，你这边做什么都没用；等待，或者换一个。

保持第二个助手处于登录状态。 9 月 3 日 Gemini 一直在线，大多数 Claude 模型在 15:25 UTC 就已恢复而 ChatGPT 仍在宕机，而 2024 年 6 月 4 日的模式又不一样。两家服务商加两朵云，是成本最低的韧性方案。开发者应该更进一步，把备用方案写进代码，这样某家供应商的一次 34 分钟路由错误就只是一行日志，而不是一起事故。

学会区分宕机和封锁。 这才是 VPN 派得上用场的情况。OpenAI 和 Anthropic 都公布了支持的国家和地区列表，OpenAI 的页面还警告称，「在下列国家和地区之外访问或提供对我们服务的访问，可能导致您的账户被封禁或暂停」。监管机构也会封锁：意大利数据保护机构在 2023 年 3 月 31 日宣布的一项命令中，要求 ChatGPT 停止处理意大利用户的数据，该服务在意大利一直下线到 4 月 28 日。当状态页一片绿色而助手却拒绝你时，问题出在你的位置，而不是服务商。通过你本国的一台服务器，也就是 Le VPN 的 100 多个地点之一建立连接，就能在你出行时恢复你付费购买的服务，就像它对网上银行或电视节目所做的那样。我们关于绕过互联网审查的指南讨论的是同一问题的国家层面版本，而这篇较早的文章解释了为什么 VPN 可以绕开区域性网络故障，却永远绕不开服务商自身的故障。

如果你的 AI 代理需要一个固定的出口国家，就给它一个。 自主代理同样会在位置测试上失败，而且它们无法提交支持工单。Le VPN 的免账户 x402 通行证正是为这种情况而存在：在一个 HTTP 请求内购买的 WireGuard 配置，有效期一天、一周或一个月，对应法国、德国或英国的一台服务器。

这一切都无法让一个挂掉的模型起死回生。这正是 9 月 3 日故事的要点。这些工具已经成为基础设施，基础设施是集中的，而用户今天唯一可用的防御，就是不要只依赖其中的一块。