一个 RoCE 交换网络可能所有接口都正常启用，但应用性能却表现不一致。因此，验收应当依次通过独立的证据层进行：物理连接、主机传输、交换网络行为和应用程序。跳过任何一层都会使后续故障更难定位。
建立可复现的基线
冻结服务器镜像、网卡驱动和固件、交换机软件、拓扑和互连清单。记录已批准的队列和拥塞设置。在不同基线下进行的测试不应合并为一个无法解释的结果。
在运行流量之前，选择工作负载负责人和验收标准。标准应描述有用的结果——例如稳定完成一个定义的集合通信工作负载——而不是端口标称速率的任意百分比。
按递增范围进行验证
| 阶段 | 测试内容 | 通过不能证明什么 |
|---|---|---|
| 物理链路 | 模式、诊断和错误计数器变化 | RDMA 或应用正确性 |
| 主机对 | 支持的传输和代表性消息大小 | 全集群扩展能力 |
| 并发组 | 多个通信组和共享路径 | 所有可能的流量模式 |
| 完整工作负载 | 定义的集合通信或应用运行 | 无关软件的性能 |
| 受控故障 | 约定的链路或设备事件及恢复 | 所有故障下的无中断行为 |
在每个阶段，保留精确的拓扑和端点位置。当生产作业跨越交换网络时，同机架的良好结果不应替代跨机架测试。
在拥塞发生时进行观察
在测试期间捕获队列、拥塞通知和相关流量控制指标。将它们与端点错误、适用的重传相关观察以及工作负载完成行为关联起来。最终的计数器快照可能掩盖问题发生的时间。
使用所选版本中记录的 RoCE 配置文件作为配置参考。避免通过启用未包含在已审核设计中的广泛 PFC 设置来“修复”无法解释的结果。R08
使集合通信结果可解释
对于 NCCL Tests 或类似工具，保留命令、消息大小范围、进程/GPU 放置、传输选择和软件版本。区分工具报告的指标与物理线路有效吞吐量。仅在相关条件匹配时比较结果。R11
作为一个示例性序列，先测试一个服务器对，然后测试几个独立的对，再测试跨机架的代表性 all-reduce 组。这是一个诊断性递进过程，不是通用性能标准，也不保证特定工具能检验所有应用需求。
在验收期间保护生产环境
在批准的时间窗口或隔离的验证域中运行可能具有破坏性的饱和与故障测试。实验室基准测试方法不应不加区分地应用于实时共享网络。R47
停止条件应包括管理访问丢失、测试范围之外的意外影响或持续错误超过约定限制。将恢复操作记录为结果的一部分。
验收包应将每个结果与需求和配置基线关联起来。未解决的异常应保持可见并指定负责人；它们不应消失在“800G 链路已启用”的说法背后。
配套工程示意图
以下配图用于说明本篇设计思路，图中英文术语可结合文末释义阅读；不代表实测结果、认证配置或随货清单。
专业术语说明
- RoCE 基于融合以太网的远程直接内存访问RDMA over Converged Ethernet
- 在以太网上承载 RDMA（远程直接内存访问）的协议。数据传输可由适配器卸载，减少处理器参与和内核数据复制；并非所有过程都完全绕过 CPU。部署时需核对端点、拥塞控制和整条路径。
- PFC 基于优先级的流量控制Priority-based Flow Control
- 一种链路级流量控制机制，可为不同优先级流量独立暂停，防止拥塞丢包。本篇中强调避免启用未审核的广泛PFC设置来掩盖问题，应参考所选版本的RoCE配置文件。
- NCCL Tests 集合通信测试工具NCCL Tests
- NVIDIA集合通信库（NCCL）的测试套件，用于评估GPU间集合通信性能。本篇中要求保留命令、消息大小、进程/GPU放置等条件，并区分工具指标与物理线路吞吐量。
- all-reduce 全规约all-reduce
- 一种集合通信操作，所有参与进程贡献数据并最终获得相同的规约结果。本篇中作为代表性集合通信工作负载，用于跨机架验收测试，但强调其仅为诊断序列而非通用标准。
- 拥塞通知congestion notification
- 网络设备在检测到拥塞时向端点发送的反馈信号，通常用于触发速率调整。本篇中要求在测试期间捕获该指标，并与端点错误和工作负载完成行为关联分析。
延伸阅读
资料来源
资料核对：
参数、兼容性与操作步骤应结合文中引用资料、完整型号及实际软件版本核对。配图为工程示意。