AI 大模型故障：宕机时 Gemini 为什么独善其身：自有 TPU 集群、不依赖共享基础设施

一、引子：三次宕机潮与一个反常识的观察

2024 年 7 月，某全球性云服务商的 DNS 与边缘网络出现区域性异常，大量依赖其托管服务的 AI 应用在数小时内无法访问。据多家技术媒体当日的公开报道，受影响产品横跨客服机器人、代码助手、文档问答等多个品类，故障根因并不在模型本身，而在模型调用链路上的共享网络组件（来源：CrowdStrike 事件后多家媒体的故障复盘报道，2024）。

2025 年初，另一家头部模型厂商的推理网关在流量高峰出现排队雪崩，API 返回大量 429 与 503，第三方监控平台 Downdetector 上相关投诉曲线在 40 分钟内陡增（来源：Downdetector 公开投诉数据，2025，整合数据）。同年，多起“套壳应用”集体失效事件进一步暴露：当底层依赖抖动时，缺乏自建推理能力的产品几乎没有缓冲带。

在这些事件中，一个反常识的观察浮出水面：Gemini 服务在同期的可用性表现显著更稳。它并非没有经历过故障，但很少出现“全球性、长时间、全量不可用”的形态。为什么？

本文评述：把“Gemini 更稳”简单归因于“Google 有钱、机器多”是懒惰的解释。真正的工程差异在于——它的推理请求从进入到返回，绝大部分路径都跑在自己控制的物理域内，跨出了别人必须跨过的那些“共享层”。

要理解这一点，需要先建立一个可操作的分析工具。本文提出“故障隔离域”概念，并以此为主线贯穿全文。

二、核心分析框架：故障隔离域（FID）

2.1 定义

故障隔离域（Fault Isolation Domain, FID）：一个故障在传播过程中，被“边界”阻断、不再向更大范围扩散的最小系统单元。FID 的粒度越细、边界越硬，系统的整体可用性上限越高。

这个概念借鉴了分布式系统中的“故障域（Failure Domain）”与“爆炸半径（Blast Radius）”思想（来源：AWS Well-Architected Framework 可靠性支柱，2023 版），但本文做了关键扩展：传统故障域关注“硬件/机架/可用区”，而 FID 进一步纳入组织边界与商业边界——即“这块基础设施是否由同一主体控制”。

2.2 为什么组织边界也是隔离边界

工程上有一个被低估的事实：跨组织的故障恢复协调成本，远高于组织内部。当你依赖第三方 API 时，故障发生时你既看不到对方的内部指标，也无法推动对方按你的优先级修复，只能被动等待。这在 SRE 领域被称为“可观测性与控制权的双重缺失”。

Google SRE 系列著作中反复强调“你无法修复你看不见的东西”（来源：《Site Reliability Engineering》，O'Reilly，2016；《The Site Reliability Workbook》，2018）。本文评述：这句话在 AI 推理场景下尤其致命，因为大模型推理的故障模式（KV Cache 抖动、批处理排队、显存碎片）比传统 Web 服务更隐蔽，跨组织排查的延迟会被进一步放大。

2.3 FID 的四层模型

本文评述：多数 AI 应用只做到了 L1 的部分隔离（比如多卡冗余），却在 L2 到 L4 完全暴露在共享基础设施之下。这就是为什么“底层一抖，全线皆倒”。

三、硬件底座：TPU 集群为什么天然更“抗抖”

3.1 TPU 的设计哲学：为确定性而生

TPU（Tensor Processing Unit）自 2015 年第一代起，就采用脉动阵列（Systolic Array）架构，专为矩阵乘加密集计算设计（来源：Jouppi et al., "In-Datacenter Performance Analysis of a Tensor Processing Unit", ISCA 2017）。与通用 GPU 相比，TPU 的指令流更简单、行为更可预测。

本文评述：可预测性本身就是一种可用性资产。GPU 的抢占式调度、多租户共享、驱动层复杂交互，都会引入难以建模的抖动源；而 TPU 从设计上就假设“整机整集群服务于确定性负载”，抖动源更少，故障模式更收敛。

3.2 自控带来的三个工程红利

1. 固件与驱动可控：不需要等待第三方驱动更新，可针对推理负载定制。
2. 故障注入可闭环：可以在生产集群上做受控的混沌工程实验，而不必担心影响其他租户。
3. 容量规划可预测：自有集群的扩容节奏与模型迭代节奏对齐，避免“租不到卡”的供给冲击。

