高带宽内存（HBM）一直是推动 AI 革命的关键技术。尽管 HBM 相对于其他形式的内存成本高昂，芯片设计者仍不断在 AI 加速器中封装越来越多的 HBM。客户一方面推动在设计中采用更新一代的 HBM，另一方面又通过增加更多内存立方体（cube）、采用更密集和更高的堆叠来提升每个 XPU 的容量。这导致 HBM 消耗的 DRAM 晶圆产能占比越来越高，最终造成了我们今天所面临的严重 DRAM 短缺。

如今这一趋势正濒临逆转，背后既有技术原因，也有供应链层面的驱动因素。下一代加速器将把 8-hi 堆叠作为标准配置，而目前的行业标准是 12-hi。Nvidia 已决定在 Rubin Ultra 上这样做，与标准版 Rubin 和 B300 相比，每个 GPU 的容量从 288GB 降至 192GB，SemiAnalysis 最先报道了这一变化。供应链目前正在为 8-hi 成为新标准做准备，而就在不到一年前，整个行业还在预期迈向 16-hi 甚至更高。

不过，正如我们在 Memory Model 中的分析，我们认为这一趋势还会走得更远。在对内存带宽最为敏感的推理负载中，4-hi HBM 能提供最优的每美元带宽（$/bandwidth），从而实现最低的单 token 成本。容量固然重要，但一旦超过某个阈值，更多的 HBM 容量带来的收益会递减，而这些增量比特却带来同样的 BOM 成本负担。因此，各大实验室的硬件团队希望在下一代 HBM4 之后的 ASIC 项目中采用这一方案。正如硬件设计者在数据中心电力受限的世界里专注于最大化 tokens/Watt 一样，4-hi 则是最大化每张 HBM 晶圆产出 token 数的方式——毕竟 HBM 晶圆本身也是一种稀缺资源。

本报告将阐述容量方程式发生了什么变化及其背后的逻辑，论证 HBM 容量经常处于闲置（stranded）状态，并说明这如何成为实验室 TCO 与内存供应商盈利能力的双赢局面。

HBM 一直是 AI 负载的主要工作内存，因为它在容量与带宽之间提供了良好的平衡，可同时服务于训练和推理的通用芯片。SRAM 虽然速度极快，但容量太低，使其成本高昂且在某些任务上受限。传统 DDR DRAM 提供了更高的单位美元容量，但带宽表现太差。

AI 是如此依赖内存的负载，因此每个加速器的 HBM 容量一代代持续增长也就不足为奇了：每个加速器搭载更多内存立方体、更密集的立方体，以及更高的堆叠。

每颗芯片所搭载的 HBM 数量不断增加，也是成本上升的一大因素。然而，过去几个月里这一趋势已被打破。下一代 Rubin Ultra 每个加速器将只配备 192GB 的 HBM，而常规版 Rubin 甚至 Blackwell Ultra 都高达 288GB！这相比不到一年前的预期是一次巨大的倒退——当时预计 Rubin Ultra 每颗 GPU 将配备 1TB 的 HBM！公平地说，那是基于 Rubin Ultra 预计拥有 4 个计算裸片的前提，而现在只有 2 个。即使按此归一化计算，每 GPU 裸片的 HBM 容量也从 256GB 降到了仅 96GB。

降低 HBM 密度的决定在很大程度上是出于供应方面的考虑。HBM 晶圆十分稀缺。根本没有足够的晶圆来供应支撑 Nvidia 明年锁定的 N3 逻辑产能和 CoWoS 产能所需的 12 层堆叠（12-hi）立方体数量。改用 8 层堆叠（8-hi）意味着从有限的晶圆中可以产出更多立方体，有助于缩小供需差距。

明年 HBM 成本的大幅上涨也无济于事，尽管 Nvidia 拿到的价格已经比其他大客户更优惠。即使在 GPU 需求远超供给的时期，随着组件成本不断上升，Nvidia 也不得不牺牲部分利润率，其中内存是最大头。

HBM 密度不断攀升的趋势如今正在被打破，这不仅仅是因为供应问题，还有架构原因以及不断变化的工作负载需求。虽然供应和成本是非常重要的因素，但如果额外的容量对客户来说是必需的，并且能明显带来更好的性能/TCO，Nvidia 就不会做出这个决定。本文的重点是要论证：在很多情况下，为每颗 GPU 增加更多 HBM 容量并不划算，而未来的 4 层堆叠（4-hi）HBM 往往才是最优配置。

