构建高效AI基础设施：网络性能优化
Broadcom
今天，我将从一个网络工程师的视角，向大家讲述AI如何融入我所在的领域——网络领域的故事。我会分享我所观察到的挑战，以及我们如何应对这些由AI带来的工作负载挑战所做出的优化。同时，我还将介绍我们在SONiC平台上为满足这些需求所做的功能增强，并探讨我们为何认为以太网是承载AI工作负载的优选方案，以及我们如何通过“超以太网联盟”（UEC）进一步优化其性能。
众所周知，云计算的核心之一是虚拟化技术，它使得多个虚拟机能够共享相同的硬件资源，从而提升资源利用率。CPU是云计算中不可或缺的组件，但虚拟化技术将CPU资源进行抽象化和管理，使其能够为多个虚拟机提供服务。
但是，GenAI与云计算中虚拟化CPU资源的做法正好相反。GenAI领域面临着巨大的挑战，即处理规模空前的模型，例如ChatGPT 3和ChatGPT 4。这些模型拥有庞大的参数数量，分别超过1700亿和1万亿，无法在单个CPU、GPU或甚至多个GPU上运行。因此，我们需要数以万计的GPU来支持它们的运算。这意味着我们需要在数千个节点上部署这些模型，并确保所有GPU能够高效协作和互连，就像一台完整的计算机一样运作。
所以从这个角度来看，这个AI网络实际上是一个分布式计算问题，在这个分布式计算问题中，网络起着关键作用，因为AI基础设施的性能取决于网络的效率，所以网络是AI基础设施的关键要素，我认为网络就是计算机，这不是我的话，这是20年前Sun提出的一句话，他们说网络就是计算机，这个说法对于AI基础设施时仍然非常正确。
这是15年前谷歌数据中心的一张图片。当时，谷歌正致力于解决上一代分布式计算难题——搜索引擎。他们是如何做到的呢？他们采用了大量通用CPU裸机服务器，并通过开放式以太网将数千台服务器连接起来。这种架构使得谷歌能够有效地处理来自全球各地的大量搜索请求。
让我们来看看这张幻灯片。这是两年前Alexis在Meta的OCP主题演讲中展示的幻灯片。Meta在其中指出了什么？他们明确表示，网络是其AI基础设施中的瓶颈。这听起来合理吗？我们已经解决了上一代分布式计算问题——搜索引擎，而Meta却遇到了网络瓶颈？
请注意这里显示的是Meta不同GPU负载中用于网络的时间占比。可以看到，在某些情况下，网络时间占比高达57%。综合所有负载，平均网络时间占比为35%。这意味着35%的时间里，这些GPU处于闲置状态，无法工作，因为它们在等待网络完成数据传输。试想一下，你投入了数百万或数十亿美元构建了最先进的AI基础设施，配备了强大的GPU。然而，令人遗憾的是，这些昂贵的GPU却有三分之一的时间处于闲置状态，无法发挥效用。究其原因，是网络未能有效地传输数据，导致GPU不得不等待，浪费了宝贵的计算资源。
正如我之前提到的，网络是AI基础设施的关键要素。尽管网络本身可能只占总成本的10%，但如果网络性能不佳，其造成的损失和影响将远远超过这10%。
现在，让我们探讨造成这种现象的原因。究竟是什么因素导致了AI工作负载与传统工作负载的差异？
首先，在云计算环境中，数据包（packets）和数据流（flows）通常较小，且存在大量机器之间的通信，其中涉及的机器数量可能达到数千台。然而，在AI基础设施中，数据流非常、非常大，这意味着它们持续时间非常非常长，并且有大量数据正在交换。这些是“大象流”（Elephant flow）。与云计算相比，AI基础设施中的数据流的数量相对较少。大家要注意，数据流的数量较少，并且是RDMA数量流，这意味着其“五元组”（Five tuples）信息呈现出较低的“熵”（Entropy），因此，在数据流的数量较少且为RDMA数量流的情况下，如果熵值偏低，将会导致负载均衡效果不佳，并无法充分利用现有链路资源。大家看到问题所在了吗？
第二点，这些RDMA流对丢包非常敏感，为什么呢？原因在于它们运行着诸如“Go-Back-N”、“Return-to-zero”之类的算法。这意味着，一旦发生丢包，大量数据包将被重新传输，具体取决于检查点的位置。因此，单个数据包的丢失可能导致整个通信阶段的延长。
最后，尾延迟（Tail latency）也是一个不容忽视的因素。在机器学习算法的执行过程中，存在计算阶段、通信阶段和同步阶段。在计算阶段，算法会进行矩阵乘法运算，并输出梯度和权重。随后，这些输出将在所有GPU之间进行交换，并完成同步操作。只有等到最后一个GPU完成工作，才能启动下一轮迭代。这是一个关键问题，因为即使只有一条流延迟，也会拖慢所有进程。请参考这张图，棕色和橙色流表示已经完成工作的流。然而，我们可以看到，由于尾延迟的存在，下一个周期必须等到所有GPU完成工作才能重新开始。这便是尾延迟对工作完成时间造成显著影响的原因。
接下来，让我们探讨如何分析网络，并确定导致这些问题的原因以及相应的解决方案。
首先，瞬时超额订阅（Transient oversubscription）。众所周知，超额订阅网络会带来性能瓶颈。在AI后端布线中，这种情况并不常见，但可能出现在AI布线的存储部分。由于与AI工作负载的相关性较低，我将不再详细介绍。
其次，流碰撞和链路故障也是值得关注的因素。流碰撞是指静态ECMP将多个流映射到同一链路，导致大流量集中在同一链路上，从而引发拥塞问题。链路故障也是需要考虑的因素。在大型网络中，链路故障难以避免。由于AI应用程序对数据包丢失高度敏感，链路故障会导致数据包丢失，进而引发性能问题。
最后，我们需要考虑incast问题。incast是指多个GPU同时与一个GPU通信，导致带宽不足，无法满足所有通信需求。如何进行拥塞管理？
接下来，让我们逐一探讨应对这些问题的解决方案。
首先，让我们来解决瞬时超额订阅问题。我们的芯片具有一些非常优秀的入站特性。如果有人参加了我去年的演讲，应该还记得我曾讨论过这些特性。当时我主要介绍了入站元素特性。我强烈推荐大家观看两年前阿里巴巴与我来自Broadcom的同事在OCP峰会上所做的一次精彩演讲。他们分享了如何利用Broadcom芯片的遥测功能显著提升效率，并降低了50%的尾延迟。这足以证明该技术的有效性，我可以演示一下，让你们亲眼目睹当客户分享他们在现实生活中如何解决问题时的价值所在，以及该技术的强大效力。他们提到，在中国“双十一”期间（相当于美国的“黑色星期五”），阿里巴巴网站的性能得到显著提升，问题也明显减少。
解决流碰撞问题的方法非常简单，那就是实现完美的负载均衡。如何才能实现良好的负载均衡呢？我将介绍两种方法。
第一种方法是“数据包喷洒”（packet spraying）。即使对于单个接收流，也可以对每个数据包进行负载均衡。将所有数据包喷射到可用链路上，即可实现完美的负载均衡。然而，这种方法存在一个问题，那就是重排序。在接收端，数据包可能会出现无序排列，因此需要具备重排序功能。
第二种方法是“认知路由”（Congnitive routing），也就是负载感知的ECMP。这也是我们将采用的方法，并将在SONiC中提供支持。这也是我今天要重点介绍的内容。
最后，incast问题最好在接收端解决。接收端能够精确地了解自身接收的流量，并控制发送端按照接收端的容量发送数据。因此，我们可以利用各种信用控制机制，这些机制可以从交换机的顶部或终端本身运行。
Broadcom提供两种独特的架构，满足所有AI网络需求。
左侧是交换调度架构，将拥塞管理、流量控制和负载均衡等功能集中在交换机层面进行处理，这也是我们将其称为“交换机调度”的原因。明天，我的同事将详细介绍该架构的解决方案。
我将重点介绍右侧的终端调度架构。顾名思义，终端设备需要主动参与拥塞管理。这也是我们将采用并在SONiC中支持的方案。
在终端调度架构中，我们利用认知路由技术，为路由决策注入全局智能，从而优化各类应用的路由，尤其是AI应用。
全局负载均衡（GLB，Global Load Balancing），是一项交换机功能，在决定如何分配流量时，不仅考虑本地状况，还会考量全局情况。交换机可以查看下游链路的利用率和多跳路径的信息，从而对整个网络拓扑结构拥有全局视角。我们是如何实现这种“魔法”的呢？我们在Broadcom的芯片中运行了一个嵌入式应用程序。如同汽车导航系统，它能够提前预知未来几条道路上的拥堵情况，并从出发点开始重新规划行程，确保畅通无阻地抵达目的地。我们将这项功能以及全局视野融入了Tomahawk 5系列芯片，为网络带来了全新的体验。
响应式路径再平衡（RPR，Reactive Path Rebalancing），也是一项非常实用的功能。请记住我之前提到的长期存在的流量，例如两个GPU之间的流量可能持续数周甚至更长时间。试想一下，如果采用静态负载均衡，但在流量开始时将它们分配到一条拥塞的链路，这将造成效率低下。因为网络情况会随着时间发生变化，拥塞状况也会随之改变。RPR能够持续地寻找更好的路径，并将重流量切换到更通畅的链路，确保流量顺畅传输。
快速链路故障转移（FLF，Fast Link Failover），是Tomahawk 5芯片的一大亮点。它实现了200纳秒的故障转移速度，比标准以太网的50微秒快一个数量级。
丢包拥塞通知（DCN，Drop Congestion Notification），从更宏观的角度来看，DCN类似于一种数据包修剪功能。当网络拥塞导致数据包丢失时，它会对数据包进行修剪，仅提取头部信息并将其通过快速队列发送到接收端。接收端能够迅速收到该信息，并向发送端请求重传丢失的数据，从而快速获取完整的数据包。相比于等待确认超时后重传，这种方式显著提高了效率。
Broadcom正在积极致力于SONiC的增强功能，以满足AI网络的不断发展需求。以下是我简要介绍的几项重要更新，其中部分功能已经发布，其余功能将于今年夏天在SONiC中推出，预计在几个月内即可实现。
1.自适应路由（Adaptive Routing）：负载感知ECMP：该功能将引入SONiC，实现基于负载感知的ECMP路由，有效提升网络负载均衡能力，优化数据包传输路径。
2.高级哈希（Advanced Hashing）：UDF哈希：我们将支持UDF哈希（用户定义字段哈希），通过提取RDMA头部中的Q对信息进行哈希计算，显著提高熵值，实现更加均衡的负载分配。多功能哈希算法：我们将采用性能优异的多功能哈希算法，相较于传统的Rag7算法，具有显著的性能提升，能够进一步优化哈希分配效率。
3.无拥塞操作（Congestion-Free Operation）：我们已在SONiC中支持RoCEv2，并简化了RoCE的部署和配置流程。只需执行“RoCE enable”命令，即可完成PFC&ECN、无损缓冲区配置等一系列操作，大幅降低部署复杂度。
4.AI多租户（AI Multi-tenancy）：我们将支持Tomahawk 5系列芯片的多租户功能，满足AI网络后端布局的多租户需求。该功能将使客户能够将GPU作为一种服务提供，有效支持AI应用场景。
几年前，由于InfiniBand在HPC领域的成功，曾有人认为它将成为AI网络中的重要角色。InfiniBand在HPC和低延迟要求方面的表现确实具有优势。然而，在AI网络领域，以太网已被证明在性能方面始终优于InfiniBand。
这张幻灯片上是我们一位大型客户进行的基准测试结果，显示以太网至少比InfiniBand提高了10%的性能。大家可能会问，10%的性能提升并不重要。但请记住，网络在AI基础设施中的成本占比高达10%。因此，如果我们能够将基础设施性能提升10%，那么网络本身就能够收回成本。
网络并非完美无缺，故障时有发生。究其原因，部分在于光学器件的可靠性问题。根据统计，光学器件的年故障率高达2%或更高。对于有4000个节点的网络而言，这意味着每月可能发生多达15次故障。对比以太网和InfiniBand的故障转移率，以太网的性能至少优于InfiniBand 30倍。
选择以太网等开放技术的另一个重要原因在于，以太网已成为AI网络的事实标准，并得到了所有主流部署者的认可。除了少数例外，几乎所有大型AI网络都采用了以太网架构。值得一提的是，阿里巴巴集团和字节跳动不仅在其AI网络中部署了AI以太网，还采用了SONiC进行管理和优化。
随着AI模型规模的快速增长，从ChatGPT 3到ChatGPT 4，模型大小增长了6倍。目前，亚马逊已经构建了超过6.4万节点的集群，但这仅仅是开始。为了迎接AI网络的下一阶段，我们正在积极准备支持百万节点规模的AI网络。为了实现这一目标，一批公司正在Ultra Ethernet Consortium中携手合作，致力于改进以太网，使其能够支持百万节点规模的网络。
我们正在开展多项工作，其中一项是现代化RDMA技术。
总而言之，我们强调了AI网络对基础设施网络提出了独特的需求。SONiC已经做好准备迎接AI时代的挑战，并得到了字节跳动和阿里巴巴等领先企业的认可和部署。SONiC能够有效满足AI工作负载的严苛要求，构建下一代AI基础设施。
问题：您提到了超级以太网，请问未来的SONiC版本会支持它吗？
回答：我对此充满期待，但目前还没有确切的答案。超级以太网产品将于明年推出，并非遥不可及的未来目标。目前已经投入了大量研发工作，相关产品将于明年发布。我相信SONiC会支持超级以太网，但目前尚无官方确认。
--【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/单位/关注领域）