导语：过去两年，整个行业默认了一条线性公式：模型越大、上下文越长，就需要越多的 HBM。但英伟达最新发布的技术解读给出了一个反直觉的结论——在 Vera Rubin NVL72 上，每 GPU 的 HBM 容量相比 GB300 NVL72 仅增加约 3%，每美元智能体吞吐量却最高提升 30 倍。这意味着 AI 算力竞争的主战场，正从「堆显存」转向「每字节、每瓦特能产出多少有效 token」。本文以架构师视角，逐层拆解这套全栈协同设计背后的工程逻辑。
一、问题重定义：为什么「加 HBM」不再是解药
在推理链路上，HBM 承担着双重身份：既要承载模型权重，又要保存 KV 缓存——后者记录了模型理解当前请求所需的全部上下文。智能体（Agent）工作流的出现，把这份压力放大了一个数量级：一次任务会在多次模型调用与工具调用之间持续携带历史上下文，部分场景需要处理多达 300 万个 token；RAG 又会把企业资料塞进提示词，进一步推高内存占用。
英伟达在技术解读中给出了一个非常精准的类比：HBM 是仓库，内存带宽是装卸口。仓库再大，如果装卸口吞吐跟不上，货物进出就会堵死——这就是经典的「内存墙」。此时单纯扩容 HBM，新增容量无法有效转化为服务能力，只会变成昂贵的闲置面积。
内存瓶颈的本质不是「容量不足」，而是「数据没有待在合适的层级」。破局方向不是买更多 HBM，而是把数据压缩、分层放置，并在需要之前提前送回 GPU。这是典型的存储层次化（Memory Hierarchy）思想在 AI 工厂尺度上的重演。
二、五层协同：全栈设计的内存分层拆解
英伟达提出的「全栈协同设计」，把 GPU、CPU、网络、存储和软件视为一个整体来调度内存。落到具体机制上，可以拆成五个相互咬合的层次。
2.1 精度层：NVFP4 压缩权重与 KV 缓存
最直接的一刀砍在数据体积上。NVFP4 低精度格式同时作用于模型权重与 KV 缓存，用更少的比特表达同等信息量。这是所有优化中「性价比」最高的一层——不需要额外硬件，纯靠数值格式换空间与带宽。
2.2 设备层：NVL72 权重分片
在 NVL72 系统中，模型权重可分散至最多 72 颗 GPU。单卡不再需要装下完整模型，权重被摊薄到整个机柜尺度，单卡 HBM 压力随之下降。
2.3 主机层：Vera CPU 的 LPDDR 就近缓冲
暂停的上下文不必长期霸占 HBM，而是下沉到 Vera CPU 的大容量 LPDDR 内存中做就近缓冲。这是一层「温数据」缓存，兼顾了容量与访问延迟。
2.4 软件层：Dynamo 与 CMX 上下文存储
Dynamo 推理软件负责把不活跃上下文迁移至 CMX 上下文存储，并在复用前取回。这一层把「上下文生命周期管理」从硬件问题变成了软件调度问题——冷上下文下沉、热上下文上浮，本质是一套面向 KV 缓存的缓存淘汰与预取策略。
2.5 存储层：RAG 索引外置
RAG 索引可以保留在 CPU 与存储侧，避免长期占用宝贵的 HBM。检索发生在存储层，只有真正命中的片段才被送入 GPU 侧参与计算。
| 层级 | 承载数据 | 关键机制 | 架构收益 |
|---|---|---|---|
| 精度层 | 权重 / KV 缓存 | NVFP4 低精度压缩 | 体积与带宽双降 |
| 设备层 | 模型权重 | NVL72 最多 72 卡分片 | 单卡 HBM 压力摊薄 |
| 主机层 | 暂停上下文 | Vera CPU LPDDR 缓冲 | 容量换延迟 |
| 软件层 | 不活跃上下文 | Dynamo 迁移至 CMX | 按需取回、冷热分层 |
| 存储层 | RAG 索引 | 索引外置 CPU/存储侧 | 释放 HBM 长期占用 |
三、数据说话：30 倍从何而来
英伟达援引 SemiAnalysis AgentX 基准给出了两组关键数据，值得逐字阅读：
- 在每用户每秒 125 token 的条件下，Vera Rubin NVL72 相较 GB300 NVL72 的每美元智能体吞吐量最高提升 30 倍，而每 GPU 的 HBM 容量仅增加约 3%。
- GB300 NVL72 较 H200 平台在每用户每秒 100 token 条件下，每美元吞吐量最高提升 10 倍。
请注意分母：是「每美元」，不是「每卡」。这个口径的转变极其关键——它把评估重心从硬件规格表拉回到了单位经济性（Unit Economics）。3% 的 HBM 增量撬动 30 倍的每美元吞吐，说明增益主要来自数据放置与调度效率，而非物理容量的堆砌。
「最高提升 30 倍」是特定基准（AgentX）、特定负载（125 token/s/用户）下的峰值数据，且高度依赖 NVL72 整机柜与 Dynamo 软件栈的完整部署。切勿将其简单外推为任意模型、任意并发下的通用加速比。做容量规划时，务必以自身业务负载做端到端压测。
四、架构师视角的落地启示
抛开厂商叙事，这套方案对自建推理集群的团队有三条可迁移的方法论：
4.1 把 KV 缓存当作一等公民来治理
KV 缓存的生命周期管理（下沉、迁移、预取、复用）应当像数据库的 Buffer Pool 一样被显式设计，而不是交给框架默认行为。Dynamo + CMX 的组合本质上就是一套面向上下文的缓存系统。
4.2 用「每美元有效 token」替代「显存容量」作为核心指标
采购与架构评审时，显存容量是输入而非产出。真正该盯的是单位成本下的有效吞吐，这迫使团队去优化数据放置，而不是无脑加卡。
4.3 分层思想可以跨厂商复用
即便不使用英伟达全家桶，NVFP4 式的低精度量化、权重分片、CPU 侧上下文缓冲、RAG 索引外置这些手段，在开源推理栈中同样有对应实现路径。
全栈协同设计的另一面是深度绑定：NVFP4、Dynamo、CMX、NVL72 之间存在强耦合，任何一层替换都可能让整体收益大幅缩水。评估此类方案时，必须把「可迁移性」与「供应商锁定成本」纳入 TCO 模型，而非只看峰值吞吐。
五、结论：内存墙的破法在墙外
英伟达这份技术解读最有价值的地方，不在于 30 倍这个数字，而在于它重新定义了问题：AI 内存瓶颈不是「HBM 不够多」，而是「数据没有在正确的层级、正确的时间出现」。当行业竞争从「显存多少」转向「每字节、每瓦特能产出多少有效 token」，架构师的工作重心也随之从硬件选型，转向数据放置策略与调度软件的设计。
对绝大多数团队而言，短期内无法复制整机柜方案，但「压缩、分层、预取、外置」这八个字，是任何规模下都能立刻着手的内存优化纲领。