HBM，急刹车

高带宽内存（HBM）一直是推动人工智能革命的关键技术。尽管HBM相对于其他类型的内存成本较高，但芯片设计人员仍然将越来越多的HBM封装到人工智能加速器中。客户在设计新一代HBM的同时，还通过增加内存立方体数量、提高堆叠密度和高度来提升每个XPU的容量。这导致HBM在DRAM晶圆总产能中所占比例越来越高，最终造成了我们今天所面临的DRAM严重短缺问题。

由于技术和供应链两方面的原因，我们正处于这一趋势转变的边缘。下一代加速器将以 8 层堆栈作为标准，而目前的标准是 12 层堆栈。英伟达已决定在 Rubin Ultra 上采用这一方案，与标准 Rubin 和 B300 相比，其单 GPU 的显存容量从 288GB 降至 192GB。SemiAnalysis 最先报道了这一变化。供应链正在为 8 层堆栈成为新标准做准备，而就在不到一年前，业界还在预期会发展到 16 层堆栈甚至更高。

然而，正如我们在内存模型中所述，我们认为这种趋势还会继续发展。对于内存带宽至关重要的推理工作负载而言，4层HBM可提供最佳的带宽性价比，从而实现最低的单芯片成本。容量在达到一定阈值之前非常重要，超过该阈值后，增加HBM容量带来的收益将递减，而这些增量比特却会带来相同的物料清单成本。这正是各大实验室的硬件团队希望从下一代HBM4开始在其ASIC项目中实现的目标。正如硬件设计人员致力于在直流电源受限的环境下最大化每瓦芯片的容量一样，4层HBM也是最大化每个HBM晶圆芯片容量（另一种稀缺资源）的有效途径。

本报告将阐述产能方程式发生变化背后的原因，证明 HBM 产能经常被闲置，并展示这如何能使实验室的总拥有成本和存储器供应商的盈利能力实现双赢。

HBM趋势已被打破

HBM一直是人工智能工作负载的主要工作内存形式，因为它在容量和带宽之间取得了良好的平衡，可用于通用芯片的训练和推理。SRAM虽然速度很快，但容量较低，因此价格昂贵且在某些任务上存在局限性。传统的DDR DRAM虽然性价比更高，但带宽却很差。

由于 AI 是一种内存密集型工作负载，因此每个加速器中的 HBM 内容一代又一代地持续增加也就不足为奇了：每个加速器更多的立方体、更密集的立方体和更高的堆栈。

每颗芯片HBM内存容量的增加也是成本上涨的主要原因之一。然而，近几个月来，这一趋势发生了逆转。下一代Rubin Ultra每个加速器仅配备192GB HBM内存，而传统Rubin甚至Blackwell Ultra的HBM内存容量都达到了288GB！这与不到一年前的预期相比，简直是巨大的倒退——当时人们还预期Rubin Ultra每个GPU将配备1TB HBM内存！公平地说，当时Rubin Ultra预计拥有4个计算芯片，而现在只有2个。即使考虑到这一点，每个GPU芯片的HBM内存容量也从256GB下降到了96GB。

降低HBM密度的决定很大程度上是出于供应方面的考虑。HBM晶圆非常稀缺。目前晶圆数量不足以满足N3逻辑和英伟达明年预定的CoWoS所需的12层立方体数量。转向8层意味着可以用有限的晶圆生产更多的立方体，从而有助于缩小供应缺口。

明年HBM成本的大幅上涨也无济于事，尽管英伟达比其他主要客户能拿到更优惠的价格。即便在GPU需求远超供应的情况下，随着组件成本的上涨（其中显存成本涨幅最大），英伟达也不得不牺牲部分利润。

HBM密度持续增长的趋势如今正在终结，这不仅是由于供应问题，还受到架构和工作负载需求变化的影响。虽然供应和成本是非常重要的因素，但如果额外的容量对客户而言是必要的，并且能够显著提升性能/总体拥有成本，那么英伟达就不会做出这样的决定。本文旨在论证，在许多情况下，增加每个GPU的HBM容量并不值得付出相应的成本，而未来的HBM 4-hi配置往往才是最佳选择。

