以太网进化：超以太网引领AI未来

• 题目：Ethernet Evolved Powering AIs Future with the Ultra Ethernet Consortium

• 演讲者：J Michel Metz, Ph.D, Chair, Ultra Ethernet Consortium

• 会议：SNIA Compute, Memory, and Storage Summit

• 日期：2024年5月22日

首先，我们将探讨为何AI的需求远比表面上看到的更为复杂，进而为何需要一种新的以太网网络思维模式。然后，我们将探讨超以太网如何解决这些问题，最后，介绍如何获取更多信息，包括博客、白皮书等。

当前，关于AI将如何重塑世界的讨论已屡见不鲜。我对此也深表认同，但同时我们必须保持谨慎，确保这一进程朝着积极的方向发展。通过快速检索网络，可以发现关于AI将如何改变网络的观点层出不穷。然而，对于网络基础设施而言，未来又将如何发展呢？为了应对即将到来的工作负载，我们需要做些什么呢？显而易见，答案是构建更大、更快、更强大的网络。但具体而言，这又意味着什么呢？简而言之，我们面临着海量数据亟待处理的挑战，这些数据需要被传输、分析并转化为可行的结构。因此，问题绝非是简单地将数据从A点搬运到B点那么简单。

事实上，随着海量数据的传输，人们可能会直观地认为，只需构建更大、更快的网络，拥有更大的带宽即可满足需求。然而，实际情况远比这复杂。超越速度和流量层面，我们可以看到更深层次的问题。首先，AI并非单一的技术概念，而是一个涵盖多元技术的复杂系统。它不仅仅是运行数学程序并输入大量数据那么简单。AI工作负载不仅对内存带宽和容量提出了不断增长的需求，而且数据访问的时间和地点也变得更加复杂。数据需求的特殊性使得快速、准确地将数据传输到指定位置变得至关重要。如果能够尽量避免数据移动或I/O操作，则将更加理想。

一些AI工作负载的运行时间可能长达数小时、数天，甚至在极端情况下可能长达数周。因此，在高效网络上节省的每一刻都至关重要。

然而，在深入探讨之前，让我们先明确工作的范围和目标。

例如，我们不会对整个以太网网络进行全面升级改造。普通的局域网和常规以太网流量并不属于我们的关注范围。我们不会对常规数据中心以太网网络进行改动。我们的目标是针对涉及AI和HPC的工作负载进行优化，因为这些工作负载对GPU和其他加速器具有特殊需求。具体而言，我们可以构建两种类型的网络：一种是scale-out网络，另一种是scale-up网络。

Scale-up网络以紧密耦合的Pod（配备共享内存）和GPU为主要特征，其特点是极高的带宽、低延迟和低功耗。Scale-out网络则将这些Pod连接在一起，支持跨越百万个端点的超大规模工作负载。目前，超以太网领域聚焦于解决Scale-out网络问题，着力于处理不同节点之间的关键连接以及图中所示的后端Scale-out网络，避免将精力分散在其他方面。

挑战在于，AI工作负载内部的进程会以指数级的方式创建数据关系。随着我们在模型中添加越来越多的参数，数据点传输的需求也会呈指数级增长，给网络带来巨大的压力。更复杂的是，不同类型的AI工作负载对网络的影响差异显著。例如，摘要工作负载主要对计算能力提出要求，而生成工作负载则更依赖内存带宽。此外，部分工作负载与CPU搭配表现良好，而另一些则更适合与GPU协同，混合使用处理器时可能会导致性能大幅下降。因此，这些工作负载需要根据自身特点，在网络内部得到差异化的处理。

然而，这些工作负载却在网络上消耗了大量的运行时间。举个例子，假设你正在进行网上购物。当你浏览商品时，网站会推荐你“其他用户也购买了这个商品”、“你最近浏览了这个商品”等等。这类功能背后的工作负载，将近60%的时间都花在了网络I/O操作上。这意味着网络性能对最终用户体验的影响极其显著。更糟糕的是，网络中的低效率还可能带来灾难性的后果。

具体来说，我们需要探讨一个重要的概念：有效吞吐量（Goodput）。有效吞吐量是指实际完成的有用数据传输量与总尝试传输数据量的比率。举个例子，当两个设备进行通信并成功建立连接时，从一个设备向另一个设备发送数据的过程就属于有效吞吐量。然而，如果通信过程中出现故障或需要等待响应，就会降低有效吞吐量。数据传输过程中的低效率会直接影响有效吞吐量。显然，数据传输量越大，出现问题的可能性也越高。这至少会导致网络内部一系列负面影响。

当我们聚焦于有效吞吐量时，速度和流量的提升、网络规模的扩张，都会带来更大的出错风险，这涵盖了从物理层到工作负载各个层面。从线缆上的比特错误率到软件栈顶层的错误，所有这些因素都会影响网络效率。现阶段，对于我们讨论的这类网络，几万个端点已经触及了规模扩展的极限。然而，这种影响并非线性的，并非每个节点的增加都会带来一个问题，而是呈对数或指数级增长。当端点数量达到百万级别时，整个网络堆栈都需要针对潜在问题进行全面考量。

