GPU 集群中的 RoCE 与 InfiniBand：延迟、运维与成本

大多数 RoCE 与 InfiniBand 的争论都起点错误。它们比较的是协议名称，而不是先问 GPU 集群必须承受什么：紧耦合训练、分片推理、共享存储流量、多租户、采购限制，以及上线后将调优网络的运维团队。

对于多节点 GPU 集群，当工作负载对延迟敏感、集合通信占比高，并且规模足以证明采用专用 AI/HPC 网络的合理性时，InfiniBand 通常是更稳妥的默认选择。当团队已经在运营高速以太网、希望获得更广泛的厂商选择，并且能在正式采用前用真实的 NCCL 测试证明无损以太网设计时，RoCE 通常是更好的起点。

难点在于，两者都能工作，也都可能失败。一个构建良好的 RoCE v2 网络可以运行严肃的 AI 集群；一个运维不佳的 InfiniBand 网络也可能错过训练窗口。本指南从roce vs infiniband 的延迟、运维和成本三个角度进行比较，帮助平台团队选择与工作负载匹配的网络，而不是被最响亮的厂商幻灯片所左右。

RoCE vs InfiniBand 快速答案

将下表作为第一轮决策过滤器。

实际答案是：当应用需要专用 AI/HPC 网络，并且希望将协议层调优风险降到最低时，选择 InfiniBand。当以太网标准化、采购灵活性或既有运维能力的重要性足以证明额外网络工程的价值时，选择 RoCE。

GPU 集群中的 InfiniBand 是什么

InfiniBand 是一种行业标准的交换式网络架构，用于互连服务器和存储。在 GPU 集群中，它通常与低延迟、高带宽、RDMA、GPU Direct RDMA、自适应路由、拥塞管理以及厂商集成的 AI/HPC 工具链相关联。

关键点不只是 InfiniBand 很快。关键点在于它是作为一个网络体系来构建的。子网管理、网络层行为、虚拟通道、服务质量、网内加速，以及交换机/适配器集成都属于其设计边界的一部分。当一个训练任务横跨数百或数千块 GPU，而每一次集合通信都会放大尾延迟时，这一点就尤为重要。

云端示例展示了这种网络为何仍主导着许多大型 AI 集群。Azure 的 ND H100 v5 文档描述了每个 VM 配备 8 块 H100 GPU、每块 GPU 具有专用的 400 Gbps NVIDIA Quantum-2 CX7 InfiniBand 连接、每个 VM 具备 3.2 Tbps 的互连带宽、支持 GPU Direct RDMA，以及面向 NCCL 的横向扩展集群。这些细节并不是泛泛的“高速网络”说法；它们是会影响分布式训练行为的集群形态事实。

对于买家来说，InfiniBand 的问题应该问得更具体：

• 包含的是哪一代 InfiniBand 和哪种交换平台？
• 每个节点连接了多少 NIC 或主机通道适配器？
• 每块 GPU 是映射到专用网络路径，还是流量被聚合了？
• 是否启用了并测试了 GPUDirect RDMA？
• 什么样的放置保证能确保这些节点处于同一个网络域？
• 供应商负责哪些网络管理、遥测和故障修复？

如果卖方只说“包含 InfiniBand”，那这份报价就是不完整的。

GPU 集群中的 RoCE 是什么

RoCE 指的是基于融合以太网的 RDMA。RoCE v2 在可路由的以太网/IP 网络上传输 RDMA，这使团队能够使用以太网交换，同时绕过普通 TCP 路径所带来的大部分 CPU 和内核开销。

这就是它的吸引力。RoCE 可以让 AI 平台团队用以太网交换机、以太网运维实践和更广的采购面来构建支持 RDMA 的 GPU 集群。对于已经大规模运行高速以太网的组织来说，RoCE 更容易纳入变更控制、遥测、布线、光模块和供应商管理之中。

