利用CXL技术：提升内存利用率，降低总内存成本（网络研讨会）
利用CXL技术，有效提升内存利用率并降低总体成本。CXL引入了先进的内存扩展和布局管理功能，增强系统可扩展性和灵活性，实现资源共享，提升性能，降低软件堆栈复杂性，同时降低整体数据中心成本。CXL 3.0中的布局增强和内存扩展功能满足HPC和AI大型模型需求，提供新的可组合性水平。
本次网络研讨会深入探讨CXL 3.0功能、新特性以及连接CXL内存的投资回报率示例。
好的，再次欢迎大家参加我们的网络研讨会，讨论CXL内存利用率。我是主持人Kurtis Bowman，CXL营销工作组的联合主席，与英特尔的Kurt Lender一同担任该工作组的联合主席，同时也是AMD的服务器系统性能总监。今天，我们有一些出色的嘉宾，包括来自Wolley的Bill Gervasi，他是那里的首席系统架构师；Micron的Vijay Nain，他是CXL产品管理的高级总监；以及IntelliProp的联合创始人兼工程副总裁Tracy Spitler。现在让我把话传给我们出色的演讲者，我们今天将从Vijay开始。
谢谢Kurtis的介绍，大家早上好，晚上好。
首先，我要说的是，对于任何新技术的成功，所有关键的生态系统参与者积极参与是非常重要的，而CXL无疑也是如此。让我们从推动者开始，换句话说，CPU供应商。在Micron，我们看到了与CPU供应商的极高水平的合作、参与和支持，这涵盖了从基本的启动到解决早期问题，确保CXL内存模块的验证正确进行。众所周知，Micron是内存供应商，正如我们所知，对于任何新的内存技术的成功，不能仅有一个供应商。因此，我们对事实感到非常高兴，即我们与其他两个大型供应商一起提供基于CXL的内存解决方案，这对CXL的未来发展非常有利。
从CXL 2.0兼容的CPU和内存模块开始，我们看到了来自所有主要服务器制造商或OEM的极强参与度，无论最终平台是进入传统企业环境还是超大规模环境。为了使所有这些都能够运作，需要一个健康的CXL ASIC生态系统，而它确实存在，有多个在该领域提供略有差异的解决方案的供应商，同时仍然符合基线CXL规范。这确实为行业提供了各种不同的选择，用于实施概念验证、制定不同的价值主张等等。
对于CXL而言，一个非常有趣且重要的领域是软件堆栈。这真的很独特，因为如果考虑传统内存模块的情况，您只需将其插入服务器插槽，然后与您选择的CPU进行一些基本的兼容性测试，这就完成了您需要进行的测试范围。而对于CXL，情况则不同，我们需要确保位于裸金属的第一层软件，无论是商业版还是开源版的虚拟化程序，或者只是数据中心中的Linux或Windows操作系统，该软件层需要意识到CXL内存模块，以便能够从不同的应用场景中提供最佳价值。
接下来，我们将继续深入探讨软件的基础层面。我们发现了一些在兼容性和应用场景方面非常有吸引力的应用程序。为了更好地管理CXL带来的不同内存层面的应用程序，我们需要从两个方面入手。首先，利用操作系统的工具和功能，更好地从CXL内存中获取价值。我们已经看到一些公司提出了非常出色的解决方案，以最大化CXL的价值主张。此外，随着我们在堆栈中不断升级，我们发现一些终端用户应用程序已经展现出与CXL相关的一些显著优势，无论是从带宽扩展、容量扩展还是二者的结合来看。
最后，为了确保所有这些能够很好地协同工作，在2.0时期，我们看到测试基础设施和测试供应商提供了卓越的支持，制定了一个非常坚实的基础设施，确保我们构建的任何东西都毫无例外地符合基线规范。现在，让我们稍微谈谈今天实际可用的硬件是什么。
在这里，我们看到了一些性能改进，我们可以讨论一下。左上角是一个很好的例子，我们有一个CXL 2.0兼容的内存模块，Micron已经公开发布，基于E3.S的尺寸，有两种容量规格，128GB和256GB。重要的是要将其与RAM进行比较，其中从这些模块中获得的带宽大约相当于从单个DDR5 A获得的带宽，该DDR5 A可能以每秒4.8亿次传输运行。这对比较直接连接或作为CXL模块的东西在带宽和容量方面可以获得什么非常有用。通过添加8个256GB的内存模块，我们可以看到增加了2TB的内存容量，通过使用基线为12的RAM的四个额外模块，我们可以看到内存带宽增加了24%。这是通过CXL进行内存扩展时可能看到的一些非常基本的第一阶效益。
一些我们看到明显效益的应用场景在右上方，这是您向任何系统添加纯粹的内存容量时可能看到的最明显的效益。SQL服务器在内存量方面有限，因此不在内存中的所有内容都必须在磁盘中。通过添加直接Rach或CXL的UDIM，您将看到这类数据库工作负载的性能大幅提高。这个2倍的增加纯粹是一种容量操作，对于这类应用场景来说是明显的附加值。右下方是一个略微更有趣的应用场景，更为微妙的应用场景，即深度学习推荐模型（DLRM），这是Meta开源的工作负载，他们今天在其推荐引擎中使用了这个工作负载的某个变体。他们需要执行的更复杂或更密集的操作之一是嵌入缩减，从数学角度来看，这实际上是将一堆矢量压缩成较小数量或单一矢量，然后有助于进一步下游的计算。这里的两个要点是，从这张图中可以看到，随着从左到右的移动，净吞吐量增加，因为您增加了线程的数量并增加了可用的计算量。如果您看左侧的直方图，我们会发现当添加CXL内存时并没有太多的改进，因为限制来自计算能力，而我们还没有达到内存带宽或容量的限制。当我们移到右侧时，我们看到吞吐量增加，但现在您可以看到直方图的独立条的相对变化，因此对于每个直方图，您可以将从左到右移动的条形视为您通过RDM或通过CXL内存直接分配的内存比率的指示，而DLRM找到了一种在本地附加和CXL附加内存的某种组合下确保最大可能吞吐量的最佳点。因此，这里的主要观点是，对于您使用的每个最终应用程序，都会有一定的比率，确保实现最佳吞吐量。
现在让我们谈一谈我们一直在研究的一些新的应用场景，再次强调这都是基于CXL 2.0的，因此这表明在3.0时期取得了很大的进展。左侧的图表实际上是Micron在Llama语言模型上运行的AI推理工作负载。我相信线上的每个人都对Lama非常熟悉，这是当今开源语言模型的方案。因此，我们运行了一个拥有700亿参数的模型，这里有两个要点。首先，在图表的下部，您可以看到性能有了净22%的提升，这是通过查看语言模型的每秒标记数或RTH（每小时请求）来测量的，这源自带宽扩展。在图表的上部，我们可以再次看到，取决于运行的工作负载类型。Lama是一个非常读取密集型的工作负载，几乎没有写入，因此通过确定直接连接内存和CXL连接内存之间的不同交织比，可以优化吞吐量。在这里，我们展示了一种软件交织方法，它为您提供了更多的灵活性。
移动到右上方，机器学习训练中存在一些应用场景，您可以将各种不同的介质组合放在CXL接口的后面，并在GPU训练吞吐量方面获得好处。正如我们所知，今天数据中心中的所有GPU都使用高带宽内存，高带宽内存在其所做的事情上非常出色，但在您可以塞入GPU的内存方面也有一些限制，而且价格也非常昂贵。当您超出本地连接的HBM支持的内存需求时，通常会转向CPU，使用一些连接到CPU的内存，或者必须转向磁盘。在这两种后一种情况下，CXL都可以帮助，可以通过扩展与CPU关联的可寻址内存来扩展，或者可以拥有某种混合介质，您可以在CXL后面拥有极大的DRAM缓冲区以及Flash，并在GPU训练中获得吞吐量的好处。
最后，在右下方的虚拟机空间中，CXL 2.0开启了一系列不同的机会，从扩展某些虚拟机的内存容量，为它们提供更多的带宽，甚至转向第三个虚拟机架构，您可以说，我不希望此虚拟机使用的所有内存都是直接连接的，我可以接受其中一部分的延迟较高，并通过CXL进行连接。这些应用场景还为VM提供了更多的机会，我们开始在行业中看到对这些应用场景的更多兴趣。所以我知道我稍微提到了ML训练，但现在我要把话交给Bill，他将为您提供更多关于这个特定领域的详细信息。
谢谢Vijay，接下来我们将深入讨论在人工智能加速、机器学习等方面使用CXL的用途。
当我们考虑将HBM用作引擎的加速因素时，这是一个很好的选择，但容量有限。即使您将这些堆叠得相当高，您可以增加的容量也是有限的。例如，对于典型的应用程序，您可能会获得80 GB的总容量，但您还必须在加速器和内存设备之间有9600个信号，并且它们必须在2mm以下。因此，从物理上来说，这意味着您将会遇到瓶颈。特别是在大型语言模型中，它们根本无法适应HBM，这就是您遇到这个无法将模型适应内存的障碍的地方。特别是这意味着您通过添加更多的AI加速器来增加带宽，存在基本成本和基本足迹的增量。
因此，Wolley想要探讨的是对此的替代方案。我们正在与一个需要为大型模型扩展但简单无法适应足够HBM的客户合作，由此引发的问题是屋顶线模型指示了这一点，您可以在某一点之前添加内存，然后从那一点开始变得受到计算限制。因此，大型语言模型的挑战是改变这个拐点，如果我们可以增加内存量，我们可以改变从内存受限到计算受限的切换点。我们不能通过不断添加更多的HBM来解决这个问题，因为它存在物理限制。
因此，我们向行业提出的建议是重新思考内存的架构，特别是当您观察CXL接口时。来自主机的FLIT或流控制单元包含内存所需的所有元素，包括地址、读或写命令、数据和内存子系统所需的元数据。鉴此，我们创造了一个名为CXL本地内存的解决方案，它利用了这一点，并通过在逻辑处理过程中实现了这一点的独立芯片连接到逻辑设备的裸内存芯片。从某种程度上说，这类似于HBM，但我们将其集中在一个更窄的接口上，即32个信号接口和PCIe x8接口。
接着，我们将在一个地方集中您在内存中实现的所有逻辑，并实现一个宽内存总线和宽IO，使我们能够在每个时钟周期内处理完整的缓存行或FLIT。通过这种方式，我们并非试图替代HBM，而是认识到HBM在逐步增加内存容量方面的优越性，尤其在非常嵌入的环境中。因此，通过非常窄的通道，我们能够增加大量的内存。利用PCIe Gen 5，我们可以获得32 GB/秒的传输速率，因为PCIe接口是全双工的，而CXL允许在峰值时同时进行读和写，从而实现这两者的并行操作。我们已经在超级计算大会上启动了这种尺寸规格的标准化，并正在考虑提出一种用于NVMe的M.2连接器的变体，将其扩展为8位接口。
因此，在大约一英寸乘一英寸的模块中，您可以在每个32引脚端口上增加8到16 GB的内存。设计成更长的连接，如100毫米，可以放在HBM之后更远的地方。通过逐步增加这些内存模块，这就是我们将提高屋顶线并提高整体解决方案性能的方式。值得注意的是，我们还观察到UCI与CXL虚拟世界非常兼容，因此，尽管焦点是CXL，但这里看到的一切同样适用于UCI。
实施。现在，能耗是一个巨大的问题，所有的数据中心经理都意识到，特别是对于人工智能，需求使得能源消耗急剧上升。美国能源部已经着手进行了一个计划，以确定其来源。正如您在左下角的图表中所看到的，加密货币和人工智能的能源使用量远远高于标准编程。因此，我们已经确定这是一个问题。
那么我们要对此采取什么措施？CXL解决方案难道不会使电源状况变得更糟吗？事实证明，这是一个小小的误解。当我们将这些内容组合在一起时，我们发现通过减少传输距离，并针对焊接或小型模块尺寸规格进行定位（与插入式模块的E3.S尺寸规格相对），我们可以将功耗降低到与HBM竞争水平。在这个特定的模型中，我们将其与LPDDR进行了比较，您可以看到在比低功耗DDR甚至LPDDR更低的轮廓下，您可以获得显着更高的性能。
这是因为我们可以假设短传输，可以完全消除DDR接口到内存的所有冗余电路，所有这些DDR芯片中都有这些冗余电路。此外，我们还可以考虑重新设计刷新操作的方式，花费大量能量仅用于刷新那些存储器单元中的电容器。现在，我们可以将刷新与CXL内存分配器联系起来，并进一步减少功耗。最后，我们的以FLIT为导向的页面意味着我们可以将内存专注于满足CXL的需求，而不是DDR甚至LPDDR对行业提供的通用解决方案。
通过以FLIT为导向，我们可以在每个时钟周期内移动64字节的数据进出核心，实现的效率比今天内存模块中的每个1千字节页面的效率提高了2000倍。那么性能方面呢？性能也是一个问题，因为我们认识到CXL的延迟略长。那对性能有何影响？嗯，您必须记住，CXL接口通过是全双工的，不像DDR、LPDDR、HBM或其他解决方案那样迅速退化。因此，在轻负载下，它们几乎是等效的。DDR解决方案在轻负载下性能可能略优，但随着负载加重，您会发现CXL解决方案的性能下降要比LPDDR的下降平缓得多，因为现在您正在处理转换时间气泡等问题。
总的来说，在这里我们看到的是，大型语言模型和越来越多的人工智能应用，包括加密货币，基本上是受限于内存的，需要一种扩展。因此，CXL的使用解决了将HBM作为模型唯一高速来源的局限性。这个CXL本地内存解决方案是以FLIT为导向的，它将CXL的概念直接提供到内存单元本身，如果您需要大量扩展内存容量，302引脚通道是将您已经放入系统的内容的简单方式。CXL内存功耗在设计为适应这些INM主板解决方案时可以与HBM相竞争。最后，全双工操作是抵消您可能会因CXL而获得的一些延迟惩罚的原因。有了这些，我就把话接给下一个演讲者。
谢谢，Bill。嗯，我是Tracy Spitler，正如Kurtis之前介绍我的那样，我在IntelliProp工作，我们已经在组合内存系统领域工作了五到六年。随着CXL 3.1的推出，我认为CXL已经开始充分认识到它在组合内存方面的能力。所以在3.1中，Bill和Vijay谈到了自一开始以来一直伴随CXL的内存扩展、带宽等方面的所有内容，一直到2.0和3.0的推出。而3.1的引入真正扩展了真正的可组合性。
在3.1中，引入了基于端口的路由交换，基于端口的路由交换将为您提供对基于树的拓扑之外的拓扑的支持。因此，在分层的基于树的路由开关（HBR开关）中，我们在某种程度上受到了PCI树型拓扑的限制。现在，随着3.1和基于端口的路由架构的引入，您可以摆脱这种限制。另外，您可以设置开关进行基于地址的路由，从而定义最佳路由路径、冗余路由路径和辅助路由路径。再次远离树型拓扑，您可以开始支持各种拓扑，如树、网状、环、星型和多维拓扑。我现在不会过多涉及这一点，但在3.1中，这是一个相当重要的问题，因为您现在共享内存，可能有多个主机连接到同一内存，也许连接到相同的区域，也许不连接到相同的区域，而在安全性方面已经有所增强。
在协议方面。因此，对于几乎任何新技术，您开始思考使用情况和可以应用此技术的地方。我认为Vijay和Bill都涉及了这些应用场景，但我想转向可组合内存如何应用于这些应用场景，因此如果我们从云计算开始，特别是虚拟机，多年来在考虑和引入可组合内存时的一个讨论焦点是，您是否可以解决被滞留内存的问题。我在这里脚注了一篇由Microsoft Azure团队撰写的文章，他们在其中很好地讨论了滞留内存的不同场景，以及CXL池内存如何解决滞留内存的问题。我认为在这里有一些有限的情况，取决于您内存的规模和系统的大小，它可能值得成本。而且，这篇文章很好地指出了，如果您要使用CXL池内存来解决滞留内存问题，这实际上是您必须这样做的方式。
超越滞留内存，我们从VM提供商、软件公司以及在安全性方面部署VM的人们那里得到了很多关注。当您运行VM时，人们担心如果CPU受到威胁，恶意行为者可能会访问您的数据。现在有了内存池，有了这种多CPU的应用场景，不仅仅是在其本地内存上，而且可能在这个与内存相连的结构上都在运行VM，从同一物理内存上运行VM。我认为这是一个好主意的应用场景，我们将稍后讨论在将VM部署到结构内存时可能遇到的挑战。
当然，每个人都担心性能，这是一个成本性能的权衡，但如果您正在进行大型数据库应用程序和需要大量交换并且经历了很多页面故障的操作，而不是交换到存储，正如Vijay也提到的，现在您可以交换到与结构相连接的内存，并获得从延迟和带宽方面都更好的性能。
还有另一种应用场景，很多人喜欢谈论的是AI训练和推理模型，显然在过去的18个月或两年里，这已经爆炸了，有很多人处理这些大型数据模型的技巧或算法，其中很多涉及存储和从存储交换数据以及从CPU内存交换数据到GPU内存，现在有了与结构相连的内存，您可以有多个处理元素，它们都可以共享相同的数据集，直接访问该数据集，并且因为它是可组合的、动态可组合的，您可以根据每个使用、每个训练或每个推理应用程序的需要来扩展或缩小所需的内存，然后为下一轮数据集再次扩展或缩小它。因此，再次，CXL内存池的潜力与应用场景相匹配，但这也扩展到了它可能发展到的地方。
因此，对于云计算和HPC，您确实会遇到，Bill和Vijay都谈到了延迟，您确实会遇到延迟问题，甚至Microsoft Azure的文档指出延迟可能非常可控，并且很多软件可以处理较高的延迟，如果您能够看到与内存相连的延迟是多少，您可以根据这些延迟调整软件工作负载。再次，我在上一张幻灯片中谈到了这些根据工作负载波动动态调整的内存大小。因此，您不会因为在启动服务器时分配的内存而被困在内存中，现在您可以添加和拿走内存，并且我们已经在这方面进行了实验，我们与客户合作过，这对于许多应用场景来说确实是一种理想的情况，因为您的工作负载增加时，可以根据结构中的可组合性动态更改内存大小，而在工作负载下降时，可以将其缩小或扩大。
然后我之前提到过VM，并且稍微涉及了一点安全性，我们与部署VM和VM公司交谈的一件事是这个无摩擦的主机迁移的概念，所以如果您担心您的CPU或主机已经受到威胁，但您的VM的数据全部保存在结构相连接的内存中，将VM完全移到指向相同数据集的不同CPU几乎是无摩擦的。然后，在AI和GPU部署方面，我再次强调这一点，动态内存容量实际上是很多人都可以充分利用的东西，根据您当前的工作负载以及未来一个月、六个月或一年内的工作负载变化，您可以动态地更改该内存容量，而无需关闭服务器。再次，AI和GPU应用程序可能非常适合结构相连的内存，因为它们对带宽的需求很大，但它们往往对延迟非常宽容，因此它们与这种可以提供高带宽但可能会对延迟产生负面影响的内存结构非常匹配。
再次强调共享处理单元的概念，您可以在结构内存中拥有一个数据集，并且CPU、DPU、GPU都可以查看和操作该完全相同的内存，现在您可以在不添加昂贵的GPU的情况下增加内存容量。我们看到有几个客户向我们表示，你知道，我获取更多内存的唯一方法是添加GPU，因为他们的HPM内存受限。现在，如果您的GPU可以直接连接到与结构相连的内存，您可以增加内存容量，而无需在您的集群中堆叠更多的GPU。再次强调这一点，通过用与结构相连的内存替换高成本HPM，减少甚至可能消除那些昂贵的GPU。Bill也提到了这一点，能源是一个大问题，我最近读到一篇有趣的论文，他们讨论了很多人谈论训练和能源的数量，但真正要节省大量能源的是推理，因为那是持续的成本，训练只发生一次，推理可以一直进行。因此，通过使用与结构相连的内存并减少数据副本，也许您可以有多个GPU进行相同的推理，但都使用相同的数据副本，因此您不需要在内存中拥有100或1000个数据的副本，您可以有一个副本，它们都可以访问它。再次回到根据工作负载波动动态调整内存大小的思想，如果您有多余的内存，并且在结构相连的内存M方案中没有使用它，您可以关闭该内存，如果您不使用该内存，就没有必要保持该内存的电源开启。
我在右边放了这张图，第一次我差点漏掉了，但这是直接从CXL 3.1规范中截取的，显示了基于端口的路由拓扑的多路径、多主机和多设备的能力，我确实想谈谈这个，这有点偏离硬件的话题。
但是，Vijay和Bill都提到了软件堆栈和支持CXL以及CXL连接内存的软件需求。现在这不仅仅是在结构拓扑中的软件应用了，您还需要一个结构管理器，这在内存管理方面是相当新的概念，因为现在您有了可以动态组合的内存，需要在这些交换机中设置路由，其中一个重要的组成部分就是结构管理器。
结构管理器是一种软件堆栈，通常运行在您的CXL PBR交换机上，其责任之一是拓扑发现和报告。因此在初始化时或设备进出时，结构管理器负责保持附加的内容和其位置的清单。此外，还有组合控制。当主机需要内存时，结构管理器是分配任何CXL设备给任何主机的软件实体。然后是之前提到的路由控制，基于地址的路由。结构管理器实际上是输入到定义路由的开关的输入。还有安全控制。我们之前提到了安全性，当然，现在您有了这些开关和这些可能在不同电源供应器上的内存，很可能在您的CPU框之外，跟踪在结构中的健康状况和监控是至关重要的，而结构管理器将不得不处理所有这些事务，与结构管理器的交互以及从结构管理器的交互。
因此，结构管理器了解硬件，因此它与开关硬件进行接口。然后在结构管理器的另一侧通常会有一个可组合性代理。可组合性代理将告诉“这个主机想要这个内存，所以现在我需要告诉结构管理器将该主机分配给这个内存”或“这个主机不再需要那个内存，我需要告诉结构管理器取消分配那个内存”。一些例子，开放结构联盟有他们的Sunfish框架，然后有液体操作系统，我们与那些人做了很多工作，他们以实现可组合性而闻名。我相信还有其他的一些人，OCP和其他人也在考虑这个可组合性代理。
这一切听起来都很好，但并非容易的，没有什么是没有代价的，所以让我们稍微谈谈CXL池内存的挑战，以及部署与结构相连内存需要克服的障碍。一个经常被提到的问题是软件摩擦，通过软件摩擦，我指的是现有的HPC、GPU和AI软件堆栈已经考虑到没有与结构相连的内存，而这些软件堆栈是经过验证的，我认为每个人都知道在HPC或服务器级别重新验证软件有多么困难。
因此，关于在哪里可以进行软件更改的一些建议，在VM空间中，要到达与结构相连的内存，将会有更长的延迟是不可避免的，当通过交换机进行切换和跳跃以获取内存时，延迟会更高。因此，VM团队和软件开发人员可以努力找出如何容忍更长的延迟，或者了解内存子系统，以便可以在能够容忍时请求更高的延迟，或在需要时请求更低的延迟。当然，不仅仅是纯粹的容忍延迟，还会有变化。根据您的结构中有多少流量，那个延迟可能会相对不那么可预测，再次回到能够容忍延迟，以及可能是NUMA感知。
我提到了NUMA感知，我们进行了一些实验，将不同的NUMA域连接到不同的L域，以便可组合性管理器可以理解根据您拥有的延迟层级在NUMA中放置内存的位置，然后NUMA感知的软件可以理解我可以期望多少容忍度或延迟。然后，从AI方面来看，编程调度将发生变化，如果今天您正在运行GPU，正在将数据交换到GPU的HBM内存中进行调度，那么如果GPU可以直接访问并直接具有对结构相连的共享内存的加载存储访问，调度程序肯定会发生变化。您知道您可以减少GPU的HBM甚至可能消除它，但这实际上要取决于应用场景和您的架构，以及诸如延迟和带宽之类的因素，而且在AI方面，您是否可以重新思考数据的复制和移动。还会出现一些其他的挑战，比如可扩展性，Bill提到了HBM的物理限制，CXL在PCI上运行，如果要在结构相连的内存上进行横向和纵向扩展，能够容忍几厘米的物理互连，可能无法横向扩展得很远。当然，当您添加了一堆开关时，您正在复杂化您的延迟，还有成本，这并不是免费的，开关将产生成本，根据您希望在内存控制器中放入多少智能，它将增加成本，这一切都不会免费。不仅仅是成本，而且是延迟成本，如果您尝试进行横向扩展，您可能认为不得不加倍，以到达开关，以实现横向扩展。然后这是复合的，您要弄清楚成本有多高，以及它能够节省多少。我认为每个人都知道DRAM成本可能会波动多少，所以这些是我们认为的一些挑战，它们当然不包括人们可能会遇到的所有挑战，但这些是我们看到的一些早期的障碍。
我将其交给Kurtis来主持，看看有没有来自观众的问题或讨论。
好的，首先我想感谢Vijay、Bill和Tracy今天的演示，非常出色的演示。现在我们开放提问，请在您有问题的情况下输入，我们会回答的。
我实际上要开始问Vijay一个问题，当你谈到通过CXL连接到服务器的内存时，你认为将通过CXL连接到支持的服务器的内存的类型是什么？
这是一个非常有趣的问题。我认为如果你看一下当前的现状，我们已经看到的是，在我们的超大规模云服务商中，有一种在CXL结构中使用旧一代内存的兴趣。这有两个非常有价值的目的。首先，当然是成本方面，直接连接到服务器的内存可以作为CXL结构中的第二层内存，找到一个新的用途，而不是在公开市场上出售，可以作为潜在的第二层内存。然后第二个好处当然是，我们现在都在竭尽全力提高环保意识，因此重用是一个很重要的问题，所以它也有这个目的。所以您会看到不同年份的不同版本，在CXL部署中，这是一种情况。第二个是我认为，数据中心中使用的内存需要更低的功耗，我们已经开始看到一些这方面的趋势，有关LP CAM在数据中心中是否适用的讨论，因此肯定会有对低功耗内存的兴趣，通过CXL或通过CXL提供这些内存。最后，我认为随着我们在CXL领域的探索，您会看到更多需要通过CXL连接到某种组合的DRAM或支持加载存储语义的其他内存以及更持久的介质，为特定工作负载和特定应用场景提供价值。我认为在我提到的最后一个情况中已经有一些例子，我认为我们会看到更多这样的解决方案。
非常感谢，谢谢。我们有来自观众的问题。来自三星的William提问关于我们谈论的通过CXL的AI加速器。CXL本地内存在PCIe Gen 6上通过8个通道运行，可能需要11个通道才能跟上HBM的性能。他的问题实际上是，是否有关于在CPU或集群中的PCIe通道数量的限制，使其可行，或者在数据中心中如何进行扩展。
是的，这是一个很好的问题，我认为会有多个答案。首先，在理论上，32条线接口比目前的19 120条线容易管理得多，而且HBM 4的引脚数将再次翻一番，所以您有一些基本的引脚数量限制。部分答案将是您希望在CPU、GPU或APU上放置多少个端口，这将随着时间的推移而演变，因为像CXL本地内存或其他解决方案的可用性，可以通过低引脚数的接口进行大量扩展，进入市场并且可用。
第二个答案实际上将由Tracy提供，Tracy，你是否愿意回答关于如何使用交换机的一部分的问题呢？
扩展方面，当然，我同意Bill的看法。交换机在这里确实起到了一定的作用。从物理上来说，你可能没有那么多的连接到CPU或GPU，但交换机可以扩展内存单元的数量。如果你的交换机、拓扑结构和架构设计得当，你可以考虑将连接到交换机的CXL内存进行交错排列。假设你在一侧连接了16个CXL内存，而GPU则可能有四个8x16的CPU或GPU CXL接口，通过在内存之间进行交错排列，你可以保持在这些CXL接口上的最大带宽。我认为你们也应该开始考虑超越PCIe Gen 6，思考PCIe或CXL可能采用的其他物理连接，比如可能是800 Gbit，这将允许更远的传输距离，以实现可扩展性和更高的带宽。另一方面，我认为答案还将来自UCIE（Unified Connector and Interface Extension）前端，减少UCIE接口上的信号数量也将非常有价值，因为我们正在设计更长的传输距离，这也可能在基板上实现，我们可能会看到这种连接方式与处理器进行连接。
好的，感谢你们的见解。
Bill，我有一个问题要问你，CXL 内存设备是如何管理电源的呢？
首先，你是否想看一下当今 DRAM 解决方案的效率，情况并不太理想。例如，如果你看一个带有10个DDR5设备的CXL内存模块，每个设备都有1千字节的页大小，那么当你进行激活以获取页面时，每个DRAM设备都会激活1千字节的数据，总计是10个设备乘以10千字节的数据，从核心激活到感应放大器，然后这是破坏性的激活，它擦除了每个电容器的内容，因此需要进行一次预充电循环来恢复这些内容。所以这是20千字节的数据移动，一个FLIT有64字节，你可以算一下，这意味着按照当前定义，一个DRAM的效率只有0.025%。我认为在重新设计和重新架构时，有很多低挂果实可以采摘，与来自三星的朋友一起思考，你可以将10或11或12个这样的CXL扩展通道放在一个处理资源上，但这假设你始终在处理相同的工作负载，而在数据中心，情况远非如此。一些数据中心在最佳情况下报告75%的利用率，而在一天的其他时间，它们的利用率可能低于30%。因此，CXL的另一个特性是能够关闭未使用的通道，因此在使用之间，可扩展性更为灵活。这是直接连接的HBM存储器所无法实现的。
DJ，你想要补充一下这个问题吗？
我认为你们两个已经基本涵盖了我要补充的内容。我认为随着CXL 3.0和3.1引入聚合切换的能力，我们可以访问的带宽能力将是巨大的。这个带宽对GPU或加速器的可用性将取决于GPU到交换机或加速器交换机之间的管道，以及其他一些变量。你们两个已经基本涵盖了这一点，我没有要补充的了。
好的，我们有一个问题提问，从Tracy开始回答，来自惠普的Mohan提问，他问你对未来的布局管理的看法，它是分布在交换机中还是集中在某种布局管理站中？
是的，目前来看，CXL 3.1规范实际上已经包括了布局管理规范。从我们的经验和规范方式来看，布局管理器将位于一个中央位置。要在不同的交换机上分布布局管理器的功能可能有些困难，特别是当你试图连接到更高级的可组合代理时。我想说的是，有一个需要关注的地方，那就是故障切换的布局管理器。我们进行了一些实验，你可能会在一个实体上运行一个布局管理器，然后将其复制到另一个布局管理器，以保持活动状态和同步。但如果那个交换机宕机了，布局管理器所在的地方真的需要冗余和故障切换，这样就不至于失去所有布局管理器，如果你碰巧失去了一个交换机。
好的，还有一个来自规模通量的Tong的问题，他说大多数CXL内存部署是否都不需要芯片级别的失效保护。
我可以回答，是的，可以继续。实际上，这是一个非常相关的问题。我首先要说的是我们推出的2.0产品支持芯片级别的失效保护。然后问题是，在未来进入3.0和3.1时期，会是什么样子。我可以分享到目前为止我们收到的反馈表明，绝大多数客户对芯片级别的失效保护非常满意，他们不愿意放弃它所提供的保障，除了内存的标准RAS能力之外，这是你无论如何都会拥有的。这是因为许多客户与他们的客户有服务水平协议，并且如果由于内存故障而导致停机，这将对服务水平协议产生显著影响，而且这是非常昂贵的。这就是我们今天看到的情况，不过从CXL内存供应的角度来看，我们确实在研究这一点，看看是否有一些应用场景，我们可能不需要同样级别的芯片级别的技能，我们会根据市场需求进行演进。
感谢Vijay。这次是关于一致性管理的问题，这次是关于Tracy的问题，有关一致性管理的。
我们只剩下几分钟了，所以我会简短回答。我可能可以讲上几个小时，但是，你知道，如果你想部署CXL，CXL文档提供了一种在计算元素和内存控制器之间进行通信的方式，以管理缓存行的状态。所以，你知道，如果其他人在内存中更新了某些内容，如果实施了通信机制，就可以通知CPU，说：“嘿，这个缓存行已经无效了”，然后CPU缓存控制器可以决定是否重新加载这些数据。在2.0版本中引入了一种被称为“回退使无效”的缓存轻量级机制，它实际上允许共享内存和内存控制器简单地通知CPU，说：“嘿，这个缓存行被访问了”，然后你知道，我认为人们多年来一直在解决这个问题，一致性的问题或答案的一部分是，你知道，在共享内存环境中如何锁定内存，有一些在处理这个问题的人，比如OpenFAM的人，还有Linux中的一些库，用于锁定内存。所以，如果你对CXL的缓存协议感到担忧，因为它可能在你的布线中产生大量的流量，你知道，这可能依赖于使用情况，也许采用OpenFAM或已经在行业中部署和测试过的共享锁定机制可能更有优势，但我会就此打住，以免时间过长。
好的，非常感谢Tracy。
我想这就是我们的全部内容，感谢大家的参与和提出的问题，我们期待在未来的网络研讨会上与大家进一步交流。
---【本文完】---
近期受欢迎的文章：
---【下面是广告】---