这些痛点相互关联，相互影响，低效性层层叠加，最终导致问题的严重恶化。让我们以针对特定网络工作负载的解决方案为例，探讨如何触及效率的自然边界。Verbs API通过使用特定的协议来确保数据包的有序传递，这是非常必要的。试想一下，如果数据包在端点处乱序，将会造成代价高昂的重新排序操作。为了避免这种情况，我们需要确保数据包按序到达端点，无需在接收端进行缓冲和重新排序。Verbs API正是强制实现了这一点。

为了实现这一点，网络架构师采用了数据包的静态路由机制。然而，这种机制存在明显的缺陷：一旦发生故障，就需要完整的消息重传，如果数据包丢失，整个传输过程必须重新开始。这被称为GBN（Go-Back-N）恢复机制。它要求网络回退一定数量的数据包，重新传输并重启整个流程。显然，这会导致网络资源的低效利用。每当传输过程需要停止、重启、重复时，都无法达到预期的有效吞吐量（Goodput）。尤其是在工作流程包含多个阶段的情况下，这种问题会更加严重，可能导致头部阻塞和网络拥塞问题。

需要注意的是，随着端点数量的增长和端点之间互连性的增强，这些问题发生的概率也会随之增加。当这些低效问题变得严重时，低效性会随着时间的推移逐渐扩散，导致网络利用率下降，并以有效吞吐量（Goodput）的降低为表现形式。具体来说，这些低效问题会占用网络带宽，导致可用链路的利用率低下，并严重影响有效吞吐量。理想情况下，我们应该能够充分利用所有链路，仅在工作负载确实需要时才强制执行顺序。控制消息等数据传输需要有序，但对于其他非控制数据，则应允许根据需要灵活调整传输顺序，而不应被局限于单一的传输方式。

随着工作负载中任务依赖关系的增加，情况变得更加复杂。例如，在训练大型模型时，由于每个阶段的最后一个比特返回都是最敏感的完成度衡量指标，训练过程变得高度依赖延迟。当工作负载基于输出tokens的数量时，这种延迟会自然增加，而输出tokens又会受到用于传递这些tokens的参数数量引入的延迟影响。以GPT-3和GPT-4为例，它们的参数数量分别高达1750亿和1万亿以上。每个参数都需要调整、移动并与其他参数建立连接以生成这些tokens。这意味着随着网络规模的扩大和性能的提升，错误累积会导致性能下降。此外，随着越来越多的交互被用于获取每个单独且更准确的tokens，网络功能和效率需求也随之提高。

现在，让我们来了解超以太网（UEC）！正如上面所讲，这是一个巨大的挑战，需要整个技术行业携手合作，以开放和共享的方式共同解决。因此，我们共同致力于此。事实上，以太网正被越来越多地用于满足AI和HPC工作负载不断增长的需求。这背后有着充分的理由：以太网技术非常灵活，能够推动技术极限的突破。然而，由于以太网被设计为通用网络技术，因此仍存在改进空间，特别是在针对特定工作负载方面。

从组织角度来看，自2023年启动以来，超以太网（UEC）已成为Linux Foundation内增长最快的项目之一。短短不到6个月的时间，已有70多家公司加入，超过800名活跃的个人志愿者在8个工作组中积极贡献。UEC的一大亮点是其内置了针对工作负载中心化结果的调整特性。我们不仅在传统的OSI分层模型上进行改进，还通过跨项目合作确保上下层的一致性，涵盖存储管理性能、合规性等关键要素。

我一直强调特定于工作负载的调整，那么这具体指的是什么呢？简而言之，我们的目标是能够以规模化的方式处理这些工作负载。然而，并非所有scale-out系统都会以相同的方式使用。举例来说，公有云和本地化部署在使用AI和HPC工作负载方面存在差异。因此，在明确不同配置文件所需内容时，我们找到了一种相当简单的方法：为公有云的AI配置、本地化的AI配置、公有云的HPC配置和本地化的HPC配置制定了不同的配置文件。所有这些配置都从一开始就集成到了UEC中。

许多人被高速率和超大传输容量所吸引，我对此也深有感触。高端网络技术的发展令人振奋，以太网速度不断攀升，从400、800Gbps到2Tbps甚至更高，这些数字足以让人热血沸腾。对于物理层面爱好者或追求极致规格的人来说，看到能在不到一纳秒内传输整部《大英百科全书》的性能数字，一定会感到无比兴奋。这正是他们孜孜不倦追求的目。然而，不得不承认，当涉及到物理层时，数学很快就会变得抽象和难以理解。因此，在这方面我更像是一个追随者，而非真正的物理层工程师。不过，以如此高速率传输数据，究竟能实现什么功能呢？这同样令人好奇。当涉及到拥有稳定、可靠的网络和成千上万的端点时，如何确保能够如我们所愿地实现这些目标呢？答案是：逆向思考。需要了解在庞大的网络中会发生什么，这些网络具有极高的容错性，这意味着需要出色的遥测技术。需要能够检测和沟通端到端的拥塞问题，并确保其安全性。同时，需要确保支持正确的数据结构和应用程序编程接口，以便工作负载无需重写。毕竟，没有人愿意反复修改自己的程序。此外，还需要拥有与上述所有内容兼容的强大的传输语义。

