英伟达AI内存全栈设计：Agent吞吐量升30倍，HBM只增3%

11月6日，英伟达发布博客文章，详细介绍了其AI内存全栈协同设计策略。文章提到，大模型参数规模、上下文长度和智能体（Agent）应用都在持续扩张，AI基础设施面临的内存压力随之加剧，光靠增加GPU内存容量已经不够用了。

按照英伟达的设想，要把GPU、CPU、网络、存储和软件放在一起做协同设计，再配合模型权重量化、KV Cache压缩与分层存储、检索数据优化等手段，提升整个AI基础设施的内存利用效率。

英伟达披露了一组对比数据：从Blackwell Ultra到Vera Rubin平台，单颗GPU的HBM容量只增加约3%，而在特定Agent工作负载下，每美元可实现的吞吐量最高能提升30倍。

这套策略的关键，是把AI工厂的内存和存储看成一个整体的数据层级，而不是一味把更多数据塞进速度最快、成本最高的GPU内存，用更低的单位成本处理更多AI任务。英伟达同时指出，大模型参数规模越做越大，上下文窗口越来越长，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，把整个系统的利用效率提上去。

模型权重占用大量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带来的挑战更动态。Agent持续推理、调用工具、等待外部结果的过程中，部分上下文要保留，但并非所有信息都得一直占着最快的GPU内存。对此英伟达从压缩、暂存和分层卸载三个方面优化KV Cache。

其一，NVFP4也能用来压缩KV Cache，相比FP8减少内存占用，让更多上下文留在GPU的HBM里。其二，Vera CPU负责加速工具调用，缩短Agent等待外部工具执行结果时KV Cache闲置的时间；Vera CPU还配有大容量LPDDR内存，通过NVLink-C2C与Rubin GPU连接，为暂时不活跃的上下文提供离GPU较近的存储空间，需要时再快速调回。

其三，英伟达Dynamo推理软件能把暂时不活跃的KV Cache从GPU内存卸载到CMX上下文内存存储平台。CMX是面向大容量、低成本数据存储设计的层级，每比特存储成本远低于HBM，并能在上下文再次被调用前把数据调回。和本地SSD不同，CMX可以跨服务器共享；和传统企业存储不同，它不必为这些短生命周期的上下文承担长期数据保护带来的额外开销。

另外，Dynamo的KV Cache Reuse功能把GPU内存、CPU内存和存储中的KV Cache当作一个系统级资源统一管理，已经计算过的上下文可以在整个系统内复用，减少重复计算。

模型权重和KV Cache之外，英伟达还盯上了检索增强生成（RAG）给内存带来的压力，并给出了一套优化方案。

RAG的做法，是先把企业文档转成向量嵌入（Embedding），再建起可供检索的向量索引，让模型能根据用户提问，从庞大的知识库里挑出相关信息。问题是，这些向量数据要是全塞进GPU的HBM，模型推理本身那点宝贵内存就更紧张了。

英伟达的思路是分头处理：向量数据的存储交给NeMo Retriever，索引的存储交给cuVS。

NeMo Retriever模型能生成更小的向量嵌入，检索准确性还更高，需要存储和传输的数据量随之减少。cuVS则可以在CPU内存和存储层级上构建、运行大型向量索引，企业知识库不必再占着GPU的HBM。

真正被检索出来、模型需要处理的相关文本片段，才会进入模型上下文。英伟达希望靠这一方式，压低模型权重、闲置上下文和RAG数据对HBM的占用，把更多GPU内存留给实际推理任务和并发用户。

这次全栈协同设计文章里，最值得关注的是英伟达公布的性能数据。公司引用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和网络之间的数据调度——这几件事做到位，规模相近的内存资源就能产出更多有效计算。