当整个行业都在为 HBM 产能抢破头时，英伟达交出了一份反直觉的答卷。
从 Blackwell Ultra 到 Vera Rubin 平台，每块 GPU 的 HBM 容量只增加了大约 3%。但同一时期，在 SemiAnalysis 的 AgentX 智能体负载上，每美元能买到的吞吐量最高涨了 30 倍。
内存没怎么变多，活却多干了几十倍。这背后不是魔法，而是一套被英伟达称为“全栈协同设计”的方法论：不再迷信把更多内存塞进 GPU，而是让每一个字节在正确的层级上做更多有用功。
在 HBM 供应趋紧、价格走高的近期内，这套思路可能比单纯堆料更能决定 AI 工厂的生死。
内存压力从四面八方涌来
2026 年 11 月 5 日，英伟达在官方博客详细拆解了这场内存危机的来龙去脉。文章由 Amr Elmeleegy 撰写，核心判断很明确：更大的模型、更长的上下文、智能体应用的爆发，正在把 GPU 内存推向极限，而供应趋紧和价格上涨的趋势在短期内不会逆转。
压力的第一来源是模型本身。前沿模型的参数量已经进入万亿级别，这些参数是模型在训练中学到的一切，推理时必须驻留在高速内存里。
第二来源是 KV cache。这是模型理解每个活跃请求时需要记住的上下文，避免重复处理相同信息。智能体应用让情况雪上加霜：一条智能体轨迹会在多次模型调用和工具调用之间携带先验上下文，某些场景下处理的 token 数量高达 300 万。这意味着每个请求的工作内存不是固定的，而是随着时间不断增长。
第三来源是 RAG。检索增强生成把企业自有信息塞进 prompt，创造出更多需要处理和保留的上下文。
推理时，HBM 主要就装两样东西：模型参数和 KV cache。两边都在膨胀，容量却有限。于是行业最本能的反应出现了，往 GPU 上堆更多 HBM。
英伟达的答案却是，不完全是。
为什么堆 HBM 救不了 AI 工厂
英伟达确实是最早把 HBM3e 和 HBM4 引入加速计算栈的公司，它与内存合作伙伴紧密合作，快速采用最新技术。但公司的核心观点很克制：增加每 GPU 的 HBM 容量只是最显而易见的答案，而容量能释放的，只有带宽能搬运的那部分。
文章用了一个精准的比喻：把 HBM 想象成仓库，内存带宽就是装卸码头。更大的仓库能装更多库存，但码头决定了单位时间能进出多少货。一旦码头满载，再多的库存也只会让搬运变慢、响应时间变长。如果延迟超过了服务等级要求，多出来的空间根本无法有效使用，却照样增加成本、消耗电力。
这就是工程师口中的“内存墙”。当每个用户都期待快速响应时，内存带宽终究无法像计算单元消耗数据那样快地供数。越过这道墙之后，额外的 HBM 容量无法投入工作，却仍在烧钱、仍在耗电。
数据仍然需要地方存放，但不是所有数据都需要住在最快、最贵的那一层。这就是为什么 AI 工厂必须把数据分布在一个内存与存储的层级结构里：GPU 的 HBM 是最快、最贵、竞争最激烈的顶层，模型权重和 KV cache 在这里争夺有限容量；往下是 CPU 内存、本地 SSD 和共享存储，每一层用速度换取更大容量和更低的每比特成本。
一个字节能做多少有用功，取决于三件事：缩小必须存储的内容，把它放在正确的层级，在需要之前把它送回 GPU。英伟达的全栈协同设计，就是围绕这三件事展开的。
三招拆解内存压力
英伟达的方法论同时瞄准三个效率漏洞：模型权重、KV cache、RAG 数据。每一招对应一种浪费。
先说模型权重。NVFP4 格式把权重的存储需求压到比 FP8 更低，FP8 已经是 Hopper 平台能支持的最低精度。越来越多的模型厂商开始拥抱 4 比特精度：Black Forest Labs 的 FLUX.2 [klein]、Thinking Machines Lab 的 Inkling、Reflection 的 Beam 1.0、Meta 的 Muse Spark、阶跃星辰的 Step 5 Preview，以及英伟达自家的 Nemotron 3.5 Super VL，都发布了 NVFP4 检查点。精度降下来，速度上去，内存占用也下来了。
更进一步，在一个 NVL72 系统里，模型权重可以分布到最多 72 块 GPU 上。每块 GPU 只需要持有模型的一小部分，省下来的 HBM 全部留给 KV cache 和并发用户。权重不再是单卡的负担，而是整个域的共同资产。
再看 KV cache。KV cache 本身也可以应用 NVFP4，占用空间比 FP8 更小，更多上下文因此能常驻 HBM。但这还不够，因为智能体调用工具时，上下文会有一段闲置时间。
这里轮到 NVIDIA Vera CPU 上场。它的作用有两个：更快的工具执行缩短了 KV cache 在工具调用期间闲置的时间；它的大容量 LPDDR 内存通过 NVLink-C2C 互连直连 Rubin GPU，给暂停的上下文提供了一个就近等待、并能快速返回的位置。
当上下文暂时不用时，NVIDIA Dynamo 推理软件会把它移到 NVIDIA CMX context memory storage。这是一个为容量打造的层级，每比特成本远低于 HBM。与本地 SSD 不同，CMX 可以跨服务器共享；与企业存储不同，它省去了短期上下文不需要的长期数据保护开销。CMX 的合作伙伴阵容相当豪华：Cloudian、DDN、Dell Technologies、Everpure（前 Pure Storage）、HPE、IBM、NetApp、VAST、WEKA。
Dynamo 的 KV Cache Reuse 则把这些层级缝合成一个整体，把 KV cache 当作跨 GPU 内存、CPU 内存和存储的系统级资源来管理。算过一次的上下文，可以在整个系统里复用，而不是每次重新计算。
最后是 RAG。RAG 把企业文档变成嵌入向量，用数值表示让系统按语义而非关键词搜索，并组织成可检索的索引。NVIDIA Nemotron Retriever 模型生成的嵌入更小、检索准确率更高；NVIDIA cuVS 库让这个索引可以在 CPU 和存储上构建与服务。结果是知识库从不占用 HBM，只有模型真正需要的段落才会进入上下文。
三招叠加后的效果很直接：更少的 HBM 被模型权重占用，更少的 HBM 被闲置上下文锁死，更多的 HBM 可以用来服务并发用户。
3% 与 30 倍的商业含义
数字不会撒谎。从 Blackwell Ultra 到 Vera Rubin，每 GPU 的 HBM 容量只涨了约 3%。但在 SemiAnalysis AgentX 的 DeepSeek V4 Pro 负载上，NVIDIA GB300 NVL72 在每用户 100 tokens/秒时，每美元吞吐量比 H200 平台最高高出 10 倍，而此时每 GPU 的 HBM 容量大约翻了一倍。到了每用户 125 tokens/秒，Vera Rubin NVL72 的每美元吞吐量比 GB300 NVL72 最高高出 30 倍，而每 GPU 的 HBM 容量只涨了约 3%。
换句话说，H200 到 GB300 这一代，吞吐提升主要还靠堆容量；而 GB300 到 Vera Rubin 这一代，容量几乎没动，吞吐却靠架构和软件的提升冲了上去。这是两种完全不同的增长模式。
对 AI 工厂运营者来说，真正重要的指标只有一个：在功耗预算之内、在满足用户响应时间要求的前提下，工厂能交付多少有用的 token。每瓦每秒更多的 token，意味着同样的电力能做更多工作、产生更多收入，每个 token 的成本也更低。英伟达全栈协同设计的最终落点，就是通过提高每个字节内存产出的有用功，把 token 成本压下去。
这也解释了为什么英伟达要同时设计 GPU、CPU、网络、存储和软件。单一环节的优化很快会触顶，只有让数据在正确的时间出现在正确的层级，才能绕过内存墙。
谁会被这套打法甩开
这场内存战的胜负手，正在从“谁能拿到更多 HBM”转向“谁能更高效地使用 HBM”。
对云厂商和大型 AI 实验室来说，这意味着选型逻辑要变。只看每 GPU 的 HBM 容量已经不够，必须同时看每美元吞吐、每瓦吞吐，以及软件栈在跨层级数据调度上的成熟度。那些只会在硬件参数表上堆数字、却在系统软件上欠账的供应商，会在真实负载下露馅。
对模型厂商来说，NVFP4 这类低精度格式的生态正在成型。越早适配 4 比特推理、越早把权重和 KV cache 压缩纳入默认流程，就能越早享受内存效率红利。观望者的上下文成本会被对手越拉越远。
内存供应链也会随之分化。HBM 仍然紧缺且昂贵，但 CMX 这样的中间层级会创造新的存储需求。那些能提供跨服务器共享、又能为短期上下文定制保护策略的存储厂商，会拿到新的增量市场。
从更长周期看，全栈协同设计正在成为 AI 基础设施的新门槛。它不再是“有更好”的加分项，而是决定 token 经济性、决定 AI 应用能否规模化落地的基础能力。当每一代平台的内存容量增长都不可避免地放缓时，唯一能持续挖掘的性能来源，就是让已有的每一个字节干更多的活。
AI 竞赛的下半场，赢家不属于囤积最多内存的人，而属于让每个字节都物尽其用的人。
快报