让我们转换视角，从连接需求转向工作负载需求时，就会发现整个网络堆栈上下存在着众多契合点。以太网成为这一基础的原因显而易见：无需重复造轮子。正如图中所示，许多以太网层尚未得到充分利用。我们能够在这个坚实的基础之上，仅通过必要的调整，就为每个配置文件提供所需的功能。超以太网传输（UET，Ultra Ethernet Transport）通过数据包喷洒（packet spraying）实现了多路径数据包传递和细粒度负载平衡。先进的拥塞控制和遥测技术确保了效率不会随着规模扩大而下降。它还允许灵活应对工作负载需求，包括可靠和不可靠的流量流、有序和无序的传输，同时完全兼容现有库。

超以太网的核心关键元素实际上位于传输传递系统（transport delivery system）中，但它还扩展到传输层之外，并进行了额外的重点调整，旨在增强整个堆栈，从物理层到软件层，以适应不同的工作负载。因此，超以太网从一开始就致力于实现这些目标。我说这是一个雄心勃勃的项目，你现在应该明白我的意思了吧？

现在，让我们从一个哲学问题开始思考：在拥有数百万节点的系统中，可靠、稳定、一致和可预测的系统应该是怎样的？要实现这些目标，你需要做什么？答案并非简单地找到一种万能的快速解决方案，而是需要真正检查整个系统中的每个部分。所以，让我们更深入地探讨这些问题。

我们观察到，目前所有提供高性能网络的方法都存在权衡利弊。遗憾的是，我们现有的网络使用方式并非最有效，因为数据包乱序接收会对工作负载造成严重影响。为此，业界已经采取了一些严格的措施来避免这种情况发生。现在，我们希望能够有效地利用所有可用路径来发送数据包。这将帮助我们更好地利用网络，同时减少尾部延迟问题。事实上，这还会带来额外的好处：网络负载将得到优化，甚至可编程，并能够适应波动的网络条件！这意味着我们可以直接在网络内部进行优化，而无需应用程序开发人员进行繁琐的改动。

造成大部分问题的是网络内部发生的波动条件。现有的网络设计往往过于冗余。为了应对拥塞和拥塞扩散等实际问题，通常会构建超出实际需求的网络。一些节点发送和接收流量的频率高于其他节点，这可能导致网络链路的异步使用，并引发类似于内部拥塞的问题。当大量数据涌入特定节点时，会产生压力，并在网络内部产生反压。所有这些都会增加工作负载的延迟和抖动，而一些工作负载对抖动非常敏感，无法很好地处理这种剧烈的变化。

这意味着，为了消除对过度设计网络的需求，必须具备极其强大的拥塞处理能力。这需要从发送者和接收者的角度来处理拥塞，并在必要时在网络中进行传播。同时，还需要能够及时有效地在网络中传递这些信息。这需要改进的拥塞信号、适当的遥测机制，以及处理这些信号的方法，并确保安全性从一开始就得到内置。

UEC的方法确实雄心勃勃，其设计不仅要解决当前工作负载暴露的网络问题，还要为未来更大、更强大的需求做好充分准备。“未来”这个词我已经说了很多遍了，这几乎已经成为一个笑话了。

这意味着我们对以太网流程的每个环节进行了仔细审视，以改进传统方法中按顺序传输的方式。如今，我们在超以太网传输的语义层中引入了更灵活的无序数据包传递和有序消息完成功能。与常规系统将安全性视为附加功能、事后考虑不同，我们从一开始就将安全性直接构建在代码中，并内置在数据包格式中。

传统方法大多基于流级别的多路径传输（flow-level multipathing），而我们则从数据包喷洒的角度出发，可以传输单个数据包，而不仅仅是整个数据流。传统的RDMA网络采用了许多不同的拥塞通知方法，而我们正在考虑一个基于发送者和接收者的拥塞控制系统，该系统足够先进，能够处理拥有高达一百万个端点的庞大系统。

传统网络中常见的严格网络结构已被修改为语义级别，以便根据需求处理不同的配置文件，甚至允许网络内部的工作负载具有一定的多样性。但最重要的是，我们正在直面一个关键问题：规模到底有多大？目前，规模通常是同时拥有从一万到几万个节点的网络。但超以太网的目标是支持高达一百万个端点。因此，总体而言，我们正试图从整个解决方案的预期结果出发，来处理这些挑战，以应对各种工作负载。

我只能简要介绍一下我们试图达成的目标、为何创建超以太网以及这个项目的宏伟蓝图。我们的目标并非仅仅调整某个层面或简单假设，认为创建一个更快的网络就能解决所有问题。正如俗话所说，海水上涨未必能托起所有船，尤其是在船过多的时候。由于时间有限，我无法深入探讨所有细节，但大家可以想象，我们还有很多工作要做。

--【本文完】---

近期受欢迎的文章：

更多交流，可添加本人微信

（请附姓名/单位/关注领域）