更矮的堆栈，相同的带宽

我们想提醒读者注意一个重要的动态：降低堆叠高度虽然会减少单个GPU的容量，但带宽却丝毫不受影响。每个HBM立方体的可用带宽与堆叠高度无关。每个HBM4或HBM4e立方体包含2048个数据I/O，这些数据路径均匀分布在堆叠中所有核心DRAM芯片上。每个芯片最多可支持512个I/O，这意味着4层堆叠是能够访问所有2048个I/O并最大化带宽的最低堆叠高度。然而，供应商和最终用户的成本主要取决于每个立方体的DRAM容量。HBM定价主要取决于每个堆叠的GB数。而用户从HBM获得的价值通常是带宽。因此，降低堆叠高度意味着最终用户每带宽的成本更低，也就是说，选择较低的堆叠高度几乎相当于白送午餐。

带宽还是容量？带宽才是王道

不同的AI工作负载对容量和带宽都有不同的需求，但带宽和容量哪个更重要，则取决于具体的工作负载。我们可以将AI计算分为三大类：预训练计算、后训练化学习计算和推理计算。强化学习与推理非常相似，因此需要类似的架构。在这三大类中，推理解码主要受带宽限制：生成的每个词元都需要读取所有激活的模型参数以及存储在内存中的用户键值缓存（KVCache）。强化学习（类似于推理）虽然也受带宽限制，但由于其侧重于处理大批量数据，因此需要比推理更高的容量。同时，预训练对容量更为敏感，因为在训练过程中，HBM用于存储权重、梯度和激活值，而推理前向传播仅存储权重和用户键值。

一个重大变化是，随着终端token需求的增加，分配给预训练的计算资源份额显著减少，而训练后技术成为模型扩展的主要途径。其结果是，现在大部分分配的计算资源对带宽的敏感性已从对容量的敏感性转变为对带宽的敏感性。

这并非意味着容量对推理无关紧要，容量的重要性是有上限的。Cerebras 和 Groq SRAM 机器的一大弱点是容量不足，尽管它们拥有充足的 SRAM 带宽，可以实现非常快速的token服务。简而言之，所需的容量存在一个阈值：推理系统需要足够的高带宽内存容量来存储模型权重以及用户的键值缓存 (KVCache)。正如我们将要展示的，超过这个阈值后，增加容量带来的收益会递减。

另一点需要注意的是，这里指的不是单个芯片的内存，而是整个系统的总内存。前沿模型的规模早已无法容纳在单个芯片的内存中，必须将其分片到多个芯片的内存中。这就是为什么网络是人工智能系统设计中不可或缺的一部分。对于目前所有前沿模型都采用的 MoE 架构而言，最佳系统通常是一个具有快速低延迟通信（例如整个机架内的 NVLink）的单一纵向扩展世界，能够支持广泛的专家并行处理，其中每个 GPU 上只加载少量专家。这种设置允许每个专家处理更大的token批次，并提高计算和内存带宽利用率，但代价是 GPU 之间所有 GPU 之间的通信成本大幅增加。

尽管模型权重和用户 KVCache 容量需求都在增长，但大规模扩展的规模使得每个节点的聚合内存能够轻松应对。在 Hopper 时代，一个 H100 HGX 系统提供 640GB 的聚合 HBM 内存。当时最好的开源模型 Llama 3.1 405B 的权重会消耗其中 63% 的容量，剩余的 KVCache 容量并不多。因此，H200 为每个 GPU 额外提供的 61GB 内存显得尤为重要。每台服务器 1128GB 的内存提供了大量的额外空间，可以容纳更多的 KVCache 并服务更多的并发用户。

借助 GB300 NVL72 机架式解决方案，NVIDIA 不仅实现了 9 倍的纵向扩展能力，还通过使用 12 层 HBM 和增加每个 GPU 的 HBM 立方体数量，使每个 GPU 的 HBM 容量翻了一番。这使得总 HBM 容量比 H200 HGX 提升了 18 倍。这一增长速度远超目前最大的开源模型 Kimi K3 2.8T 的近 7 倍参数增长。此外，通过将 16/8 位量化精度降低到 4 位四分之一精度，容量负担也显著降低。存储在 MXFP4 中的 2.8T Kimi K3 单个副本仅占用 1,561GB，不到 GB300 NVL72 上近 21TB 可用 HBM 容量的 8%。纵向扩展能力的增长势头依然强劲。 Rubin Ultra 的最大升级是升级到 NVL576，比 NVL72 提升了 8 倍，这足以弥补每个 GPU 的 HBM 容量减少三分之一。

