刚说完可降级，又来一个故障域？

设计 AI 集群时，首先考虑这些问题：

1. GPU 数量够不够？
2. 网络带宽够不够？
3. 交换机是不是无阻塞？
4. RoCE / IB 能不能跑满？
5. NCCL AllReduce 性能怎么样？

这些肯定都没错，但故障域怎么设计也需要考虑。

有人会把故障域理解为传统数据中心里的概念：一台服务器坏了、一个机柜掉电、一台交换机故障，或者一个区域不可用。但在 AI 集群里，故障域远比这个复杂。

因为 AI 任务不是普通 Web 服务：

• 训练里，一个 rank 慢，可能拖住整个 AllReduce。
• 推理里，一个 Decode 副本慢，可能拉高整组服务的 p99。
• RoCE 里，一个 priority 触发 PFC，可能影响同一队列里的所有流。
• 多轨网络里，一条 rail 异常，可能让 NCCL 通信路径不均衡。

所以 AI 集群设计故障域，不只是为了回答“哪台设备坏了”，更是为了回答：

这个故障会影响多少 GPU、多少任务、多少租户、多少 token、多少 step？

故障域不是“故障在哪里”，而是“故障会被放大到哪里”

传统系统里，一个故障的影响范围通常比较直观：一台机器坏了，影响这台机器上的服务；一个 ToR 坏了，影响这个机柜里的服务器；一个存储节点坏了，影响部分数据访问。

但 AI 集群不一样。AI 集群里的很多故障会被同步机制放大。

比如一个 128 卡训练任务，每一步都要做 AllReduce。如果其中一个 rank 网络变慢，其他 127 张 GPU 都要等待。真正的故障点可能只是一张 NIC、一个端口、一个 GPU 或一个 rank，但影响范围却是整个训练任务。

再比如推理任务：

• 某个 Decode 副本网络拥塞；
• KV Cache 迁移变慢；
• Decode 开始等待；
• 一批请求的 TTFT 变高；
• 用户看到 p99 抖动。

故障点可能只是一个 Decode 组或一个 Leaf 出口队列，但影响的是一批在线请求。

所以 AI 集群里的故障域，本质是：

故障影响被同步通信、队列拥塞、调度路径、KV 状态和尾延迟机制放大后的边界。

AI 集群必须设计故障域，是因为局部故障很容易被放大成全局影响。

为什么普通故障域思维不够？

普通业务系统里，一个请求通常只依赖少数服务实例。服务 A 慢了，不一定拖住所有服务；某个副本异常，负载均衡可以绕开；某台机器故障，系统可以通过副本继续服务。

但 AI 训练通常是强耦合的。无论是 64 卡、128 卡还是 1024 卡训练，这些 GPU 都不是各跑各的，而是在每个 step 里频繁执行：

• 梯度同步；
• 参数同步；
• ReduceScatter；
• AllGather；
• AllReduce；
• MoE All-to-All。

这意味着一个局部慢点会被同步点放大。在 AllReduce 里，最快的 GPU 也不能自己往下走，必须等待最慢的 rank。

因此，AI 训练的故障域不能只按设备划分，还要按通信组划分：

• 一个 DP group 影响多少 GPU？
• 一个 TP group 影响多少 GPU？
• 一个 PP stage 影响多少 GPU？
• 一个 NCCL communicator 覆盖多少节点？
• 一条 rail 故障会影响哪些 rank？

AI 训练的故障域不只看物理位置，还要看这些 GPU 在通信逻辑上是否绑定在一起。

第一类故障域：GPU 故障域

AI 集群里最基础的故障域是 GPU。GPU 可能出现：

• Xid 错误；
• ECC 异常；
• 掉卡；
• 显存错误；
• 温度过高；
• 功耗异常；
• 频率异常；
• NVLink 异常。

问题是：一张 GPU 异常到底影响多大？这取决于任务形态。

单卡推理

一张 GPU 异常，可能只影响当前推理副本。调度器可以摘除这个副本，其他副本继续服务。

单机 8 卡推理

如果模型需要 8 卡 TP 才能运行，一张 GPU 异常可能导致整个 8 卡副本不可用。

多机训练

如果这张 GPU 是某个 NCCL communicator 的成员，它异常可能导致整个训练 job 失败。

因此，GPU 故障域不能只按“卡”理解，还要问：

• 这张 GPU 属于哪个任务？
• 是否属于某个 TP group 或 DP group？
• 是否属于某个推理副本？
• 能否只摘除这张卡，还是必须摘除整台服务器？
• 任务是否支持弹性恢复？
• 是否存在可用的 checkpoint？