代价在于，RoCE 依赖以太网网络在负载下保持良好行为。GPU 集合通信会产生同步突发流量。检查点和存储流量可能与训练流量发生冲突。拥塞会演变为延迟尖峰。对于 RDMA 而言，丢包的代价可能远高于普通应用流量。

因此，RoCE 集群设计通常包括：

• 优先流量控制（Priority Flow Control）或其他经过验证的无损策略。
• 显式拥塞通知（Explicit Congestion Notification）和拥塞控制调优。
• 跨交换机和 NIC 的数据中心桥接（Data Center Bridging）配置。
• 队列、服务等级（class-of-service）和 DSCP/优先级映射规范。
• 按优先级统计丢包、暂停帧、ECN 标记、重传和缓冲区压力的计数器。
• 对固件、交换机操作系统、NIC 驱动、MTU 和路由策略进行严格的变更控制。

RoCE 可以非常出色，但把它理解为“它只是以太网”是一种错误的思维模型。在 GPU 集群中，RoCE 是为 RDMA 流量工程化设计的以太网网络。

延迟：比较尾部行为，而不只是中位数

在 roce vs infiniband 的决策中，平均延迟不如真实集体负载下的尾部行为有用。

分布式训练通常要等待最慢的参与者。少数延迟更高的 rank 可能会拖慢整个步骤。对于分片推理，p95 和 p99 网络延迟可能会体现在面向用户的延迟上，或者降低批处理效率。对于存储密集型训练，检查点流量可能会产生在干净的微基准测试中看不见的突发流量。

从四个层面进行测量：

InfiniBand 往往更有优势，因为许多集群设计从一开始就是围绕以集合通信为主的工作负载来构建和验证的。只要以太网网络结构经过调优、隔离并得到验证，RoCE 也可以缩小差距。测试的重点不是 RoCE v2 是否理论上可以做 RDMA，而是这套具体的交换机/NIC/布线/驱动/拓扑组合在你实际运行的工作负载下，能否维持 p95 和 p99 表现。

运维：InfiniBand 是专用方案，RoCE 是集成方案

运维是 roce vs infiniband comparison 变得不那么明显的地方。

InfiniBand 为平台团队提供了一个具有成熟 AI/HPC 假设的专用网络结构。这可以减少调优歧义。缺点是团队需要 InfiniBand 专门技能、网络管理工具、子网管理器知识和支持路径。如果集群是从专业提供商或超大规模云厂商租用的，其中很多内容可能会被隐藏在提供商的服务边界之后。如果集群是自有的或托管在机房中，这个技能差距就会变得现实。

RoCE 由于运行在以太网上，更自然地适合许多企业网络组织。采购、布线、交换机运维、监控和变更管理模式可能已经存在。风险在于，普通的以太网运维并不够。RDMA 流量需要一致的端到端处理。一次常规的交换机策略变更如果导致 PFC、ECN、队列映射、MTU、哈希或拥塞控制漂移，就可能破坏网络结构。

使用这份运维模型清单：

如果你的团队已经具备强大的以太网自动化能力，但没有 InfiniBand 技能，那么 RoCE 在运维上可能更有吸引力。如果你的团队希望由提供商以经过测试、类似设备的层来负责 AI 网络结构，那么 InfiniBand 可能会降低交付风险。

成本：把网络结构风险算进去，而不只是交换机价格

RoCE 常被描述为更便宜，因为以太网设备更容易广泛采购和复用。InfiniBand 常被描述为昂贵，因为它是专用的 AI/HPC 网络结构。这些说法可能都对，但仍然会导致错误决策。

对于 GPU 集群而言，网络结构成本不只是交换机、NIC、光模块和线缆的价格。它是完成有价值工作的成本。

fabric_adjusted_gpu_cluster_cost =
  compute_capacity
  + network_adapters
  + switches
  + optics_and_cables
  + rack_power_and_space
  + storage_and_data_path
  + fabric_operations
  + failed_job_and_retry_waste
  + queue_delay_and_idle_gpu_time
  + support_and_escalation