据 Google 公开的技术博客，其数据中心内的 TPU 集群采用自研液冷与自研网络，整机架级别的部署密度高于通用云区域（来源：Google Cloud Blog 关于 TPU v5e/v5p 的技术说明，2023–2024）。这意味着单位面积内的算力供给更集中，调度器可用的“整块资源”更多。

3.3 与“租用 GPU”的对照

需要说明：上表为本文基于公开资料与工程经验的定性整合对比，非实测数据，读者应结合自身场景验证。

四、互联拓扑：ICI 与 OCS 如何切断级联故障

4.1 ICI：芯片间的高速专用通道

TPU 之间通过 ICI（Inter-Chip Interconnect）互联，形成 2D/3D Torus 拓扑。据公开论文，TPU v4 的 ICI 带宽可达数百 GB/s 量级（来源：Jouppi et al., "TPU v4: An Optically Reconfigurable Supercomputer for Machine Learning with Hardware Support for Embeddings", ISCA 2023）。

本文评述：专用互联的价值不只是快，更是“故障不共享”。当推理流量走专用 ICI 而非通用以太网时，它就不会被同一数据中心内其他业务的流量洪峰波及。这是 FID 在 L2 层的关键体现。

4.2 OCS：光路交换带来的拓扑可重构性

TPU v4 引入 OCS（Optical Circuit Switch），可在运行时动态重构芯片间的光路连接（来源：同上 ISCA 2023 论文）。这意味着当某个链路或节点出现异常时，调度系统可以在物理拓扑层面绕开故障，而不是仅靠软件重试。

本文评述：软件层的重试只能应对“瞬时错误”，而 OCS 提供的是“物理层绕行”。两者是不同量级的韧性手段。多数共享云环境里，租户根本无法触达这一层。

4.3 拓扑感知调度的操作要点

如果你的团队正在自建或半自建推理集群，以下步骤可直接落地：

1. 采集拓扑信息：把机架、交换机、链路带宽写入调度器的资源画像。
2. 定义亲和/反亲和规则：同一推理副本尽量分散到不同机架。
3. 设置链路健康探针：对 ICI/高速链路做秒级探测，异常即触发重调度。
4. 预留“热备拓扑位”：保留一部分空闲链路用于故障时的快速重构。

延伸阅读：Kubernetes 拓扑感知调度官方文档 Topology Spread Constraints，可作为自建集群的起点。

五、软件栈：从 XLA 编译到推理网关的隔离设计

5.1 XLA：把不确定性编译掉

XLA（Accelerated Linear Algebra）是 Google 的编译器栈，可把模型图编译为针对 TPU 优化的可执行代码（来源：TensorFlow XLA 官方文档；OpenXLA 项目，2023）。编译期确定内存布局与算子融合，减少了运行时的动态决策。

本文评述：运行时动态决策越少，抖动源越少。这与传统 Web 服务“动态扩缩容”的思路相反，但在推理场景下，确定性往往比弹性更值钱。

5.2 推理网关的三道闸门

一个健壮的推理网关应至少包含：

请求 → [准入控制] → [队列与批处理] → [副本路由] → TPU 执行
              │              │              │
          限流/鉴权      优先级分级      健康检查+熔断
              │              │              │
          拒绝恶意流量   防止雪崩       隔离坏副本

本文评述：这三道闸门对应 FID 的 L3 层。很多团队只做了第一道（限流），却忽略了队列优先级与副本级熔断，导致一个慢副本拖垮整个服务。

5.3 批处理策略的取舍

连续批处理（Continuous Batching）能显著提升吞吐，但会引入排队延迟。据 vLLM 团队的公开论文，连续批处理可将吞吐提升数倍（来源：Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention", SOSP 2023）。

本文评述：吞吐与韧性存在张力。高吞吐配置在故障时更容易雪崩，因为队列积压更快。建议对关键流量保留一条“低延迟、低批处理”的专用通道。

六、对照实验：共享基础设施的故障传导链

6.1 一条典型的传导链

以一个“套壳”AI 应用为例，其调用链通常为：

用户 → CDN → 应用服务器 → 第三方模型 API → 共享 GPU 云
         │         │              │              │
      共享边缘   共享主机      共享网关       多租户 GPU

