InfiniBand与RoCE都能为NCCL提供RDMA传输，因此PoC不能只证明“能跑通”。真正要回答的是：在目标节点规模、消息范围和并发作业下，哪套Fabric的有效带宽、尾部延迟和故障恢复更符合生产要求。

第一步固定服务器侧条件。记录GPU与NIC的PCIe拓扑、NUMA亲和性、GPUDirect RDMA状态、网卡固件、驱动和NCCL版本。若两套方案使用不同的GPU-NIC路径，最终差异可能来自服务器内部，而不是网络协议。

第二步固定拓扑与端口预算。接入带宽、Leaf上行、Spine容量、ECMP路径和故障后剩余带宽应保持可比。测试范围至少覆盖同Leaf、跨Leaf、跨Spine；规模化测试前，先用ibstat、mlxlink及基础RDMA工具确认链路速率和健康状态。

InfiniBand侧重点是子网管理、路由、自适应路由状态、HCA与交换机计数器，以及Fabric管理基线。具备SHARP等集合通信能力时，还要明确是否启用、软件版本与测试条件，不能把不同功能状态的结果直接对比。

RoCE侧需要核对DSCP或PCP映射、队列、PFC、ECN、CNP、缓冲区和网卡拥塞控制。不要把“PFC计数为零”当成唯一目标，也不要看到计数增长就判断故障；应把计数变化与NCCL吞吐、队列深度和尾部延迟放到同一时间线上分析。

第三步运行NCCL Tests。固定消息大小范围、进程与GPU映射、运行轮次和持续时间，记录算法带宽、总线带宽及多轮方差。再加入多作业并发和链路故障，观察性能隔离、收敛时间和恢复后的稳定性。单次峰值不能代表生产质量。

测试期间需要统一时间戳。把NCCL结果、交换机端口计数器、网卡统计和GPU利用率放到同一时间线，才能判断吞吐下降之前究竟发生了队列堆积、链路错误，还是服务器侧等待。只保留最终平均值，会丢掉最关键的因果线索。

软件版本也是边界条件。驱动、固件、NCCL、操作系统、交换机系统和管理组件应使用经过验证的组合，并写入测试记录。参数从另一套集群复制过来，不代表在当前版本与拓扑上仍然合理。

建议再做一次回归：调整拥塞参数或升级固件后，重新执行同一组测试，并保留变更前后的配置快照。没有可重复基线，就无法证明优化有效，也难以在出现回退时快速恢复。

最后把测试结果与运维成本一起评审：日常监控是否能覆盖GPU到端口、告警能否定位到队列或Fabric、团队是否能独立完成升级和故障处理。性能测试通过但无法持续维护的方案，仍然不是合格的生产选型。