据 NVIDIA 大众博客《More Performance From Every Byte》，从 Blackwell Ultra 到 Vera Rubin 平台，每颗 GPU 的 HBM 容量只增加了约 3%，但在 SemiAnalysis AgentX 基准上，每美元的 Agent 推理吞吐量最高提升 30 倍——这是 NVIDIA 自己公布的数据，尚无独立测试验证。这两组数字来自 NVIDIA 在 2026 年 11 月 5 日同日发布的两篇官方博客，它们共同传递了一个明确信号：在 HBM 供应趋紧、价格持续上涨的近期趋势下，NVIDIA 的策略核心已经从”给 GPU 塞更多内存”转向”让每一字节做更多有用功”。

这两篇博客——一篇面向大众的技术叙事《More Performance From Every Byte》和一篇面向开发者的工程拆解《Five Ways NVIDIA Co-Design Maximizes the Value of Every Byte in the AI Factory》——联合构成了 NVIDIA 对 AI 基础设施内存挑战的完整回应。它们的核心论点一致：当 HBM 成为 AI 工厂中最昂贵、最紧缺的资源时，系统级的全栈协同设计（full-stack codesign）才是真正的护城河。

以下逐层拆解。

内存压力的 3 个来源：模型权重、KV Cache 与 Agent 工作流的零和博弈

NVIDIA 在博客中将 GPU HBM 上的压力归结为 3 股同时发力的趋势。

第 1 股：模型规模膨胀。 NVIDIA 在博客原文中直接指出，前沿模型现在拥有数万亿参数（trillions of parameters）——这些参数就是模型在训练中学到的数值，推理时必须驻留在 HBM 中供计算单元读取。笔者判断，到了万亿参数这个量级，单是权重就很难放进一颗 GPU 的 HBM，需要跨多颗 GPU 分布存储。

第 2 股：上下文窗口爆炸式增长。 KV cache 是推理过程中保存已处理上下文的工作记忆，它的存在使模型不必对每个新请求重新处理相同信息。NVIDIA 在博客中给出了具体场景：Agent 式推理的轨迹（agentic trajectories）会在反复的模型调用和工具调用之间携带先前上下文，某些情况下单次请求需要处理多达 300 万 token，这意味着每个请求的工作记忆会随时间持续增长。

第 3 股：RAG 与 Agent 工作流叠加。 检索增强生成（RAG）将企业相关信息注入提示词，创造出更多需要处理和保留的上下文。Agent 应用则进一步加剧了这一压力——每一轮工具调用都可能产生新的上下文需要缓存，而多轮对话意味着 KV cache 在整个会话期间持续膨胀。

这 3 股压力的交汇点就在 HBM 上：推理期间，HBM 主要承载模型参数和 KV cache 两大负载。NVIDIA 在博客中将此描述为”更大的 HBM 压力”（greater pressure on HBM）。在一块固定容量的 HBM 上，模型权重和 KV cache 构成零和博弈——权重占的空间越大，留给 KV cache 的就越少；KV cache 膨胀则挤压可用于权重驻留的空间。当并发用户数增加时，每个用户的 KV cache 都在争抢同一块 HBM，这种争抢最终会触及物理极限。

与此同时，外部供应侧的压力也在加大。NVIDIA 在博客中明确写道：供应趋紧、价格上涨——这一趋势预计将在近期持续。据 Tom’s Hardware 援引 Reuters 报道，Apple CEO John Ternus 在 2026 年 11 月 2 日的财报电话会议上将当前的内存价格涨幅描述为”前所未有的”（unprecedented），Apple 预计内存采购成本将在 2027 年继续走高，据报道其整体制造成本（manufacturing bill）在短短几个月内已攀升了 330 亿美元。AI 数据中心正在吞噬全球内存和存储供应——这是整个行业面临的结构性约束。据同一篇 Tom’s Hardware 报道，三星称内存供应紧张可能延续到 2028 年以后，SK Hynix 称已和客户签下覆盖其 2027、2028 年一半以上产能的长期协议。

AI 工厂的存储层级：仓库与装卸码头的类比

NVIDIA 在博客中用了一个精准的类比来解释为什么单纯增加 HBM 容量并非最优解。

把 HBM 想象成一个仓库，内存带宽就是它的装卸码头。更大的仓库可以存放更多库存，但码头决定了同一时间能搬运多少货物。一旦码头满负荷运转，搬运更多库存就需要更长时间，响应速度随之下降。如果延迟超过了服务水平要求，那些额外的仓库空间就无法被有效利用——即便它仍在消耗成本和电力。

