五步将内存从AI的最大制约转变为竞争优势

过去几年，AI基础设施的关注点一直集中在计算能力上，将其置于所有其他指标之上。更多的加速器、更大的集群和更高的FLOPS主导了关于如何充分利用GPU的讨论。当模型进展主要依赖于训练规模时，这种方法有其道理。如今，随着AI生产部署成为优先事项，一个新的制约因素需要关注：内存。

今天，许多最棘手的AI制约因素体现在内存容量、带宽、延迟以及数据在系统中移动的时间和能耗成本上。上下文窗口持续扩大，像Anthropic这样的公司现在在其标准定价服务中提供百万令牌的窗口。推理工作负载正在增长。多智能体系统的发展意味着AI系统正在将更大量的数据从一个阶段传递到下一个阶段。运营商可以继续尝试增加更多GPU，但他们仍然无法达到预期的性能，因为当每个服务器独立运行时，这些系统缺乏足够的RAM来高效地供给加速器，受限于系统内RAM。

这种转变影响着超大规模云提供商和数据中心运营商的吞吐量和成本。当内存成为限制因素时，组织通常的反应是过度配置昂贵的硬件，导致GPU容量利用不足，并承受更高的电力和基础设施成本。AI规模化的下一阶段将更少依赖于增加原始计算能力，而更多地依赖于构建符合生产AI实际运行方式的内存架构。

以下是基础设施领导者现在可以采取的五个步骤，以应对不断增长的内存需求。

1. 从衡量真正的瓶颈开始

许多组织仍然通过计算优先的视角来评估AI性能。他们跟踪集群利用率、加速器数量和总体吞吐量，然后假设改进将来自增加更多GPU加速器。这种观点常常忽略了真正的问题。

内存压力通常表现为加速器停滞、更高的单令牌延迟以及负载下不稳定的吞吐量。如果GPU正在等待数据从另一个内存层级、另一台服务器或应用程序的另一个阶段到达，它可能看起来利用率不足。随着KV缓存大小增长以及更多并发会话竞争带宽，推理使这个问题更加明显。

运营商需要更好地了解有效内存利用率，查看每令牌移动的字节数、加速器停滞时间以及跨CPU、GPU和相邻内存层级的内存访问模式。他们还需要能够将内存相关延迟与网络或存储问题区分开来的流水线跟踪。没有这种可见性，团队可能会在计算上投入更多资金，却没有解决导致速度减慢的实际根源。

2. 在增加容量之前减少数据移动

在大型AI系统中，移动数据产生的开销可能与处理数据一样多。

这在推理中尤其如此。随着上下文窗口扩大，KV缓存可能成为堆栈中最大的系统内存消耗者之一。多租户服务和多智能体工作流可能进一步增加消耗。第一阶段生成输出，然后另一个阶段消费它，基础设施通过在GPU之间、跨服务器或通过框架级序列化复制大块数据来处理这种交接。

这些复制操作带来真实的成本。它们消耗带宽、增加延迟，并使昂贵的计算资源等待下一次传输完成。它们还促使运营商购买比工作负载实际需要更多的高成本内存。

在投资更多加速器之前，团队应该识别系统中哪些地方的数据移动超出了必要。GPU到GPU传输、服务器到服务器复制以及跨智能体流水线重复移动中间状态是很好的切入点。在许多环境中，减少不必要的移动比增加另一台服务器能带来更多可用的性能提升。

3. 围绕工作负载行为构建内存层级

当运营商不再将内存视为单一来源，而是将其视为具有不同角色的层级结构时，AI基础设施会运行得更好。

最热的数据应保持在最接近加速器的地方。这包括需要最低延迟和最高带宽的工作集。其他活跃缓冲区和频繁访问的状态可以放在DRAM中。需要规模更甚于绝对速度的较大结构可以移动到池化内存中。较冷的数据和不太活跃的模型属于堆栈的更下层。

这种方法要求团队了解哪些数据不断变化，哪些数据被许多进程共享，以及哪些数据可以容忍适度的延迟权衡而不影响服务质量。太多的部署仍然默认将所有内容推入最快的HBM层级，因为这感觉更安全。这种方法推高了成本，并且通常未能实现效率优化。

分层内存策略让运营商对性能和经济性都有更多的控制。在生产AI中，这种平衡正成为一个核心设计要求。

4. 将共享内存视为智能体AI架构的一部分

多智能体AI正在提高碎片化内存设计的成本。

在许多智能体系统中，一个智能体产生的输出会立即被另一个智能体使用。第三个服务可能对该输出进行排名、添加上下文或将其路由到另一个模型。如果每个步骤都创建相同状态的新副本，流量会迅速上升。随着上下文增长，被复制数据的大小也随之增长。系统花费更多时间移动信息而不是处理数据。

这就是共享内存变得越来越重要的地方，特别是对于多个智能体或服务需要访问的共享KV缓存和其他状态。共享内存可以减少冗余副本、降低网络流量并提高整个应用程序路径的利用率。当不同节点或智能体能够通过共享内存重用KV缓存时，它还可以帮助智能体系统有效扩展。

对于超大规模云提供商来说，这不再是边缘情况。随着智能体AI的成熟，共享内存正成为高效部署的实际要求。

5. 在生产基础设施中拥抱CXL

过去几年，业界将CXL视为一个有前途但需要更多时间成熟的标准，因为CXL从版本1迅速发展到版本2。现在，随着3.x硬件即将面世，CXL正达到功能完备、向后兼容并准备好承担生产负载的阶段。

CXL已经成熟到超大规模云提供商和数据中心运营商应将其视为生产内存扩展、池化和共享内存架构的实用选项的程度。它现在应被纳入严肃的基础设施规划中，特别是对于那些需要更灵活内存扩展和更好推理经济性的环境。

这并不意味着每个工作负载都应迁移到基于CXL的内存。本地内存对于最热和对延迟最敏感的数据仍然至关重要。但运营商不再需要等待标准的某个未来版本再采取行动。更有用的问题是，CXL今天可以在哪里解决实际的生产问题。

最明显的机会在于内存扩展、池化内存和共享内存设计，这些可以减少跨AI工作流的不必要复制。这些用例直接对准了当前的压力点：不断上升的KV缓存需求、日益增长的智能体间数据传输，以及在不推高总拥有成本的情况下提高GPU利用率的需求。

运营商仍然需要仔细设计。延迟、可预测性和软件支持仍然很重要。内存管理策略需要在正确的时间将数据放置在正确的层级。但这些都是实施问题，而不是推迟规划的理由。

在XCENA，我们将内存、数据移动和利用率视为生产AI基础设施的核心制约因素。这就是为什么我们专注于基于CXL的计算内存和架构，以减少不必要的复制、支持共享访问，并帮助运营商更好地利用昂贵的计算资源。

业界多年来一直将内存视为AI进步真正引擎背后的支持性资源。这种观点已不再符合生产部署的现实。内存现在影响着堆栈每一层的利用率、效率和成本。那些及早认识到这一转变的运营商将获得优势，这种优势不仅体现在性能上，更体现在他们在现实世界中扩展AI的有效性上。