构建未来：AI驱动下的网络与存储技术革新
当前，我们面临着一个经典的“先有鸡还是先有蛋”的难题。在探讨AI系统大规模增长所带来的网络基础设施挑战时，经常会遇到这个问题。AI的发展离不开数据，而数据的存储也需要可靠的网络基础设施。然而，究竟是AI的规模先发展到一定程度，导致网络架构必须做出调整，还是网络基础设施应该超前部署以满足AI发展的需求？这是一个难以回答的“先有鸡还是先有蛋”的难题。
当开始着手解决这个问题时，很多人首先会强调速度和数据传输能力的重要性。这两点确实至关重要。但当速度达到1.6Tbps后，接下来应该关注什么呢？答案是：内容。事实确实如此，一旦达到这些速度和传输能力水平，将面临诸多问题，包括电力、扩展和误码率等一系列物理层面的挑战。
然而，当深入探讨AI及其涉及的各类处理流程和工作负载时，比特误码率就不再是大家关注的焦点。取而代之的是，人们开始讨论GenM、GenV等需要多种处理类型以及数据在不同类型缓冲区之间移动的问题。当触及这一层面时，存储就变得至关重要。需要强调的是，我所指的存储不仅仅是容量。许多人误认为存储仅仅关乎容量，这是一种错误的理解。实际上，存储的核心是数据，即数据如何传输到目的地、如何处理以及何时处理等等。
当开始确定数据在何时何地需要时，必须始终关注这些问题。数据是否位于正确的位置？其工作机制如何？需要进行哪些调整？可能存在的痛点有哪些？
谈谈AI的需求。我们所谈的每一点都指向了一个核心问题：我们所面对的是海量数据、PB/EB级别的DRAM等。我们谈的是以100万个端点为基础的基础设施。然而，现实情况并非如此，这样的基础设施并不存在。这里说的的“基础设施”，是指能够深刻理解数据如何移动、传输和处理的架构。
这正是我们需要在百万级端点上解决的关键问题。试想一下，如果每个设备增加一瓦的功耗，对于系统和应用程序而言，就意味着100万瓦的额外功耗。这显然是不可接受的。必须从物理层到存储数据处理层，以最高效的方式整合所有工作，并确保它们同步运行。这不仅是我们需要克服的挑战，也是我们在探讨AI工作负载及其细化为不同处理类型时共同面临的难题。
当面对如此大的规模水平时，时间将成为我们需要攻克的最大挑战。时间已然成为我们的对手。慢数据，即最后到达的数据位，将成为我们必须解决的难题。在存储领域，这一问题已经困扰了我们数十年。如今，我们意识到它将对这类工作负载构成更为严峻的挑战。所以需要构建专用网络来应对此类问题。
另一个关键问题在于，我们往往只关注纳秒、毫秒或微秒级别的延迟，而忽略了更长的时间尺度。然而，现实情况并非如此。如果我们的工作负载需要持续数小时、数天、甚至数周或数月，那么所有时间尺度都至关重要。我们必须确保数据或数据移动的高效传输，避免任何低效传输。
有效吞吐量（Goodput）是指实际完成的工作量与尝试完成工作次数的比率。如果网络传输过程中需要频繁重试，则意味着有效吞吐量低，网络利用率不足。我们期望通过网络传输的每一个比特都能得到充分利用，实现最优的传输效果。为此，需要努力在网络层、物理层和存储层面消除错误和重试，以实现最佳的I/O性能。
关于AI处理的基本概念。Transformer模型及其生成类似ChatGPT聊天文本的能力背后涉及两个核心过程：编码器和解码器。简而言之，编码器负责接收所有信息并识别出这些不同元素之间可能产生的事件序列。这些元素被称为token，它们之间的关系和权重是基于它们之间的关联确定的，而这种权重的确定需要大量的数据移动、处理和存储。对于GPU而言，这种并行处理能力至关重要。
另一方面，文本的生成则依赖于解码器。这是一个顺序过程，其中加权token通过链条传递以生成下一个单词的文本。由于只能有一个结果，因此解码过程始终按照顺序进行。这是这类应用内部必须完成的任务之一。
然而，问题在于所需的数据并不总是易于获取。数据通常缺乏结构化，因此需要进行清理和处理。这涉及到各种类型的数据结构，它们都需要得到妥善处理。从计算型存储的角度来看，将处理过程放在数据最终存储的位置进行，要比将数据移动到全新的PB级系统中进行重构更高效。就地处理数据更加便捷。
当将这些不同阶段结合起来时，将面临两种截然不同的内存处理问题。在网络方面也会遇到不同的挑战。这涉及到语义层面上的差异，我们需要确保某些处理必须按照顺序进行，而另一些处理则可以并行执行。这些问题并非同一问题，需要分别加以解决。
当我们开始思考在尝试完成这些任务时会遇到哪些挑战时，我们会发现并不存在一种通用的解决方案。面对各种限制，尤其是在处理数十万个端点的情况下，我们必须意识到，如果继续沿用现有的网络模式，将无法实现预期的目标。究其原因，在于现有的网络和存储设计主要用于建立端点之间的一对一关系。
例如，如果使用InfiniBand的Verbs API，它可以在流级别进行多数据包处理，但这可能导致网络使用效率低下。在这种情况下，无法进行真正的数据包喷洒或多路径处理，导致部分网络资源没有得到充分利用。这是需要解决的一个问题。
另一个问题是，当面对100万个端点时，会遇到拓扑和遥测方面的问题。网络内部发生了什么？如何了解网络内部的情况？此外，当开始处理大量数据规则时，会遇到自动拥塞的问题，即热点的自发出现。这也是一个亟待解决的问题。需要结合遥测、拥塞信号、拥塞通知和拥塞缓解措施来解决这些问题。
另一个挑战是，有些工具需要手动调整，它们可能具有特殊的处理方法，可能是专有的。这意味着需要特定的硬件和软件组合来处理某些有效的工作负载，这非常困难，即使使用脚本也难以做到，特别是在处理真正大规模的端点时。
接下来是数据恢复的问题。当意外发生时，如何恢复需要处理的数据？如何从可能丢失的传输中恢复数据？如何恢复必要的处理过程？这些问题在存储领域早已是众所周知，但在网络领域仍处于逐步认知的阶段。以往在网络或服务器环境中，重启虚拟机通常可以解决问题。然而对于SSD而言，情况并非如此，无法像重启虚拟机那样简单地恢复。网络领域正在逐渐意识到，这类事件可能带来不可避免的后果，亟需采取措施加以缓解。
然后是管理方面的问题。如何有效管理100万个端点？需要注意的是，这里的100万个端点并非指单个服务器，而是泛指基础设施端点，例如GPU上的端口。一个GPU端口可能拥有16、128或256个子端口，尽管目前数量可能还没有达到如此之多，但未来随着技术发展，这将成为常态。这也是我们当前讨论的核心议题。
近期DPU成为了热议话题。那么，DPU究竟承担了哪些处理任务？在这些兼具多元功能的DPU上，基础设施能力的处理又有哪些变化？过去，基础设施能力的处理主要由单一设备（网卡）负责。如今，随着DPU的出现，网卡的角色发生了转变，它不再是唯一的处理单元，而是被整合进了DPU内部。同时，DPU还负责处理NVMe over Fabrics端点，并将数据分发到服务器内部的CXL基础设施中。由此可见，端点的定义和处理方式都发生了显著变化。
最后但同样重要的是安全问题。在如此庞大的环境中，如何实现端到端的安全性？这将是我们在未来需要解决的关键挑战之一。
接下来，我们需要解决一些基础性的问题。例如，内存带宽、容量和延迟之间的平衡。这些因素对于所有工作负载都至关重要，并且会因工作负载类型而异，无论是转换、聚合还是生成，都存在着独特的挑战。如何有效地平衡这些因素是我们需要解决的关键课题。
为了解决这些问题，可能会考虑在系统中添加GPU或DPU。为了避免内核间通信带来的开销，我们需要确保正确的数据缓冲区得到有效地移动。这些都是扩展系统规模时需要考虑的重要因素。那么，面对内存受限的工作负载，我们该如何应对？由于无法将所有数据及其元数据都存储在一个GPU缓冲区中，因此我们需要对数据进行相应的处理和适配。例如，我们可以考虑采用分批处理的方式，每次只处理一部分数据，并将其存储在GPU缓冲区中进行计算。
以“推荐系统”为例，这类工作负载类似于你在亚马逊购物时看到的“其他购买该商品的人还购买了这些商品”。据Meta公司统计，这类工作负载占到了整体I/O需求的60%。这会导致额外的I/O开销，因为如果所有数据都在不断移动，那么其中约70%的数据实际上是在网络中传输的。这显然不是我们希望看到的场景。那么，如何优化这一过程？关键在于识别哪些数据必须通过网络传输，哪些数据可以留在本地处理。这仍然是一个亟待解决的挑战。
最后，还将面临I/O混合效应（I/O Blender）的问题，这是任何长期从事虚拟化工作的人都知道的复杂问题。当我们开始处理这些流程并尝试确定它们的最佳位置时，所有事情最终都会变得错综复杂，就像一个巨大的谜团。需要明确的是，AI的发展并不仅仅是简单地给系统添加一个GPU那么简单。
因此，这对网络有何影响？刚才提到Verbs API，需要注意的是，RDMA技术并非一种类型，有多种RDMA技术可供选择，Verbs只是其中一种流行的方式。如果采用Verbs API，需要按顺序进行通信，这可能会带来问题。但是，并非所有工作负载都需要网络按顺序交付。如何判断哪些工作负载需要顺序交付，哪些不需要？如何实现这一点？
这本质上是一个语义问题，因为在这样的环境下，如果遇到顺序问题且缺少必要的数据位，数据包将无法传递。可能需要回退一定数量的数据包才能重新获取完整序列。这显然不是理想的数据传输效率，而是低效的数据传输。这是我们必须解决的关键问题之一。
有时需要传输顺序流量，例如控制流量；而其他情况下，数据传输不需要顺序，例如乱序流量。如何区分这两种流量类型？这需要在Verbs API之上的更高层进行识别。这是UEC团队正在努力解决的问题之一。
因此，在这种情况下，尤其是在需要重新传输数据的情况下，会出现额外的链路层问题。这是因为这类数据通常使用优先级流量控制。优先级流量控制旨在向网络注入拥塞，以实现特定的目的。但是，如果设计不当，例如存在过订阅或扇入比例问题，则会导致整个网络出现头阻塞，这是需要避免的。这突显了在这种情况下使用优先级流量控制的局限性。
因此，需要更有效的拥塞处理机制。需要注意的是，没有完美的解决方案。在所有情况下，都需要权衡利弊。
在探讨不同类型的网络环境时，需要明确每个组件的功能和责任。网络的不同层次将承担哪些处理任务？这需要一种目前网络尚未具备的智能化能力。原因在于，正如之前所述，需要对物理层、链路层、传输层以及软件API有深入理解，并使它们协同工作。然而，现有的标准并未设计成支持跨层协作。它们被设计成可层层叠加，以保持清晰的层次结构和避免跨层越权。这是网络设计的基本原则。
然而，UEC提出了一种新的问题，即存在跨层工作负载，被称为“集体工作负载”。这类流程在HPC和AI工作负载中十分常见，因为它们涉及终端节点间的通信方式以及最终获取结果所需数据的过程。这些不同层面的任何问题都可能对工作负载效率造成负面影响。这些都是亟需解决的问题。
接下来谈谈存储。将数据存储在某处，之后又需要将其迁移到其他位置，并在那里进行处理。为了确保数据安全，不得不采取这些措施。但这种方式显然效率低下。因此，我们需要确保在扩展规模的同时保持性能，并将其存储在真正需要的地方。如今，出现了各种创新技术，例如缓冲区和反弹缓冲区，专门用于处理数据，尤其是元数据的移动。不同的存储技术（文件系统、对象存储和块存储）在这一层面有着不同的需求。在大规模上实现高效的数据管理至关重要。
我们讨论的不同类型数据存储在哪里？例如，对于AWS而言，边缘设备的定义可能与其他公司有所不同。手机和其他设备都可以是边缘设备。那么，如何定义边缘设备？边缘和核心又有什么区别？它们是如何协同工作的？此外，不同模式的数据（例如文本、视频和照片）也需要不同的处理方式。除了一些来自学术文章的图表外，其余都是由AI生成的。那么，AI是如何生成代表文本含义的图像的呢？与相关领域的专家交流后，我们发现摘要工作的具体机制尚不明确。我们不清楚权重是如何从数据中自动学习出来的。此外，随着数据量的增加，模型参数也呈指数增长，例如GPT-4有1.4万亿个参数。但是，参数或设置的任何更改都需要I/O操作。因此，我们讨论的是I/O的多个层面。此外，具体特性还取决于使用的加速器类型。
如果你对上面的话题感到困惑，这很正常，因为我们需要同时处理网络层面和存储层面的问题。也就是说，我们需要从整体角度解决的这两方面的问题。
从SNIA的角度来看，可以复用大量已完成的工作。例如，SNIA已经制定了持久性内存的编程模型。电源管理是理解大规模系统关键之一，因此“翡翠计划”至关重要。还有最近更新的安全标准和安全机制。此外，汽车存储也越来越重要，因为AI已经成为存储的重要组成部分。虽然SNIA目前还没有开发相关项目，但正在密切关注这一领域的发展。
最后，要重点介绍智能数据加速器接口（SDXI）。SDXI是一种数据搬移器，允许在内存中执行部分处理，这非常高效。
在讨论内存基础设施时，我们提到了内存和存储的融合。我们知道它们是如何相互作用的。数据的类型和流向可以通过范围概念进行管理。在讨论内存概念时，例如计算密集型内存布局和CXL协议。分层内存、访问不同的网络节点以及实际发生的处理，如何控制和管理不同类型的处理，并通过NVMe命名空间进行识别。
此外，我们还进行了一些低层的效率提升，有助于降低功耗成本。例如，SDXI不仅是一个数据搬移器，还能够在不同内存区域之间转换和修改数据。
接下来，谈谈未来的计划。基本的想法是，如果我们可以使用硬件组件构建数据搬移器，并避免IO操作，那么就可以节省IO成本。正如我之前所说，最好的IO就是完全不需要进行IO操作。
举个例子，这项功能目前尚不可用，但代表了我们未来的发展方向。这始终是我们设计理念的一部分。例如，在GPU内部移动专业数据时，需要经过多个不同位置和缓冲区。一旦意识到这一点，就需要将处理分散在多个位置。这使得处理变得复杂，尤其是在数据格式不符合需求的情况下。此时，就需要对数据进行清理、准备和格式化，这在特殊环境中尤其具有挑战性。
计算型存储的核心思想是将数据存储在终端设备本身。如果需要修改数据，可以使用SDXI在内存中进行数据搬移，从一个位置移动到另一个位置，并同时调整数据格式。但传统方法通常需要进行IO操作，并在不同处理设备之间移动数据，这会降低效率。因此，我们希望尽量避免这种情况。
因此，如果我们能够使用一个与处理器无关的软件数据搬移引擎，它还能够在内存寄存器之间进行数据修改，那么就可以节省大量数据搬移操作，因为设备之间不再需要这些数据缓冲区。
这非常有效，并且可以随着时间的推移标准化内存的数据处理和数据结构。它高度可编程，并且由于运行在特权进程中，安全性也得到了根本保障。
这幅图的目的是展示数据移动的总量，以及通过使用合适的工具可以减少多少数据移动。这里的核心思想是避免出现“数据反复搬移”现象。数据反复搬移是指数据在不同位置之间来回移动，而没有进行任何必要的处理或转换。这会导致严重的性能开销和低效率，因为需要多次传输数据，并可能涉及不必要的复制或重复。因此，减少数据移动，并直接在数据所在的位置进行处理，可以显著提高工作效率。
那么，未来发展方向是什么呢？
超以太网（Ultra Ethernet）涵盖了从物理层到软件API处理的完整技术栈，能够识别并处理不同类型的数据流量，例如需要可靠顺序传递的数据流量和无序传递的数据流量。它还能够处理管理、存储合规性和性能等方面的问题。因此，超以太网是第一个专门为HPC和AI应用设计的高性能网络架构，能够满足可靠和不可靠数据流量的需求。
UEC正在致力于解决传统HPC和AI网络存在的性能瓶颈和局限性。预计2024年底发布1.0版规范。这是一个可行的目标。
SNIA在其中扮演什么角色呢？SNIA已经发布了许多相关标准。将会推动SNIA将现有标准和技术整合起来，以满足特定工作负载的需求。AI显然是其中一个重要领域，这也是我们今天讨论的重点。SNIA的目标不是重复开发现有的技术，希望充分利用现有的标准和技术，为更广泛的服务奠定基础。这也是SNIA未来几年的重点工作方向之一。因此，SNIA的工作将成为解决网络专家和软件开发人员难以解决的一些问题的关键要素，因为这些问题超出了他们的专业范围。存储领域与容器化软件和网络领域存在显著差异，我们经常听到有人抱怨存储问题，认为存储人员应该负责解决所有数据存储问题。SNIA正在努力解决这些问题，并尽可能减轻存储人员的负担。
最后强调一下，AI和HPC工作负载对数据传输的容错率非常低。随着链路速度的提高，这个问题变得更加突出。链路速度越快，容错空间越小。因此，我们需要解决这些问题。从信号速率到终端设备功耗，一切都至关重要。因此，我们需要确保从软件API和管理架构到Redfish和Swordfish等所有环节的数据传输顺畅可靠。需要明确的是，单一的技术方案无法解决所有问题。
问题：在可预测良好输出下降（例如前向纠错）与数据包重传之间的权衡及其动态变化方面，您是否正在进行研究？您认为这可以通过调整来优化吗？
主要是在物理层进行纠错。传输层面的错误可以通过拥塞信号、拥塞通知等手段进行处理。UEC构建了一套基于发送方和接收方协同的机制，支持在物理层的所有链路上实现数据包流级别的处理。由于超以太网并非涵盖所有以太网物理组件，其中部分属于IEEE 802.3标准的范畴，因此UEC与IEEE保持着合作关系，并指派了专门联系人共同探讨相关工作，这部分工作可能将纳入IEEE标准体系。接下来，需要考虑如何在语义层和传输层处理这个问题，即如何将其纳入协议栈的上层。基于语义，拥塞通知也拥有相应的API接口。这整合过程是超以太网设计的一部分，旨在贯通并确保垂直方向的一致性。但部分内容尚未公开属于技术机密。
Source:J Metz; AI at the Intersection of Storage and Networking;June 24, 2024
--【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/单位/关注领域）