适用于大规模 AI 基础设施的软件定义 RDMA 网络

*本文编译自enfabrica blog，作者Sujal Das

过去十年间，软件定义网络（SDN）技术经历了跨越式发展，已成为云网络架构的行业标准。这一技术革新为数据中心运营带来了革命性提升：通过实现网络控制与数据转发功能的解耦，运营商得以将底层基础设施从上层应用中抽象出来，使网络控制具备可编程特性。这种架构设计为行业带来了两大核心优势 —— 精细化控制能力与业务灵活性，显著提升了数据中心的运营效率。据统计，采用 SDN 架构的数据中心在新功能部署速度、资源调配精准度等关键指标上均实现了量级提升。

相比之下，同期远程直接内存访问（RDMA）技术的发展路径呈现明显差异。在存储和高性能计算领域，受限于应用场景的基础设施规模，RDMA 始终未能突破小众应用范畴。即使在微软 Azure、亚马逊 AWS 等早期探索大规模部署的云服务商中，RDMA 网络在控制灵活性方面也面临着与传统架构类似的瓶颈。

随着生成式 AI 的爆发式增长，GPU 集群构成的后端网络（又称scale-out网络）在短时间内推动 RDMA 技术进入大规模应用阶段。大语言模型（LLM）训练产生的特殊流量特征 —— 低频突发数据、低熵高利用率 —— 对传统网络架构形成严峻挑战。以 400Gbps RDMA 网卡为例，其瞬时流量可能直接触达设备容量上限，而低熵流量模式更会显著削弱等价多路径（ECMP）负载均衡技术的效能。

这种技术演进的不平衡性正在重塑数据中心网络格局。为应对 AI 军备竞赛的迫切需求，运营商不得不牺牲长期积累的控制灵活性优势，当前主流的 RDMA 部署方案中几乎没有或根本没有解耦，而是普遍采用垂直集成架构，通过机架级定制设计追求短期性能提升。尽管 AI 堆栈中存在一定程度的抽象层设计，但快速迭代的市场压力迫使运营商放弃跨厂商兼容性的技术路线。

因此，数据中心网络已分裂为传统和新网络。存储和计算网络被归类为传统系统，通常称为前端网络，SDN 的价值及其用途在该领域仍然存在。GPU 的后端网络相对较新，这个领域没有太多 SDN。这两个世界已经分裂。

根据阿里巴巴的生产统计数据显示，LLM 训练中的故障可能给公司造成的损失是一般云计算的 20 倍。随着 GPU（包括 AI 加速器）后端网络的成熟，以及 GPU 集群规模逐步向通用计算基础设施靠拢，云基础设施的运营效率规范必然会回归主流。正如 SDN 技术通过解耦与抽象重构了传统网络架构，当前针对 RDMA 网络的技术创新已在部分领域取得突破。可以预见，当行业对云原生效率的需求传导至 RDMA 领域时，具备可编程能力的新型网络架构取代现有垂直方案将是大势所趋。

随着数据中心运营商所部署的 GPU 集群规模持续扩张，采用 RDMA 技术的后端 AI 网络对于控制和灵活性的需求愈发强烈，为预估其需求走向，我们首先来回顾一下微软、亚马逊、谷歌、Meta 以及阿里巴巴等云服务提供商（CSP）是如何让各自的 RDMA 网络适配规模高达约 32,000 个 GPU ，未来甚至可能达到超过 100,000 个 GPU 的集群的部署 。

微软 Azure 的 RDMA 网络扩展

微软很早就开始使用 RoCEv2，用于支持高可靠性和延迟敏感的存储和 HPC 服务。为了拓展到更大规模的网络，满足数据中心内部通信需求，微软为其云基础设施增添了新功能。主要方法和步骤如下：

表 1：Microsoft Azure 扩展 RDMA 网络的方法

基于表 1，对微软 Azure的控制水平评估为中等。原因是RDMA 传输由单一网卡供应商通过硬件实现，所以新功能的推出依赖于 RDMA 网卡供应商修复问题、发布新版本硬件的能力，不依赖定制或专用交换机供应商的功能。

对灵活性的评估同样为中等，还是RDMA 网卡来自单一供应商的问题。Azure 采用适用于异构数据中心的商用交换机解决方案和网络设计，并借助 MSCCL 实现跨多个 GPU 供应商使用通用的集合通信库（CCL）。虽说这在一定程度上增强了采购 GPU 的灵活性，但目前还不确定它是否增强了 Azure 灵活采购和部署 RDMA 网卡的能力。

需要注意的是，Azure 平台的趋势似乎正朝着获取更多对 RDMA 网卡部署控制权的方向发展。Azure 通过收购 Fungible，拥有了可编程网卡资产。Azure 能够运用这些资产，来获取更高的控制权和灵活性。MAIA 加速器芯片集成了以太网网卡功能，支持自定义的类 RoCE 协议，不过目前还不清楚该解决方案是否具备可编程性。

Amazon Web Services (AWS) 的 RDMA 网络扩展