在机架级服务器时代及未来，可用内存容量远超模型权重所需，为用户键值缓存 (KVCache) 提供了充足的余量。系统现在可以轻松支持具有超长上下文长度的推理请求，并拥有足够的并发性以支持极高的推理裕度。这大大缓解了 HBM 的容量压力，并允许每个芯片的 HBM 密度有所降低。这与之前小型服务器部署的模式截然不同，在之前的部署中，模型权重会消耗大量总内存。那时，提高每个 GPU 的 HBM 密度是获得宝贵容量余量的关键途径。

虽然低堆叠、低带宽的论点一直成立，但我们现在才看到这种堆叠高度增加的趋势开始逆转，因为每个芯片的最低HBM容量阈值最近才大幅降低。我们认为这种趋势还会继续发展。Frontier Labs的芯片和硬件团队认为，4层HBM是许多推理工作负载的最佳SKU，因为它能提供最佳的性能/总拥有成本比，接下来我们将深入探讨其中的原因。

带宽和容量的最佳组合

带宽和容量之间存在一个最佳比例，但通常情况下，容量最终会被过度配置或闲置，因为每个token的带宽不足以读取 HBM 中的所有可用容量。

我们先来看一个简单的例子。每个 HBM4E 内存堆栈提供 3,328 GB/s 的标称峰值带宽（假设有 2048 个引脚，每个引脚的带宽为 13 Gbps）。对于 HBM4E，每个核心芯片的内存容量为 32 GB，因此 4 层、8 层和 12 层堆栈的内存容量分别为 16 GB、32 GB 和 48 GB。假设一个单次读取序列的速率为 100 个 token/s，则每个 token 可用的内存带宽为 3,328/100 = 33.28 GB。然后，我们将每个 token 的可用带宽除以堆栈容量，即可得到每个 token 能够读取的总堆栈容量的次数。每个 token 读取一次堆栈容量，这意味着容量和带宽完美匹配：一个 token 拥有足够的带宽来读取 HBM 中存储的所有工作数据，不多也不少。

大于 1 的数值表示带宽相对于容量而言“过剩”，因为一个token只需要读取一次工作集（即一次前向传递）。然而，带宽很少会“过剩”，因为额外的带宽预算可以通过增加每秒token数来消耗掉。小于 1 的数值表示token没有足够的带宽来读取所有可用的 HBM 容量。为了以给定的吞吐量服务token，工作集的大小不能大于每个token的可用带宽，因此它必须小于总内存容量。这会导致内存容量过剩，从而造成过剩配置。

如上表所示，token处理速度的提升会降低每个token的可用带宽，从而降低堆栈读取/token比率，进而增加容量过剩的可能性。这就造成了一种不对称性：相比于容量，拥有充足的带宽更为可取。带宽通常可以完全利用，而剩余容量却不一定能被充分利用，而且其成本还在不断攀升。

当然，这只是一个简单的分析，忽略了为多个并发用户提供批量请求服务的情况。批量处理在推理经济中扮演着关键角色，因为它可以在给定的交互水平下最大化总token吞吐量。批量处理带来的最大节省来自于将一次权重读取操作分摊到多个用户的请求中。更高的并发性也会消耗更多内存容量，因为每个用户的键值缓存（KVcache）都需要加载到内存中。增加批处理大小通常是推理工作负载受内存容量限制而非带宽限制的原因。当 HBM 容量足以容纳模型权重时，增加 HBM 容量的优势在于它可以提供更高的token吞吐量，这也是为什么额外的比特位值得投入 BOM 的原因。

