NVIDIA 全栈协同设计瞄准 AI 的内存瓶颈，而不只是更大的 GPU

NVIDIA 认为，仅仅增加 GPU 内存，无法解决 AI 智能体日益增长的需求。该公司在 11 月 5 日的说明中，将 NVIDIA 全栈协同设计置于这一观点的核心。NVIDIA 希望买家综合评估处理器、内存、网络、存储和软件，而不是将内存容量视为充分的性能指标。

眼前的矛盾集中在推理，即运行训练完成的模型以生成答案的过程。更大的内存池可以容纳更多信息，但存储信息与提供响应迅速的答案，是两种不同的能力。随着更长的对话和调用工具的应用让容量愈发难以忽视，NVIDIA 的立场正挑战以容量优先的采购策略。

将内存管理视为性能问题，有其历史依据。FlashAttention 和 vLLM 背后的学术研究表明，以不同方式组织数据移动和分配，可以提升现有硬件的利用率。如今，NVIDIA 将这一系统层面的观点扩展至整个平台。买方面临一个实际问题：在自身的工作负载和响应要求下，哪些改进能够转化为有效产出？

NVIDIA 全栈协同设计改变内存讨论方式

NVIDIA 的公告将内存效率重新定义为整个服务系统的属性。

11 月 5 日的文章是对平台战略的阐释，而非一次独立的内存芯片发布。在其内存效率分析中，NVIDIA 介绍了压缩、共享上下文管理以及不同内存层级之间的数据迁移。

高带宽内存（HBM）是一种堆叠式内存，部署在加速器附近以快速传输数据。NVIDIA 表示，在更有针对性地利用系统其他部分的同时，可以降低对这一资源的需求。

该公司还列举了一项显著的性能对比。它表示，在指定的 AgentX 工作负载下，Vera Rubin 的每美元吞吐量最高可达 GB300 NVL72 的 30 倍，同时每块 GPU 的 HBM 容量仅增加约 3%。

这些是 NVIDIA 报告的数据，并非通用的性能保证。其意义更为有限：该公司认为，平台进步并不只是来自与内存容量成比例的提升。

买家应区分这一主张与其提出的解释。平台基准测试衡量的是多项变化共同作用的结果，并不能单独说明有多少改进来自内存管理。

在将醒目的测试结果转化为采购决策时，这一区别至关重要。考虑增加内存的企业需要了解，现有系统究竟缺乏空间、传输速度，还是有效调度能力。

容量衡量系统能存放多少数据。带宽衡量数据移动的速度。延迟衡量一次操作所需的时间。这些限制彼此影响，但购买更多容量并不会自动消除其他限制。

设想一个企业助手：它一边处理文档，一边回答员工问题。其运营人员可能会发现，在加速器达到计算极限之前，内存已经被占满。另一种部署则可能在内存中轻松容纳数据，却难以足够快地移动数据。

两种情形的适当应对措施并不相同。更多空间能直接解决第一种限制；而在第二种情况下，更好的传输行为、软件改进或不同的工作负载部署方式则更为重要。

因此，NVIDIA 全栈协同设计改变了评估单位。相关产品变成了经过配置的服务，其中包括软件行为和配套基础设施。

这也让供应商承担了更广泛的责任。如果其优势依赖于组件之间的协调，证据就必须清晰说明这些组件。买家需要足够细节，才能复现产生该优势的条件。

它同样改变了客户解读规格参数的方式。内存容量依然是必要信息，但不能独自承担完整的性能论证。规格表描述的是资源；工作负载测试则证明这些资源能交付什么。

AI 智能体让基础设施团队承受不同压力

即使计算暂时停止，基础设施团队也必须为模型调用之间仍具价值的信息预留资源。

AI 智能体是一类使用模型选择并执行步骤的应用，通常会涉及外部工具。其工作负载不同于单个提示词对应单个答案的模式。

设想一名编程助手检查代码仓库、运行测试、读取失败信息并修改补丁。测试运行期间，应用仍需保留对任务的连贯记录。当生成恢复时，这些信息必须保持可访问。

这一示例说明的是运营层面的张力，而不是已量化的客户结果。将所有内容保留在加速器附近，有利于快速恢复；将不活跃的信息转移到其他位置可以释放稀缺空间，但取回它会引入额外工作。

