英伟达详解AI内存全栈协同设计:HBM容量仅增3%,Agent吞吐量/美元最高提升30倍

华尔街见闻
Nov 06

美东时间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产业从追逐算力扩张转向关注投资效率的市场环境。英伟达此次强调的全栈协同设计,正是试图从系统效率和单位Token成本的角度回应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中。

其次,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作为一个系统级资源统一管理,使已经计算过的上下文能够在整个系统内复用,减少重复计算。

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的成本。

Disclaimer: Investing carries risk. This is not financial advice. The above content should not be regarded as an offer, recommendation, or solicitation on acquiring or disposing of any financial products, any associated discussions, comments, or posts by author or other users should not be considered as such either. It is solely for general information purpose only, which does not consider your own investment objectives, financial situations or needs. TTM assumes no responsibility or warranty for the accuracy and completeness of the information, investors should do their own research and may seek professional advice before investing.

Most Discussed

  1. 1
     
     
     
     
  2. 2
     
     
     
     
  3. 3
     
     
     
     
  4. 4
     
     
     
     
  5. 5
     
     
     
     
  6. 6
     
     
     
     
  7. 7
     
     
     
     
  8. 8
     
     
     
     
  9. 9
     
     
     
     
  10. 10