考虑批处理后，结果如上图所示。在其他条件相同的情况下，更高的 HBM 堆栈可以提供更高的吞吐量，直至达到某个用户延迟 SLA，超过该 SLA 后，额外的容量将变得冗余。这些重叠点即代表不同曲线的重叠点。

“每用户延迟 SLA”是基于最低交互性假设的。这只是最低要求，而非实际交互性。当并发量受限于容量时，意味着还有额外的带宽可用于支持更高的每秒每用户token数。因此，即使 4-hi 架构的并发量较低，但更高的每秒每用户token数可以完全或部分抵消较小批处理大小的影响，从而提高总token吞吐量。

并发性基于以下两者中的较小值：容量受限时的最大并发性（即内存中可容纳的单个用户 KVCache 集合数量）；以及带宽受限时的最大并发性（即在最小交互水平下可服务的最大用户数，该交互水平已考虑上述每个token的可用带宽计算）。用户数乘以每秒每个用户的token数即可得到每秒生成的总token数，即吞吐量。

这些曲线可以告诉我们，额外的容量在推理性能方面所提供的价值，它显示了通过增加容量（通过更多的批处理）可以实现更高的token吞吐量，同时也显示了在最小交互性的哪些点上，额外的容量不会增加价值。

这很大程度上取决于模型大小，或者换句话说，取决于需要分配给模型权重的 HBM 容量百分比。一般来说，模型越大，曲线就越向右移动，因此更高的堆栈会在更高的交互点提供更高的吞吐量。此外，更高的堆栈也会带来更大的峰值吞吐量提升。这与批处理的经济性有关。无论批处理大小如何，每个步骤都只读取一次权重，因此权重占用空间越大，每个额外的并发用户解锁的吞吐量就越多。

让我们用实际数据来分析一下，看看目前最大的开源模型 Kimi K3 的表现如何。这只是一个近似分析，实际上，实际达到的内存带宽远低于峰值带宽。实际结果会显示最小交互阈值向左偏移，因此总体结论仍然相同。此外，本次分析仅针对解耦式 PD 设置中的解码池。如需查看实际结果，请参阅我们的 InferenceX 和 AgentX 基准测试。

我们使用 Rubin Ultra NVL576 系统，因为它更能代表 HBM4E 时代大规模应用场景的典型规模。我们假设 HBM 为 HBM4E，速度为 13Gbps。4 层、8 层和 12 层分别对应每个 GPU 128GB、256GB 和 384GB 的内存。对于运行在该 NVL576 系统上的 Kimi K3，每个 GPU 存储 16.8GB 的权重，即每个 HBM 堆栈 2.1GB。我们可以看到，在最低 SLA 为 105 tok/s/用户的情况下，12 层 HBM 的吞吐量并不比 8 层 HBM 更高。当交互量进一步翻倍至 213 tok/s/用户时，使用高于 4 层堆栈的高度也没有任何优势。就最大吞吐量而言，8层架构相比4层架构，最大总token/秒数提升了8%，而12层架构则提升了10%。然而，即使将吞吐量降至4层架构所能达到的最大吞吐量，交互性也能提升一倍以上。我们再次强调，实际上，由于并非所有原始内存带宽都能被充分利用，实际结果会将这些曲线向左偏移，这意味着高容量下的盈亏平衡交互点会更低，甚至可能导致用户认为速度过低而无法接受。

我们可以看到，虽然增加内存容量可以略微提高这些模型的token吞吐量（暂且不考虑更快的token带来的优势），但问题在于，这种额外的吞吐量是否值得增加内存带来的额外物料清单成本。HBM 是加速器物料清单成本的重要组成部分，而且由于 HBM 供应紧张，明年每 GB 的成本将大幅上涨。

考虑到成本因素，我们对Rubin Ultra NVL576系统相对于基于HBM4E 4层架构的基准Rubin Ultra的BOM成本增加进行了建模。8层架构的系统总成本增加（我们将其近似为TCO，因为系统总成本占TCO的绝大部分）相对于基准4层架构系统为12.1%，而12层架构则高达26.3%。然后，我们可以比较在最小交互性的不同点上，token吞吐量增加与成本增加之间的关系，以展示在这些点上，更大的内存容量是否能够降低每个token的成本。