这个类比直接指向了 HBM 的”内存墙”（memory wall）问题。NVIDIA 在博客中解释：更多的 HBM 可以容纳更多 KV cache、支持更多并发用户，但每增加一个用户就要共享同一套计算和内存带宽资源。当每个用户都期望快速响应时，内存带宽最终无法以计算消耗数据的速度供给数据。过了这个临界点，额外的 HBM 容量就无法被投入使用，却仍然增加成本和功耗。

这就是为什么 AI 工厂需要跨层级管理数据。NVIDIA 描述了一个明确的存储层级结构：GPU HBM 是最快、最贵、竞争最激烈的层级；往下依次是 CPU 内存、本地 SSD 和共享存储，每一层用速度换取更大容量和更低的单位比特成本。正在流转的数据留在最快的层级，等待中的数据移到更大、更便宜的空间，在需要时提前调回。

NVIDIA 博客中的关键判断是：一个字节能做多少有用功，取决于整个层级被利用得多好——缩减必须存储的数据量、将数据放在正确的层级、在 GPU 需要之前把数据调回来。这 3 个维度共同决定了内存效率，而非任何单一层级的绝对容量。

这一层级观为接下来的 5 种协同手段提供了统一的分析框架。

5 把手术刀：NVIDIA 全栈协同设计的工程细节

NVIDIA 开发者博客以《Five Ways NVIDIA Co-Design Maximizes the Value of Every Byte in the AI Factory》为题，逐一拆解了 5 种协同手段。每一种都针对不同的低效来源，共同覆盖从单个权重的比特编码到跨节点共享存储的完整链路。

手术刀 1：NVFP4——用更少的比特编码同样的智能

最直接的提升字节价值的方式是让每个数值更小，同时不丢失它编码的信息。NVIDIA 的 NVFP4 格式使用 4 位 E2M1 元素，配合两级缩放机制：每 16 个值组成的微块（micro-block）共享一个 FP8（E4M3）缩放因子，顶层再叠加一个 per-tensor 的 FP32 缩放因子。这种设计使格式足够小以释放大量 HBM，同时足够精细以保持精度——在朴素的 4 位格式容易失准的场景下表现更好。

NVIDIA 开发者博客给出了具体的压缩比：NVFP4 将模型占用相比 FP16 缩减约 3.5 倍，相比 FP8 缩减约 1.8 倍，同时保持精度。这里的 3.5 倍可以从格式本身推算：FP16 每个值 16 位，NVFP4 的有效位宽约 4.5 位（含缩放因子在微块内的分摊），按上述披露数据推算 16 除以 4.5 约为 3.56 倍，与官方数字吻合。释放出的 HBM 空间直接用于 Agent 推理最需要的资源：更多 KV cache 容量、更大的 batch size 和更高的并发。

生态采纳方面，NVIDIA 在博客中列举了多个已发布 NVFP4 检查点的模型：Black Forest Labs 的 FLUX.2 [klein]、Thinking Machines Lab 的 Inkling、Reflection 的 Beam 1.0、Meta 的 Meta Muse Spark、StepFun 的 Step 5 Preview，以及 NVIDIA 自家的 Nemotron 3.5 Super VL。这些模型的发布表明，4 位精度在模型构建者中的采纳正在加速。NVFP4 已成为多个严格要求精度的开放 Agent 基准测试的默认精度，包括 AA-AgentPerf、SemiAnalysis AgentX 和 MLPerf Endpoints。在这些基准测试和主流 MoE 架构上，NVFP4 在相同交互延迟下实现了最高 4 倍于 FP8 基线的吞吐量。

同样的原理也延伸到了 KV cache 本身。NVFP4 KV cache 将缓存占用相比 FP8 削减最多 50%，意味着约 2 倍的上下文可以驻留在设备上。更少的驱逐意味着预填充阶段更高的缓存命中率，更小的缓存意味着解码阶段消耗更少的带宽。

NVFP4 的精度保持声明来自 NVIDIA 自身测试和上述基准。

手术刀 2：宽专家并行——跨 72 GPU 分布权重并复用

缩减了每个权重的比特数之后，下一个问题是这些字节存放在哪里，以及 AI 工厂需要保留多少份副本。

在 NVL72 系统内，模型权重可以分布到最多 72 颗 GPU 上，使每颗 GPU 只需持有一份权重的子集。NVIDIA 开发者博客详细描述了 TensorRT-LLM 中的宽专家并行（wide expert parallelism）机制：它将 MoE 模型中的专家分布到 8 颗或更多 GPU 上，使每颗 GPU 留出更多 HBM 给 cache，同时通过权重复用提升算术强度（arithmetic intensity）。