为了让 RDMA 网络适配云服务的大规模需求，AWS 面临着与微软相似的挑战，不过它采用了截然不同的应对策略。为了支持HPC和AI应用的大规模运行，AWS 需要在其基础设施中加入能够保证低延迟一致性的功能。与渐进式改进 RDMA 网卡供应商提供的解决方案不同，AWS 另辟蹊径，采用了一种全新方法，以应对 HPC 和 AI 工作负载中出现的流量拥塞问题，具体方法见表 2：

表 2：Amazon Web Services (AWS) 扩展 RDMA 网络的方法

基于表 2可以看出，AWS 的控制水平较高。原因在于AWS 凭借自主的可编程 RDMA 网卡，能够在不依赖 RDMA 网卡或交换机供应商的情况下，进行创新并引入适用于大规模 AI 网络的新功能。同样的，其灵活性也较高，并且能够采用适用于异构数据中心的商用交换机解决方案和网络设计。

Google 的 RDMA 网络扩展

2023 年，谷歌将其 Falcon 传输协议贡献给了开放计算项目 (OCP) 。谷歌在供应商提供的、支持 RDMA 且可编程的网卡（称为基础设施处理单元或 IPU NIC）中实现了该传输协议。它采取的路径介于微软和亚马逊的方法之间。与微软一样，谷歌也采用了供应商 RDMA 网卡解决方案。而与 AWS 相似的是，谷歌创建并部署了自己的 RDMA 传输协议，具体内容见表 3：

表 3：Google 扩展 RDMA 网络的方法

基于表 3可以看出，谷歌控制水平为中等。因为谷歌通过在可编程核心中实现核心传输组件，保留了为拥塞控制算法添加新功能，并快速发布这些功能以满足新工作负载需求的能力。不过，谷歌仍依赖其 RDMA 网卡供应商来提升硬件速度和数据传输能力。

对其灵活性的评价较高。谷歌在实施核心 RDMA 扩展和拥塞管理功能方面具备充分的灵活性，并且能够使用适用于异构数据中心的商用交换机解决方案和网络设计。

Meta 的RDMA 网络扩展

Meta 能够针对特定工作负载需求，设计和微调 RDMA 网络及计算基础设施。其扩展 RDMA 网络的方法与上面谈到的都不同。Meta 并未在 RDMA 传输层进行更改或创新，也没有发明新的传输层，而是对基础设施的其他方面进行了诸多更改和优化，具体见表 4：

表 4：Meta扩展 RDMA 网络的方法

根据表 4，对Meta 控制水平的评估较低。由于 RDMA 传输由单个网卡供应商在硬件中实现，新功能的推出依赖于 RDMA 网卡供应商修复问题和发布新版本硬件的能力。此外，Meta 借助专用的深度缓冲、高基数、机箱以太网交换机中的独特功能来解决拥塞问题，这使其高度依赖交换机供应商的功能支持。若要扩展到更大的集群，可能需要重新考虑交换机采购和网络设计策略，进而导致产品上市时间延迟。

对其灵活性的评估也较低。因为 Meta 的拥塞管理解决方案和遥测要求，与 RDMA 网卡供应商的 RoCE 实现以及 GPU 供应商的库（NCCL）紧密相关。而且 Meta 使用单一供应商提供的专用交换机，并采用自定义交换机架构设计，这与其他数据中心网络设计不同。

阿里巴巴 的 RDMA 网络扩展

阿里巴巴展示了其为大语言模型（LLM）训练专门设计的数据中心中所部署的高性能网络（HPN）架构。其方法与 Meta 的有些类似，阿里巴巴没有在 RDMA 传输层进行改动和创新，而是在应用层以及架顶式（ToR）、聚合和核心交换机网络层进行了优化。为了提高网络可靠性（减少训练作业失败及相关的高昂成本）和负载均衡能力（缓解拥塞），阿里巴巴对训练数据中心基础设施的多个方面进行了更改和优化，详情见表 5：

表 5：阿里巴巴扩展 RDMA 网络的方法

基于表 5，对阿里巴巴控制水平的评估为中等。和前面提到的部分情况类似，RDMA 传输由单个网卡供应商在硬件中实现，新功能的推出依赖于 RDMA 网卡供应商修复和发布新版本硬件的能力，且不依赖定制或专用交换机供应商功能。若要扩展到更大的集群，可能需要重新规划网络设计策略，从而影响上市时间。对其灵活性的评估较低。原因与Meta相同，不做赘述。

表 6 总结了上述这些云服务提供商当前 GPU 集群设计的控制和灵活性水平。AWS 和 GCP 控制和灵活性较高，Meta 和阿里巴巴的控制和灵活性相对较低，而 Microsoft Azure 处于中间位置。

表 6：CSP 的控制和灵活性水平

如果这些CSP计划构建可扩展至数十万个GPU或AI加速器的AI基础设施 ，这就需要他们应对全新的网络设计和拓扑问题，具体如下：

微软借助MAIA加速器、特斯拉依托Dojo加速器，分别创建了用于在各自AI加速器间传输数据的自定义传输协议。微软的自定义RoCE传输协议以及特斯拉的TTPoE（以太网特斯拉传输）都有助于实现网络扩展。随着越来越多的CSP构建自己的加速器，他们很可能也会采用类似且需要自定义传输实现的方法。