总体而言，我们发现 12 层或 8 层 HBM 带来的吞吐量提升低于增加内存所带来的系统成本增加，这意味着在当前的内存价格下（加上英伟达的利润），12 层和 8 层 HBM 的单token成本高于 4 层 HBM。这甚至还没有考虑更多 HBM 节省技术，例如将 KVCache 卸载到更低层级的内存。下一节将展示我们执行的实际生产运行，以说明更低的内存容量如何影响实际吞吐量。

一项真实实验：

KVCache卸载缓解容量压力

虽然降低 HBM 容量会减少存储的 KVCache 数据量（只要模型权重能够拟合），但可以使用第二层 DRAM 来存储那些“热度”较低且需要即时检索的 KVCache 数据。这在具有极长上下文长度的智能体工作负载中越来越常见，这些工作负载会给 HBM 容量带来压力，同时回合之间也存在较长的停顿，因此将 KVCache 数据卸载到 DRAM 甚至存储中，而不是重新计算，是更划算的做法。在我们最近的 AgentX 基准测试中，许多工作负载在并发度超过一定阈值后，通过卸载 KVCache 数据获得了帕累托最优结果。

为了测试在实际工作负载中减少 HBM 的影响，我们在减少 HBM 的 Kimi K3 上运行了 InferenceX 基准测试。该系统配备了 16 个 GB300 GPU，采用分离式配置，其中 8 个 GPU 用于预填充池，8 个 GPU 用于解码池。受限内存工作负载的 HBM 利用率为 85%，而正常情况下为 92%。诚然，HBM 仅减少了 8%，远不及从 8 层架构到 4 层架构减少 50% 的效果，但这是 Kimi K3 仅由 8 个 GPU 提供服务，因此权重占用了相当一部分内存。最终，每个 GPU 的 KVCache 存储空间减少了 20GB。具体来说，对于聚合服务，GPU KV 预算从 53GB 降至 34GB，减少了 36%。对于分离式架构，则从 44GB 降至 24GB，减少了 44%。总体而言，这大幅减少了 KVCache 的 HBM 预算。

从结果来看，在曲线的大部分点上，HBM 受限运行的吞吐量与高 HBM 运行非常接近（以红色虚线曲线表示）。然而，一旦并发数超过 70，吞吐量便急剧下降，与高 HBM 运行相比下降了近 30%。此时，受限内存版本的 GPU KV 缓存峰值占用率达到 100%。抢占、重复加载和排队等因素都会影响吞吐量。值得注意的是，此时曲线上的某个点并发数很高，但交互性却很低。我们知道，DRAM 卸载的使用频率要高得多，因为在相同的并发数下，低 HBM 受限配置对 DRAM KVCache 的读取次数是高 HBM 配置的 10 倍以上。

在实际工作负载中，我们可以看到将 KVCache 卸载到 DDR DRAM 可以非常有效地缓解 HBM 容量压力。这是针对 Kimi K3 而言的，并未考虑最新 DeepSeek v4.1 闪存模型中引入的一些更为极端的缓存缩减技术，这些技术与 v4 闪存相比，可将活动 KVCache 大小减少约 75%。在 KVCache 容量如此缩减的情况下，提高并发性以充分利用所有 HBM 容量很可能意味着工作负载将受计算和网络限制，而非容量限制，因此也会降低更高 HBM 堆栈的价值。

4-Hi是否放弃了未来升级的可能性？

在我们利用 NVL576 架构上的 HBM4E 进行 K3 屋顶线分析时，一个明显的缺陷是，我们使用当前工作负载在未来的系统上来证明 4 层架构就足够了。要等到一年后，当这些更大规模的扩展域以及 HBM4E 和前沿模型都可用时，扩展规模只会更大。此外，AI 服务器的部署寿命超过 5 年，并且需要能够在这段时间内持续提供token服务。