这里的工程逻辑是：当专家被分散到更多 GPU 上时，每颗 GPU 上驻留的权重更少，释放出的 HBM 可以容纳更多 KV cache；而权重复用意味着同一份权重在多次计算中被反复使用，提高了每次内存读取对应的计算量——即算术强度。在 HBM 带宽受限的场景下，更高的算术强度直接转化为更高的计算效率。

笔者判断，这种设计的前提是 NVLink 提供的高速互联带宽足以支撑跨 GPU 的权重通信开销。NVIDIA 将 72 颗 GPU 组成一个统一的 scale-up 域，正是为了让这种分布式权重存储在通信延迟上可行。

手术刀 3：NVIDIA Dynamo——KV Cache 的集群级调度

NVFP4 解决的是”缩减数据量”，宽专家并行解决的是”减少冗余副本”，NVIDIA Dynamo 解决的是”把数据放在正确的层级”。

NVIDIA 开发者博客描述了 Dynamo 如何将 KV cache 视为集群级资源（fleet-wide resource），而非单颗 GPU 的本地缓存。它通过 3 个协同机制实现这一目标：

KV-aware 路由： 将请求路由到已经缓存了相关 KV 数据的 GPU 上，避免重复计算已处理过的上下文。这在多轮 Agent 对话中尤为关键——当用户的第 N 轮请求到达时，前 N-1 轮的 KV cache 可能已经存在于某颗 GPU 上，智能路由可以直接复用。

Disaggregated serving： 将预填充（prefill）和解码（decode）阶段分离到不同的计算资源上。预填充是计算密集型的，解码是内存带宽密集型的，二者对资源的需求截然不同。分离之后，每种资源可以针对各自的瓶颈独立优化。

KV Cache Runner： 通过 NIXL（NVIDIA 的数据传输库）在 GPU、CPU 和存储之间分层调度 KV cache 块。活跃会话的 KV cache 留在 GPU HBM 上；暂时空闲的（比如等待工具调用返回的 Agent 会话）被卸载到 CPU 内存或更低层级的存储上；当会话重新激活时，数据在 GPU 需要之前被提前调回。

这套机制的核心思想是：并非所有 KV cache 都需要同时驻留在最快、最贵的 HBM 上。Agent 工作流天然存在大量”等待”时间——模型调用外部工具、等待 API 返回、等待用户输入——这些间隙中的 KV cache 是闲置的，完全可以暂存到更便宜的层级。

笔者判断，Dynamo 的 KV cache 分层调度在延迟敏感场景中存在 trade-off：从 CPU 内存或更低层级调回数据需要时间，如果工具调用返回速度极快、而 KV cache 块尚未完成回迁，可能引入额外延迟。实际部署中的表现取决于工具调用间隙的长短与预取策略的精度。

手术刀 4：Vera CPU——1.5 TB LPDDR5X 作为 KV Cache 的暂存层

Dynamo 将 KV cache 分层调度到 CPU 内存的能力，需要 CPU 端有足够的容量和带宽来承接。这正是 NVIDIA Vera CPU 的角色。

NVIDIA 开发者博客给出了 Vera CPU 的目标规格（announced specifications，尚未量产出货）：88 个 Olympus 核心，单线程性能提升 1.8 倍，支持最高 1.5 TB LPDDR5X 内存，通过 NVLink-C2C 以 1.8 TB/s 带宽与 Rubin GPU 以相干方式（coherently）连接。

这里有几个工程细节值得拆解。据开发者博客，每颗 Vera CPU 最多 1.5 TB 的 LPDDR5X，超过单颗 Rubin GPU HBM 容量的 5 倍，为 KV cache 的卸载提供了充裕的空间。NVLink-C2C 的 1.8 TB/s 带宽约为 x16 PCIe Gen 6 的 256 GB/s 的 7 倍，确保了 GPU 与 CPU 之间的数据搬运不会成为新的瓶颈。笔者判断，至少在 KV cache 块的预取场景下，这个带宽足以在工具调用返回之前将数据调回 GPU。

NVIDIA 在博客中给出了一个具体的使用场景：在 Agent 的工具调用间隙暂存闲置的 KV cache。当 Agent 调用外部工具时，它的 KV cache 暂时不需要被 GPU 访问，此时 Dynamo 的 KV Cache Runner 将其卸载到 Vera CPU 的 LPDDR5X 中；当工具调用返回、模型需要继续生成时，数据通过 NVLink-C2C 被调回 GPU HBM。这个过程对上层应用透明，但释放了宝贵的 HBM 容量给其他活跃会话。

手术刀 5：CMX——Pod 级共享存储层