然后进行归一化：

cost_per_accepted_training_run =
  fabric_adjusted_gpu_cluster_cost
  / accepted_training_runs_completed_on_time

或者：

cost_per_accepted_output =
  fabric_adjusted_gpu_cluster_cost
  / accepted_inference_outputs_after_retries

当以太网采购、复用和运维在不损害作业完成率的前提下降低总成本时，RoCE 可以胜出。当更高的网络成本能够避免训练延迟、多节点作业失败以及数周调优时，InfiniBand 可以胜出。让昂贵 GPU 闲置的更便宜网络，并不便宜。

将 roce networking vs infiniband 的成本决策绑定到三个数字：

• 在网络停顿和作业失败后仍然有效的 GPU 利用率。
• 在精确节点数下的基准测试通过率。
• 为保持网络稳定所需的运维工时。

如果这些数字缺失，成本模型就还没准备好。

工作负载匹配：训练、推理、存储和混合集群

正确的 roce vs infiniband comparison 取决于流量模式。

分布式训练

分布式训练是 InfiniBand 最强的适用场景。大规模 all-reduce 和 reduce-scatter 操作、同步步骤以及横向扩展作业都会受到抖动影响。如果作业跨越多个节点，并且业务关心按时完成训练窗口，InfiniBand 往往是风险更低的路径。

RoCE 仍然可能是一个有效选择，尤其是在具备成熟以太网/RDMA 实践的组织中。但它必须在你计划运行的同一模型家族、框架、精度、批大小、节点数和检查点模式下得到验证。

分片与分布式推理

推理更为混合。如果模型被拆分到多个 GPU 或节点上，网络延迟就很重要。如果集群主要是彼此独立的副本，GPU 内存、批处理、缓存行为、排队和自动扩缩容可能比网络本身更重要。

对于许多生产推理团队来说，首先更好的问题不是 InfiniBand 还是 RoCE，而是工作负载是否真的需要直接控制 GPU。如果托管模型 API 能达到延迟、质量、隐私和成本目标，那么在签订集群合同之前，先比较这条路径。

相关阅读：Flatkey 关于 GPU 云 vs 模型 API、LLM 推理最佳 GPU 和 vLLM 部署 的指南涵盖了服务侧的成本边界。

存储密集型工作负载

需要加载大规模数据集、频繁写入检查点或重新加载模型权重的训练任务，可能会变成存储网络问题。高速 GPU 网络无法解决缓慢的数据集预热，或在检查点期间被打满的共享文件系统。

对于 InfiniBand 和 RoCE，都应将存储纳入基准测试：

• 数据集加载时间。
• 检查点写入和恢复时间。
• 本地 NVMe 溢出行为。
• 对象存储路径和出站流量。
• 共享文件系统争用。
• 节点故障后的恢复时间。

多租户 GPU 集群

多租户集群需要比基准实验室更强的隔离。邻居噪声、后台存储任务、用户容器和维护窗口都会改变网络行为。InfiniBand 和 RoCE 都需要准入控制、配额、遥测和事件响应。当 RDMA 流量与普通以太网流量共享运维边界时，RoCE 需要额外小心。

任一网络的验收测试

不要把厂商的 infiniband vs roce comparison 当作证明。请在你将要购买或租用的精确集群形态上执行验收测试。

1. 锁定测试物料清单

记录：

• GPU 型号、显存大小以及每节点 GPU 数量。
• CPU、内存、PCIe/SXM 布局、NUMA 和本地 NVMe。
• NIC/HCA 型号、速率、固件和驱动。
• 交换机型号、交换机 OS 和网络代际。
• 光模块、电缆类型和链路速率。
• MTU 和队列配置。
• 放置组、机架、可用区、区域和节点数。
• CUDA、NCCL、MPI、框架、容器镜像和内核版本。

