夜雨聆风这里是「算力网络架构手记」北京
专注 AI 集群网络架构与性能优化
深入 GPU×RoCE×NCCL×K8s 跨层瓶颈
只拆真实问题，不写概念科普
👇 试听内容
👉 AI 训练网络全路径拆解 → 私信：AI网络
👉 AI 推理网络全路径拆解 → 私信：推理
👉 AI 网络架构工程指南手册 → 私信：工程指南
👉 AI 算力网络架构系统（真机实验环境） → 私信：系统
👉 日常工作1对1答疑 → 私信：答疑
00
刚说完可降级，又来一个故障域？
设计 AI 集群时，首先考虑这些问题：
GPU 数量够不够？
网络带宽够不够？
交换机是不是无阻塞？
RoCE / IB 能不能跑满？
NCCL AllReduce 性能怎么样？
肯定是没错！
我只是想提醒你：
故障域怎么设计也需要考虑因为难免有人以为故障域就是传统数据中心里的概念：
一台服务器坏了
一个机柜掉电
一台交换机故障
一个区域不可用
但在 AI 集群里，故障域远比这个复杂。
因为 AI 任务不是普通 Web 服务。
训练里，一个 rank 慢，可能拖住整个 AllReduce。推理里，一个 Decode 副本慢，可能拉高整组服务 p99。RoCE 里，一个 priority 触发 PFC，可能影响同一队列里的所有流。多轨网络里，一条 rail 异常，可能让 NCCL 通信路径不均衡。
所以 AI 集群设计故障域，不只是为了回答：
哪台设备坏了？
更是为了回答：
这个故障会影响多少 GPU、多少任务、多少租户、多少 token、多少 step？
01
故障域不是“故障在哪里”，而是“故障会被放大到哪里”
传统系统里，一个故障的影响范围通常比较直观。
一台机器坏了，影响这台机器上的服务。一个 ToR 坏了，影响这个机柜里的服务器。一个存储节点坏了，影响部分数据访问。
但 AI 集群不一样。
AI 集群里，很多故障会被同步机制放大。
比如训练任务：
128 张 GPU 一起训练 每一步都要做 AllReduce 其中一个 rank 网络慢 其他 127 张 GPU 都要等
这时候，真正的故障点可能只是一张 NIC、一个端口、一个 GPU、一个 rank。
但影响范围是整个训练任务。
再比如推理任务：
某个 D 副本网络拥塞 KV Cache 迁移变慢 Decode 开始等待 一批请求 TTFT 变高 用户看到 p99 抖动
故障点可能只是一个 D 组或一个 Leaf 出口队列。
但影响的是一批在线请求。
所以 AI 集群里的故障域，本质是：
故障影响被同步通信、队列拥塞、调度路径、KV 状态和尾延迟机制放大后的边界。
AI 集群必须设计故障域，是因为局部故障很容易被放大全局影响。
02
为什么普通故障域思维不够？
普通业务系统里，一个请求通常只依赖少数服务实例。
服务 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 在通信逻辑上是否绑在一起。
03
第一类故障域：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 故障不是硬件清单问题。
它决定的是调度系统能否把坏卡影响限制在最小任务单元内。
04
第二类故障域：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 故障域要问：
每条 rail 对应哪些 GPU？ 每条 rail 接哪个 Leaf？ 每条 rail 是否独立故障？ 一条 rail 故障后能否摘除？ NCCL 是否能避开故障 HCA？ 调度器是否感知 rail health？ 多租户是否共享同一 rail？
多轨网络的成熟度，不只看满血时带宽多高。
还要看一条 rail 异常时，影响是否可控。
05
第三类故障域：Leaf 故障域
Leaf 是 AI 网络里的关键故障边界。
一台 Leaf 可能连接：
一组服务器 一个 rack 一条 rail 多个租户 多个训练任务 一批推理副本
如果 Leaf 故障域设计不好，一台 Leaf 出问题，可能影响非常大。
常见问题包括：
一台 Leaf down，整排服务器掉一条 rail 某个 Leaf buffer 异常，多个训练任务慢 某个 Leaf 上 PFC pause 异常，影响同 priority 流量 某个 Leaf 上行拥塞，推理 D 组 p99 变差
Leaf 故障域设计要问：
每台 Leaf 下挂多少服务器？ 每台 Leaf 对应哪些 rail？ 每台服务器的多张 NIC 是否分散到多个 Leaf？ 一个 Leaf 故障后，每台服务器损失多少带宽？ 是否会导致某些节点完全失联？ 是否会导致某个租户整片不可用？ 是否有 ECMP / 上行冗余？ Leaf 故障后 NCCL 是否还能降级运行？
理想情况下，Leaf 故障不应该导致所有路径同时消失。
至少应该让系统有机会：
降速运行 摘除部分 rail 迁移推理副本 训练任务从 checkpoint 恢复 限制影响范围
Leaf 不是普通接入交换机。
在 AI 集群里，它经常是 GPU 通信故障域的第一层放大器。
06
第四类故障域：Spine 故障域
Spine 故障和 Leaf 故障不同。
Leaf 故障通常影响某个接入范围。
Spine 故障更容易表现为：
全局容量下降。
比如一个 Clos 网络里，有多台 Spine 提供上行等价路径。
一台 Spine 故障后，网络不一定断。
但问题是：
总上行容量下降 ECMP 路径减少 剩余 Spine 压力增加 某些通信阶段更容易 Incast 队列更容易升高 ECN / PFC 更容易触发 step time / p99 开始变差
这类故障很容易被误判。
因为链路还通。任务还能跑。但性能开始下降。
所以 Spine 故障域要看：
一台 Spine 故障后，收敛比变成多少？ 训练 AllReduce 性能下降多少？ 推理 p99 是否受影响？ 是否触发更多 ECN marked？ 是否增加 PFC pause 风险？ ECMP 是否重新均衡？ 是否有可观测基线对比？
Spine 故障最危险的地方，不一定是断。
而是网络还通，但从无阻塞变成有拥塞，业务开始慢。
07
第五类故障域：PFC / QoS 故障域
RoCE 网络里，PFC 故障域必须单独设计。
因为 PFC 的影响不是按 IP、Pod、租户来划分的。
它是按 priority 生效。
这意味着：
只要多个业务流量共享同一个 PFC priority，它们就可能被一起 pause。
比如：
租户 A 训练流量进入 priority 3 租户 B 推理流量也进入 priority 3 存储流量被错误映射进 priority 3 某个出口队列拥塞触发 PFC 同 priority 的流量都被影响
这就是 PFC 故障域。
它的边界不是设备。
而是：
同一个 lossless priority 上承载了哪些业务。
如果 PFC 故障域设计不好，就会出现：
一个租户的 Incast，pause 其他租户 一个存储大流，误伤 RoCE 训练 一个错误映射，让普通流量污染 RDMA 队列 pause storm 扩散到多个端口
所以 RoCE 故障域设计要问：
哪些流量进入 lossless priority？ 训练和推理是否共用 priority？ 热路径和冷路径是否共用 queue？ CNP 是否独立处理？ PFC 是否只作为兜底？ ECN 是否先于 PFC 触发？ 是否能按 priority 监控 pause？ 是否能按租户或任务关联 pause 影响？
PFC 故障域不是按网络拓扑画的。
它是按 priority、queue 和 buffer 共享关系画的。
08
第六类故障域：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
所以 AI 集群设计故障域时，要把 NCCL 拓扑纳入设计。
要问：
一个 NCCL job 跨多少 Leaf？ 跨多少 Spine？ 跨多少 rack？ 一个 TP group 是否跨故障域？ 一个 DP group 是否跨多个电源域？ 任务调度是否尽量让通信组落在可控范围内？ 是否有拓扑感知调度？ 是否能定位 slow rank 到物理设备？
NCCL 故障域是逻辑故障域。
它不一定和物理 rack、Leaf、VLAN 完全一致，但它决定慢点会影响多少 GPU。
09
第七类故障域：推理服务故障域
推理系统的故障域和训练不一样。
训练看 step。推理看请求和 token。
推理故障域常见边界包括：
一个模型副本 一个 Decode 组 一个 Prefill 池 一个 KV Cache 分片 一个调度分区 一个租户服务 一个 D 节点所在 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 组拖住了”。
10
第八类故障域：存储故障域
AI 集群里，存储不是外围系统。
训练要读数据。训练要写 checkpoint。
推理要加载模型。推理可能要读远端 KV 或会话状态。
如果存储故障域设计不好，会出现：
数据加载慢，GPU 等数据 checkpoint 慢，训练周期性卡住 模型加载慢，推理扩容失败 远端 KV 缓存慢，TTFT 变差 存储流量挤压训练网络
存储故障域设计要回答：
哪些任务依赖同一存储集群？ checkpoint 是否共享同一出口？ 数据集读取是否会影响训练通信？ 模型加载是否会影响在线推理？ 存储网络是否和训练网络隔离？ 存储异常时是否能降级？ 是否支持本地缓存？ checkpoint 失败是否会导致任务失败？ 存储慢是否有监控与限流？
存储故障域不是只影响文件读写。
它可能通过数据等待、checkpoint 阻塞和网络拥塞，间接拖慢 GPU。
11
故障域设计的核心原则
故障域设计不是简单多买设备。
它的核心是：
让同一种故障，不要同时影响太多关键资源。
比如：
不要让同一训练任务的所有 rail 都落在同一 Leaf 不要让同一租户的所有推理副本都落在同一 rack 不要让训练热流、存储大流、管理控制流都进同一队列 不要让所有 checkpoint 都打向同一存储出口 不要让所有 D 副本都依赖同一 KV 缓存节点 不要让所有高优先级任务共用一个 PFC priority 且无边界
故障域设计要做的是风险分散。
但也不能无限分散。
因为分散过度会带来：
跨域通信增加 延迟增加 运维复杂 成本上升 调度困难
所以故障域设计本质是平衡：
性能 成本 可用性 故障影响范围 调度复杂度
故障域不是越碎越好。
而是要让故障影响范围可预测、可隔离、可恢复。
12
如何落地故障域设计？
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 缓存路径。
这些图的价值在于：
以后任何故障出现，你可以快速判断：
属于哪个故障域 影响哪些任务 是否会跨租户扩散 是否需要摘节点 是否需要限流 是否需要降级 是否需要回滚
没有故障域图，故障发生时只能靠经验猜影响范围。
有了故障域图，故障处理才有边界。
13
故障域设计必须进入验收，而不是只停留在方案里
故障域不能只写在方案里。
必须进入验收。
验收时要做几个动作：
1）单节点故障演练
验证节点摘除、任务迁移、推理副本摘除。
2）单 GPU 故障演练
验证 GPU 健康检查、资源下线、任务重调度。
3）单 NIC / rail 故障演练
验证多轨降级、NCCL HCA 排除、流量是否重新均衡。
4）Leaf 上联故障演练
验证容量下降后，AllReduce 和推理 p99 是否仍可接受。
5）PFC / 队列异常演练
验证 pause 是否局限在预期 priority，是否影响其他租户。
6）推理 D 组过载演练
验证调度器能否限流、摘除、迁移。
7）存储慢速演练
验证训练是否能继续、checkpoint 是否可降级、推理是否受影响。
验收报告里应记录：
故障注入方式 影响范围 告警是否触发 恢复动作 恢复时间 业务指标变化 是否符合预期故障域边界
故障域设计如果不演练，就只是拓扑图上的假设。
真正的故障域，必须在故障注入中被验证。
14
敲黑板
AI 集群设计故障域，不是为了避免故障。而是为了让故障发生时，影响范围可预测、可隔离、可恢复。
GPU 故障域，决定坏一张卡影响一个 Pod、一个副本，还是整个任务 NIC / rail 故障域，决定坏一条路径是降速还是全挂 Leaf 故障域，决定一台交换机影响多少服务器和 GPU Spine 故障域，决定容量下降后是否触发全局拥塞 PFC / QoS 故障域，决定 pause 是否误伤其他业务 NCCL 通信组故障域，决定一个慢 rank 影响多少 GPU 推理故障域，决定一个慢 D 组影响多少请求 存储故障域，决定存储慢是否拖死 GPU
故障域设计的本质，是提前回答：
这类故障最多影响到哪里？怎么发现？怎么隔离？怎么降级？怎么恢复？
如果这些问题没想清楚，AI 集群一旦出问题，就很容易从局部故障变成全局事故。
传统网络故障域，关注设备影响范围。
AI 集群故障域，还要关注通信组、队列、租户、任务和 token 的影响范围。
真正成熟的 AI 集群，不是不出故障，而是故障不会无限扩散。
👉 AI 训练网络全路径拆解 → 私信：AI网络
👉 AI 推理网络全路径拆解 → 私信：推理
👉 AI 网络架构工程指南手册 → 私信：工程指南
👉 AI 算力网络架构系统（真机实验环境） → 私信：系统
👉 日常工作1对1答疑 → 私信：答疑
如果你也在做 AI 集群架构
欢迎关注「算力网络架构手记」
长期拆解真实算力网络问题