AMD 2.0时代将至，MI450X将如何助其挑战英伟达（五）：AMD与NVIDIA通信库技术差距加速扩大

AMD RCCL与NVIDIA NCCL的鸿沟持续扩大

集体通信库对AI训练与推理至关重要，它们使多块GPU能协同处理同一工作负载。NVIDIA的通信库名为NCCL，AMD则以"复制粘贴"方式分叉出RCCL。自我们2024年12月文章剖析RCCL以来，该团队取得一定进展：MI300X量产一年多后，RCCL终于支持LL128协议。这虽值得肯定，但对比之下，Blackwell首发即完整支持SIMPLE、LL、LL128三大协议。

此外，RCCL最新支持了"轨道优化树"技术——通过减少主干交换机流量提升网络性能，降低路径冲突概率。而该功能在NCCL中已存在多年。

尽管RCCL有所进步，但NVIDIA在GTC 2025宣布的NCCL新特性使差距加速扩大。RCCL团队需更多大规模计算集群资源追赶，至少应获得1,024块MI300级GPU的专属持续集群。AMD管理层更需大幅提升RCCL工程师的限制性股票激励以留住核心人才——这是最关键的基础软件库之一。

由于RCCL是NCCL的"复刻版"，NCCL 2.27/2.28版本的大规模重构将持续扩大CUDA护城河，迫使AMD耗费数千工时同步代码。当AMD工程师疲于追赶时，NVIDIA正全力推进通信栈与算法前沿。此消彼长之下，AMD既难维持现有开发节奏，更遑论实现反超。AMD透露正筹划重写RCCL以摆脱分叉依赖。

在GTC 2025的提问环节中，当NCCL负责人Sylvain Jeaugey被问到是否会对"复制粘贴版"RCCL施以援手，他明确回绝："帮助RCCL迁移？我们通常不参与这类开发。

在此次演讲中，Sylvain还宣布了NCCL即将推出的多项新特性。这些革新包括在NCCL中原生支持对称内存，以及运行速度更快、占用流式多处理器（SM）更少的新算法（从而释放更多SM资源用于计算）。

PyTorch引入的SymmetricMemory API使用户能够轻松利用多GPU扩展编程性，并通过CUDA或Triton编写集体操作或融合计算/通信内核。此前编写多GPU融合计算/通信内核需要大量工作，但借助PyTorch SymMem，所需工作量已大幅缩减。高性能推理内核（如one-shot/two-shot集体操作和all gather融合矩阵乘法内核）现可通过SymmetricMemory轻松实现。

值得注意的是，该功能已在NVIDIA GPU上运行8个月，而AMD GPU至今仍未支持。AMD表示计划在2025年第二季度初步实现对PyTorch SymmetricMemory API的支持。

在即将发布的2.27版本中，allreduce操作在相同消息量下的带宽效率提升4倍，或在消息量缩减至1/4时仍保持同等算法带宽。

而2.28版本将提供设备端API，允许终端用户轻松编写自定义通信/计算融合内核。

NCCL 2.28还将支持InfiniBand和RoCEv2以太网上的GPUDirect Async（IBGDA）。目前NCCL和RCCL中均使用CPU代理来控制横向扩展通信的流控。尽管数据流不经过CPU，但通过CPU发送控制流仍会限制实际性能表现。通过NVIDIA NCCL 2.28与IBGDA的集成（同时支持RoCEv2和InfiniBand），控制流将由GPU直接初始化而无需经过CPU，从而显著提升中小型消息量场景下all2all及基于all2all算法的性能。

另一项目前仅NVIDIA支持的功能是用户缓冲注册。该功能可避免在用户张量与NCCL内部缓冲区间创建冗余拷贝，有助于减少集体操作所需的SM数量并缓解内存压力，最终带来5-20%的端到端训练效率提升。

大多数资深ML工程师都遭遇过令人头痛的NCCL_TIMEOUT/RCCL_TIMEOUT错误或通信停滞问题。NVIDIA NCCL支持ncclras工具，可简化此类问题的调试过程。遗憾的是，RCCL目前尚未包含任何辅助调试的功能。

基础设施软件进展滞后

过去四个月，AMD在软件基础设施层（包括Kubernetes、SDC检测器、健康检查、SLURM、Docker、指标导出器等）取得实质性进展，但其推进速度远不及机器学习库的发展水平。

直到七个月前，AMD仍完全缺乏GPU指标导出功能，这意味着集群运营商无法获取GPU运行状态的可观测性。尽管ROCm自称是开源生态系统，但AMD的GPU指标导出器直至SemiAnalysis向高管层提出该问题（并敦促其践行"开源承诺"的紧迫性）后才开放源代码。需要强调的是，该导出器仍处于开发阶段，多项关键功能缺失且尚未达到NVIDIA开源指标导出器的水平。例如，AMD的导出器目前仍不支持矩阵核心活动度、CU占用率或CU活跃度等指标——这些都是评估工作负载性能的关键参数。现有AMD导出器中唯一的利用率指标GPU_UTIL（正如多数资深ML工程师所知）实际上根本无法准确衡量NVIDIA和AMD GPU的真实利用率。

正如去年12月SemiAnalysis的AMD文章所述，与NVIDIA相比，AMD的Docker用户体验极其糟糕。AMD已承认这一缺陷，并向我们表示正在着手改进，计划在本季度晚些时候公布相关路线图。

与NVIDIA生态相比，AMD当前Slurm+容器的整合状态令人失望。在NVIDIA开源pyxis Slurm环境下，通过"sudo srun --container-name=pytorch"即可轻松启动容器。反观AMD平台，用户必须经历极其复杂的间接操作流程。考虑到AMD内部AI工程师都在使用Slurm+容器的工作方式，当前这种低效的交互体验尤其令人担忧。

我们已多次建议AMD优先解决此问题，通过资金投入和购买Slurm维护团队（SchmedMD）的咨询服务来打造一流的Slurm+容器体验。但截至目前，我们仍未看到任何具体的解决时间表或路线图。

此外，NVIDIA的数据中心管理工具（DCGM）已直接集成NVVS（NVIDIA验证套件），用户仅需运行"sudo dcgmi diag -r"即可完成诊断。而AMD的RVVS（ROCm验证套件）与其数据中心工具（RDC）相互独立，迫使终端用户额外下载组件。我们建议AMD将RVVS整合至RDC，使其用户体验达到NVIDIA DCGM的便捷程度。

同时，AMD的用户体验和验证覆盖度也逊色于DCGM。NVIDIA的DCGM采用分级标识系统（r1、r2、r3、r4），而AMD的NVVS尚未引入类似设计语言。