加速生成式AI：克服数据流瓶颈的方案探讨（专家会议）
演讲嘉宾：
Mario Baldi，AMD Pensando
Rob Davis，NVIDIA
Dave Eggleston，Microchip
David McIntyre，Samsung
Joe White，Dell
Andres Rodriguez，Intel
日期：2024年1月24日
对于使用基于大型语言模型训练的生成式AI工作负载，常常面临资源不足的挑战，包括但不限于内存、存储、计算以及网络数据流瓶颈。若不及时识别和解决，这些数据流瓶颈可能会将GenAI应用的性能限制在远低于最优水平的范围内。
鉴于生成式AI在自然语言处理（NLP）、视频分析、文档资源开发、图像处理、图像生成和文本生成等领域具有引人注目的应用，高效运行这些工作负载对许多IT和行业领域至关重要。影响生成式AI性能和效率的资源包括CPU、DPU、GPU、FPGA以及内存和存储控制器。
本次网络研讨会由业界经验丰富的代表组成，将提供以下洞见：
定义生成式AI数据流瓶颈 使用于识别加速选项的工具和方法 将适当的xPU解决方案与目标生成式AI工作负载进行匹配 优化网络以支持加速方案 在数据附近进行数据移动，或将处理移动到数据附近 软件堆栈在确定生成式AI性能方面的作用
---【以下为正文】---
欢迎加入我们关于生成式AI加速的讨论。我们将进行专题小组讨论，探讨克服可能出现的各种瓶颈的不同方式，以及推动生成式AI发展的方法。我们将涵盖从处理器到网络存储和内存等多个主题。
首先，让我们从第一个问题开始，也就是让我们谈谈你在进行生成式AI时在各种系统中观察到的瓶颈。这可能出现在系统的任何环节，所以我们从Mario开始。Mario，你认为有哪些瓶颈？
考虑到这是我的工作领域，我首先看到的瓶颈肯定是网络。但这不仅仅是我的观点，事实上，如今我们试图构建高度分布式的系统进行训练和推理，数据交换的量与成本之间存在巨大的差距。因此，在许多情况下，网络确实是限制我们性能的地方。我今天感受到了这种痛苦，因为在这个网络研讨会期间，我遇到了网络瓶颈问题，所以如果我中途掉线，David McIntyre将代替我。
是的，网络确实可能是我们需要关注的瓶颈所在。
好的，NVIDIA的GPU专家Rob Davis，我猜你还代表其他方面，但请告诉我们从你的角度看，瓶颈是什么？
当然，这取决于AI应用，但瓶颈可能出现在计算、内存、未优化的软件，或者如Mario所说I/O方面。具体来说一个I/O的例子。在使用生成式AI时，你训练的数据集或推理的实时数据可能太大，无法适应GPU服务器的本地存储，或者问题太大，无法适应一个GPU服务器。
在这些情况下，这些模型有多大呢？给我们一些线索，你最近看到了什么情况，Rob？
好的，举个例子，大约五年前，构建一个大型语言模型所需的参数数量约为两亿，而去年这个数字已经超过了一万亿，所以这是一个庞大的模型。当然具体取决于应用，但确实非常庞大。
好的，让我们听听英特尔的Andres对此有何看法。Andres，也请你分享一下，我们需要考虑的一些瓶颈是什么？
我有些不同的视角。一些非常大的公司，尤其是互联网公司，正在训练这些极大的语言模型，其中网络是训练过程中的主要瓶颈之一。但是，如果你观察整个生态系统，你会发现大多数企业部署的是利用较小规模的大语言模型，这些公司通常不是在训练这些极大的语言模型，而是经常对其进行微调，这需要较少的计算资源。在进行推理时，它们通常部署在单个服务器上，其中网络不是瓶颈。在多数市场的部署场景中，我观察到的模型通常在130亿参数以下，130亿、70亿是常见的数字，得益于Meta发布的Llama 2系列模型，具有70亿、30万万、70亿参数。如果仅看下载数量，你会看到巨大的下载量和以70亿参数为中心的应用程序，这些模型在单个服务器上运行得非常好。这并不是说超万亿参数模型不重要，只是它们的应用范围非常有限，仅限于极少数。
你帮助我们了解生成式AI应用的整个堆栈，其中一些确实需要GPU、大量内存和存储以及非常快的网络，但有些则不需要。在你工作的一些系统中，你认为瓶颈是什么？我知道你从事软件开发，软件有时是瓶颈吗？
我认为主要瓶颈实际上是计算和内存带宽之间不断增长的差距。我们继续增加可以放入硅片中的晶体管数量，从而获得更多的计算能力，但内存带宽的增长速度要慢得多，这在业界并不是秘密。
好的，那么让我们听听三星的David有什么看法。David，作为内存和存储的主要供应商，你们是否遇到了内存带宽的问题？你们打算如何解决这个问题？
实际上，我们并没有遇到带宽问题，因为我们有一个非常出色的HBM产品路线图。三星不仅是内存和闪存组件的领先供应商，现在已经发展成为一家解决方案公司，这对我们来说是一项非常令人兴奋的挑战。当然，我们已经在整个领域的不同应用中涉足解决方案业务，但具体到我们今天讨论的内容，对我们来说很重要的是要找到内存、存储和计算资源之间的正确平衡，以处理LLM的平衡工作，最终在客户端实现较小规模的语言模型。
我认为，可能两年前我们讨论过云对云的部署，涉及到物联网，以及在实地端点的部署。
嗯，三星有资源支持所有这些类型的基础设施部署，并围绕LLM和数据中心、本地、云中以及客户端站点的应用开展工作。
那么你认为瓶颈在哪里呢？确实，HBM广泛用于GPU，但瓶颈在哪里？
我们看到的瓶颈主要是在计算资源和内存之间的平衡方面，提供对更多带宽需求的无尽需求。HBM在这方面可以发挥作用。此外，容量本身也会造成瓶颈，新技术如CXL可以支持这方面的需求。我相信我们稍后会讨论一些相关的内容。
Joe，接下来请戴尔的Joe分享一下看法。戴尔作为硬件供应商，需要整合所有这些组件来满足客户需求，那么在生成式AI中，我们需要关注哪些瓶颈呢？
基本上我们看到在各个组件之间的接口都存在瓶颈。你听到了我的同事们讨论的各种组件和瓶颈，我们确实看到了所有这些，但实际上，如果你从整体的角度来看，每个接口都有一个瓶颈或潜在的瓶颈。而复杂性是由每个模型、每个数据集的大小以及每个模型的大小驱动的，以及你希望分发它的速度取决于你正在进行的训练。
因此，如果你正在训练一个模型与训练另一个模型相比，你会得到一个不同的重要事项集。如果你正在进行单节点训练与多GPU节点训练相比，或者分布式或分离式的规模扩展，你会遇到不同的瓶颈。正如我的同事所说，有解决每个瓶颈的方法，但将它们整合在一起有一个技巧，你可以做到这一点，我们都在努力做到这一点，但它变得更加复杂。你不仅运行一个网络，还要运行三个或五个网络，有时甚至更多的网络。你不仅运行一个内存接口，你必须扩展内存的宽度等等。你不仅运行某种存储，而是直接访问本地存储和远程存储，并使远程存储看起来像是本地的。你不仅运行任意的软件，而是运行具有优化、以更直接、更有效地使用网络、存储和GPU的软件。
对我们来说，重要的是构建能够在各种部署中灵活使用的基础设施，然后针对每种模型、每种规模、每种训练集进行端到端的优化。这给我们带来了很多问题，有很多要解决的接口。我认为对于我们的观众来说，我们在这里看到的是观点的多样性。你看到的是不同的问题，无论是内存接口、模型的大小还是网络，所以观点的多样性当然是我们看到问题的方式的多样性。
那么让我们深入讨论一些潜在的解决方案。Joe，让我们从你开始。你是如何确定这些瓶颈在哪里以及我们如何前进来识别可以进行改进的地方的？
是的，基准测试非常重要。像MLPerf、TPCx-AI、STAC-ML等基准测试，以及一些底层基准测试如STREAM、iPerf、Fio等，可以帮助我们了解每个接口和组件的行为方式。
在实时部署中，我们需要适当的可见性、观察、遥测和分析工具，以便了解是否存在问题或是否需要采取不同的方法。同时，当某个部分运行良好时，也可以确定没有需要进一步优化的地方。
我会引用Amdahl先生的“Amdahl定律”，即优化只占问题10%的部分并不能带来太大的好处。因此，我们需要找到问题最严重的部分，这就是工具发挥作用的所在。
谢谢，明白了。
Mario，请你分享一下你的观点。对于相同类型的问题，你是如何确定问题区域和潜在解决方案的？
我认为Joe确实提到了一件我认为非常重要的事情，那就是获取关于你的工作如何运行的数据。我同意Joe的观点，基准测试很重要，但能够监控作业在运行时发生了什么也是非常重要的，因为在某些情况下，我们处理的系统非常庞大，以至于不可能或不切实际地复制它们，只是为了进行一些性能分析。
因此，在作业运行时进行监控非常重要。在这方面，软件起着至关重要的作用。当然，我们还需要硬件提供正确的遥测数据，但随后需要软件来收集这些遥测数据，同时在更高层次上对软件进行工具化也是非常重要的。例如，我们用于构建应用程序的框架，记录对我们而言至关重要的任何信息。因为我们不能过度依赖于细粒度的低级信息，因为那将是大量的信息，而且很难处理。相反，一种方法是工具化软件以立即帮助我们识别瓶颈，而不会创建庞大的日志，然后我们必须浏览这些日志，因为那将绝对不切实际。
让我们请Andres发言。这些是我们确定问题区域的一些方式。Andres，你提出了一个重要的概念。我们有许多不同的处理器，无论是GPU、CPU、DPU还是各种解决方案，我们如何知道如何匹配适合工作负载的正确处理器？我们如何确定这一点？
有人提到了基准测试，我认为这是一种方法。但我认为传统基准测试面临的挑战是，它们所使用的模型都是过去的，例如MPR基准测试从2015年的ResNet-50开始，与当前的AI领域相比已经过时。因此，我们需要监测整个生态系统，与企业密切合作，了解他们目前正在部署什么，以及他们明天打算部署什么。这与大多数基准测试中的大多数工作负载将会有很大不同。
你可能会问，我们正在采取哪些措施来提高性能并解决这些瓶颈。我们正在做很多事情，包括改进处理技术，从纳米级提高到未来几年的18埃。我们正在与软件生态系统合作，与Fighters、TensorFlow、ML业界一起确保这些库针对各种硬件后端进行了良好的优化。
你提到了可用的硬件平台，我们还致力于算法创新。例如，如何更好地量化，如何使用较低的精度，因为这需要更少的功耗，你可以放置更多的计算资源。如何将这些非常大的模型提炼为小型模型，这些小型模型在大型模型的准确性上几乎相同，但需要更少的计算资源、网络等。
如何有效地实施类似All-Reduce算法的算法，改进通信基元、通信集合基元，这在训练和推理中都至关重要。因此，我们正在全方位地看待硬件、软件和算法的协同设计，以便在CPU、GPU和加速器之间提供性能。
关于接下来谁发言的问题还不确定，但我可以加入讨论。我认为需要考虑的因素之一是时间。虽然我们可以在CPU上进行大量的AI处理，但这可能需要几天甚至几年的时间。相比之下，使用GPU通常可以更快地完成计算。另一个需要考虑的因素是成本。CPU确实更便宜，但再次强调，我们需要从整个系统的角度来考虑性能。我同意Joe的观点，即每个组件都对整体性能有影响。从软件到GPU或CPU，在GPU的情况下，我们必须记住，通常会有一个托管该GPU的CPU。这可能会影响总体性能。因此，我们必须从整个堆栈的角度来看待问题，包括所有不同的软件、库、驱动程序和组件。关于CPU需要很长时间的说法，我认为这需要进一步讨论。
事实上，在某些领域，CPU已经取得了显著的进步，大大提高了性能。现在，通过内置专门的AI加速器芯片阵列，以及软件的高度优化，CPU的性能得到了极大的提升。相比几年前，如今在CPU上进行推理和微调、甚至训练都成为可能，只要你有耐心等待。在过去，如果没有足够的优化和AI硬件加速器，CPU上的推理可能会出现明显的性能滞后。但今天，使用CPU进行推理甚至微调和训练工作已经成为可能。
Joe，看来你有些意见要发表，为什么不趁现在说出来呢？
这取决于模型、数据集的细节以及优化的具体部分。有些模型，如果你只在纯CPU上运行，可能需要很长时间，因为GPU在执行某些线性代数和算术运算方面具有优势，运算速度更快、更高效。在每瓦特性能和运行速度方面，GPU也表现得更好，拥有更多的并行流水线。现在的带宽也更优秀。
还有其他模型，可能并不需要这些优势。还有一些完全独立的模型。在推理方面，权衡更加复杂。你可能会想：“我可以部署一个GPU，但在运行和提供该GPU所需的基础架构方面存在一定的复杂性。我是否可以只使用CPU进行推理呢？”另一方面，如果你需要在边缘进行大量实时推理，一个小型GPU可能是更好的选择，或者采用CPU与GPU的组合。因此，情况并非一成不变。我的看法是，没有绝对的“非此即彼”的选择。如果你的推理需求很高，那么肯定需要使用GPU。
我们请Mario发表一下他的看法。
实际上我们面临的一大挑战是我们处理异构系统，其中我们有不同类型的计算资源。除了CPU和GPU之外，我们还可能有其他类型的加速器，如带有DPU、IPU的智能Mi，或基于FPGA的加速器，这在使用可能不受传统GPU或CPU支持的特定数据类型时可能非常有用。因此，首先取决于应用程序，但其次我们确实需要工具来能够将应用程序或应用程序的各个部分映射到系统的正确部分，这确实是我们面临的挑战之一。
好的，让David也来发表一下意见。
你提到了异构计算，这实际上是我们正在讨论的内容。在选择什么类型的计算元素最适合数据和需要运行的应用程序时，确实需要进行权衡。从基础设施的角度来看待数据中心计算，这里有一些额外的机会，特别是在节能和效率方面。通过智能地设计系统并利用像CXL这样的扩展元素和内存，我们不必移动数据就可以更智能地解决问题，而不仅仅是采取强力的解决方案。就像艺术家创造出基础设施解决方案的最佳作品一样，这可以提供可持续性的好处。
那么，David，你提到的将处理过程移至数据附近，或者将数据移至处理过程附近，亦或是两者兼顾，哪种方式更合适呢？确实，这取决于具体的应用程序。Rob，能否给我们一些实例，说明在什么情况下哪种方式更有意义？
我认为这里存在一个关键的差异：关于数据性质与边缘或云端核心相对的位置，以及处理扩展在基础设施元素中的位置。换句话说，我们是在存储方面拥有能力，还是在计算方面拥有能力？例如GPU加CPU加DPU、IPU这样的计算能力，以及是否有存储能力？因为我发现，除了非常专业的情况外，我永远无法将足够的计算能力直接放置在我的存储上，这总是一个损失。除了非常专业的情况外，永远不会有足够的容量。或者说，计算存储上的计算是否足够通用，能够更有效地进行某些转换，而不是先移动数据进行转换，然后再将其移回并用于训练。
我认为我们作为一个行业还没有就未来的方向达成共识。我们该如何实现这一点？我们该如何收敛？是的，给我们你的看法。是的，行业如何就此达成一致是一个试错的过程。我们将尝试并看看什么能够实现。让我们构建一些东西并看看会发生什么。
好的，让Andres也来加入我们的讨论。关于将数据移至处理过程附近或处理过程移至数据附近的思路，我认为这也取决于应用程序，无论是进行训练还是推理。在进行训练时，由于需要读取大量数据，因此将数据放置得离计算越近越有利。然而，在进行推理时，情况就不同了，处理的数据量要小得多，因此需求也不同。
我想再次强调一个观点，即在CPU中等待时间较长的问题。这已经不再是CPU中的问题，大型语言模型可以在几毫秒内进行推理，部分原因是加速器和软件优化的使用。在部署模型时，通常不使用在训练过程中处理的非常大的批次，因为大批量很容易并行化。然而在推理时，一次处理一个或几个样本，这取决于使用的模型，这更加困难。
有很多单个操作会受益于更高的核心性能。正如有人提到的，对于较小的操作，并行化更加困难。因此，这是一个特别适用于推理的好平台，特别是实时部署。
David，你在我们对话的开头提到了与存储和内存有关的这个SE部分，讨论了将计算移至内存和存储附近，或者将其与内存和存储集成。你对这方面的趋势以及如何解决生成式AI的瓶颈有何更详细的看法？
是的，SNIA有一个计算存储的工作模型，以及一个与之相辅相成的编程模型。我了解到，计算存储并不是一个孤立的存在，不能独立存在。我们必须将内存、存储和计算视为一个整体。最新的趋势是将内存视为内存层次结构、内存缓存甚至内存持久性的主要组成部分。我之前提到了CXL，这是一个非常令人兴奋的技术领域，因为大多数公司都在接受运行在PCIe Gen 5和不久后的Gen 6上的三个协议。
因此，这里有一个机会，可以将计算存储的定义扩展到我之前提到的数据中心计算。通过使用这些拼图块或构建块在资源之间解决性能瓶颈和效率问题，是一个非常令人兴奋的时刻。但我也看到了这里的挑战，从基础设施效率升级到与应用程序本身的同步，这是软件发挥非常重要作用的地方。
好的，那么最后再请各位就处理位置等相关话题发表一下意见。
如果可以，我想为计算移动到数据和数据移动到计算的话题增加一个维度，即在数据移动时进行计算。这非常有效。我之前提到过，例如在智能交换机中，我们拥有相当强大且高效的处理能力，特别是用于卸载集体通信期间需要执行的计算，需要聚合或减少数据，然后需要重新分发给多个工作节点的计算。这是可以在网络边缘、智能交换机中非常高效地完成的计算。当然，这需要与这些设备不同的计算能力。我们拥有功能强大且可编程的设备，但传统上这些计算能力设计用于协议处理和数据包处理。在这里，我们需要一种略有不同类型的处理，但绝对是网络中进行某些计算非常有效的地方。因此，增加这些所需的计算能力可能是非常具有成本效益的。
好的，让我们继续。对不起，这已经在InfiniBand交换机上完成了，至少在我们公司的交换机上是这样。我同意你的观点，DPU是另一个考虑这个问题的完美地方。从以太网的角度来看，是的，让我们深入探讨一下Rob，为什么这是正确的地方？
嗯，因为CPU和GPU专门用于AI应用程序，而DPU的设计目标是卸载、加速和安全地处理GPU服务器或普通服务器。它具有许多能力来加速AI应用程序。内置在DPU中的卸载引擎、风险处理器或ARM处理器基本上是针对不必担心通用CPU的非常专注的应用程序。它们连接到高性能网络，并且具有PCI交换机。它们基本上是插入到主GPU服务器或普通CPU中的小型服务器。
明白了，Joe。如果你考虑执行训练和推理这些模型所需的操作，回到最基本的原则，你需要进行数据馈送和数据变换。如果你想扩展数据或执行其他算术运算，你需要进行聚合或扇入扇出操作，其中将参数集合与简单的算术运算结合，然后进行扇出。如果你观察哪些元素擅长于哪些运算，通用计算、线性代数等都有其适用的场景。不同的元素或设备都能很好地完成其中的一部分工作。
一个DPU或网络中间的逻辑单元能很好地处理数据包的合并和发送，或者复制并分发，或者对内容进行缩放。存储计算可以扩展或过滤数据，GPU能执行线性代数运算，CPU能完成所有这些操作，但它不是最佳选择。现在人们不再只是构建CPU，如我的同事Andres所说，他们正在构建针对未来工作负载的优化处理器，结合类似GPU的东西与传统的CPU加速，这种组合对某些模型非常有效。
再次强调，这不是一刀切的解决方案。这是复杂问题的一部分，特别是如果你想为人们构建有趣的应用程序，比如真正好用的健康顾问机器人。
那么让我快速插一句，随着问题的浮现，如果有人有疑问，请随时提问。最后关于DPU的一点是，它还有助于解决网络中的瓶颈问题。因为它直接连接到网络，无需依赖操作系统和CPU等接口，可以执行一些诸如拥塞先进拥塞控制之类的操作，这些都是标准以太网上可以做的事情。你可以执行一些拥塞控制、自适应路由，直接在DPU和网络之间进行优化网络流量。当进行非常强烈的AI应用时，网络流量会变得非常庞大。
是的，你还可以准备数据以优化通信。就像你知道的，你可以进行压缩或使用特殊的加密，当然也可以利用稀疏性。所以这真的非常重要，而且非常符合Joe所说的，你知道这些不同的部分真的非常擅长他们所做的事情。如果你可以优化整个栈解决方案，使每个部分都针对其专业知识进行优化，那么你真的可以得到最好的答案。
那么Rob，现在有一个问题，Joe和Andres都在，它问的是GPU是否比CPU和DPU更有效。Joe，请继续回答，我看到你在摇头，请继续。
如果有人以同样的方式问我，我会给出一个否定答案。如果他们以另一种方式提问，我也会给出否定答案。所以没有唯一的答案，这也是我们进行网络研讨会的部分原因。没有单一的解决方案，一切都取决于应用程序。现在的主意是将整个基础设施进行解聚，有能够最有效地使用每个元素的软件，并在系统方面进行优化。这样你就可以提出一个高层次的问题陈述，它会生成一个模型，然后你可以将数据馈送到该模型中并获得答案。我们还没有达到这一步，但我们正在努力实现这一目标。
Andres，请就同样的问题发表一下你的意见。
我们在大型语言模型领域面临的挑战，尤其是在过去一年里，爆炸性增长，是没有一种单一的硬件能够在大型语言模型的两个阶段都表现出色的，而且在两个端点都存在效率低下的情况。因此大型语言模型的两个组成部分是处理输入，这是非常计算密集的操作，然后开始生成文本或标记，这是非常内存带宽密集的操作。因为对于每个生成的标记，你通常都需要从内存中读取整个模型。在某些情况下，模型可能相当大，即使是较小的语言模型也仍然相当大。因此，你必须移动所有这些数据，而且在此期间，你的CPU或GPU的计算能力在低利用率下运行。因此这确实是一个巨大的挑战。我认为硬件供应商在能够尽力预测未来以及硬件组件将如何受到压力的情况下所面临的巨大挑战，以便能够做出正确的设计决策，以提供市场上可能提供的最佳平衡平台。但是可能会存在一些效率低下的问题，因为模型将会对AI系统设计的不同部分施加压力。
有一个具体的问题是关于GPU与GPU接口的。我们的朋友Danny问到NVLink或其他专有GPU与GPU互联是否会解决瓶颈问题。为什么行业关注8 GPU部署而不是16 GPU部署的方案？因为大型语言模型并没有在成千上万的GPU上进行训练。有谁愿意回答吗？
NVLink的设计初衷是实现GPU的集群化，并让GPU之间共享内存。这种性能非常强大，比我们目前支持的其他任何网络技术，比如InfiniBand或以太网，都要出色。
但是，它的规模是有限的。我们正在努力扩展其规模，但无论如何，其主要目的是让GPU能够共享内存，从而解决之前提到的内存问题。当然，对于非常大的问题，通过集群化GPU也能带来优势。在CH中的8、16与32的CH，机箱和盒子的设计都是实际可行的极限。这并不是基于任何基本原则的原因，只是我们能放入一块薄金属板上并能一起运行的极限。它受到PCI到CXL开关大小、每个接口的连接数、我们讨论过的带宽连接性限制，以及功耗和散热的限制。
我想说的是，未来的机箱设计将发生变化，这很有趣。因此，存在一些标准，如Open Rack V3，这将改变现状。还有一些重要的电源和散热趋势，你可以查阅相关资料，这将改变现状。你知道在一个机箱中有八个GPU和本地连接是切实可行的，如果能有32个我会更高兴。如果能在一个机架中有4到64个，并且超级灵活，我会更高兴。但实际上它们是有权衡的，这就是为什么你看到这些数字的原因。
而NVLink在Joe刚才提到的参数范围内没有任何限制，它可以执行任何操作。实际上，即使是在构建CXL网络方面，所有网络的光信号速率，即使你在谈论构建CXL网络，线上的速率和线上的距离基本上是相同的。因此你构建网络拓扑的带宽量和方式是一个复杂的问题，再次充满了权衡。我知道我一直在说这个，但我希望你能明白，没有一个解决方案是万能的。
我们知道，理论上所有网络都可以扩展到你想要的任何规模，只要你愿意付出所需的交换机和接口数量，花费时间和资源进行调整、配置和解决实际操作问题。所以理论上，这些网络都可以根据需求扩展。但是再次强调，没有任何一种方案可以解决所有的问题，使用CXL会遇到与分布式CXL相同的网络问题，使用InfiniBand、以太网、NVLink等也会遇到相同的问题。坦白说，这与之前存在的光纤通道、环形FDDI等网络问题是一样的。是的，我们正在重新审视这些问题，但速度更快。
抱歉打断一下，让我们快速转到Mario，Andres，我一会儿会回到你。Mario有一个问题，是否有带有矢量引擎的DPU？Rob，InfiniBand交换机是否带有矢量引擎？Mario，请继续。
嗯，据我所知，目前没有DPU配备了矢量引擎。它们主要是为了数据包和协议处理而设计的。然而，确实存在其他解决方案，比如FPGA，可以在这些平台上实现各种处理和操作。我之前提到的是关于数据类型的问题，哪种数据类型最适合特定应用程序。
好的，Rob，请你简要回答一下。
至于InfiniBand交换机是否带有矢量引擎，我无法给出100%的确定答案。但它们非常强大，并且一直在不断增强。多年来，它们在高性能计算领域的应用已经证明了这一点。另外，我们还制造了带有GPU和DPU的PCI适配器，因此你可以同时获得两者的优势。
我认为David可能被卡住了，我们可以转到下一个问题。
关于扩展，Joe和Rob你们说过，无论之前提到的接口还是NVLink，都存在某些挑战。但是这些连接可以共存，对吧？
CXL非常有趣，因为你可以为加速器使用三种协议类型。就像我们之前讨论过的智能网卡一样，那是类型一，还有用于内存缓存的类型。实际上，对于CXL，Joe是对的，物理上只能做这么多，但在内存扩展和内存分层以及通过CXL解决智能网卡的问题方面，有扩展这些障碍的机会。
因此，考虑到我们拥有的整体方案，我认为这些接口是可以共存的。而且随着时间的推移，这些接口的速度会越来越快，因为人们学会了如何更好地利用它们，如何调整它们以使其更实用。但是再次强调，每种技术都有其局限性。没有一种技术可以完全替代另一种。如果使用CXL，就会遇到与分布式CXL相同的网络问题，还会遇到与InfiniBand、以太网、NVLink等相同的网络问题。坦率地说，这与之前存在的光纤通道、环形FDDI等网络问题是一样的。是的，我们正在重新审视这些问题，只不过速度更快。
尽管如此，我认为在协议级别存在另一个限制。这些协议被设计用于构建不太大的群集或Pod。一旦想要构建更大的Pod或群集，就需要引入更多的复杂性。例如，Rob之前提到的复杂的拥塞控制问题。那些解决方案并没有设计来处理这样的问题。这就是为什么它们更快、更平坦的原因。这也是为什么在这种情况下我们需要一套不同的解决方案的原因。通常我们在扩展和展开之间进行区分。更远和更大规模通常也意味着性能较低。
引入具有加载存储的内存语义与读写和流语义相比，确实是一个有趣的方向。我是说，所有这些语义都会给你不同的编程模型认识，并以不同的方式抽象硬件。将一定程度的横向扩展内存混合到透明的存储访问中，并让一些基础设施处理较低级别的优化，这是一个有趣的前进方向。你是说缓存吗，John？
是的，缓存或分层，或自动将数据移动到正确位置的操作，这样应用程序就不必管理自己的数据访问和数据移动。这些底层操作在应用程序进行加载、存储、加载、存储时发生，包括GPU和CPU，底层是一系列复杂的事情。现在，你是否可以使它在一个大的域上保持高速缓存一致是一个有趣的理论和实际问题，但行业正在研究所有这些各种各样的组合，因为每个人都与每个人合作，我们正在研究所有这些各种各样的组合，而且我们有进行相同研究的行业联盟。这让我想到的是，眼下最丰富的创新领域可能是将软件堆栈整合到基础设施中，以及软件堆栈如何以一种非常清晰的方式优化和利用该基础设施。
好的，让我们迅速转到Andres，来谈谈在软件领域如何将软件堆栈整合到硬件中。之前你想提到的一点，Andres，请继续。
首先，我们谈谈在实际中将计算节点扩展到8个以上的问题。在GTI加速器和Ari加速器的背景下，我们研究过这个问题。它们确实需要在8个单位以上进行扩展。虽然理论上能力是存在的，但在实际情况下，特别是对于推理任务而言，这并不是那么关键。当你拥有8个GPU或其他GPU组成的群集时，几乎可以对每个LLM模型执行推理。你有足够的内存容量来执行极大型语言模型的推理，参数高达200多亿个。但当模型进入推理时的万亿级参数规模时，你需要扩展到32个节点。实际上，很多公司很少部署这样大型、极大型的语言模型。8个节点似乎是一个可以覆盖绝大多数市场的平衡点。
在整合软件方面，大多数市场使用PyTorch，而TensorFlow的使用程度较小。TensorFlow的流行度在下降，而PyTorch的流行度正在上升。作为硬件供应商，我们与这些公司合作，确保这些库能够充分利用我们作为硬件供应商提供的计算和通信功能。我认为我们需要继续保持这种密切的整合，确保这些开源库与我们作为硬件供应商之间的整合，以确保这些库的最终用户能够从硬件供应商提供的加速中受益。
好的，现在我们快到整点了，感谢我们的观众一直陪伴着我们，也感谢我们的专家小组。现在我们将迅速切换到快速回答环节，我将要求你在五到十个词的范围内总结，看看你是否能够在这个框架内概括解决生成式AI瓶颈的方法。
Rob，让我们先听听你的意见。
GPU效率、内存和网络。
Mario。
效率，对于特定的运营场景使用合适的计算资源。
Andres。
单位芯片容纳更多的晶体管的处理技术，经过更好的软件优化，充分利用所有晶体管和算法创新，从而实现在较小的语言模型（或一般意义的小模型）上实现大语言模型的需要的性能。
Joe，请继续。
优化的软件集成，建立在分布式灵活硬件之上，解决各种模型类型和规模的AI问题。
David。
智能且节能的基础设施解决方案。
---【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/关注领域）