英伟达博客：Vera Rubin NVL72智能体推理每美元吞吐量最高为GB300 NVL72的 30 倍
英伟达在博客中称，从Blackwell Ultra到Vera Rubin，每GPU的HBM容量仅增加约 3%，但SemiAnalysis AgentX上的智能体每美元吞吐量最高提升 30 倍；这一数字来自英伟达援引的测试工作负载，并非独立验证。
AI解读：英伟达博客以“全栈协同设计”解释其内存策略：不单靠增加每GPU的HBM容量，而是把GPU、CPU、网络、存储和软件放在一起设计，让每一字节内存在AI工厂的不同层级上承担不同任务。
博文给出英伟达援引的SemiAnalysis AgentX数据：在DeepSeek V4 Pro工作负载、每用户 100 tokens/s条件下，GB300 NVL72每美元吞吐量最高为H200平台的 10 倍，此时每GPU HBM容量约翻倍；在每用户 125 tokens/s条件下，Vera Rubin NVL72每美元吞吐量最高为GB300 NVL72的 30 倍，而每GPU HBM容量只增加约 3%。
英伟达把压力来源归于前沿模型的万亿级参数、不断扩大的KV cache，以及智能体应用跨多次模型与工具调用传递上下文，部分场景处理多达 300 万token；RAG又把企业文档加入提示，进一步占用HBM。
英伟达称自己是首家在加速计算栈中采用HBM3e和HBM4的公司。
上述 10 倍、30 倍和 3% 均为英伟达博客表述，读者需要注意：这些数字针对特定平台代际和特定工作负载，不能直接外推为所有推理场景的能效或成本变化。
英伟达在官方博客中称，从Blackwell Ultra到Vera Rubin平台，每GPU的HBM容量仅增加约 3%，但在SemiAnalysis AgentX的DeepSeek V4 Pro工作负载上，Vera Rubin NVL72在每用户 125 tokens/s条件下，每美元吞吐量最高可达GB300 NVL72的 30 倍。
该博客由Amr Elmeleegy署名，主题是英伟达如何通过“全栈协同设计”应对AI推理的内存压力。文中数字均来自英伟达的表述。
英伟达给出的两组代际对比数据
博客称，在SemiAnalysis AgentX的DeepSeek V4 Pro工作负载上，GB300 NVL72在每用户 100 tokens/s条件下，每美元吞吐量最高为H200平台的 10 倍，同时每GPU的HBM容量大约翻倍。
到下一代，Vera Rubin NVL72在每用户 125 tokens/s条件下，每美元吞吐量最高为GB300 NVL72的 30 倍，而每GPU的HBM容量只增加约 3%。英伟达将这些结果归因于全栈协同设计，而非单纯堆叠内存容量。
这些对比是在指定工作负载与指定响应速度下测得，英伟达没有在博客中给出其他模型或通用推理场景的对应数据。
内存压力来自哪里
英伟达称，前沿模型已有万亿级参数，KV cache也在扩大。智能体轨迹会把先前上下文带到反复的模型和工具调用中，部分场景处理多达 300 万token，使单个请求的工作内存随时间增长。RAG把企业相关信息加入提示，又增加了需要处理和保留的上下文。
在推理过程中，HBM主要存放模型参数和KV cache，因此容量竞争集中在GPU的高带宽内存这一层。博客还提到，内存供应趋紧、价格上涨，并预计这一趋势在近期持续。
英伟达提出的分层与压缩做法
博客用仓库与装卸口的比喻解释内存带宽限制：HBM容量再大，数据搬运仍受带宽约束；一旦带宽无法按计算所需速度供数，就形成“内存墙”，多余的HBM容量无法有效投入使用，却仍带来成本和功耗。
英伟达列出的做法包括：用NVFP4格式压缩模型权重，并在NVL72域内把权重分布到最多 72 块GPU，让每块GPU承担更小份额；对KV cache同样应用NVFP4；用Vera CPU加快工具执行，并以LPDDR内存暂存暂停的上下文；由Dynamo软件把不活跃上下文移到CMX上下文内存存储，使用时再取回。
博客称CMX是跨服务器共享的存储层，合作方包括Cloudian、DDN、Dell Technologies、Everpure、HPE、IBM、NetApp、VAST和WEKA。对于RAG，英伟达称Nemotron Retriever模型生成更小的嵌入向量，cuVS库让索引在CPU和存储上构建与服务，知识库本身不占HBM。
英伟达还称，包括Black Forest Labs的FLUX.2 [klein]、Thinking Machines Lab的Inkling、Reflection的Beam 1.0、Meta的Muse Spark、StepFun的Step 5 Preview和英伟达自家的Nemotron 3.5 Super VL在内的近期模型已发布NVFP4检查点。