键值缓存（KV cache）存储中间注意力信息，使模型无需重新计算此前的全部上下文即可继续运行。注意力是模型用于关联序列中不同信息的机制。

对运营人员而言，除了存储模型权重这一熟悉挑战外，该缓存还带来了调度问题。权重是模型执行过程中使用的、通过学习得到的数值。

一项服务可能有足够空间容纳模型，却没有足够宽裕的空间容纳活跃对话。反过来，它也可能为等待工具响应的对话预留了大量空间。

这两种情况都不会在简单的模型规模比较中清晰呈现。应用的行为决定了内存会被占用多少，以及这些信息何时会再次变为活跃状态。

这给推理服务提供商、企业平台团队以及构建智能体产品的开发者带来了压力。他们必须支持波动的活跃度，同时避免缓慢请求消耗响应迅速的请求所需资源。

由此带来的应对措施，是让应用行为与服务基础设施更加紧密地协同。工具执行、取消操作、上下文保留和请求调度，都会影响加速器效率。

产品团队也需承担部分责任。保留更多对话历史的功能会改变基础设施需求；启动额外并行任务的功能同样会改变需求。

对知识工作者而言，这种影响体现为响应速度和服务限制。在复杂任务中反复停顿的助手，与能够持续稳定推进的助手，会带来截然不同的体验。

这也是为什么不应将应用内存与持久知识库混为一谈。临时执行状态帮助模型延续工作；存储的文档则提供应用日后可以检索的信息。

个人知识库解决的是源材料的组织与检索问题。加速器内存解决的则是模型处理选定材料时所需的资源问题。

更好的文档检索可以减少不必要的输入，但无法消除所有运行时限制。服务仍需处理有用的证据，并保留足够的任务上下文。

因此，近期压力是实际存在的。运营人员需要了解哪些信息应立即访问，哪些可以等待，以及系统能够多可靠地区分这些状态。

更有效的内存始于更少浪费

最有力的技术依据，是在购买额外容量之前减少不必要的存储和数据移动。

独立研究为这一做法提供了先例。它们并不验证 NVIDIA 当前的基准测试主张，但支持内存感知软件具有广泛的重要性。

FlashAttention 研究提出了一种围绕不同内存层级间数据移动设计的注意力算法。其方法通过精心组织计算，减少了代价高昂的数据传输。

这一结果之所以重要，是因为数学运算与其实现属于问题的不同层面。软件可以保留预期的运算，同时改变硬件执行它的效率。

对买家的启示很直接：加速器的物理资源并不能脱离使用它们的软件而独立决定性能。实现质量可以改变这些资源所能带来的有效产出。

另一个例子来自支撑 vLLM 服务系统的PagedAttention 研究。它将缓存的注意力数据组织为易于管理的块，从而解决空间浪费并支持共享。

这些研究工作解决了不同来源的低效率问题。FlashAttention 强调注意力计算期间的数据移动；PagedAttention 强调缓存信息的分配和管理。

它们的共同教训很明确。内存压力既可能反映真实的工作负载需求，也可能源于本可避免的开销。消除这些开销可以在不实际扩展设备的情况下释放空间。

压缩提供了另一种机制。量化是指以更少比特表示数值；当模型和执行软件支持时，它可以降低存储需求。

不过，更小的表示形式并不自动等同于同等水平的服务。运营人员必须评估质量是否仍能满足任务需求，也必须将任何转换或管理开销纳入考量。

对于文档助手而言，仅保持整体流畅性还不够。压缩后的系统仍必须能够检索相关证据、区分相似事实，并在真实文档中遵循指令。

对于编程助手而言，平均基准质量可能掩盖特定语言或代码仓库模式中的失败。有效的评估应反映客户实际提交的工作。

同样的谨慎也适用于迁移不活跃信息。卸载是指将数据从加速器内存传输到另一层内存或存储中。其收益取决于这些信息是否会在拖慢有效工作之前返回。

一个假设中的支持智能体展示了这种取舍。在等待业务系统响应时，其上下文可以保持不活跃。当该系统返回结果后，模型又需要重新获取这些上下文。

