英伟达详解AI内存全栈协同设计：HBM容量增3% 每美元吞吐量最高升30倍

美东时间11月5日周四，英伟达在公司博客发文，系统说明其AI内存全栈协同设计思路。文中提到，大模型参数规模、上下文长度和智能体（Agent）应用都在持续扩张，AI基础设施面临的内存压力随之加重，只靠堆GPU内存容量已经解决不了问题。

英伟达给出的办法是把GPU、CPU、网络、存储和软件放在一起做协同设计，再配合模型权重量化、KV Cache压缩与分层存储、检索数据优化等手段，提升整个AI基础设施的内存利用效率。公司披露的数据是：从Blackwell Ultra到Vera Rubin平台，单颗GPU的HBM容量只增加约3%，而在特定Agent工作负载下，每美元可实现的吞吐量最高能提升30倍。

这套思路的重点，是把AI工厂的内存和存储看成一个整体的数据层级，不再一味往速度最快、成本最高的GPU内存里塞数据，转而用更低的单位成本处理更多AI任务。

不过，就在这篇技术文章发布当天，英伟达股票遭到猛烈抛售。周四盘中股价一度跌超9%，今年内累计涨幅被抹平并转为下跌，市值较10月创下的最高纪录蒸发近1.4万亿美元。

抛售背后，市场正在重新审视AI基础设施投资的回报周期、数据中心建设进度以及AI产业链企业的估值。AI产业的环境已经变了，从追逐算力扩张转向关注投资效率。

大模型和Agent推高内存压力，单纯增加HBM容量不够

英伟达指出，大模型参数规模不断扩大，上下文窗口越来越长，Agent又需要在多轮推理和工具调用之间持续保留历史信息，GPU高带宽内存（HBM）因此承受更大压力。

推理过程中，KV Cache（键值缓存）是内存消耗的重要来源。模型处理请求时算过的上下文信息存在这里，后续生成内容就不必重复处理相同信息。放到Agent身上，一次任务可能包含多轮模型推理、工具调用和结果返回，历史上下文不断累积，KV Cache也跟着变大。英伟达称，部分Agent任务轨迹涉及的处理上下文规模已经达到300万Token。

检索增强生成（RAG）同样会推高需要处理和保留的数据量：企业文档要先转成向量表示，模型推理时再检索相关内容。

英伟达强调，推理时模型权重和KV Cache都要占用HBM，而HBM恰恰是AI工厂里速度最快、成本最高、供应也最受限制的内存层级。

光靠增加HBM容量，并不能把所有问题都解决。英伟达打了个比方：HBM是仓库，内存带宽是仓库的装卸码头。仓库再大，能装的货再多，装卸速度跟不上，实际吞吐量还是上不去。

在AI推理中，HBM更多，确实能装下更多用户的模型工作负载和KV Cache。但所有用户仍然要共享GPU计算资源和内存带宽。计算能力或带宽一旦成为瓶颈，多出来的内存容量就可能用不上，成本和功耗反倒增加。

所以在英伟达看来，关键不在于单纯把内存容量做大，而是让不同类型的数据落到最合适的存储层级，需要时再及时调回GPU，从而抬高整个系统的利用效率。

NVFP4压缩模型权重，NVLink将权重分布至72颗GPU

模型权重占掉大量HBM，英伟达的对策是用NVFP4低精度格式压缩模型权重，再通过NVLink实现跨GPU分布式存储。

具体来说，NVFP4能把模型权重压到4位精度，存储空间比FP8进一步减少。英伟达称，已有越来越多模型开发商采用NVFP4格式发布模型权重，包括Black Forest Labs、Thinking Machines Lab、Reflection、Meta等机构和公司的部分模型。

硬件层面，英伟达用NVLink搭建NVL72机架级GPU互联系统，模型权重最多可以分布到72颗GPU上。这样单颗GPU只需存模型的一部分，更多HBM空间被腾出来容纳KV Cache、服务更多并发用户。

也就是说，英伟达想用低精度量化加机架级互联一起解决模型权重占内存的问题，而不是只靠单颗GPU不断加大HBM容量。

KV Cache压缩与分层卸载，Vera CPU和Dynamo协同管理内存

和模型权重相比，KV Cache带来的挑战更动态。Agent持续推理、调用工具、等待外部结果的过程中，部分上下文需要保留，但并非所有信息都得一直占着速度最快的GPU内存。

对此，英伟达从压缩、暂存和分层卸载三个方面入手优化KV Cache。

第一，NVFP4也能用来压缩KV Cache，内存占用比FP8更少，更多上下文可以留在GPU的HBM里。

其次，

第三是CMX上下文内存存储平台。CMX面向大容量、低成本数据存储设计，每比特存储成本远低于HBM，并且能在上下文再次被调用之前把数据调回来。

它和本地SSD不一样，CMX可以跨服务器共享；它也和传统企业存储不同，这些短生命周期的上下文不需要承担长期数据保护带来的额外开销。

Dynamo的KV Cache Reuse功能也被英伟达用上了。GPU内存、CPU内存和存储里的KV Cache被当成一套系统级资源统一调度，算过的上下文可以在整个系统里重复使用，重复计算随之减少。

NeMo Retriever和cuVS优化RAG，企业知识库不再占用HBM

模型权重和KV Cache之外，检索增强生成（RAG）带来的内存压力，英伟达同样给出了优化办法。

RAG要先把企业文档转成向量嵌入（Embedding），再建起可检索的向量索引，模型才能根据用户提问从庞杂知识库里捞出相关内容。问题是，这些向量数据要是全塞进GPU的HBM，模型推理本就紧张的内存会被进一步挤占。

英伟达的思路是用NeMo Retriever和cuVS分别优化向量数据和索引的存储。

具体分工上，NeMo Retriever模型生成的向量嵌入更小，检索准确性反而提高，需要存储和传输的数据量随之下降；cuVS则允许在CPU内存和存储层级上构建、运行大型向量索引，企业知识库因此不必占用GPU的HBM。

真正被检索出来、模型需要处理的相关文本片段，才会进入模型上下文。

英伟达想借这套做法压低模型权重、闲置上下文和RAG数据对HBM的占用，把更多GPU内存留给实际推理任务和并发用户。

从扩充内存转向提升单位资源产出，Vera Rubin效率最高提升30倍

英伟达公布的成绩单，是这篇全栈协同设计文章里最受关注的部分。

数据来自SemiAnalysis AgentX基准测试中的DeepSeek V4 Pro工作负载，用来比较不同代际AI计算平台的吞吐量与成本效率。

在每位用户每秒100个Token的服务速度下，GB300 NVL72对比H200平台，每美元可实现的吞吐量最高提升10倍，单颗GPU的HBM容量大约翻倍。

服务速度提到每位用户每秒125个Token时，Vera Rubin NVL72对比GB300 NVL72，每美元吞吐量最高提升30倍，而单颗GPU的HBM容量只增加约3%。

也就是说，在英伟达着重说的这类Agent推理场景里，性能和成本效率的涨幅远不是单纯堆内存容量能换来的。压缩模型权重和KV Cache、把闲置上下文卸载到更便宜的存储层级、优化GPU、CPU和网络之间的数据调度，几项合起来，相近规模的内存资源能产出更多有效计算。

英伟达强调，AI工厂运营商该看的不是手里有多少GPU、多少HBM，而是在满足用户响应速度要求的前提下，既定电力预算内能交付多少有用Token。每瓦产出更多Token，同样的电力就能干更多活、带来更多收入，每个Token的成本也会降下来。