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

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

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

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

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

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

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

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

借助 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 容量减少三分之一。

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

我们先来看一个简单的例子。每个 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吞吐量。批量处理带来的最大节省来自于将一次权重读取操作分摊到多个用户的请求中。更高的并发性也会消耗更多内存容量，因为每个用户的键值缓存（KVcache）都需要加载到内存中。增加批处理大小通常是推理工作负载受内存容量限制而非带宽限制的原因。当 HBM 容量足以容纳模型权重时，增加 HBM 容量的优势在于它可以提供更高的token吞吐量，这也是为什么额外的比特位值得投入 BOM 的原因。

“每用户延迟 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层架构所能达到的最大吞吐量，交互性也能提升一倍以上。我们再次强调，实际上，由于并非所有原始内存带宽都能被充分利用，实际结果会将这些曲线向左偏移，这意味着高容量下的盈亏平衡交互点会更低，甚至可能导致用户认为速度过低而无法接受。

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

为了测试在实际工作负载中减少 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 倍以上。

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

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

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

正如上文所述，另一个主要制约因素是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。