GPU 故障不是硬件清单问题，它决定的是调度系统能否把坏卡影响限制在最小任务单元内。

第二类故障域：NIC / Rail 故障域

AI 服务器常见设计是 8 GPU、8 NIC、8 rail。很多人以为多轨网络只是为了叠加带宽，这只说对了一半。多轨还有一个重要价值：限制故障影响范围。

如果所有 GPU 通信都压在一张 NIC 上，这张 NIC 一抖，全节点通信都会抖。如果每个 GPU 对应一条 rail，当某条 rail 异常时，理论上可以把影响限制在：

• 对应 GPU；
• 对应 HCA；
• 对应 rail；
• 对应 Leaf 路径；
• 对应 NCCL channel。

当然，前提是系统真正设计了 rail 边界。否则多轨只是多张网卡，运行时仍然可能乱用。

NIC / rail 故障可能表现为：

• 某条 rail 带宽低；
• 某个 HCA error 持续增长；
• 某个端口 PFC pause 异常；
• NCCL 某些 channel 变慢；
• 多轨流量不均；
• 某些 rank 等待。

因此要明确：

• 每条 rail 对应哪些 GPU？
• 每条 rail 接哪个 Leaf？
• 每条 rail 是否具备独立故障边界？
• 一条 rail 故障后能否摘除？
• NCCL 是否能避开故障 HCA？
• 调度器是否感知 rail health？
• 多租户是否共享同一 rail？

多轨网络的成熟度，不只看满血时带宽多高，还要看一条 rail 异常时影响是否可控。

第三类故障域：Leaf 故障域

Leaf 是 AI 网络里的关键故障边界。一台 Leaf 可能连接一组服务器、一个 rack、一条 rail、多个租户、多个训练任务或一批推理副本。

如果 Leaf 故障域设计不好，一台 Leaf 出问题就可能造成很大影响：

• 一台 Leaf down，整排服务器掉一条 rail；
• 某个 Leaf buffer 异常，多个训练任务变慢；
• 某个 Leaf 上 PFC pause 异常，影响同 priority 流量；
• 某个 Leaf 上行拥塞，推理 Decode 组 p99 变差。

Leaf 故障域设计需要回答：

• 每台 Leaf 下挂多少服务器？
• 每台 Leaf 对应哪些 rail？
• 每台服务器的多张 NIC 是否分散到多个 Leaf？
• 一个 Leaf 故障后，每台服务器损失多少带宽？
• 是否会导致某些节点完全失联？
• 是否会导致某个租户整片不可用？
• 是否有 ECMP / 上行冗余？
• Leaf 故障后 NCCL 是否还能降级运行？

理想情况下，Leaf 故障不应该让所有路径同时消失。系统至少应有机会降速运行、摘除部分 rail、迁移推理副本、从 checkpoint 恢复训练任务并限制影响范围。

Leaf 不是普通接入交换机。在 AI 集群里，它经常是 GPU 通信故障域的第一层放大器。

第四类故障域：Spine 故障域

Spine 故障和 Leaf 故障不同。Leaf 故障通常影响某个接入范围，Spine 故障更容易表现为全局容量下降。

在一个由多台 Spine 提供等价上行路径的 Clos 网络里，一台 Spine 故障后网络不一定中断，但可能出现：

• 总上行容量下降；
• ECMP 路径减少；
• 剩余 Spine 压力增加；
• 某些通信阶段更容易发生 Incast；
• 队列更容易升高；
• ECN / PFC 更容易触发；
• step time / p99 开始变差。

这类故障很容易被误判，因为链路仍然连通，任务也还能运行，只是性能开始下降。

因此，Spine 故障域要看：

• 一台 Spine 故障后，收敛比变成多少？
• 训练 AllReduce 性能下降多少？
• 推理 p99 是否受影响？
• 是否出现更多 ECN marked？
• 是否增加 PFC pause 风险？
• ECMP 是否重新均衡？
• 是否有可观测基线可供对比？

Spine 故障最危险的地方不一定是断，而是网络还通，但从无阻塞变成有拥塞，业务开始变慢。

第五类故障域：PFC / QoS 故障域

RoCE 网络里，PFC 故障域必须单独设计。因为 PFC 的影响不是按 IP、Pod 或租户划分的，而是按 priority 生效。

只要多个业务流量共享同一个 PFC priority，它们就可能被一起 pause。例如：

• 租户 A 的训练流量进入 priority 3；
• 租户 B 的推理流量也进入 priority 3；
• 存储流量被错误映射进 priority 3；
• 某个出口队列拥塞触发 PFC；
• 同 priority 的流量全部受到影响。

