ReelOS.AI 禅定｜一句话看懂本文
RoCE Fabric 的核心，不是网络能不能通，而是训练能不能稳。
- GPU 很贵。
- GPU 集群越大，越怕通信抖动。
- 通信一抖，训练 step time 就抖。
- step time 一抖，GPU 就等待。
- GPU 等待，就是算力浪费。
- PFC、ECN、DCQCN、MTU、buffer 都重要。
- 但它们只是底层条件，不是完整答案。
- 真正的 RoCE Fabric，要把拓扑、QoS、负载均衡、NCCL 和遥测闭环打通。
- 拓扑决定数据怎么走。
- QoS 决定拥塞怎么控。
- 负载均衡决定路径怎么分。
- NCCL 决定 GPU 通信怎么组织。
- 遥测决定问题能不能定位。
- 所以合格的 AI Ethernet，不是网络可用，而是训练可预测。
- RoCE Fabric 的本质，是把以太网从“能跑 RDMA”，升级成“能稳定承载 AI 训练任务”的系统工程。
导读
AI 时代的网络，已经不再只是“服务器之间的连接”。
在传统数据中心里，网络主要负责搬运请求、文件、日志和存储流量。但在大规模 GPU 集群里，网络直接参与训练过程。一次 AllReduce、AllGather、ReduceScatter 或 All-to-All 通信，都会影响 GPU 是否等待、训练 step time 是否抖动、集群扩展效率是否下降。
所以，AI 集群里的 RoCE 网络，不能再被理解成“把以太网调成无损网络”。
它更接近一张 AI Compute Fabric：既要承载 RDMA，也要理解 GPU 拓扑、NCCL 通信模式、训练任务调度、拥塞反馈、故障恢复和遥测闭环。
本文的核心判断是：
最前沿、同时最可落地的 RoCE 优化方向，不是单点调 PFC、ECN 或 DCQCN，而是 拓扑设计 + QoS 边界 + NIC / 交换机负载均衡 + NCCL / 通信库调优 + 遥测闭环 五层协同。
这篇文章不是 RoCE 参数速查表，而是一张 AI Compute Fabric 学习地图。
一、先定义：RoCE 到底解决什么问题？
RoCE，全称 RDMA over Converged Ethernet，即在以太网上运行 RDMA。
RDMA 的价值，是让一台机器可以直接读写另一台机器的内存，减少 CPU 参与、降低延迟、提升吞吐。在 GPU 集群里，RoCE 主要服务这几类通信：
| 通信类型 | 典型场景 | 网络压力 |
|---|---|---|
| AllReduce | 数据并行梯度同步 | 大流量、强同步 |
| AllGather | 参数或激活聚合 | 带宽敏感 |
| ReduceScatter | 张量并行 / 数据并行切分 | 带宽敏感 |
| All-to-All | MoE Expert Parallel | 流量复杂，容易形成热点 |
| Checkpoint / Storage | 模型保存、数据加载 | 容易与训练流量互相干扰 |
所以，RoCE 网络的优化目标不是“ping 更低”“端口速率更高”，而是：
让 GPU 在分布式训练和推理中少等待，让 collective communication 更稳定，让训练 step time 更可预测。
二、核心判断：RoCE 优化已经从网络参数进入系统工程
很多团队一开始做 RoCE，容易把问题收敛到几个参数：
- PFC 开不开？
- ECN 阈值怎么调？
- DCQCN 要不要启用？
- MTU 配多大？
- buffer 怎么切？
- GID index 怎么选？
这些都重要，但它们只是底层条件。
真正影响 GPU 集群效率的，是训练任务在网络上的整体行为。Meta 在大规模 AI 训练 RoCE 实践中指出，AI 训练流量具有低熵、突发、大象流等特征，普通 ECMP 容易出现路径碰撞；他们通过 QP scaling 与 Enhanced ECMP 增加 hash entropy，使 AllReduce 性能最高提升约 40%。
这说明一个关键变化：
AI Fabric 的问题，不是“网络能不能通”，而是通信模式、路由熵、拓扑位置、拥塞反馈、训练任务调度能不能协同。
换句话说，RoCE 优化已经从网络工程，变成了 AI Infra 系统工程。
三、学习地图：理解 RoCE Fabric 的五层结构
可以把 AI RoCE Fabric 拆成五层。
| 层级 | 核心问题 | 典型能力 |
|---|---|---|
| 1. 拓扑层 | GPU、NIC、交换机如何组织？ | FE / BE 分离、Rail-optimized、Multi-plane |
| 2. QoS 层 | 如何让 RoCE 接近无损但不失控？ | PFC、ECN / WRED、DSCP / PCP、PFC Watchdog |
| 3. 负载均衡层 | 如何避免低熵流量打爆少数路径？ | ECMP、QP scaling、Adaptive Routing、PLB |
| 4. 通信库层 | NCCL / EP 通信如何感知网络？ | NCCL rail / plane、QP 数、Cross NIC、DeepEP |
| 5. 遥测闭环层 | 如何知道瓶颈在哪里？ | DCGM、RDMA counters、switch telemetry、step time |
这五层缺一不可。
只做拓扑，无法处理拥塞；只调 PFC，可能制造 PFC storm；只看端口吞吐，可能看不到 NCCL bus bandwidth；只看 NCCL 日志，又可能忽略交换机队列和 RDMA 错误计数。
最终要形成的不是一张“RoCE 参数表”，而是一套：
RoCE Fabric Runbook：从建网、验收、调优、监控、故障注入到生产运维的一整套方法。
四、系统位置：AI Factory 为什么需要 Backend RoCE 网络？
在成熟的 AI 集群里，网络通常不应该是一张大而全的通用网络，而应拆成不同用途的 fabric。
Meta 的 RoCE 生产实践里，训练网络被拆分为 Frontend 和 Backend：Frontend 负责数据、checkpoint、日志等通用流量；Backend RoCE 网络专门服务 GPU 训练 collective，并要求高带宽、低延迟、lossless 和 non-blocking。
这一点非常关键。
因为训练 collective 与普通业务流量不同：
| 维度 | 普通数据中心流量 | AI 训练流量 |
|---|---|---|
| 流量形态 | 多租户、多样化、熵较高 | 低熵、同步、大象流 |
| 性能指标 | 平均吞吐、请求延迟 | step time、busbw、尾延迟 |
| 故障影响 | 单服务降级 | 整个训练任务等待 |
| 调优对象 | 应用 + 网络 | GPU + NCCL + NIC + Switch + Scheduler |
这也是为什么 AI Factory 不应该只问“交换机是多少 G”，而要问：
- GPU 到 NIC 的 affinity 是否固定？
- 每张 GPU 走哪条 rail？
- NCCL 是否感知 rail / plane？
- 跨 rack、跨 pod、跨 zone 的 collective 是否被调度器控制？
- PFC、ECN、CNP 与 step time 是否能关联分析？
五、三条主流路线：Meta、Spectrum-X、开放 SONiC
1. Meta 路线：生产 RoCE 的系统经验
Meta 的经验最值得学习的地方，不是某个参数，而是方法论。
他们面对的问题是：AI collective 流量低熵，普通 ECMP 容易路径碰撞；path pinning 又会在碎片化调度和链路故障下导致 uplink 不均衡。Meta 后续通过 QP scaling 和 Enhanced ECMP，让交换机 hash RoCE destination QP 字段，改善路径分布。
更值得注意的是，Meta 对 DCQCN 的实践并不是“默认开启”。在其 400G RoCE 部署中，他们讨论了 DCQCN 在固件行为、CNP 可观测性和性能退化方面的挑战，最终生产实践更强调 PFC、collective library 与接收端 admission control 的配合。
这给 AI Infra 团队一个重要提醒：
DCQCN 不是信仰，PFC 也不是答案。最终判断标准应该是 NCCL 性能、训练 step time、拥塞恢复和故障隔离。
2. Spectrum-X 路线：把 Ethernet 做成 AI Fabric 产品
NVIDIA Spectrum-X 的方向，是把 RoCE 从“以太网能力”升级成 AI Fabric 全栈方案。
它不是单一交换机或网卡，而是由以下能力组成的系统：
| 组件 | 作用 |
|---|---|
| Spectrum 交换机 | AI Ethernet fabric 的交换层 |
| ConnectX / BlueField | RDMA、RoCE、SuperNIC、offload |
| Network Operator | Kubernetes 网络组件部署 |
| NIC Configuration Operator | NIC 固件与 profile 配置 |
| Multi-plane / PLB | 更高阶的路径利用与负载均衡 |
| Topology-aware placement | 让调度器理解网络位置 |
2026 年 Spectrum-X 论文进一步把这一方向总结为 giga-scale AI Factories 的高性能网络方案，强调 multiplane 架构、NIC / 交换机硬件加速负载均衡、低抖动延迟、跨租户隔离和链路故障下的容量保持。
这条路线适合大规模、高端、NVIDIA GPU 体系内的训练集群，尤其是 B200 / B300 及后续平台。
但也要看到它的边界：
Spectrum-X 的价值来自 NVIDIA 全栈协同，不是买普通以太网交换机后靠手工参数就能复现。
3. SONiC 开放路线：开放 Ethernet AI Fabric 的可能性
如果希望降低供应商绑定，SONiC + 商用 ASIC + RoCEv2 是值得重点研究的开放路线。
SONiC 的关键价值在 QoS 和可观测性。SONiC 的 PFC Watchdog 设计用于检测和缓解 PFC storm，因为 PFC pause 的 back-pressure 可能扩散到整个网络，导致网络停止转发。
SONiC 也明确支持在 lossless queue 上启用 ECN，并要求 ECN 应先于 PFC packet 触发。
SAKURAONE 论文展示了一个值得参考的案例：100 个节点、每节点 8 张 H100、800GbE、SONiC、RoCEv2、rail-optimized leaf-spine fabric，并在 ISC 2025 TOP500 前 100 中被描述为唯一使用 fully open networking stack 的系统。
这说明开放 Ethernet 并不只是“低端替代方案”，而是正在进入 AI / HPC 高性能系统。
一个典型开放 RoCE Fabric 栈可以这样理解：
Switch NOS：SONiC
Control Plane：FRR / BGP / EVPN 可选
ASIC：Broadcom Tomahawk 5/6 或同级
NIC：ConnectX-7 / ConnectX-8 / Broadcom Thor / AMD AI NIC
QoS：PFC + ECN/WRED + PFC Watchdog
Topology：Rail-optimized Leaf-Spine
Telemetry：SONiC counters + gNMI / SNMP / Prometheus开放路线的优点是可控、可组合、可形成自有方法论；缺点是对网络工程能力要求更高。
SONiC 路线更像“基础设施团队的能力放大器”，不是“买来即用的黑盒方案”。
六、QoS 层：PFC、ECN、DCQCN 不是三件孤立的事
RoCE 要在以太网上实现低丢包、高吞吐、低延迟，通常需要配合 QoS 机制。
最常见的组合是：
PFC：只对 RoCE lossless priority 开启
ECN/WRED：早于 PFC 触发
DSCP/PCP：把 NCCL/RDMA 流量映射到固定 priority
PFC Watchdog：防止 PFC storm
Buffer：按端口速率、RTT、线缆距离、burst 模型计算这里最容易误解的是 PFC。
PFC 不是“打开以后网络就无损”。它只是让某个 priority 的流量在拥塞时暂停。如果设计不好，PFC pause 会产生 back-pressure，进而造成 head-of-line blocking、拥塞扩散，甚至 PFC storm。
所以更合理的顺序是：
ECN / WRED 提前标记拥塞，端侧或传输层先降速，PFC 只作为最后的安全网。
七、负载均衡层：AI 流量最大的问题之一是低熵
传统数据中心流量往往足够多样，五元组 hash 可以让 ECMP 分布相对均匀。但 AI 训练流量不同，尤其是 collective communication，流量模式高度规律、同步、突发，容易形成低熵大象流。
这会带来一个常见问题：
网络总带宽看起来够，但少数路径被打爆，训练 step time 出现抖动。
Meta 的 QP scaling + Enhanced ECMP 经验，正是为了解决这个问题。通过增加 queue pair，并让交换机把 RoCE destination QP 纳入 hash，低熵流量可以获得更好的路径分布。
从工程落地看，负载均衡可以分成四档：
| 档位 | 方法 | 适用场景 |
|---|---|---|
| L1 | 普通 ECMP | 小规模、低压力 |
| L2 | QP scaling + Enhanced ECMP | 中大规模 RoCE 集群 |
| L3 | Adaptive Routing / Dynamic Load Balancing | 交换机能力较强的集群 |
| L4 | Multi-plane + PLB | 高端 Spectrum-X 或同类 AI Fabric |
这也是为什么下一代 AI Ethernet 不只是“更高速率”，而是越来越强调 path diversity、packet-level load balancing、multi-plane 和硬件快速反馈。
八、通信库层：RoCE 调优不能脱离 NCCL
RoCE 网络不是独立工作的，它最终要服务 NCCL、UCX、MPI、DeepEP、vLLM / SGLang 等通信和推理框架。
NCCL 已经越来越显式地感知网络拓扑。
NVIDIA NCCL 文档中，NCCL_CROSS_NIC 用于控制 ring / tree 是否跨 NIC；其说明明确指出这个变量依赖网络拓扑，尤其是 rail-optimized 网络。
NCCL 也支持通过 NCCL_IB_QPS_PER_CONNECTION 为每个 rank connection 使用多个 queue pairs，从而增加多层 fabric 的 routing entropy。
所以，RoCE Fabric 的调优终点不在交换机 CLI，而在这些指标上：
- NCCL algbw
- NCCL busbw
- collective time
- training step time
- GPU utilization
- tail latency
- 多任务并发下的性能稳定性
建议至少建立三类 NCCL profile。
| Profile | 适用场景 | 重点变量 |
|---|---|---|
| A | 普通 RoCE 训练集群 | NCCL_IB_HCA、NCCL_IB_GID_INDEX、NCCL_IB_TC |
| B | Rail-optimized 多 NIC 集群 | NCCL_CROSS_NIC=0、HCA / rail 对齐 |
| C | 需要增加 ECMP entropy 的网络 | NCCL_IB_QPS_PER_CONNECTION、NCCL_IB_SPLIT_DATA_ON_QPS |
这些参数不能凭经验拍脑袋。它们必须结合具体拓扑、NIC 数量、rail 设计、交换机 hash 能力和 NCCL benchmark 结果来验证。
九、MoE 与 Expert Parallel：All-to-All 正在改变网络压力模型
传统训练中，AllReduce 是核心通信模式；但随着 MoE 模型普及，All-to-All 和 Expert Parallel 通信变得更重要。
DeepSeek 开源的 DeepEP 面向 expert parallelism，提供高吞吐、低延迟的 all-to-all GPU kernels，用于 MoE dispatch 和 combine。
这类变化会让 RoCE Fabric 面临新的压力：
| 模型 / 并行模式 | 主要通信模式 | 对网络的挑战 |
|---|---|---|
| 数据并行 | AllReduce | 大流量、同步性强 |
| 张量并行 | AllGather / ReduceScatter | 延迟与带宽都敏感 |
| MoE / EP | All-to-All | 流量更复杂，热点更难预测 |
| 推理 Prefill / Decode 分离 | Send / Recv、All-to-All | 尾延迟与隔离更重要 |
这意味着未来 RoCE 优化不能只停留在网络层。通信库、模型结构、推理引擎和调度系统都会参与 Fabric 设计。
十、遥测闭环：把 GPU、RDMA、Switch、Job 放到同一张图里
RoCE 调优不能靠“上线前调好一次”。它必须持续观测。
建议把以下指标放到同一条时间线上：
| 指标类别 | 关键指标 |
|---|---|
| GPU | utilization、HBM、NVLink、power、temperature |
| NCCL | algbw、busbw、collective time、NCCL error |
| RDMA NIC | xmit_wait、symbol error、duplicate request、CNP、packet discard |
| Switch | PFC pause、ECN mark、queue depth、link flap |
| Job | step time、吞吐、失败率、重启次数 |
真正有价值的 Dashboard，不是只显示端口 up / down，而是回答：
- 哪个 job 的 step time 变慢了？
- 变慢时哪条 rail 出现 PFC pause？
- 哪个交换机队列 ECN mark 突增？
- 哪些 NIC 出现 xmit_wait 或 symbol error？
- 是否存在某个 rack / pod / zone 的拓扑热点？
- NCCL busbw 下降是否和网络拥塞同一时间发生？
十一、UEC：下一代开放 AI Ethernet 标准信号
Ultra Ethernet Consortium，简称 UEC，是面向 AI 和 HPC 优化 Ethernet 的开放标准组织。
UEC 1.0 规范已在 2025 年发布，目标是面向 AI 和 HPC 优化 Ethernet，覆盖硬件到应用的完整技术栈，并强调开放互操作。
Ultra Ethernet 的设计论文指出，UE 1.0 的核心贡献之一是 Ultra Ethernet Transport，也就是 UET，目标是为 extreme-scale 系统提供可靠、快速、高效、可硬件加速的通信协议。
对今天的 AI Infra 团队来说，UEC 的现实意义不是马上替代 RoCE，而是提供一个长期方向。
| 时间尺度 | 判断 |
|---|---|
| 短期 | RoCEv2 仍是 Ethernet AI Fabric 的主流落地路径 |
| 中期 | 关注 UEC 兼容 NIC、Switch、Transport |
| 长期 | UET 可能成为跨厂商 AI Ethernet 的重要传输层 |
换句话说：
RoCE 是当下工程主线，UEC 是下一代开放 AI Ethernet 的标准化方向。
十二、可落地的 RoCE Fabric Runbook
如果要把 RoCE Fabric 变成可复制能力，不能只沉淀一张参数表，而要沉淀一套 Runbook。
阶段一：建立标准验收基线
先解决“能不能测、能不能复现、能不能对比”。
| 验收项 | 目标 |
|---|---|
| 单链路 RDMA | 验证 NIC、driver、firmware、MTU、GID |
| 单节点多 GPU | 验证 GPU-NIC affinity 与 GDRDMA |
| 多节点 NCCL | 验证 collective 性能 |
| 多 job 压力 | 验证隔离性和拥塞行为 |
| 故障注入 | 验证链路故障、降速、恢复时间 |
阶段二：固化 QoS Profile
基础原则：
- PFC 只对 RoCE lossless priority 开启。
- ECN / WRED 应早于 PFC 触发。
- DSCP / PCP / TC 映射必须标准化。
- PFC Watchdog 必须开启。
- buffer 不能拍脑袋配置，要结合端口速率、RTT、线缆距离和突发模型。
阶段三：拓扑与调度协同
重点建立三张表：
| 表 | 作用 |
|---|---|
| GPU-NIC affinity 表 | 明确每张 GPU 最近的 NIC |
| Rail 编号表 | 明确每个 NIC 所属 rail |
| Rack / Pod / Zone 拓扑表 | 让调度器避免高代价跨域通信 |
训练任务调度不应只看“哪里有空闲 GPU”，还应看“这些 GPU 是否在合适的网络拓扑位置”。
阶段四：解决 ECMP 低熵问题
从低到高可以分四档：
| 档位 | 方法 | 适用场景 |
|---|---|---|
| L1 | 普通 ECMP | 小规模、低压力 |
| L2 | QP scaling + Enhanced ECMP | 中大规模 RoCE 集群 |
| L3 | Adaptive Routing / Dynamic Load Balancing | 交换机能力较强的集群 |
| L4 | Multi-plane + PLB | 高端 Spectrum-X 或同类 AI Fabric |
阶段五：建立遥测闭环
每个训练任务都应该沉淀以下数据：
- NCCL busbw
- NCCL algbw
- collective time
- training step time
- GPU utilization
- RDMA xmit/rcv data
- PFC pause
- ECN mark
- CNP rate
- retrans / duplicate / symbol error
- link flap最终目标不是“这次调好了”，而是：
每一次训练变慢，都能回放：当时 GPU、NCCL、NIC、Switch、Job 发生了什么。
十三、判断框架：什么样的 RoCE Fabric 才算合格？
可以用一张表判断。
| 维度 | 不合格表现 | 合格表现 |
|---|---|---|
| 拓扑 | GPU、NIC、rail 混乱 | GPU-NIC affinity 固化，rail 清晰 |
| QoS | 全网随意开 PFC | lossless priority 明确，ECN 先于 PFC |
| 负载均衡 | 只靠普通 ECMP | 有 QP entropy 或 adaptive routing |
| NCCL | 使用默认环境变量 | 按拓扑配置 HCA、GID、TC、Cross NIC、QP |
| 遥测 | 只看端口 up / down | GPU、NCCL、RDMA、Switch、Job 同屏 |
| 验收 | 只跑 ib_write_bw | 跑 NCCL collective + 多 job + 故障注入 |
| 运维 | 故障靠人工经验 | 有 Runbook、Dashboard、告警、回归测试 |
一句话：
合格的 RoCE Fabric，不是“网络可用”，而是“训练任务可预测”。
十四、常见误区
误区一：RoCE = 便宜版 InfiniBand
RoCE 的优势是基于以太网生态，开放、供应链丰富、易与现有数据中心体系结合。但 RoCE 并不是“便宜买来就能跑满 GPU”的方案。
RoCE 的代价是工程复杂度：PFC、ECN、buffer、QoS、GID、MTU、交换机 ASIC、NIC firmware、NCCL profile、调度器、遥测都要协同。
更准确的说法是：
InfiniBand 把很多确定性做进系统；RoCE 把更多工程控制权交给团队。
误区二：PFC 开了就是 lossless
PFC 只是让某个 priority 的流量在拥塞时暂停，而不是自动保证系统稳定。
PFC 可能引发 head-of-line blocking、拥塞扩散甚至 PFC storm。SONiC 专门设计 PFC Watchdog，就是为了检测和缓解异常 pause 造成的网络停转风险。
所以 PFC 的正确位置是：
PFC 是最后的安全网，不是第一拥塞控制手段。
误区三：调 RoCE 只看 ib_write_bw
ib_write_bw 能验证 RDMA 单链路能力，但不能代表训练性能。
NCCL tests 会报告 operation time、algorithm bandwidth 和 bus bandwidth，这些指标更接近 collective communication 的真实瓶颈。
真正的验收应至少分四层：
| 层级 | 工具 | 目标 |
|---|---|---|
| RDMA 基线 | perftest / ib_write_bw | 单链路、单 NIC、GDRDMA 基线 |
| NCCL collective | nccl-tests | AllReduce、AllGather、ReduceScatter、All-to-All |
| 多任务压力 | 多 job + 背景流 | 看拥塞、隔离、尾延迟 |
| 故障注入 | link flap、降速、丢包 | 看恢复时间和 step time |
误区四：网络优化和 NCCL 是两件事
NCCL 已经显式暴露了大量网络相关配置，包括 interface、HCA、GID、traffic class、cross NIC、queue pairs 等。
这意味着：
RoCE Fabric 的调优终点，不在交换机 CLI，而在 NCCL collective 的有效带宽和训练 step time。
十五、对创业者、产品经理和基础设施团队的启发
对创业者
AI Infra 的机会，不只在 GPU 租赁，也在 GPU 利用率提升。
当客户开始从“买多少卡”转向“每张卡的有效训练产出是多少”，RoCE Fabric、NCCL 诊断、集群遥测、训练性能回归、故障定位都会成为高价值基础设施产品。
未来真正有壁垒的不是卖带宽，而是卖：
可验证的 GPU 集群有效算力。
对产品经理
不要把 RoCE Fabric 产品设计成“参数配置后台”。
更有价值的产品形态，是围绕任务闭环：
- 这次训练慢在哪里？
- 是 GPU 等网络，还是网络等存储？
- 是某条 rail 热点，还是某个 rack 跨域通信过多？
- 是 PFC storm，还是 ECN 阈值过晚？
- 是 NCCL ring / tree 选择问题，还是 NIC affinity 错误？
- 是否能在下次调度时自动避开同类问题？
产品界面应该从“设备视角”升级为“任务视角”。
对基础设施团队
RoCE Fabric 最重要的工程资产不是一次调参经验，而是四类沉淀：
| 资产 | 说明 |
|---|---|
| Topology Inventory | GPU、NIC、rail、rack、pod、zone 关系 |
| Fabric Profile | QoS、PFC、ECN、MTU、GID、TC、firmware 标准 |
| Benchmark Suite | RDMA、NCCL、多 job、故障注入基准 |
| Observability Dashboard | GPU、NCCL、RDMA、Switch、Job 全链路关联 |
这些资产决定了团队能不能从“救火型运维”走向“工程化运营”。
十六、三条产品化路线
如果把 RoCE Fabric 作为 AI Infra 产品能力，可以分成三条路线：
| 路线 | 定位 | 适合客户 |
|---|---|---|
| A. 标准开放 RoCE | SONiC + RoCEv2 + NCCL + Prometheus | 中型 GPU 集群、成本敏感、希望开放可控 |
| B. 高端 Spectrum-X | NVIDIA Spectrum-X + ConnectX / BlueField + Multi-plane / PLB | B200 / B300 大规模训练、追求性能和稳定性 |
| C. 前沿研究增强 | DeepEP / NCCL GIN / UEC / GPUNetIO / UCCL-EP | MoE、异构 GPU、下一代 AI Fabric 研究 |
更现实的建议是：
短期：先建立标准 RoCE 验收和监控能力
中期：形成开放 RoCE Fabric Runbook
高端客户：评估 Spectrum-X 全栈方案
长期：持续跟踪 UEC / UET / GPU-Initiated Networking结语
AI 集群网络正在经历一次角色变化。
过去，网络是数据中心里的连接层；现在，在 AI Factory 中，网络已经成为算力系统的一部分。
RoCE 的真正挑战，也不是把以太网调成“尽量无损”，而是把 GPU、NIC、交换机、NCCL、调度器和遥测系统组织成一张可观测、可调度、可验证的 AI Compute Fabric。
所以，RoCE Fabric 的终局不是一组参数，而是一套闭环：
用拓扑降低不确定性，用 QoS 控制拥塞边界，用负载均衡提升路径利用，用 NCCL 感知通信模式，用遥测把网络问题还原到训练任务。
这才是 AI Factory 时代，Ethernet 网络真正需要升级的地方。
完整参考资料
生产实践
- Meta Engineering｜RoCE networks for distributed AI training at scale
- ACM SIGCOMM｜RDMA over Ethernet for Distributed AI Training at Meta Scale
NVIDIA / Spectrum-X
- NVIDIA Spectrum-X Networking Platform
- NVIDIA Network Operator v26.4.0
- NVIDIA NIC Configuration Operator
- High-speed Networking for Giga-Scale AI Factories
SONiC / 开放 Ethernet
- SAKURAONE: An Open Ethernet-Based AI HPC System
- SAKURAONE 技术文章
- SONiC GitHub
- SONiC PFC Watchdog
- SONiC ECN on Lossless Queues
NCCL / 通信库
- NCCL Environment Variables
- NVIDIA nccl-tests
- NCCL Tests Performance
- DeepSeek DeepEP
- NVIDIA DOCA GPUNetIO
- UCX
Benchmark / 遥测
- linux-rdma/perftest
- linux-rdma/rdma-core
- NVIDIA DCGM Exporter
- rdma_exporter
- Meta GPU Cluster Monitoring, GCM