最后一层是跨节点的共享存储。据 NVIDIA 开发者博客描述，CMX 增加了一个 pod 级的 G3.5 存储层，基于 BlueField-4 STX、Spectrum-X、DOCA Memos 构建，并与 Dynamo 集成。

这一层解决的问题是：不同节点上的不同会话可能需要相同的 KV cache（例如共享相同系统提示词或 RAG 文档前缀的多个用户），跨节点共享和复用这些缓存可以避免重复计算。NVIDIA 开发者博客将其定位为在节点间共享和复用 KV cache 的能力。

笔者判断，CMX 的意义在于将 KV cache 从”单 GPU 本地资源”提升为”pod 级共享资源”，这在大规模 Agent 部署中可以显著减少重复的预填充计算——而预填充恰恰是推理中最耗计算的阶段。

从 288 GB 到 30 倍吞吐：数字背后的系统工程

现在回到开头那组数据。据 NVIDIA 开发者博客，从 GB300 到 Rubin，每颗 GPU 的 HBM 容量保持在 288 GB，同时带宽提升到 19.2 TB/s。但 Agent 吞吐量每兆瓦的增长远远超过了容量和带宽的提升幅度。

两篇博客给出的是两组不同口径的数据：

开发者博客的口径：每兆瓦吞吐量。 在 SemiAnalysis AgentX 基准测试上——该测试回放真实的编码 Agent 会话，包含真实的工具调用间隙和持续增长的上下文——据 NVIDIA 开发者博客，Vera Rubin NVL72 在每用户 160 token/s 的交互速度下，实现了最高 30 倍于 GB300 NVL72 的每兆瓦吞吐量（原文：”up to 30x the throughput per megawatt of GB300 NVL72…from the same 288 GB per GPU”）。

大众博客的口径：每美元吞吐量。 据 NVIDIA 大众博客《More Performance From Every Byte》，在每用户 125 token/s 的交互速度下，Vera Rubin NVL72 的每美元吞吐最高是 GB300 NVL72 的 30 倍，每 GPU 的 HBM 容量约增 3%；同一工作负载上，GB300 NVL72 相比 H200 平台的每美元吞吐最高提升 10 倍，而 HBM 容量大约翻倍。

两组数据的度量维度不同（每兆瓦 vs 每美元），延迟约束也不同（160 vs 125 token/s/用户），但倍数均为”最高 30 倍”。这两个 30 倍并非同一个测量结果。这一数据来自 NVIDIA 自身测试，尚未经独立第三方验证，实际客户工作负载中的表现可能有所不同。SemiAnalysis 是独立分析机构，但 AgentX 基准的设计方法论和 NVIDIA 的参与程度目前尚不明确，读者在评估这一数字时应考虑基准本身的独立性。

笔者判断，两组不同口径（每兆瓦与每美元）在不同延迟约束下恰好产出相同的 30 倍倍数，这一巧合提出了一个可检验的问题：NVIDIA 是否在选择延迟约束参数时进行了优化，以使两篇博客的 headline 数字对齐？若独立测试者在相同基准上使用统一的延迟约束分别测量每兆瓦和每美元吞吐，即可验证这两个倍数是否在更广泛的参数空间中成立。

据 NVIDIA 开发者博客的总结：单靠容量无法解释从同样的 288 GB 每 GPU 中获得的 30 倍增益。差异在于每一字节能交付多少有用功。

关于大众博客中”HBM 容量约增 3%”与开发者博客中”288 GB”的关系：大众博客的比较基线是”从 Blackwell Ultra 到 Vera Rubin 平台”，开发者博客的比较基线是”从 GB300 到 Rubin”。笔者判断，这两个比较基线可能对应不同的产品配置，大众博客的”约 3%”增幅可能反映的是 Blackwell Ultra 到 Vera Rubin 之间的容量变化，而开发者博客的 288 GB 是 GB300 和 Rubin 共享的数字。

这 5 层协同手段的叠加效应可以这样理解：NVFP4 将权重和 KV cache 压缩到更少的字节，宽专家并行消除跨 GPU 的冗余权重副本，Dynamo 将 KV cache 调度到最合适的层级，Vera CPU 提供了 HBM 之下的高带宽暂存层，CMX 在 pod 级别实现跨节点的缓存共享。每一层都在减少 HBM 上的”无效占用”——要么缩减数据量，要么把不需要即时访问的数据搬走，要么避免重复存储同一份数据。

NVIDIA 的差异化定位与局限性

NVIDIA 在面向大众的博客中强调：NVIDIA 与内存合作伙伴紧密合作，快速采纳最新内存技术。NVIDIA 是首家将 HBM3e 和 HBM4 技术纳入加速计算栈的厂商。