PFC 故障域的边界不是设备，而是同一个 lossless priority 上承载了哪些业务。

如果设计不好，就会出现：

• 一个租户的 Incast pause 其他租户；
• 一个存储大流误伤 RoCE 训练；
• 一次错误映射让普通流量污染 RDMA 队列；
• pause storm 扩散到多个端口。

RoCE 故障域设计需要明确：

• 哪些流量进入 lossless priority？
• 训练和推理是否共用 priority？
• 热路径和冷路径是否共用 queue？
• CNP 是否独立处理？
• PFC 是否只作为兜底？
• ECN 是否先于 PFC 触发？
• 是否能按 priority 监控 pause？
• 是否能把 pause 影响关联到租户或任务？

PFC 故障域不是按网络拓扑画的，而是按 priority、queue 和 buffer 共享关系画的。

第六类故障域：NCCL 通信组故障域

NCCL 的故障域经常被忽略。很多人只看物理设备：服务器属于哪个 rack、网卡接哪个 Leaf；但 NCCL 看的是通信组，例如：

• 8 卡单机通信组；
• 16 卡跨 2 机通信组；
• 128 卡训练 group；
• 1024 卡大规模 communicator；
• TP group；
• DP group；
• PP stage group。

一个故障影响多大，和它落在哪个通信组高度相关。某张 NIC 变慢，如果只影响一个小通信组，影响可能可控；如果它位于一个 512 卡 AllReduce group，影响就会被放大。某个 rank 出现抖动，也会拖慢所有等待它的 rank。

因此要把 NCCL 拓扑纳入故障域设计：

• 一个 NCCL job 跨多少 Leaf、Spine 和 rack？
• 一个 TP group 是否跨故障域？
• 一个 DP group 是否跨多个电源域？
• 任务调度是否尽量让通信组落在可控范围内？
• 是否具备拓扑感知调度？
• 是否能把 slow rank 定位到物理设备？

NCCL 故障域是逻辑故障域。它不一定和物理 rack、Leaf、VLAN 完全一致，但它决定慢点会影响多少 GPU。

第七类故障域：推理服务故障域

推理系统的故障域和训练不同：训练看 step，推理看请求和 token。

推理故障域常见边界包括：

• 一个模型副本；
• 一个 Decode 组；
• 一个 Prefill 池；
• 一个 KV Cache 分片；
• 一个调度分区；
• 一个租户服务；
• 一个 Decode 节点所在的 Leaf；
• 一个长上下文缓存池。

在 P/D 分离架构里，Prefill 在 P 池执行，Decode 在 D 池执行，P 生成 KV Cache 后再传给 D。如果某个 D 组过载或其接入网络拥塞，就会出现：

• KV 到位变慢；
• Decode 排队；
• TTFT 上升；
• p99 拉高；
• 一批请求变慢。

这个故障域可能包括该 D 组上的所有请求、调度到该 D 组的租户、迁移到该 D 组的 KV 流量，以及对应的 Leaf、rail 和 queue。

推理故障域设计需要回答：

• D 组是否有独立故障边界？
• 调度器是否感知 D 组健康？
• KV 迁移是否会集中到少数 D 组？
• D 组过载时是否限流？
• 是否支持请求迁移或副本摘除？
• 是否有 p99 分组监控？
• 是否能按副本、租户和 D 组查看 TTFT？

推理故障域不是“哪台机器坏了”，而是“哪些请求被同一个慢副本、慢 KV 路径、慢 Decode 组拖住了”。

第八类故障域：存储故障域

AI 集群里，存储不是外围系统。训练要读取数据、写入 checkpoint；推理要加载模型，也可能读取远端 KV 或会话状态。

如果存储故障域设计不好，可能出现：

• 数据加载慢，GPU 等数据；
• checkpoint 慢，训练周期性卡住；
• 模型加载慢，推理扩容失败；
• 远端 KV 缓存慢，TTFT 变差；
• 存储流量挤压训练网络。

存储故障域设计需要回答：

• 哪些任务依赖同一存储集群？
• checkpoint 是否共享同一出口？
• 数据集读取是否会影响训练通信？
• 模型加载是否会影响在线推理？
• 存储网络是否和训练网络隔离？
• 存储异常时是否能降级？
• 是否支持本地缓存？
• checkpoint 失败是否会导致任务失败？
• 存储慢是否有监控与限流？

存储故障域不只影响文件读写，还可能通过数据等待、checkpoint 阻塞和网络拥塞间接拖慢 GPU。

故障域设计的核心原则