我们想提醒读者注意一个重要动态：通过降低堆叠高度来减少每颗 GPU 的容量，完全不会以牺牲带宽为代价。无论堆叠高度如何，每个 HBM 立方体可提供的带宽都是相同的。HBM4 或 HBM4e 每个立方体有 2048 个数据 I/O，这些数据通路会平均分配给堆叠中的所有核心 DRAM 裸片。每颗裸片的上限是 512 个 I/O，这意味着 4 层堆叠是能够用满全部 2048 个 I/O 并实现最大带宽的最低堆叠高度。然而，供应商和最终客户的成本主要由每个立方体的 DRAM 容量决定，HBM 的定价主要由每堆叠的 GB 数驱动。而客户从 HBM 中获得的价值往往在于带宽。因此，更低的堆叠高度意味着对最终客户而言低得多的单位带宽成本（$/带宽），选择更低的堆叠高度几乎是一顿免费的午餐。

虽然不同的 AI 工作负载对容量和带宽都有需求，但根据工作负载的不同，侧重点会有所倾斜，有的更看重带宽，有的更看重容量。我们可以将 AI 计算分为三大类：预训练计算、后训练/强化学习计算、推理计算。强化学习与推理非常相似，因此需要类似的架构。在这三类中，推理解码主要受带宽制约：每生成一个 token，都需要读取所有活跃的模型参数，以及存储在内存中的用户 KVCache。强化学习（因其类似推理）同样偏向于受带宽制约，但由于注重大批量处理，它比推理需要更大的容量。与此同时，预训练对容量要敏感得多，因为在一次训练过程中，HBM 不仅要存储权重，还要存储梯度和激活值，而不像推理前向传播那样只需存储权重和用户的 KV。

一个重大变化是，随着终端 token 需求的增长以及后训练技术成为模型扩展的主要途径，分配给预训练的计算份额已大幅缩减。其结果是，目前分配的计算资源中，大多数已从对容量敏感转变为对带宽敏感。

这并不意味着容量对推理无关紧要，容量在一定程度上仍然重要。Cerebras 和 Groq 的 SRAM 机器的一大弱点就是容量不足，尽管其充足的 SRAM 带宽可以实现极快的 token 服务。简而言之，容量存在一个门槛要求：推理系统必须具备足够的高带宽内存容量，来容纳模型权重以及用户的 KVCache。超过这一门槛后，增加容量的边际收益会递减，我们将在后文展示这一点。

另一个重要的一点是，这里的内存不是指单芯片内存，而是整个系统的总内存。前沿模型的规模早已无法装入单颗芯片的内存，必须分片到多颗芯片的内存中。这正是网络设计成为 AI 系统设计核心部分的原因。对于当今所有前沿模型都采用的 MoE 架构而言，最优的系统往往是一个具备快速低延迟通信的单一纵向扩展域（例如整个机架内的 NVLink），以支持广泛的专家并行，即每块 GPU 上只加载少数几个专家。这种设置让每个专家能处理更大的 token 批次，提升了计算和内存带宽的利用率，但代价是 GPU 之间产生高得多的全互联通信开销。

尽管模型权重和用户 KVCache 的容量需求都在增长，但 scale up 世界规模（world size）的大幅提升，使得每个节点的总内存不仅跟得上、甚至绰绰有余。在 Hopper 时代，一台 H100 HGX 系统提供 640GB 的总 HBM。当时最好的开源模型 Llama 3.1 405B 的权重会占用其中 63% 的容量，为 KVCache 留下的余量不多但也还算有一些。这正是 H200 为每颗 GPU 额外提供 61GB 内存之所以重要的原因。凭借每台服务器 1,128GB 的内存，系统获得了大量额外余量，可以容纳更多 KVCache 并服务更多并发用户。