如果检索能够成功与其他工作并行进行，应用就能获得可用的加速器容量。如果检索到达过晚，用户就会经历又一次停顿。

这正是 NVIDIA 全栈协同设计具备具体技术依据的地方。协调一致的软件可以做出孤立组件无法有效做出的决策。

但协同也要求准确的信息。系统必须了解哪些上下文处于活跃状态，哪些可复用，哪些很可能很快再次需要。

糟糕的预测可能只是转移瓶颈。如果存储系统变得拥塞，释放出的加速器内存价值有限。同样，压缩只有在最终执行仍然高效时才能真正节省空间。

因此，应将这一机制作为一条链路来评估。在负载下，分配、表示、放置和检索必须协同工作。任何一个环节的薄弱之处，都可能消耗预期收益。

AMD 表明容量依然重要

系统层面的论证强化了内存对比；但这并不意味着更大的内存池无关紧要。

AMD 提供了一个有价值的竞争参照。其 MI350 内存规格列出 288GB HBM3E 内存和 8TB/s 带宽。

这些数字描述了软件可用的物理资源。它们并不能证明哪家供应商能为每一种模型或应用带来更好的结果。

不过，这一比较说明了买家为何应避免陷入错误的二选一。容量与软件效率是互补关系。一个系统既能从更大的空间中受益，也能从更好的管理中受益。

有些工作负载需要先拥有足够内存来容纳关键信息，优化才会发挥作用。如果所需数据无法放入可接受的配置中，仅靠高效调度无法解决部署问题。

另一些工作负载虽然能够放入内存，却会因分配、重复或空闲状态而浪费资源。它们的运营者需要不同的干预措施。额外容量或许能掩盖问题，却无法解决根本原因。

这使得核心竞争不止是 NVIDIA 对 AMD。首要问题仍然是：买家更看重原始容量，还是经验证的系统级输出。

供应商比较应保持这一重点。更大的内存规格意味着对容量敏感型工作可能具有潜在优势。更优秀的服务栈则意味着在利用率上可能具有潜在优势。

这两种说法都无法保证最终结果。实际性能取决于模型、其数值表示、软件实现以及应用的响应要求。

因此，公平的评估应保持工作负载不变。比较不同模型或质量设置，回答的是与比较同一服务基础设施不同的问题。

还应区分部署便利性与稳态性能。经过大量调优后能够高效运行的配置，可能需要超出客户可承受范围的工程投入。

即使不附加具体价格数字，这些投入也应纳入决策考量。专业人员配置、维护和发布协调都会影响理论性能能否转化为运营价值。

软件可移植性同样重要。采用深度协同基础设施的公司，应了解应用行为在多大程度上依赖特定运行时或硬件特性。

这并不意味着集成天然不可取。集成能够为客户减少大量工作。问题在于，由此产生的收益是否足以证明这些依赖关系是合理的。

买家应要求供应商在相同验收标准下展示同一应用。这意味着等效的答案质量、可比的响应预期，以及清晰说明的系统边界。

如果额外内存使原本会失败的工作负载得以运行，这很有意义。如果更好的管理让既有容量支持更多响应迅速的会话，这同样很有意义。

有用的比较对象是交付的服务。硬件规格解释了一部分结果，而软件行为与运营复杂性解释了其余部分。

基准测试增益需要清晰的核算边界

只有当买家理解测量涵盖的内容时，吞吐量声明才具有决策价值。

吞吐量是指在一段时间内完成的工作量。对于语言模型，供应商通常以生成的 token 来表示，即模型处理的文本单位。

不过，一项服务可以生成更多 token，同时带来更差的体验。更长的排队时间或更慢的单次响应，可能提高总体利用率，却让用户感到挫败。

因此，性能证据需要附带响应约束。买家应了解答案多久开始出现，以及后续输出能否保持稳定。

他们还需要知道什么才算有用输出。更多文本并不自动意味着更多价值。不准确的答案可能消耗大量计算资源，却无法完成任务。

对于智能体而言，这种关系更加复杂。一次成功的工作流包含工具调用、等待期以及可能未成功的尝试。仅统计生成文本会遗漏其中一部分活动。

因此，审慎的解读应是方法论层面的。NVIDIA 的平台比较值得审视，但其标题中的倍数无法证明不相关部署也会得到同样结果。