如果这些项目中有任何一项在基准测试后发生变化，请重新测试。

2. 在每个节点上运行 NCCL 测试

NVIDIA 的 nccl-tests 项目是实用的基线，因为它既检查 NCCL 操作的性能和正确性，也支持多节点 MPI 运行。

验收形态示例：

# Build with MPI support.
make MPI=1 MPI_HOME=/path/to/mpi CUDA_HOME=/usr/local/cuda NCCL_HOME=/usr

# Example: 8 nodes, 8 GPUs per node, 64 ranks total.
mpirun -np 64 -N 8 ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 1 \
  -n 50 -w 10 -a 2 -S 1 -J all-reduce-64gpu.json

跟踪：

• 算法带宽和总线带宽。
• 最小、平均和最大延迟。
• 如果启用，则记录每次迭代的 p95/p99。
• rank 异常值。
• 失败的正确性检查。
• 重复运行之间的差异。
• 节点重启、驱动重启或交换机维护事件后的性能。

3. 重放真实工作负载

微基准测试是必要条件，但还不够。重放一个真实的训练或推理作业：

• 相同的模型家族和序列长度。
• 相同的框架和分布式策略。
• 相同的精度、量化和批大小。
• 相同的检查点频率。
• 相同的数据路径。
• 相同的自动扩缩容或作业调度器策略。

然后比较步时、tokens/sec、排队延迟、检查点持续时间、故障恢复和每个已接受输出的成本。

4. 注入故障和拥塞

只在干净环境下通过的网络，不具备生产就绪性。

测试：

• 作业中移除一个节点。
• 一条链路中断或降级。
• 训练期间存储检查点突发。
• 训练作业期间的后台推理负载。
• 交换机/NIC 计数器阈值和告警。
• 厂商对某次 fabric 事故的支持响应。

roce vs infiniband 的赢家，是在这些测试之后仍能让有效工作保持可预测性的 fabric，而不是理论线速更好的 fabric。

InfiniBand 供应商的采购问题

签约前请问这些：

1. 包含的 InfiniBand 具体代际、交换机型号、适配器型号和链路速率是什么？
2. GPUDirect RDMA 是否已为 GPU、驱动和框架栈启用并受支持？
3. 是否保证所有节点都在同一个 fabric 域或同一个放置组中？
4. 对于相同 GPU 数量，你们可以提供哪些 NCCL all-reduce 结果？
5. 谁负责子网管理、固件更新、拥塞调优和事件响应？
6. 是否启用了并支持 SHARP、自适应路由、服务质量或网络内特性？
7. 客户可以看到哪些遥测：端口计数器、拥塞事件、HCA 错误、路由变更以及作业级 fabric 指标？
8. 如果报价的 fabric 无法通过约定的基准测试，财务上会如何处理？
9. 集群扩容时能否不改变拓扑或超额订阅假设？
10. 适用哪些维护窗口、备件和更换时限？

RoCE 供应商的采购问题

签约前请问这些：

1. 该 fabric 是否为 RoCE v2，且能否跨所需拓扑路由？
2. 哪些交换机和 NIC 型号已针对这个确切的 GPU 集群规模进行验证？
3. 需要哪些 PFC、ECN、DSCP、队列、MTU 和拥塞控制设置？
4. RDMA 流量是与普通以太网流量隔离，还是共享？
5. 在 NCCL 负载下，哪些计数器可以证明无损配置运行正常？
6. 如何检测 PFC 风暴、暂停帧堆积、ECN 配置错误和缓冲区压力？
7. 谁负责交换机配置漂移和固件兼容性？
8. 对于相同的节点数和工作负载类别，已有哪些 NCCL 结果？
9. 网络团队能否通过代码复现该配置？
10. 当问题跨越 GPU 驱动、NIC 固件、交换机策略和应用框架时，适用什么支持边界？

决策矩阵

在基准测试之后再使用这个矩阵，不要在之前。