但博客随即指出，全栈协同设计才是方法论的核心。NVIDIA 有意将 GPU、CPU、网络、存储和软件作为一个整体来设计，使 AI 工厂的每一层都能从内存中获取更多有用功。

这段表述的战略含义在于：NVIDIA 正在将”内存效率”从一个硬件参数重新定义为一个系统工程问题。单点的硬件升级——无论是更大的 HBM、更快的带宽还是更先进的制程——都只能解决层级中某一层的瓶颈。全栈协同设计意味着在每一层同时优化：格式层（NVFP4）、计算层（宽专家并行）、调度层（Dynamo）、CPU 层（Vera）和存储层（CMX），使得瓶颈不会简单地从一层转移到另一层。

笔者判断，NVIDIA 在这个时间点集中讲内存效率，与 HBM 供应紧张直接相关。当 HBM 的绝对供给量受限时，能够从同样的 HBM 容量中榨取更多性能的厂商就拥有了竞争优势。NVIDIA 的叙事逻辑是：即便 HBM 价格继续上涨、供应继续紧张，全栈协同设计也能让客户在不成比例增加 HBM 采购量的前提下扩展 AI 工厂的吞吐能力。

同时需要指出这套叙事的局限。全文所有性能数据均来自 NVIDIA 官方测试，30 倍的每兆瓦吞吐提升和 30 倍的每美元吞吐提升均基于特定基准（SemiAnalysis AgentX）和特定配置，客户实际工作负载中的增益幅度可能显著不同。全栈协同设计在带来性能优势的同时，也意味着客户在 GPU、CPU、网络、存储和软件层面都深度绑定 NVIDIA 生态——这是一个需要客户自行权衡的 trade-off。

据 Tom’s Hardware 援引 Reuters 报道，Apple 的案例从侧面印证了内存成本压力的广泛性。Apple CEO John Ternus 在财报电话会议上表示，Apple 预计 12 月季度的内存成本将进一步上升，公司此前通过使用低价库存、削减其他组件成本和部分产品涨价来缓冲影响，但这些缓冲正在变薄。据同一篇 Tom’s Hardware 报道，Futurum Group 首席研究官 Dave Nicholson 将内存价格视为 Apple 利润率和硬件定价在假日季及 2027 年面临的增长压力点。Nicholson 认为，Apple 的处境与那些投入数千亿美元建设 AI 数据中心基础设施的公司不同——更高组件成本的影响比大规模 AI 资本支出的最终回报更容易量化。

当整个行业都在为内存涨价买单时，NVIDIA 提出的”从每一字节中榨取更多性能”就具有了超越技术优化的商业意义——它直接关系到 AI 基础设施的总体拥有成本（TCO）。

内存效率作为基础设施竞争力

据 NVIDIA 开发者博客，每一字节能交付多少有用功，已经取代了单颗 GPU 的内存容量，成为衡量 AI 工厂效率的核心指标。

5 层协同手段——NVFP4 格式压缩、NVL72 域内的宽专家并行、Dynamo 的集群级 KV cache 调度、Vera CPU 的高带宽暂存层、CMX 的 pod 级共享存储——每一层都在回答同一个问题：如何在不成比例增加 HBM 用量的前提下，支撑更大的模型、更长的上下文和更复杂的 Agent 工作流。

据 NVIDIA 开发者博客，Vera Rubin NVL72 在相同的 288 GB 每 GPU 容量下，实现了最高 30 倍于 GB300 NVL72 的每兆瓦 Agent 吞吐量。据 NVIDIA 大众博客《More Performance From Every Byte》，从 Blackwell Ultra 到 Vera Rubin，每 GPU 的 HBM 容量仅上升约 3%，而每美元 Agent 吞吐量最高提升 30 倍。这两组数字是这套全栈叙事的量化锚点。它们能否在客户的实际工作负载中复现，将是检验这套协同设计方法论的最终标准。在 NVIDIA 的框架中，内存效率已经被提升到了与算力同等重要的地位——当 HBM 每一字节的成本都在上升时，让每一字节做更多有用功，就是最直接的降本路径。

主题分类：技术突破

参考资料

  1. More Performance From Every Byte: How Full-Stack Codesign Solves AI’s Memory Challenge — NVIDIA Blog, 2026-11-05
  2. Five Ways NVIDIA Co-Design Maximizes the Value of Every Byte in the AI Factory — NVIDIA Developer Blog, 2026-11-05
  3. Apple faces unprecedented memory cost increases as RAM prices continue to surge — Reuters via Tom’s Hardware, 2026-11-03