跨代结果还综合了许多变化。计算能力、网络、软件成熟度和数值格式都可能影响结果。

如果没有受控比较，读者无法将全部改进归因于内存效率。这一限制并不否定结果；它只是限制了该结果所能支持的结论。

核算边界带来了另一层不确定性。将上下文移出加速器内存的系统，仍会消耗配套资源。这些资源需要电力、空间、管理和足够的性能。

买家在评估效率时应纳入这些依赖。否则，一个组件内部的改进可能掩盖其他环节增加的工作量。

压力下的运行行为同样值得关注。典型性能可能看起来很有吸引力，但异常峰值可能造成长时间延迟。当大量请求同时恢复时，共享资源尤为重要。

现实的评估还应包含中断因素。工具故障、放弃的会话和应用重启，都会影响缓存信息能保留多少实际价值。

安全性还带来额外约束。复用上下文需要用户和工作负载之间具备可靠隔离。共享资源不能让性能优化变成非预期的信息暴露。

持久性要求也应保持明确。临时执行上下文和权威业务记录服务于不同目的。适用于可丢弃状态的设计，可能不适合需要可靠留存的记录。

最后，质量必须保留在测量边界内。压缩或缩减上下文应根据任务结果进行评估，而不能被视为无代价的节省。

对于企业买家而言，这意味着需要提出一个比“该基准是否很快”更严格的问题。他们需要知道，被测系统是否与自身应用足够接近，能够为决策提供参考。

NVIDIA 全栈协同设计为跨组件追求效率提供了连贯的解释。剩余的不确定性在于：这些增益在具体部署中的规模、可重复性和运营成本。

关注可复现性、上下文行为和买家采用情况

下一阶段的证据应将平台声明与真实需求下可重复的服务联系起来。

第一个值得关注的信号是可复现的性能证据。未来几个月内，有价值的披露应说明模型版本、软件配置、响应要求和系统边界。

独立测试将进一步增强论证。其价值在于展示这种优势是否能在供应商选定环境之外依然成立。

在提升响应式吞吐量的同时保持质量的证据，将支持系统论点。依赖狭窄设置的结果，则意味着收益更为有限。

第二个信号是实际智能体活动中的上下文行为。买家需要看到有关等待、恢复和复用的证据，而不只是连续文本生成。

一项有意义的演示应展示应用因外部工具暂停后再返回时会发生什么。它还应揭示大量请求争夺共享资源时的表现。

可靠的恢复能力将强化通过层级移动非活跃信息的论点。不可预测的延迟则会显示这种方法仍需改进的地方。

第三个信号是由运营细节支撑的采用情况。客户描述应说明哪些约束发生了改变，以及由此带来的服务如何改善。

具名部署固然有用，但其配置和验收标准比背书本身更重要。买家需要足够的信息来判断相关性。

来自不同应用类型的证据尤其具有参考价值。文档分析、编程和交互式辅助对内存和调度提出了不同要求。

因此，这一预测是有条件的，而非宣传性的。如果可重复的结果能够将资源管理与有用输出联系起来，系统级评估将获得更强支持。

如果这些增益在现实并发量、上下文长度或质量要求下减弱，容量规划将保留更大权重。两种结果都将帮助客户做出更好的决策。

对于开发者而言，眼下的启示是在假定硬件扩展是唯一答案之前，先观察应用行为。测量应识别出有用工作在何处等待。

对于企业团队而言，启示是让采购与服务要求保持一致。一次采购应解决已证实的约束，并包含消除该约束所需的配套资源。

知识工作者在比较助手时也可以采用同样的原则。在复杂任务中的响应能力，比一次孤立的快速文本生成演示更重要。

在下一次基础设施评审前，请团队识别影响其最重要 AI 工作流的约束。模型是难以容纳、在等待数据，还是保留了闲置的上下文？随后，要求进行一项能够保持任务质量与现实响应预期的比较。将配套内存、存储和运营投入纳入评估。将 NVIDIA 全栈协同设计视为一项可检验的系统主张，并针对相同工作负载评估竞争方案。有用的结果，是一项能够可靠完成有意义工作的服务。对于你的应用，哪项改变能带来这一结果？又需要什么证据才能说服你部署它？