谈到 B300 集群网络，最常见的问题是：
RoCE 设备是不是主要指交换机？
从采购分类看，确实如此。
GPU 服务器通常已经配置了网卡，真正需要独立比较品牌、型号和数量的，主要是 Leaf、Spine 交换机。因此，行业里经常把“RoCE 设备选型”简化成“RoCE 交换机选型”。
但从系统架构看，这个理解并不完整。
RoCE 不是一种交换机，也不是交换机上的一个功能开关。
它是一套由 GPU、服务器内部拓扑、RDMA 网卡、交换网络、光链路、拥塞控制、路由机制、管理软件和通信框架共同组成的端到端 GPU 网络。
交换机只是其中最显眼的一层。
真正需要采购和交付的，不是一批高速端口，而是一套能够让数百乃至数千块 GPU 稳定完成分布式通信的 GPU Compute Fabric。
ReelOS.AI 禅定｜一句话看懂本文
不是把 B300 服务器连接到一批 800G 交换机，就建成了 RoCE 网络。
- 模型规模扩大
- 单台服务器无法容纳完整计算任务
- 训练开始跨越大量 GPU 节点
- NCCL 持续产生 AllReduce、AllGather 和 All-to-All 通信
- 大量 GPU 在相近时间向网络发送高速流量
- 普通以太网开始出现路径碰撞、队列拥塞和尾部延迟
- 一条慢链路就可能让整个同步任务等待
- 网卡必须及时感知拥塞并调整发送速率
- 交换机必须准确标记拥塞并分散流量
- 光模块和线缆必须长期保持低误码
- 双平面必须在故障时继续提供有效路径
- 遥测系统必须找到每一条慢链路和异常队列
- NCCL 必须证明网络真正提升了 GPU 有效利用率
- RoCE 的建设单位因此不是一台交换机
- 而是一套从 GPU 显存到 GPU 显存的端到端通信系统
一、为什么大家总把 RoCE 设备理解成交换机
原因在于，服务器侧的网络端点通常已经随着 GPU 服务器一起确定。
以标准 NVIDIA DGX B300 为例，一台系统配置：
- 8 个 B300 GPU；
- 8 张 ConnectX-8 网卡；
- 8 个最高 800Gb/s 的 InfiniBand/Ethernet OSFP 接口；
- 2 张双端口 BlueField-3 DPU；
- ConnectX-8 通过 PCIe Gen6 直接连接 GPU。
其中，ConnectX-8 面向集群计算网络，BlueField-3 主要面向存储和管理网络。
当服务器平台已经确定后，项目团队真正需要比较的通常是：
- Leaf 交换机；
- Spine 交换机；
- 光模块和线缆；
- 网络操作系统；
- 控制器与遥测平台。
因此，交换机成为 RoCE 项目中最容易被单独识别的设备。
但需要注意：
交换机不负责发起 GPU RDMA 通信。
真正发起和接收 RDMA 数据的是服务器网卡。交换机负责为这些数据提供低拥塞、低丢包、可预测的传输路径。
所以更准确的表达应该是：
RoCE 交换机是 RoCE 网络的重要组成部分，但交换机本身不等于 RoCE 网络。
二、RoCE 的两个“端”到底在哪里
“端到端”中的两个端，不是两台交换机。
而是：
起点：一块 GPU 的显存
终点：另一块 GPU 的显存完整的数据路径大致是：
训练框架 / NCCL
↓
GPU A 显存
↓
PCIe / GPUDirect RDMA
↓
ConnectX-8 SuperNIC
↓
DAC / AEC / 光模块
↓
Leaf 交换机
↓
Spine 交换机
↓
目标 Leaf 交换机
↓
光模块 / 线缆
↓
目标 ConnectX-8
↓
GPU B 显存只要其中任何一层出现性能瓶颈，最终表现出来的都是同一个结果：
GPU 等待网络。
这也是为什么 GPU 网络不能只按交换机端口速率设计。
端口显示 400G 或 800G，并不意味着 GPU 应用能够获得同等的有效通信带宽。
三、一套完整的 RoCE 设备体系包括什么
Ultra Ethernet Consortium 在其 Ethernet AI/HPC 通信架构中，明确把 NIC、交换机、光模块和线缆视为完整网络栈的一部分，并将传输、拥塞控制、直接内存访问、链路与安全纳入同一套架构。
从 B300 集群工程角度，可以把 RoCE 设备拆成六层。
第一层：GPU 与服务器内部互联
这一层包括：
- B300 GPU；
- NVLink；
- PCIe Gen6；
- CPU NUMA；
- GPU 与 NIC 的拓扑关系。
服务器内部拓扑决定了 GPU 数据到达网卡之前是否已经产生瓶颈。
例如，两种服务器都可能标称“8×B300、8×800G”，但实际设计可能不同：
方案一：
每块 GPU 对应一张独立 NIC
方案二：
多块 GPU 共享 NIC 或 PCIe Root Complex两者的理论端口带宽可能相同，但 GPU 可获得的稳定有效带宽并不一定相同。
所以第一项设计不是交换机，而是确认：
GPU、NIC、PCIe 和 NUMA 是否形成正确的本地拓扑。
第二层：RoCE 网卡与 SuperNIC
RoCE 网卡负责：
- 发起和接收 RDMA；
- GPUDirect RDMA；
- 队列管理；
- 拥塞反馈处理；
- 发送速率调整；
- 多路径流量处理；
- 数据包重排；
- 与 GPU 通信软件协同。
在 DGX B300 中，8 张 ConnectX-8 通过 PCIe Gen6 直接连接 GPU，这使服务器内部的 GPU 到网络路径成为整机设计的一部分，而不是后期外挂的普通网卡。
因此，服务器侧需要明确五个问题：
- 每块 GPU 对应多少网络带宽；
- GPU 与 NIC 是否接近 1:1 映射；
- 使用单 400G、单 800G，还是双 400G 平面；
- NIC 与 GPU 是否位于正确的 PCIe 和 NUMA 位置；
- 网卡固件、驱动和交换机功能是否完成兼容验证。
如果这一层设计错误，增加交换机数量也无法解决服务器内部的拥塞。
第三层：Leaf 与 Spine 交换机
交换机主要负责三件事：
转发
将 GPU 流量从源节点送到目标节点。
控制拥塞
在队列开始积压时识别拥塞、进行 ECN 标记，并与网卡端的拥塞控制形成闭环。
分散流量
将大量并行通信分配到不同路径，避免少数链路拥塞而其他链路空闲。
传统数据中心交换机通常关注：
- 端口是否足够；
- 总交换容量是否足够；
- 路由是否可达。
AI Compute Fabric 还需要关注：
- 瞬时拥塞；
- 多对多流量；
- 尾部延迟；
- 路径极化；
- 负载不均；
- 长任务稳定性；
- 故障后的任务连续性。
因此，同样是“64×800G”，不同产品的实际价值可能完全不同。
真正需要比较的是：
- 交换 ASIC；
- 端口基数；
- 800G Breakout；
- Buffer 架构；
- ECN 精度；
- PFC Watchdog；
- Adaptive Routing；
- Packet Spray 或 Flowlet；
- 队列级遥测；
- 网络操作系统；
- 自动化与故障定位。
端口规格决定网络能不能连接，拥塞控制决定网络能不能工作。
第四层：光模块、线缆与物理链路
这一层包括：
- 800G OSFP；
- 400G QSFP112；
- 800G 拆分 2×400G；
- DAC；
- AEC；
- 多模光模块；
- 单模光模块；
- MPO 或 LC 光纤；
- 配线架；
- 光纤路径。
它们不是交换机附属品，而是 GPU 网络的物理传输层。
在大型集群中，常见问题不是链路完全断开，而是链路仍然处于 Up 状态，但持续出现：
- FEC Corrected Error；
- BER 异常；
- 光功率接近临界值；
- 某个 Lane 性能下降；
- 温度升高后误码增加；
- AEC 固件兼容问题；
- Breakout 子链路不稳定。
这些问题不会立刻让网络中断，却可能持续降低 NCCL 有效带宽。
NVIDIA 也要求根据 ConnectX 固件对应的验证列表选择受支持的线缆、适配器和交换机，而不是仅根据接口形态采购任意光模块。
所以应该把光链路理解为：
交换机提供理论带宽，光链路决定这部分带宽能否长期存在。
第五层：控制器、网络操作系统和遥测平台
网络规模较小时，管理员可以通过命令行逐台检查交换机。
到了数百节点，这种方式已经不可行。
RoCE 网络需要持续看到：
- 每个端口的吞吐量；
- ECN Mark；
- PFC Pause 次数和持续时间；
- 队列深度；
- Buffer Watermark；
- FEC Error；
- BER；
- 收发光功率；
- RDMA 重传；
- 路径利用率；
- Plane A 与 Plane B 的负载差异；
- NCCL 有效带宽；
- GPU 通信等待时间。
在 NVIDIA B300 SuperPOD 参考架构中，NetQ 用于 Spectrum-X 网络的实时遥测、健康检查、网络验证和故障排查。
不同交换机厂商的差异，也不仅存在于硬件，而是存在于整套运维系统：
- NVIDIA：Spectrum-X、NVIDIA Route、NetQ；
- Arista：EOS、CloudVision；
- Cisco：NX-OS、Nexus Dashboard；
- Juniper：Junos、Apstra；
- 华为：VRP、NCE-Fabric；
- 白盒方案：SONiC 加自建遥测体系。
一套网络能否被看见，和它能否转发数据同样重要。
第六层：NCCL、调度系统和任务验证
网络最终不是给交换机管理员使用的，而是给 GPU 任务使用的。
最上层包括：
- NCCL；
- CUDA；
- PyTorch；
- DeepSpeed；
- Megatron；
- Slurm；
- Kubernetes；
- 训练框架和并行策略。
网络是否成功，最终要通过任务表现判断：
- NCCL Bus Bandwidth；
- NCCL Algorithm Bandwidth；
- AllReduce 性能；
- All-to-All 性能；
- GPU 利用率；
- 通信等待时间；
- Job Completion Time；
- 长任务成功率。
所以，NCCL 不是网络建成之后才运行的应用测试。
它本身就是 GPU 网络的验收工具。
四、为什么 B300 集群尤其强调端到端架构
普通服务器网络中的一条慢链路，通常只影响部分请求。
分布式训练不同。
大量 GPU 会按照同步节奏完成计算和通信。当某一块 GPU、某一张 NIC 或某一条路径变慢时，其他 GPU 即使已经完成计算，也必须等待最慢的参与者。
可以把它理解为：
因此，AI 网络追求的不是单端口峰值，而是：
- 高有效带宽；
- 低尾部延迟；
- 路径性能一致；
- 故障时可降级；
- 长时间运行可预测。
NVIDIA 将 Spectrum-X 定义为 Spectrum-4 交换机与 ConnectX-8 网卡紧密协同的网络平台，而不是单独的交换机产品。
这反映出一个重要变化：
AI 网络的竞争单位，正在从单台设备转向端到端系统。
五、B300 端到端架构究竟包括哪些设计
“先确定端到端架构，再选择交换机”，至少需要先确定八件事。
1. 工作负载
需要明确：
- 预训练还是推理；
- Dense 模型还是 MoE；
- 数据并行、张量并行还是专家并行；
- 单任务还是多租户并发；
- AllReduce 多还是 All-to-All 多；
- 是否存在大量 Checkpoint 流量。
MoE 的 All-to-All 与传统数据并行的 AllReduce，对网络的压力模式并不相同。
所以网络设计必须从模型通信模式开始，而不是从交换机目录开始。
2. 节点内部拓扑
需要明确：
- 每节点多少 GPU；
- 每节点多少 NIC；
- GPU 与 NIC 的对应关系；
- 每 GPU 获得多少带宽；
- PCIe 和 NUMA 是否正确对齐；
- 是否支持 GPUDirect RDMA。
这是确定服务器侧端口数量的基础。
3. 网络分层
一个完整 GPU 集群通常至少包含：
Compute Fabric
GPU 与 GPU 之间的训练通信
Storage Fabric
训练数据、Checkpoint、并行文件系统
In-band Network
Slurm、Kubernetes、镜像和用户访问
Out-of-band Network
BMC、PDU、交换机和液冷设备管理需要决定：
- 四张网络完全分离；
- Compute 独立，Storage 与 In-band 融合；
- 哪些流量可以使用 RoCE；
- 哪些流量必须与训练网络隔离。
训练通信与存储流量的目标不同，不应在没有明确容量模型的情况下随意混合。
4. Compute Fabric 拓扑
需要决定：
- 单平面还是双平面；
- Rail-Aligned 还是普通 Clos；
- Leaf-Spine 还是三层网络；
- 是否 1:1 无阻塞；
- 每个扩展单元包含多少节点；
- 单台交换机故障影响多少 GPU。
NVIDIA B300 SuperPOD 使用双平面设计，两个独立平面不在 Core 层互联，因此可以在两层 Leaf-Spine 下扩展到更大规模。ConnectX-8 上的平面负载均衡能力与 NVIDIA Route 配合，将流量分配到更合适的路径；单链路故障时，应用仍可通过另一条路径继续运行。
双平面的价值不是简单将带宽翻倍，而是同时提供：
- 多路径；
- 故障隔离；
- 降级运行；
- 更大的两层网络规模。
5. 拥塞控制
需要确定：
- 使用什么 ECN 阈值；
- 网卡使用什么拥塞控制算法；
- 哪个优先级启用 PFC；
- PFC 何时触发；
- 如何避免 Pause Storm；
- 是否启用 PFC Watchdog；
- 不同流量进入什么队列；
- 队列和 Buffer 如何分配。
合理的原则应当是：
ECN 负责主动减速，PFC 负责极端状态保护。
而不是让网络长期依赖 Pause 保持无丢包。
6. 多路径与负载均衡
普通 ECMP 通常以流为单位选择路径。
在 GPU 网络中，少数大流可能被哈希到同一条路径：
路径一：严重拥塞
路径二：严重拥塞
路径三：利用率很低
路径四：利用率很低此时网络拥有足够的总带宽，却没有足够的有效带宽。
因此，需要确定使用：
- ECMP；
- Flowlet；
- Adaptive Routing；
- Dynamic Load Balancing；
- Packet Spray；
- 多平面负载均衡；
- 端侧数据包重排。
Spectrum-X 的细粒度自适应路由会根据网络状态把流量分散到不同路径，以减少传统静态 ECMP 产生的路径利用不均。
这里体现出端到端设计的必要性：
如果交换机按包分散流量，网卡端就必须能够正确处理乱序。
只更换交换机，而不考虑 NIC 和软件能力，无法形成完整方案。
7. 物理故障域
需要明确：
- Plane A 与 Plane B 是否使用独立交换机；
- 是否采用独立光纤路径；
- 是否使用不同 PDU；
- 是否放在不同网络机柜；
- Spine 是否集中形成单点故障；
- 交换机升级是否会同时影响两个平面。
如果两个平面共用：
- 同一个机柜；
- 同一个 PDU；
- 同一条光纤路由；
- 同一组配线架；
那么它们逻辑上是双平面，物理上仍然可能是单故障域。
真正的双平面必须尽可能做到：
独立交换机
+
独立链路
+
独立供电
+
独立布线路径
+
独立维护窗口8. 任务级验收标准
在采购前就需要定义验收标准，而不是设备安装完成后再临时决定。
验收对象至少包含三层。
网络层
- 端口吞吐量；
- ECN；
- PFC；
- Queue Occupancy；
- FEC；
- BER；
- 光功率；
- 路径利用率。
RDMA 层
- RDMA Read/Write 带宽；
- 消息时延；
- P99 和 P999；
- 拥塞恢复速度；
- 多路径有效利用率。
GPU 任务层
- NCCL AllReduce；
- NCCL AllGather；
- ReduceScatter；
- All-to-All；
- GPU 利用率；
- Job Completion Time；
- 单链路故障；
- 单 Leaf 故障；
- 单 Spine 故障；
- 单 Plane 降级；
- 长时间任务完成率。
最终验收标准不是：
每个端口是否跑到了 400G。
而是：
网络是否让 GPU 在真实任务中保持高利用率，并稳定完成长周期训练。
六、为什么“先买交换机，再设计网络”容易失败
一种常见的项目流程是：
先选择一台 64×800G 交换机
↓
根据端口数计算数量
↓
连接 B300 服务器
↓
配置 PFC 和 ECN
↓
运行 NCCL这种方式的问题是，交换机被当成了架构起点。
但在没有确定下列问题之前，交换机数量和型号都没有可靠依据：
- 每块 GPU 是单 400G 还是双 400G；
- 是单平面还是双平面；
- 是否需要 Rail-Aligned；
- 是否要求 1:1 无阻塞；
- 主要运行 AllReduce 还是 All-to-All；
- 是否需要 Packet Spray；
- NIC 是否支持对应的乱序处理；
- 存储流量是否独立；
- 单个故障允许影响多少 GPU；
- 需要监控哪些网络与任务指标。
同样一台 64×800G 交换机，在不同架构里可能承担：
- Compute Leaf；
- Compute Spine；
- Storage Leaf；
- 汇聚交换机；
- 业务网络交换机。
设备相同，系统角色完全不同。
所以正确顺序应该是：
确定工作负载
↓
确定GPU与NIC拓扑
↓
确定每GPU带宽
↓
确定网络分层
↓
确定Plane与Rail
↓
确定无阻塞比例
↓
确定拥塞和多路径机制
↓
确定物理故障域
↓
确定验收标准
↓
最后选择交换机七、不同厂商真正比较的不是端口，而是系统闭环
选择 NVIDIA、Arista、Cisco、Juniper、华为或白盒交换机时，不应只比较：
| 厂商 | 端口 |
|---|---|
| 厂商A | 64×800G |
| 厂商B | 64×800G |
| 厂商C | 64×800G |
更有价值的比较方式是：
| 比较维度 | 需要回答的问题 |
|---|---|
| NIC协同 | 是否与ConnectX-8完成端到端验证 |
| 拥塞控制 | ECN、PFC和端侧算法如何配合 |
| 多路径 | 普通ECMP、Flowlet还是Packet Spray |
| 乱序处理 | 由NIC、交换机还是软件处理 |
| Telemetry | 能否看到队列、ECN、PFC、FEC和路径状态 |
| 自动化 | 能否批量配置、验证和回滚 |
| 光链路 | 支持哪些经过验证的模块和线缆 |
| 故障模型 | 单链路和单交换机故障时任务是否继续 |
| 任务验证 | 是否经过真实NCCL和模型工作负载测试 |
| 责任边界 | 出现性能问题后由谁负责定位 |
NVIDIA 的优势在于 GPU、ConnectX、Spectrum 交换机、Route、NetQ 和 NCCL 形成较完整的闭环。
开放厂商方案的优势在于选择更多、网络体系更开放，也可能与现有数据中心运维系统更容易融合。
但开放不等于简单。
选择多厂商方案后，建设方需要自己承担更多工作：
- 参数匹配；
- 固件矩阵；
- 光模块兼容；
- 拥塞控制调优；
- NCCL 验证；
- 故障责任划分。
所以厂商选型的本质不是：
谁的交换机更快？
而是：
谁能以可接受的成本，交付一套性能可预测、故障可定位、长期可运营的 GPU 网络？
八、正确的 B300 RoCE 采购对象是什么
采购清单不应只有：
交换机型号
交换机数量
光模块数量还应包括：
- 服务器侧
-
- GPU/NIC 拓扑
- ConnectX 固件
- DOCA-OFED
- GPUDirect RDMA
- NUMA 和 PCIe 绑定
- 网络侧
-
- Leaf
- Spine
- Plane
- Rail
- ECN
- PFC
- QoS
- Adaptive Routing
- Telemetry
- 物理侧
-
- DAC
- AEC
- 光模块
- 光纤
- Breakout
- 配线架
- 布线路径
- 冗余供电
- 管理侧
-
- 网络控制器
- 配置自动化
- 固件管理
- 日志
- 告警
- 网络验证
- 故障定位
- 验收侧
-
- RDMA 测试
- NCCL 测试
- 多任务并发
- 故障注入
- 长时间稳定性
- GPU 利用率
- Job Completion Time
最终采购对象应该被定义为：
B300 GPU Compute Fabric 端到端交付。
而不是：
800G 交换机采购项目。
九、一个真正有价值的 PoC 应该测试什么
很多 RoCE PoC 最终只验证了：
- Ping 可以通信；
- iperf 可以跑满；
- RDMA 可以建立连接；
- 单条链路可以达到标称带宽。
这些测试只能证明基础连通性。
真正的 B300 PoC 应该分为五个阶段。
第一阶段：单节点与单链路
验证：
- GPU/NIC 拓扑；
- PCIe 带宽；
- 单端口 RDMA；
- GPUDirect RDMA；
- 光模块和 FEC 状态。
第二阶段：单 Leaf
验证：
- 同 Leaf NCCL；
- 多端口同时通信；
- ECN 触发；
- PFC 是否异常出现；
- Leaf 本地拥塞。
第三阶段：跨 Spine
验证：
- ECMP 或 Adaptive Routing；
- 多路径利用率；
- 跨 Leaf AllReduce；
- 跨 Leaf All-to-All；
- 路径极化。
第四阶段：多任务并发
验证：
- 多个 NCCL Job 同时运行；
- 大流与小流并发；
- Compute 与 Storage 并发；
- 性能隔离；
- 尾部延迟。
第五阶段：故障与长稳
验证：
- 拔掉一条链路；
- 关闭一台 Spine；
- 关闭一台 Leaf；
- 中断一个 Plane；
- 制造链路误码；
- 连续运行真实任务；
- 检查任务是否继续以及性能下降幅度。
PoC 的目标不是证明设备能用。
而是证明：
整套网络在拥塞、并发和故障条件下仍然可预测。
十、最终判断
RoCE 设备主要是交换机吗？
在采购分类中，主要讨论的是交换机。
因为服务器侧 NIC 通常随 B300 平台确定，而交换机品牌、型号、数量和网络操作系统仍有较大选择空间。
但从系统架构看：
RoCE 设备绝不只是交换机。
它至少包括：
GPU负责计算
NIC负责发和收
交换机负责转发和控制拥塞
光模块和线缆负责传输
控制器负责保持配置一致
遥测系统负责发现异常
NCCL负责验证真实效果
调度系统负责将任务放到正确的网络故障域B300 集群不是在采购一批端口。
它是在构建一条从 GPU 显存到 GPU 显存的高速数据路径。
这条路径必须同时满足：
- 带宽足够；
- 路径均衡；
- 拥塞可控；
- 链路稳定；
- 故障可降级；
- 状态可观测；
- 任务可完成。
因此，B300 RoCE 网络的建设原则应该是：
先确定模型和通信，再确定网络。
先确定端到端架构，再选择交换机。
先验证任务完成率，再比较端口价格。
网络建设的目标不是让交换机跑满，而是让 GPU 不再等待。