这条链路上有四个共享层，任何一层抖动都会向上传导。据 Uptime Institute 的年度报告，2023–2024 年数据中心重大故障中，相当比例源于网络与第三方依赖（来源：Uptime Institute Annual Outage Analysis，2023、2024）。

6.2 模拟数据：传导延迟的放大效应

下表为本文基于排队论模型的模拟数据（M/M/1 近似，参数为假设值），用于说明共享层数量对尾部延迟的影响：

本文评述：尾部延迟的放大是超线性的。这意味着每减少一个共享层，收益都远超直觉。Gemini 的架构本质上把共享层数压到了最低。

七、多级降级：Gemini 的“优雅退化”路径拆解

7.1 降级不是失败，是设计

据 Google 公开的模型卡与服务说明，Gemini 提供多个规格（Ultra/Pro/Flash/Nano 等），不同规格对应不同算力档位（来源：Google DeepMind Gemini 模型卡，2024）。这为降级提供了天然的“档位”。

本文评述：多规格模型本身就是一套内置的降级矩阵。当高端算力紧张时，可把部分流量导向小规格模型，保证“有响应”优于“无响应”。

7.2 四级降级路径

本文评述：降级路径必须提前设计、提前演练，而不是故障时临时拍脑袋。建议每季度做一次“降级演练”，验证每一级的切换是否平滑。

八、工程落地：自建推理底座的 7 步操作清单

以下步骤面向有一定规模的团队，目标是把关键推理链路的 FID 收敛到自控范围。

Step 1：盘点依赖，画出共享层地图

列出从用户到模型执行的每一跳，标注“自控/第三方”。工具推荐：OpenTelemetry 做链路追踪（官方文档）。

Step 2：定义关键路径与非关键路径

把“必须可用”的能力（如核心问答）与“可降级”的能力（如富文本渲染）分开。

Step 3：为关键路径建立专用资源池

哪怕规模不大，也应给核心流量预留独立副本，避免与实验流量混跑。

Step 4：引入副本级熔断与健康检查

参考 Envoy 的 outlier detection 机制（Envoy 文档），自动摘除异常副本。

Step 5：设计降级矩阵并编码

把第七节的四级降级写成配置，纳入 CI/CD 流程。

Step 6：做混沌工程演练

工具推荐：Chaos Mesh（官方文档），可模拟网络分区、Pod 故障等。

Step 7：建立 FID 指标看板

持续度量隔离域粒度，见下一节。

九、量化评估：如何度量你的故障隔离域

9.1 三个核心指标

本文评述：这三个指标简单但有效。建议纳入 SRE 的季度评审，与可用性目标挂钩。

9.2 一个可复用的评估脚本思路

# 伪代码：计算关键路径的共享层数
def compute_sln(trace):
    shared = 0
    for span in trace.spans:
        if span.owner != "self":
            shared += 1
    return shared

# 目标：对每条关键路径，SLN 尽可能小

十、前沿预判：推理底座的“主权化”趋势

10.1 从“租算力”到“控底座”

据多家分析机构的公开报告，2024–2025 年企业对自建或专属推理集群的兴趣显著上升（来源：Gartner 关于 AI 基础设施的公开分析，2024；IDC 相关报告，2024）。驱动因素包括成本、合规与本文强调的可用性。

本文评述：“推理主权”正在成为与“数据主权”并列的议题。谁控制了推理底座，谁就控制了服务的可用性上限。

10.2 三个可能的技术方向

1. 专用推理芯片的普及：类似 TPU 的专用加速器会更多，通用 GPU 的份额可能被侵蚀。
2. 光互联下沉：OCS 类技术可能从超算走向中型集群。
3. FID 即服务：出现专门帮助团队度量与优化故障隔离域的工具链。

延伸视频：Google Cloud 关于 TPU 架构的公开讲解可在其官方 YouTube 频道检索“TPU architecture”获取。

十一、结论与行动建议

回到开头的问题：Gemini 为什么能在宕机潮中独善其身？本文的答案是——它把故障隔离域收敛到了自控物理域。自有 TPU 集群、专用互联、自研编译与调度栈、多规格降级矩阵，共同构成了一道别人难以复制的韧性护城河。

对多数团队而言，完全复制不现实，但可以借鉴其思路：减少共享层、细化隔离粒度、预置降级路径。这三件事，今天就能开始做。

十二、主要参考文献