故障域设计不是简单地多买设备。它的核心是：

让同一种故障，不要同时影响太多关键资源。

例如：

• 不要让同一训练任务的所有 rail 都落在同一 Leaf；
• 不要让同一租户的所有推理副本都落在同一 rack；
• 不要让训练热流、存储大流、管理控制流都进入同一队列；
• 不要让所有 checkpoint 都打向同一存储出口；
• 不要让所有 D 副本都依赖同一 KV 缓存节点；
• 不要让所有高优先级任务共用一个没有边界的 PFC priority。

故障域设计要做的是风险分散，但也不能无限分散。分散过度会带来跨域通信增加、延迟增加、运维复杂、成本上升和调度困难。

所以故障域设计本质上是在平衡：

• 性能；
• 成本；
• 可用性；
• 故障影响范围；
• 调度复杂度。

故障域不是越碎越好，而是要让故障影响范围可预测、可隔离、可恢复。

如何落地故障域设计？

AI 集群设计故障域不能只靠口头描述，建议至少画 8 张图。

1. 物理 rack / 机柜故障域图

标出服务器、交换机、电源和机柜边界。

2. Leaf 故障域图

标出每台 Leaf 下挂哪些服务器、哪些 rail、哪些租户。

3. Spine 容量故障域图

标出一台 Spine 故障后的容量下降比例。

4. GPU-NIC-Rail 映射图

标出每张 GPU 对应哪张 NIC、哪条 rail、哪个 Leaf。

5. NCCL 通信组覆盖图

标出一个训练任务的 TP / PP / DP group 覆盖哪些节点和网络路径。

6. RoCE QoS 故障域图

标出 priority、TC、PG、PFC、ECN、租户和业务流量之间的映射关系。

7. 推理 P/D 故障域图

标出 P 池、D 池、KV Cache、调度域和 D 组边界。

8. 存储与 checkpoint 故障域图

标出训练数据、checkpoint、模型加载和 KV 缓存路径。

这些图的价值在于：任何故障出现后，可以快速判断它属于哪个故障域、影响哪些任务、是否会跨租户扩散，以及是否需要摘节点、限流、降级或回滚。

没有故障域图，故障发生时只能靠经验猜影响范围；有了故障域图，故障处理才有边界。

故障域设计必须进入验收

故障域不能只写在方案里，必须进入验收。

1. 单节点故障演练

验证节点摘除、任务迁移和推理副本摘除。

2. 单 GPU 故障演练

验证 GPU 健康检查、资源下线和任务重调度。

3. 单 NIC / Rail 故障演练

验证多轨降级、NCCL HCA 排除，以及流量是否重新均衡。

4. Leaf 上联故障演练

验证容量下降后，AllReduce 和推理 p99 是否仍可接受。

5. PFC / 队列异常演练

验证 pause 是否局限在预期 priority，是否影响其他租户。

6. 推理 D 组过载演练

验证调度器能否限流、摘除和迁移。

7. 存储慢速演练

验证训练是否能继续、checkpoint 是否可以降级、推理是否受影响。

验收报告里应记录：

• 故障注入方式；
• 影响范围；
• 告警是否触发；
• 恢复动作；
• 恢复时间；
• 业务指标变化；
• 是否符合预期故障域边界。

故障域设计如果不演练，就只是拓扑图上的假设。真正的故障域，必须在故障注入中被验证。

敲黑板

AI 集群设计故障域，不是为了避免故障，而是为了让故障发生时，影响范围可预测、可隔离、可恢复。

• GPU 故障域，决定坏一张卡影响一个 Pod、一个副本，还是整个任务。
• NIC / rail 故障域，决定坏一条路径是降速还是全挂。
• Leaf 故障域，决定一台交换机影响多少服务器和 GPU。
• Spine 故障域，决定容量下降后是否触发全局拥塞。
• PFC / QoS 故障域，决定 pause 是否误伤其他业务。
• NCCL 通信组故障域，决定一个慢 rank 影响多少 GPU。
• 推理故障域，决定一个慢 D 组影响多少请求。
• 存储故障域，决定存储慢是否拖住 GPU。

故障域设计的本质，是提前回答：

1. 这类故障最多影响到哪里？
2. 怎么发现？
3. 怎么隔离？
4. 怎么降级？
5. 怎么恢复？

如果这些问题没有想清楚，AI 集群一旦出现问题，就很容易从局部故障变成全局事故。

传统网络故障域关注设备影响范围；AI 集群故障域还要关注通信组、队列、租户、任务和 token 的影响范围。真正成熟的 AI 集群不是不出故障，而是故障不会无限扩散。