随着 GB300 NVL72 机架级方案的出现，Nvidia 将 scale up 世界规模提升了 9 倍，同时通过采用 12-hi HBM 并增加每颗 GPU 上 HBM 芯粒的数量，使每颗 GPU 的 HBM 翻倍。相比 H200 HGX，这带来了 18 倍的总 HBM 容量增长，显著跑赢了当前最大开源模型 Kimi K3 2.8T 近 7 倍的参数增长。此外，从 16/8 位量化降到 4 位四分之一精度（quarter precision），也大幅减轻了容量负担。一个以 MXFP4 存储的 2.8T Kimi K3 副本仅占用 1,561GB，还不到 GB300 NVL72 上近 21TB HBM 的 8%。Scale up 世界规模的增长并未放缓：Rubin Ultra 的一大升级是从 NVL72 转向 NVL576，规模再提升 8 倍，足以抵消每颗 GPU HBM 容量减少三分之一的影响。

在机架级服务器时代及之后，可用内存容量已远超模型权重的需求，为用户 KVCache 留出了非常充裕的余量。如今系统可以从容支持超长上下文长度的推理请求，并发度也足以支撑很高的推理利润率。这缓解了大量 HBM 容量压力，也让每颗芯片的 HBM 密度得以放松要求。这与之前小规模推理部署的时代截然不同——那时模型权重要占用总内存的相当大一部分，因此提升每颗 GPU 的 HBM 密度是获取宝贵容量余量的关键手段。

虽然“更低堆叠层数、更便宜的带宽”这一论点一直站得住脚，但直到最近，每颗芯片最低 HBM 容量门槛大幅下降，我们才刚刚开始看到高堆叠层数的趋势出现逆转。我们认为这一趋势还会走得更远。前沿实验室的芯片与硬件团队认为，对许多推理工作负载而言，4-hi HBM 才是最优 SKU，因为它能带来最佳的性能/TCO。接下来我们将深入探讨其中的原因。

带宽与容量之间存在一个最优配比，但容量往往被过度配置或闲置浪费：按每 token 计算的带宽不足以读完全部可用的 HBM 容量。

我们先从一个简单的例子开始。每个 HBM4E 堆栈提供 3,328 GB/s 的标称峰值带宽（假设 2048 个引脚、每个引脚 13 Gbps）。对于 HBM4E，每个核心裸片（core die）容量为 32-Gb，因此 4-hi、8-hi 和 12-hi 堆栈分别对应 16 GB、32 GB 和 48 GB。假设单个序列的吞吐量为 100 tokens/s，那么每个 token 可用的内存带宽为 3,328/100 = 33.28 GB。接下来，我们用每个 token 可用的带宽除以堆栈容量，得到每个 token 能够读取的总堆栈容量次数（即堆栈读取次数）。当该值为 1 时，意味着容量与带宽完美匹配：一个 token 拥有的带宽恰好足以读取存储在 HBM 中的全部工作数据，不多也不少。

如果该数值大于 1，说明相对于容量而言带宽是“超配”的，因为一个 token 只需要读取一次工作集（即一次前向传播）。不过，带宽很少会真正“过剩”，因为多出来的带宽预算可以通过提高每秒 token 数来消耗掉。如果该数值小于 1，则说明一个 token 拥有的带宽不足以读取全部可用的 HBM 容量。要在给定吞吐量下服务这些 token，工作集的大小就不能超过每个 token 可用的带宽，因此必须小于总内存容量。这就会导致内存容量出现超配、产生过剩。

正如上面的示例表格所示，提高 tokens/s 会降低每个 token 可用的带宽，使堆栈读取次数/token 的比值下降，从而加大容量超配的可能性。这就造成了一种不对称性：相比大容量，人们更倾向于拥有大带宽。带宽通常可以被完全消耗掉，而闲置的容量却并不总能被利用，同时其成本还在不断攀升。

当然，这只是忽略了请求批处理（batching）的简单分析，而批处理可以同时服务多个并发用户。批处理在推理经济学中扮演着关键角色，因为它能在给定的交互性水平下最大化总 token 吞吐量。批处理带来的最大节省，在于将一次权重读取分摊到多个用户的请求上。不过，更高的并发度也会消耗内存容量，因为每个用户的 KVcache 都需要加载到内存中。增大 batch size 往往正是推理负载从带宽受限转变为内存容量受限的原因。当 HBM 容量足以轻松容纳模型权重时，额外 HBM 容量带来的好处就是能够提供更高的 token 吞吐量，这也解释了为什么这些额外的存储位值得计入 BOM 成本。