如果矩阵得出的结果相同，就租用或对两者都做基准测试。多节点 GPU 网络太昂贵，不能只根据协议概述来决定。

可复制的 RoCE vs InfiniBand 工作表

在采购文档中使用此表。

最重要的几行不是列出的 fabric 价格，而是基准测试结果、运维负责人、空闲/重试浪费以及扩容路径。

什么时候模型 API 才是更好的答案

一些在研究 roce vs infiniband 的团队，其实还没有准备好采购网络 fabric。他们是在试图降低 AI 输出成本、消除队列延迟，或交付一个产品功能。

如果工作负载不需要自定义权重、直接 GPU 调度、自定义内核、严格放置或硬件级隔离，请先比较托管模型 API。Flatkey 为团队在官方模型和 AI 工具之间提供一把密钥、一个余额和一份使用账单；在产品仍在变化时，这可能比自建 GPU 集群更简单。

当你需要硬件控制时，使用 fabric 路线。当业务指标是可接受的输出，而不是网络所有权时，使用模型/API 路线。

相关 Flatkey 指南：

• GPU 集群 TCO：适用于云租赁、托管和本地部署的成本测算。
• GPU 集群租赁：用于供应商评估和容量合约。
• GPU 租赁价格：了解按需、竞价实例、预留和隐藏成本。
• 无服务器 GPU 与专用 GPU：关于冷启动、闲置容量和控制。

官方来源检查清单

先将官方页面作为来源核查，然后验证你实际购买的具体集群。

不要把这些页面当作验收测试的替代品。把它们当作严肃买家评审所需的最低来源清单。

常见问题

InfiniBand 总是比 RoCE 更快吗？

不是。对于专为低延迟 AI/HPC fabric 构建的场景，InfiniBand 通常是风险更低的选择，但设计良好的 RoCE v2 fabric 也可以表现不错。请使用 NCCL 和应用测试对具体集群进行比较。

RoCE 比 InfiniBand 更便宜吗？

当以太网采购、复用和现有运维降低总成本时，RoCE 可能更便宜。如果无损以太网调优、拥塞事件、失败作业或空闲 GPU 抹掉了这些节省，那么它就不便宜。

RoCE v2 和 InfiniBand 有什么区别？

RoCE v2 在可路由的以太网/IP 网络上传输 RDMA。InfiniBand 是一种专用交换式 fabric 架构，通常用于 HPC 和 AI 集群。运维上的差异在于，RoCE 继承了以太网的设计灵活性和调优负担，而 InfiniBand 则更专注于 fabric 本身。

分布式训练用哪个更好？

对于大规模、强耦合的分布式训练，InfiniBand 往往是更稳妥的默认选择。当以太网 fabric 是隔离的、已调优、可监控并且已用相同训练工作负载验证过时，RoCE 可以是一个强有力的选项。

推理场景哪个更好？

这取决于推理架构。分片模型和跨节点服务更关注 fabric 延迟。独立副本可能更关注 GPU 内存、批处理、缓存命中率、自动扩缩容以及每个可接受输出的成本。

在选择之前我应该做什么基准测试？

在目标节点数量上运行 NCCL all-reduce，回放真实工作负载，包含存储/检查点流量，注入故障或拥塞，并记录 fabric 计数器。roce vs infiniband 的决策应基于这些结果。

最终建议

不要根据通用基准测试来选择 roce vs infiniband。应根据工作负载、运维模型和验收测试来选择。

如果集群是专用 AI/HPC fabric，分布式训练是关键路径，而且错过训练窗口的代价很高，那么选择 InfiniBand。如果以太网标准化、采购灵活性和现有运维更重要，并且团队能够在真实 GPU 工作负载下证明无损 RDMA 行为，那么选择 RoCE。

如果应用只需要 AI 输出，而不需要直接控制 GPU fabric，那么在租用或购买集群之前，先比较 Flatkey 托管的模型/API 路线。最便宜的网络，是你不必运维的网络。