如果未来工作负载的模型规模大幅增长，那么牺牲现有容量可能会严重低估未来工作负载的最佳容量需求。例如，假设未来模型的规模是 Kimi K3 的三倍（同时每个用户的 KVCache 容量也增加三倍），那么通过更高 HBM 堆栈带来的吞吐量提升将更加显著。12 层堆栈比 4 层堆栈的总token数多 47%，而 8 层堆栈虽然速度只有一半，但token数却多 36%。在这种情况下，增加容量就显得更加合理，最终的决策取决于更快的token数额究竟有多大。

如果将成本考虑在内，在这种情况下，8-hi 提供的吞吐量高于 TCO 增加值，低于 180 tok/s/用户。

然而，从 8 层升级到 12 层并不值得，在整个曲线上，12 层带来的token吞吐量增加都超过了 BOM 成本的增加。

对此存在一些反驳论点。首先，调整模型参数（以及模型权重）对模型性能的重要性已不如以往。强化学习的显著增加以及推理/思考时间的延长，是模型架构效率提升的关键因素。此外，GPT-6 Astra 确实使用了循环变换器，并且很多人推测 Anthropio 的大型模型也采用了这种设计。循环变换器实际上是将输入多次通过变换器层进行处理。这种方式通过增加模型深度而非权重来实现模型的扩展。

其次，如果4层加速器成为人工智能服务器加速器装机量的重要组成部分，研究人员将会调整他们的模型，以便能够有效地利用这种硬件。此外，我们了解到，Frontier Labs的硬件团队最支持4层HBM。这些团队致力于软硬件协同设计，他们对4层加速器的呼吁反映出，未来的模型发展方向不再需要如此强大的处理能力。

最后，从宏观角度来看，所有构建和运营模型的人的目标都是尽可能多地服务token。而采用 4 层堆栈正是确保这一点的关键……

最大化token/瓦特token/HBM晶圆

最优硬件架构是指在资源有限的情况下最大化产出。在构建人工智能基础设施方面，我们面临着诸多资源短缺的问题。电力是其中关键资源之一，因此优化每瓦token数 (tokens/W) 至关重要，这也是推理提供商和硬件架构师努力优化的关键指标。当然，资金也是有限的，因此性能/总拥有成本 (Performance/TCO) 一直是影响硬件决策的重要指标。

正如上文所述，另一个主要制约因素是HBM晶圆的供应。虽然文中并未提及，但优化每片HBM晶圆的token数可以类比于优化每瓦的token数和每总拥有成本的token数。实现方法很简单：使用4层HBM。由于4层堆叠与8层或12层堆叠的带宽相同，简单来说，4层堆叠意味着每片HBM晶圆可获得的内存带宽是12层堆叠的三倍，或是8层堆叠的两倍。考虑到4层堆叠更高的封装良率，实际效果甚至更佳。由于内存带宽通常与token吞吐量成正比，这意味着在HBM供应有限的情况下，4层堆叠是充分利用资源的最佳选择。

通过采用 4 层封装，可利用的 HBM 立方体数量相比 8 层封装可增加一倍以上。这些立方体只有在与加速器共封装并集成到系统中才能发挥作用。这意味着瓶颈将从 HBM 晶圆转移到供应链的其他环节，例如逻辑晶圆（包括加速器和 HBM 基片所需的晶圆）、基板、PCB、下游集成能力以及许多其他中间组件。此外，部署更多系统所需的电力也不容忽视。不过，总体而言，我们相信未来几年内供应链其他环节的产能提升速度将超过 DRAM 的供应速度。即使 AI 服务器供应链无法满足两倍 HBM 立方体的供应需求，这也释放了用于传统 DRAM 的晶圆，以满足其他因 HBM 对整体 DRAM 供应的蚕食效应而面临内存短缺的应用需求。首先想到的就是服务器 DRAM，为了最大限度地利用有限的服务器 DRAM 供应，每个插槽的 DRAM 容量正在大幅减少。这也与支持代理工作负载密切相关，因为在代理工作负载中，大量时间实际上是花费在等待 CPU 相关的执行，而不是等待 GPU 解码token。

（来源：编译自semianalysis）

*免责声明：本文由作者原创。文章内容系作者个人观点，半导体行业观察转载仅为了传达一种不同的观点，不代表半导体行业观察对该观点赞同或支持，如果有任何异议，欢迎联系半导体行业观察。