把批处理考虑进来后，就得到了上面这条泛化曲线。在其他条件相同的情况下，更高的 HBM 堆叠能带来更高的吞吐量，直到达到某个单用户延迟 SLA 上限，此时额外容量就变得多余了。这些临界点在图中表现为不同曲线相互重叠的地方。

“每用户延迟 SLA”是一个最低交互性假设。这是最低值而非实际交互性。当并发数受容量限制时，意味着还有额外的带宽可用于支撑更高的每用户 tokens/s。因此，即使 4-hi 只能提供更低的并发数，更快的每用户 token/s 也能完全或部分抵消批量变小带来的影响，从而提高总 token 吞吐量。

并发数取决于容量受限和带宽受限两种情况下的最大并发数中的较小者：容量受限时，取决于内存中能容纳多少组单个用户的 KVCache；带宽受限时，取决于在最低交互性下能同时服务的最大用户数，这一计算需要结合上文得出的每 token 可用带宽。用户数乘以每用户 tokens/s 就得到每秒生成的总 token 数，也就是吞吐量。

这些曲线能告诉我们额外容量在推理性能方面的价值：它们展示了更多容量（通过更大的批量实现）能带来多大的 token 吞吐量提升，同时也显示出在哪些最低交互性点上，额外容量并不能带来价值。

这在很大程度上取决于模型大小，换句话说，取决于需要分配给模型权重的 HBM 容量占比。一般来说，模型越大，曲线就越向右移，这样更高的堆叠层数就能在更高的交互性点上提供更多吞吐量。此外，更高的堆叠层数还能带来更大的峰值吞吐量提升。这又回到了批处理的经济学：无论批量大小如何，每一步都会读取一次权重，因此权重占用越大，每个新增并发用户所解锁的吞吐量就越多。

让我们用实际数字来看看当今最大的开源模型 Kimi K3 的情况。这是一种 roofline 分析，实际上，真实达到的内存带宽显著低于峰值带宽。真实结果中最低交互性阈值会向左移动，因此总体结论仍然相同。此外，本分析仅关注分离式 PD 部署中的 decode 池。如需真实交付结果，请参阅我们的 InferenceX 和 AgentX 基准测试。

We use a Rubin Ultra NVL576 system as this will be a more representative scale up world size in the HBM4E era. We assume the HBM is HBM4E with 13Gbps speeds. 4-hi, 8-hi, and 12-hi means 128GB, 256GB, and 384GB per GPU respectively. For Kimi K3 on this NVL576 system, each GPU holds 16.8GB of weights which is 2.1GB per HBM stack. We can see that at a minimum SLA of 105 tok/s/user, 12-hi HBM doesn’t deliver more throughput than 8-hi HBM. Then when the interactivity is doubled further to 213 tok/s/user, there is no benefit to having taller than 4-hi stacks. In terms of maximum throughput benefits, 8-hi provides an 8% increase in maximum total tokens/s vs 4-hi while 12-hi provides a 10% improvement. However, again stepping down to the maximum throughput that 4-hi can deliver allows for more than double the interactivity. We also reiterate that in reality, as not all of the raw memory bandwidth can be utilized, actual results will shift these curves to the left, meaning that the higher capacity breakeven interactivity points are lower and could push into the speeds that users find unacceptably low.

We can see that while more capacity can deliver marginally more token throughput for these models (putting aside the benefit of faster tokens). The question then becomes, is that additional throughput worth the additional BOM cost associated with more memory. HBM is a significant part of accelerator BOM cost, and with HBM so tight, the cost per GB will rise dramatically next year.

When taking into account costs, we model the BOM cost increase the end owner pays relative to a baseline HBM4E 4-hi based Rubin Ultra for the Rubin Ultra NVL576 system. The all-in system cost increase (which we proxy as TCO as all-in system cost makes up the vast majority of TCO) of 8-Hi is 12.1% relative to a base 4-hi system and for 12-hi it becomes a 26.3% premium. We can then compare the increase in token throughput relative to the cost increase at different points on minimum interactivity to show whether more memory can deliver lower cost per token at any of those points.

Overall we see that the increase in throughput provided by 12-hi or 8-hi HBM comes in below the increased system cost associated with more memory, meaning at these memory prices (along with Nvidia’s margin stack), 12-Hi and 8-Hi HBM result in higher cost per token than 4-hi HBM. This comes before we even take into account more HBM conserving techniques, namely KVCache offloading to lower tiers of memory. This next section will show an actual production run we performed to show how lower memory impacts actual throughput.

在模型权重能够容纳的前提下，虽然削减 HBM 容量会减少可存储的 KVCache，但第二层 DRAM 可以用来存储那些不那么“热”、但又需要即时检索的 KVCache。这种方式在智能体（agentic）工作负载中正变得越来越普遍：这类工作负载的上下文长度非常高，给 HBM 容量带来很大压力，同时轮次之间又存在较长的停顿，因此把 KVCache 驱逐到 DRAM 甚至存储设备上，比完全重新计算更加划算。在我们近期的 AgentX 基准测试中，许多工作负载的帕累托最优结果，都是在并发度超过一定阈值后通过 KVCache 卸载（offloading）获得的。

为了在真实工作负载中测试 HBM 减少的影响，我们在 Kimi K3 上以减少的 HBM 运行了 InferenceX 基准测试。系统由 16 块 GB300 GPU 组成，采用分离式（disaggregated）部署：8 块 GPU 用于预填充（prefill）池，8 块 GPU 用于解码（decode）池。受限内存工作负载以 85% 的 HBM 利用率运行，而正常情况下是 92% 的 HBM 利用率。是的，这仅是 8% 的 HBM 缩减，距离从 8-hi 降到 4-hi 时的 50% 缩减还很远。但这是因为 Kimi K3 只在 8 块 GPU 上提供服务，权重本身就占据了相当大的一部分内存。最终相当于每块 GPU 减少了 20GB 的 KVCache 存储。具体而言，对于聚合式（aggregate）服务，GPU 的 KV 预算从 53GB 降至 34GB，缩减了 36%；对于分离式配对，则是从 44GB 降至 24GB，缩减了 44%。总体来看，这对用于 KVCache 的 HBM 预算来说是一个相当可观的缩减。

从结果来看，在曲线上的大部分区间内，HBM 受限运行仍能提供非常接近的吞吐量（由红色虚线曲线表示）。然而，一旦并发度超过 70，吞吐量相比高 HBM 运行就骤降了近 30%。这正是受限内存版本的峰值 GPU KV 占用率达到 100% 的时刻。此时，抢占（preemption）、反复加载和排队都会影响吞吐量。需要注意的是，这发生在曲线的高并发但交互性极低的区间。我们知道 DRAM 卸载被使用得更多，因为在相同并发度下，较低的 HBM 受限配置对 DRAM KVCache 的读取量是较高 HBM 配置的 10 倍以上。

我们可以在真实工作负载中看到，将 KVCache 卸载到 DDR DRAM 能够非常有效地缓解 HBM 容量压力。以上结果是针对 Kimi K3 的，尚未考虑最新的 DeepSeek v4.1 Flash 模型中引入的一些更为激进的缓存缩减技术——相比 v4 Flash，这些技术可将活跃 KVCache 大小缩减约 75%。在这样的 KVCache 水平下，提高并发度以用满全部 HBM 容量，很可能意味着工作负载将变为计算和带宽受限，而非容量受限，这也会削弱更高层数 HBM 堆叠的价值。

在我们针对 NVL576 上 HBM4E 的 K3 roofline 分析中，明显的缺陷在于：我们是在用当前的负载去检验一个未来系统，以此证明 4-hi 已足够。而实际上要到一年之后，这些更大规模的 scale-up 域才会与 HBM4E 一同面世，届时前沿模型的规模只会进一步增长。此外，AI 服务器的部署寿命超过 5 年，在此期间必须能够持续提供 token 服务。

如果未来负载的模型规模大幅增长，被牺牲掉的容量可能会严重低估最优容量需求。举例来说，假设未来模型规模是 Kimi K3 的 3 倍（同时每个用户的 KVCache 也增至 3 倍），那么更高层数 HBM 堆叠带来的吞吐提升就会好得多。12-hi 可以比 4-hi 多交付 47% 的总 token，8-hi 则多交付 36% 的 token，尽管速度只有一半。在这种场景下，额外的容量开始变得更合理，最终决策取决于更快的 token 究竟有多大的价值。

如果将成本纳入这一分析，在本例中，当每个用户低于 180 tok/s 时，8-hi 带来的吞吐增益会超过 TCO 的增幅。

然而，从 8-hi 升级到 12-hi 并不划算：在整条曲线的任何位置上，12-hi 的 token 吞吐增益都不及 BOM 成本的增幅。

对此有几点反驳意见。首先，扩大参数量乃至模型权重，对模型能力的重要性已经大不如前。大规模增加强化学习以及更长的推理/思考时间，是带来更高效模型架构的关键进展。此外，已有确凿消息证实 GPT-6 Astra 使用了 looped transformer，也有大量猜测认为 Anthropic 最大的模型同样如此。Looped transformer 会将输入多次重复通过 transformer 层。这种方式是通过深度而非增加权重来扩展模型。

其次，如果 4-hi 加速器成为 AI 服务器加速器装机量中的重要组成部分，研究人员就会调整其模型，以便在这类硬件上高效地提供服务。另外，据我们了解，最支持 4-hi HBM 的恰恰是各前沿实验室（Frontier Labs）的硬件团队。这些团队对软硬件协同设计（co-design）极为执着，他们对 4-hi 的呼吁反映出未来模型正朝着不需要那么大容量的方向发展。

最后，从大局来看，所有构建和提供模型服务的人都有一个共同目标：交付最大数量的 token。采用 4-hi 堆叠正是实现这一目标的保障……

最优的硬件架构，就是能在稀缺资源下实现最大产出的架构。在构建 AI 基础设施方面，我们正面临诸多短缺。电力是其中的关键之一，这就是为什么优化 tokens/W（每瓦特令牌数）如此重要——它是推理服务商和硬件架构师努力优化的核心指标。当然，资金也是有限的资源，因此性能/TCO（总拥有成本）一直是驱动硬件决策的经久不变的评价标准。

如上文所述，另一个主要制约因素是 HBM 晶圆的供应。虽然很少被提及，但优化 tokens/HBM 晶圆（每片 HBM 晶圆的令牌产出）的思路与 tokens/W 和 tokens/TCO 是一脉相承的。实现方法很简单：使用 4-hi HBM。由于 4-hi 堆叠可以获得与 8-hi 或 12-hi 堆叠相同的带宽，简单来说，如果晶圆原本用于制造 12-hi HBM，那么采用 4-hi 意味着每片 HBM 晶圆可获取的内存带宽是原来的三倍；相比 8-hi 晶圆则是两倍。如果再考虑 4-hi 更高的封装良率，实际数字还要更好。由于内存带宽通常直接对应令牌吞吐量，这意味着在有限的 HBM 供应下，4-hi 是实现产出最大化的最佳选择。

与 8-hi 相比，采用 4-hi 后可获取的 HBM 堆叠块（cube）数量可能超过两倍。但这些堆叠块只有与加速器共同封装并装入系统才有价值。这意味着瓶颈将从 HBM 晶圆转移到供应链的其他环节，例如逻辑晶圆（既包括加速器，也包括 HBM 的基础裸片）、基板、PCB、下游集成产能，以及介于其间的许多其他组件。此外，别忘了部署更多系统还需要大量电力。不过总体而言，我们相信未来几年供应链其他环节的产能扩张速度能够超过 DRAM 供应。即使 AI 服务器供应链无法满足两倍 HBM 堆叠块所需的相关供应，这也会为传统 DRAM 释放出晶圆产能，去服务那些因 HBM 挤占整体 DRAM 供应而陷入内存短缺的其他应用。首先想到的就是服务器 DRAM——为了充分利用有限的服务器 DRAM 供应，每个插槽的 DRAM 配置已被大幅削减。这也与支持智能体（agentic）工作负载密切相关，因为在这类负载中，大量时间实际上花在等待 CPU 相关的执行上，而不是等待 GPU 解码令牌。

在付费章节中，我们将讨论这对内存供应商的影响、4-hi 如何使他们受益，以及他们的应对措施。我们的内存模型（Memory Model）中还包含更多深度洞察、产品 SKU / 供应商决策，以及供需细节。