top of page

SemiAnalysis 4-hi HBM 分析:为何更短的堆叠可能赢得 AI 推理

9月14日
讀畢需時 16 分鐘

SemiAnalysis 对 AI 内存行业一味追求更高堆叠的趋势提出质疑,认为 4-hi HBM 能以三分之一的 DRAM 芯片实现完整带宽。

这一主张之所以重要,是因为加速器制造商多年来一直在增加内存堆叠高度。更多层数带来了更大容量,支持了更大的模型,也让高带宽内存成为 AI 计算不可或缺的一部分。

这份 SemiAnalysis 4-hi HBM 分析指出,推理如今改变了这笔账的计算方式。机架级系统提供了更多总容量,而量化和缓存卸载则减少了每块 GPU 必须容纳的数据量。

该报告并不认为每种工作负载都需要更少内存。训练、大批量处理和未来模型仍可能从更高的堆叠中获益。它更尖锐的论点聚焦于交互式推理:在这里,带宽往往会在容量变得稀缺之前限制 token 的生成。

这让两项设计优先级展开直接竞争。一方追求每颗加速器的最大内存容量;另一方则追求从每片受限的 DRAM 晶圆中获得最大的 token 带宽。

有关 Nvidia Rubin Ultra 内存容量缩减的报道提供了眼前的信号。SemiAnalysis 称,该加速器将配备 192GB HBM,低于标准 Rubin 和 Blackwell Ultra 的 288GB。

Nvidia 尚未公开详述 Rubin Ultra 的 4-hi 配置。不过,据报道其转向 8-hi 堆叠,表明一味提高 HBM 堆叠高度已不再是理所当然的选择。

如果这一逻辑延伸至 4-hi HBM4E,AI 基础设施便能在不牺牲每个堆叠外部带宽的情况下,使用更少的 DRAM 芯片。这将降低内存成本,并从有限的晶圆供应中产出更多可用的 HBM 封装。

Nvidia 的内存路线图不再只朝一个方向发展

真正重要的变化并非 Nvidia 突然只需要很少的内存,而是额外容量似乎不再值得不惜一切代价去获取。

Blackwell Ultra 清晰确立了高容量的发展方向。Nvidia 标注每块 Blackwell Ultra GPU 配备 288GB HBM3E,一台 GB300 NVL72 机架则拥有 20TB。

该公司的 GB300 规格还显示,GPU 总内存带宽可达每秒 576TB。这些数字说明了 Nvidia 此前为何同时强调容量和带宽。

SemiAnalysis 目前报告称,Rubin Ultra 将逆转这一趋势的一部分。其预计每块 GPU 配备 192GB,相比 Blackwell Ultra 和常规 Rubin 减少了三分之一。

这一比较需要谨慎看待。据报道,Rubin Ultra 的架构已从四颗计算芯片改为两颗。因此,其此前预计的内存容量属于不同的系统设计。

即使对这一变化进行归一化处理,SemiAnalysis 仍估计,每颗计算芯片的内存将从此前的 256GB 降至 96GB。这是一项重大的架构重置,而非表面化的规格调整。

报告将供应列为原因之一。据报道,Nvidia 已锁定大量先进逻辑和封装产能,但可用的 HBM 晶圆无法支撑等量的 12-hi 堆叠产出。

一个 12-hi 堆叠在基底芯片上方包含 12 颗核心 DRAM 芯片。8-hi 堆叠使用 8 颗,使同样的已加工 DRAM 供应能够支持更多成品堆叠。

这很重要,因为每比特 HBM 比传统 DRAM 消耗更多制造产能。贯穿硅通孔,即 TSV,会在内存堆叠中垂直传输信号和电力。

这些 TSV 需要额外的加工步骤。HBM 芯片还需为垂直连接预留面积,因此与采用类似工艺制造的普通内存相比,其比特密度更低。

SemiAnalysis 此前估计,按每比特计算,HBM 消耗的晶圆产能约为通用型 DRAM 的三倍。随着生产转向 HBM4,这一估计接近四倍。

这一数字是分析师估计,并非行业标准。不过,这种底层制造负担已在各家内存供应商中得到充分验证。

SK hynix、Samsung 和 Micron 必须对多颗已知良品芯片进行加工、减薄、连接、测试和封装。每增加一层,都会提高材料用量,并使封装面临额外的良率风险。

历史上,更高的堆叠足以证明这类负担的合理性,因为加速器需要其容量。模型权重、激活值、梯度、优化器状态和键值缓存都会在不同工作负载中争夺内存。

这一新决策表明,对于某些推理系统而言,容量已经跨过一个阈值。一旦机架容纳了所需的工作集,为每块 GPU 增加内存所产生的价值便会下降。

Nvidia 尚未公开确认 SemiAnalysis 对 Rubin Ultra 容量构成的确切说法。因此,这一主张仍应被视为已报道的路线图变化,而非最终产品规格。

不过,供应链准备工作可能会在产品公开发布前揭示方向。SemiAnalysis 称,在行业推动 12-hi 和 16-hi 产品之后,供应商正在准备让 8-hi 配置成为标准。

这一已报道的变化为 4-hi HBM 创造了机会。如果八层已足够,设计者就必须思考:四层能否以更经济的方式服务于特定推理部署。

在近期的容量竞赛中,这个问题听起来或许是逆向而行。但在严峻的 DRAM 限制下,它正成为行业最务实的架构选择之一。

SemiAnalysis 4-hi HBM 在减少芯片的同时保持带宽

更短的 HBM 堆叠会降低容量,但不会自动降低封装的外部带宽。

HBM 通过极宽的接口传输数据,而非仅依赖极高的信号速度。HBM4 将这一接口扩展至每个堆叠 2,048 个数据连接。

HBM4 标准由 JEDEC 于 2025 年 4 月发布。它为新一代 AI 和高性能内存奠定了基础。

据 SemiAnalysis 称,每颗 HBM4 DRAM 芯片最多可访问堆叠中 512 个数据连接。因此,四颗芯片即可填满全部 2,048 个连接。

增加第五至第十二颗芯片会提升容量,但不会将外部接口拓宽至超过 2,048 个连接。

在更高的堆叠中,可用引脚会分配给更多内存层。该堆叠向加速器呈现的整体接口仍然相同。

这正是短堆叠论点背后的核心机制。若采用相同代际和信号速率,4-hi、8-hi 和 12-hi 封装可提供相近的标称带宽。

它们的容量则存在显著差异。SemiAnalysis 对 32Gb HBM4E 核心芯片建模:4-hi 可提供 16GB,8-hi 为 32GB,12-hi 则为 48GB。

这些是建模中的未来配置,而非普遍可买到的零售产品。它们说明了层数如何改变容量,同时保持封装接口不变。

经济层面的差异源于供应商消耗的资源。DRAM 含量构成 HBM 堆叠成本的主要部分,而推理客户往往更看重向加速器供给数据的带宽。

4-hi 买家获得的 GB 数更少,但仍可得到让计算单元持续获得数据供应所需的数据通路。

这改变了相关的效率衡量方式。以容量为重点的采购会问:每颗加速器旁能容纳多少 GB?以带宽为重点的采购则会问:这些内存连接能支持多少 token?

对推理而言,第二个问题可能占据主导地位。自回归解码会按顺序生成输出,每一步都必须从内存中读取模型的活跃权重。

这一过程通常针对每移动一个字节只进行相对较少的计算。因此,解码常常受限于内存带宽,即数据传输会先于原始算力限制吞吐量。

只有当工作负载会使用其额外容量时,更高的堆叠才有帮助。否则,额外芯片承载的信息无法以可用带宽足够频繁地读取。

SemiAnalysis 给出的示例性 HBM4E 带宽为每个堆叠每秒 3,328GB。该数字基于 2,048 个引脚以每秒 13Gb 的速率工作得出。

以每秒生成 100 个 token 计算,每个 token 对应 33.28GB 的理论带宽。若每个 token 都必须读取一次,有用工作集便不能超过这一预算。

一组 48GB 堆叠将包含超过理论带宽每个 token 所能扫描的数据。部分容量将无法被该特定速度下的工作负载利用。

现实系统永远无法持续达到标称带宽的每一个单位。协议开销、访问模式、通信和软件行为都会降低有效吞吐量。

这种限制可能强化短堆叠的论点。较低的可用带宽意味着,工作负载会在利用全部已安装容量之前就触及带宽上限。

通过这一机制解释的 4-hi HBM,并不只是更便宜的内存。它是一种将外部带宽与最大垂直密度分离开的配置。

这一差异也会影响制造产出。用于四层堆叠的一片晶圆,理论上可支持的封装数量是一片用于 12 层堆叠晶圆的三倍。

实际增益取决于良率、基底芯片供应、测试和封装吞吐量。更短的堆叠也应能避免部分与更多层数相关的累积组装损失。

SemiAnalysis 认为,由此带来的每片 HBM 晶圆带宽与每瓦 token 数同样重要。两项指标都在衡量:面对无法快速扩张的资源,可产出多少有用的 AI 输出。

为何推理更重视带宽而非最大容量

交互式推理需要内存快速为处理器供给数据,而未被使用的容量对 token 吞吐量贡献甚微。

训练和推理对 HBM 提出不同需求。训练在通过前向和反向传播处理大批量数据时,需要存储权重、激活值、梯度和优化器数据。

这类工作负载可能消耗极大的容量。它也会执行足够多的计算,使许多操作变为算力受限。

推理解码则不同。系统在逐个生成 token 时,会反复读取活跃权重以及用户的键值缓存,即 KV cache。

KV cache 存储了先前 token 的注意力信息。它避免模型每生成一个新 token 时都重新计算整段对话。

更多用户和更长上下文会扩大这一缓存。不过,只有当系统能在可接受的延迟目标内为这些用户提供服务时,更大容量才有价值。

批处理让情况更为复杂。通过将多个请求一起处理,服务器可让多个用户分摊一次模型权重读取。

更大的批量可提升总吞吐量,但也需要更多 KV cache 容量。在这里,8-hi 或 12-hi 堆叠可以重新获得优势。

其中的权衡在于交互性。服务提供商可以等待更久以形成更大的批量,也可以通过较小批量快速返回 token。

SemiAnalysis 使用未来 Rubin Ultra NVL576 配置上的 Kimi K3 对这种关系进行了建模。它发现,随着所需的每用户速度提高,更高堆叠带来的吞吐量增益会递减。

在模型设定的每用户每秒 213 个 token 下,报告发现超过 4-hi 不再带来吞吐量收益。带宽上限会在额外内存容量变得有用之前到来。

在曲线的其他位置,8-hi 可将最大吞吐量提高 8%。12-hi 配置相较于 4-hi 可提高 10%。

这些改进在模型内部确实存在。问题在于,它们是否足以弥补额外的内存和系统成本。

SemiAnalysis 估计,其建模的 8-hi Rubin Ultra 系统成本比 4-hi 基线高出 12.1%。其 12-hi 配置则增加 26.3%。

这些是基于未来组件和假设内存价格得出的分析师估算,并非供应商报价,也不是已部署 Rubin Ultra 系统测得的拥有成本。

在这些假设下,吞吐量的增长速度慢于系统成本。因此,两种更高堆叠配置的每 token 成本都更高。

这是 SemiAnalysis 关于 4-hi HBM 方案最有力的论点。更短的堆叠不仅能降低硬件账单,还能提升单位支出的建模产出。

机架级计算让这一论点更具说服力。早期服务器连接八块 GPU,因此每个设备上的内存会强烈限制整个推理系统。

一套 H100 HGX 系统提供 640GB 的总 HBM 容量。在系统存储任何实质性的 KV 缓存之前,大型模型权重便可能占据其中大部分容量。

H200 通过为每块 GPU 增加内存缓解了这一压力。在那个阶段,提升单设备容量具有直接的运营价值。

GB300 NVL72 改变了规模。Nvidia 通过 NVLink 连接 72 块 Blackwell Ultra GPU,形成更大的共享通信域。

该机架配备约 20TB 的 GPU 内存。其总容量远高于配备八块 GPU 的 Hopper 服务器。

SemiAnalysis 将这一增长与 Kimi K3 进行比较,后者是一款拥有 2.8 万亿参数的专家混合模型。此类模型会针对每个 token 仅激活部分专家。

报告估计,量化后的 Kimi K3 副本占用 1,561GB。这将消耗一套约 21TB 的 GB300 NVL72 配置不到 8% 的容量。

量化以更少的位数表示数字,从而减少权重存储和内存传输。它以一定数值精度为代价,显著降低硬件需求。

大型 NVLink 域还能将专家分布到更多 GPU 上。这种安排增加了通信需求,但减少了每台设备必须保存的模型权重数量。

据报道,Rubin Ultra 将通信域从 NVL72 扩展至 NVL576。连接 GPU 数量增加八倍,足以抵消每个加速器 HBM 减少三分之一的影响。

因此,容量问题从单块 GPU 问题转向机架级资源分配问题。部署方案可以容纳大型模型,同时采用更薄的本地内存堆叠。

这并不会消除内存限制。它改变了架构师解决限制的位置,以及哪一种资源会最先变得稀缺。

缓存卸载有所帮助,但 4-hi HBM 并非没有代价

短堆叠策略只有在软件、二级内存和工作负载行为能够避免缩减后的 HBM 容量成为瓶颈时才有效。

SemiAnalysis 使用 Kimi K3 和 16 块 GB300 GPU 的 InferenceX 工作负载测试了这一假设的一部分。其中八块 GPU 负责预填充,另八块负责解码。

预填充会在 token 生成开始前处理提示词。将其与解码分离,可让运营者针对不同的计算和内存行为分别优化每个阶段。

实验将允许的 HBM 利用率从 92% 降至 85%。这远小于 8-hi 与 4-hi 堆叠之间的容量削减幅度。

不过,这一限制显著减少了可用的 KV 缓存空间。报告称,面向聚合服务的 KV 总容量从每块 GPU 的 53GB 降至 34GB。

对于解耦配对,可用预算从 44GB 降至 24GB。这些变化分别意味着 36% 和 44% 的下降。

在大多数测试并发级别下,吞吐量保持相近。受限配置将非活跃 KV 缓存数据转移至普通服务器 DRAM。

这一过程称为 KV 缓存卸载。它将频繁访问的信息保留在 HBM 中,同时将较冷的对话状态迁移到速度更慢、容量更大的内存中。

智能体工作负载可能适合这种方式。它们经常会在工具运行、CPU 执行代码或外部服务返回信息时暂停。

在这些暂停期间,GPU 并不需要立即访问每段对话的缓存。迁移较冷的数据可为活跃请求释放昂贵的 HBM。

受限测试遇到了明确的极限。当并发超过 70 时,与高内存配置相比,吞吐量下降了近 30%。

GPU KV 占用率已达到 100%。抢占、反复传输和排队随后降低了有效工作量。

受限运行中,从基于 DRAM 的 KV 缓存读取的次数也超过十倍。卸载缓解了容量压力,却增加了经过较慢层级的流量。

这一结果既提供支持,也提出警示。它表明,软件可以在显著减少内存后维持性能,但仅限于低于取决于工作负载的阈值时。

拥有大量同时使用长上下文用户的生产服务可能跨过这一阈值。在这种情况下,更高的 HBM 堆叠可支持更大的批处理和更高的总吞吐量。

网络容量同样重要。将模型专家和缓存分布到数百个加速器上,会产生密集的全互连通信。

系统可能不再受内存容量限制,转而受网络限制。这一结果仍会使额外的 HBM 闲置,但并不保证整体性能高效。

二级 DRAM 带来另一项限制。随着 AI 系统提升 CPU 侧容量,服务器内存本身也正面临供应压力。

卸载还会消耗电力并增加运营复杂性。软件必须决定哪些数据保持热态、哪些迁移,以及何时需要回迁。

不佳的决策可能将容量节省转化为延迟尖峰。该架构需要谨慎的调度、缓存管理和工作负载隔离。

未来模型增长带来了更大的不确定性。SemiAnalysis 承认,其分析将当前工作负载应用于预计稍后推出的硬件。

AI 服务器通常会部署超过五年。在此期间,模型、上下文、用户并发量和推理工作负载都可能发生巨大变化。

报告对一款规模为 Kimi K3 三倍、每用户缓存需求也为三倍的模型进行了压力测试。在这一假设下,更高堆叠变得更有用。

其 8-hi 配置的总 token 产出比 4-hi 高出 36%。12-hi 版本高出 47%,尽管两者的单用户速度都较低。

在计入估算成本后,当每用户每秒低于 180 token 时,8-hi 变得更具优势。12-hi 系统仍无法抵消其建模成本增幅。

这些结果说明,4-hi HBM 不能成为通用方案。首选堆叠高度取决于模型规模、延迟目标、批处理方式和系统寿命。

训练系统尤其不适合激进地削减容量。其激活值、梯度和优化器状态可能会占用所有可用内存。

为许多独立模型提供服务的推理系统同样需要容量。运营者可能更看重灵活性,而非针对单一优化工作负载的最低成本。

硬件买家面临选择权问题。4-hi 加速器或许适合当下的服务,但在工作负载变化后可能形成限制。

研究人员可能围绕已安装的硬件调整模型。循环计算、量化、稀疏专家和更小缓存都能降低对存储参数的依赖。

这种适应并无保证。模型质量的提升可能再次来自更大的参数规模或内存密集型架构。

因此,更恰当的解读应当更为狭窄。四层 HBM 为经过细致特征分析的推理提供了强有力的配置,而不是对更高内存堆叠的自动替代。

更少层数给内存供应商和系统制造商带来压力

如果买家优化的是带宽而非 GB 容量,经济压力将从 DRAM 生产转向基底晶片、封装、网络和完整系统集成。

SK hynix、Samsung 和 Micron 多年来一直在开发更高密度、更高堆叠的 HBM。其路线图强调容量、信号速度、封装良率和散热控制。

SK hynix 于 2025 年开始供应 12 层 HBM4 样品。其 HBM4 公告介绍了容量为 36GB、带宽超过每秒 2TB 的封装。

这一产品方向对于训练和容量密集型推理仍然有用。若市场显著转向 4-hi,将带来截然不同的采购优先级。

客户可能要求以更少的核心晶片提供完整接口带宽。供应商将出货更多封装,但每个封装内的 DRAM 位数更少。

乍看之下,这似乎不利于 HBM 收入。供应商一直受益于向每一代加速器销售更多专用 DRAM 内容。

SemiAnalysis 认为,结果可能更为平衡。更短的堆叠可以提升组装良率,并增加每片晶圆可生产的可售封装数量。

供应商也可能基于带宽价值收费,而不是主要将 HBM 视为按 GB 销售的产品。客户是否接受这种模式仍不确定。

供应层面的益处更为明确。从 12-hi 转向 4-hi,理论上可将固定 DRAM 数量所能提供的堆叠晶片组数量提高至三倍。

如果更短的堆叠提升封装良率,实际增幅可能超过这一简单比例。当其他组件成为限制因素时,增幅则会低于该比例。

每个 HBM 封装仍需要基底晶片、测试、堆叠,以及与加速器并排贴装。增加封装产量会提升所有这些环节的需求。

HBM4 使基底晶片更加重要,因为其包含更多逻辑,并可能采用先进代工工艺。节省 DRAM 并不会创造等量的代工产能。

更多内存封装还需要更多加速器封装。这些封装需要中介层、有机基板、供电、散热和高密度组装。

因此,瓶颈可能发生迁移而非消失。逻辑晶圆、基底晶片、基板、电路板和系统集成都将面临更高需求。

大型横向扩展域会加剧另一项限制。在其总内存成为实用的共享资源之前,更多加速器需要广泛的交换与网络连接。

Nvidia 的 GB300 NVL72 使用九个 NVSwitch 托盘连接 72 块 GPU。其第五代 NVLink 互连网络提供每秒 130TB 的总带宽。

未来的 NVL576 系统必须大幅扩展这一规模。其经济性取决于网络能否保持足够快,以支持分布式专家和缓存迁移。

电力仍是最终边界。只有当运营者能够部署与之相连的加速器时,带宽丰富的 HBM 封装数量翻倍才有意义。

4-hi 策略可以延展 DRAM 供应,却无法创造新的供电容量。数据中心建设、散热和电网接入仍决定可用算力。

这解释了为何每片 HBM 晶圆产出的 token 数是有用指标,但并不完整。运营者必须同时优化每瓦、每机架、每个网络端口及每单位资本预算的 token 产出。

这种变化还会影响传统内存市场。HBM 生产与服务器、PC 和移动 DRAM 争夺制造资源。

减少 HBM 核心晶片的使用,可将部分晶圆产能返还给这些产品。随着智能体 AI 部署推动 CPU 侧内存增长,这种缓解尤为重要。

不过,其益处取决于实际采用情况。如果 4-hi 设计促成远多于此前的加速器出货量,更大的总体销量可能消耗部分节省。

如果比特需求受到削弱,内存供应商也可能抵制快速转型。其反应将通过产品可得性、认证进度和产能分配体现。

因此,核心竞争并非 Nvidia 对阵某一家内存供应商,而是面向带宽的推理设计与面向容量的 HBM 经济性之间的竞争。

这种竞争格局使行业影响一目了然:当带宽能够创造收入、而已安装的 GB 容量无法创造收入时,短堆叠方案就会胜出。

当客户能够将额外容量转化为更大的批次、更多模型或更长期的硬件灵活性时,更高的堆叠方案就会胜出。

三个信号将揭示 4-hi HBM 是否真正胜出

只有当产品路线图、量产可用性和实测推理结果趋于一致时,短堆叠论点才会变得可信。

第一个信号是 Nvidia 最终确定的 Rubin Ultra 配置。公开文档必须确认内存容量、堆叠高度、带宽以及 NVL576 系统架构。

若确认采用 8-hi HBM 的 192GB 配置,将支持这一方向性论点。若重新采用 12-hi,则会削弱容量需求已普遍放松的说法。

一款商用的 4-hi Rubin 产品将提供更有力的证据。在此之前,SemiAnalysis 对 4-hi HBM 的提议仍只是对未来 ASIC 和加速器的有依据预测。

第二个信号是供应商对高速 4-hi HBM4 或 HBM4E 的认证。供应商必须能以加速器设计人员所需的信号传输速率提供这些封装。

仅有标称接口宽度并不足够。产品还需要在完整系统中具备可接受的良率、散热、可靠性和持续性能。

关注 SK hynix、Samsung 或 Micron 是否会在公开路线图中加入 4-hi 配置。向客户送样将表明短堆叠已不再只是内部架构研究。

还应关注定价模式。如果 4-hi 的成本主要随其较低容量而变化,其带宽经济性将极具吸引力。

如果供应商将大部分价值定价于基础裸片和接口,预期节省幅度可能收窄。即使 DRAM 用量更低,封装短缺也可能维持高溢价。

第三个信号是覆盖多样化工作负载的独立推理测试。基准测试必须包括交互式助手、智能体服务、长上下文请求和大批量部署。

平均 token 吞吐量并不足够。测试还需要涵盖每位用户的速度、排队行为、缓存命中率、卸载流量和尾延迟。

结果还应比较在规模和架构上不同的模型。针对 Kimi K3 优化的配置,无法证明它是每个未来前沿模型的最佳选择。

决定性证据将是在现实服务等级目标下,稳定的每 token 成本优势。这一优势必须能经受高并发和不断变化的工作负载组合考验。

开发者应当关注,因为硬件限制会塑造模型设计。可用内存会影响量化、专家放置、上下文处理和缓存策略。

企业采购方也应关注,因为标称容量可能具有误导性。当带宽、网络或延迟成为限制因素时,更多 HBM 并不保证带来更多有效推理。

基础设施团队应在机架层面评估工作集。在选择某一种内存配置之前,他们应区分训练、预填充、解码和智能体工作负载。

他们还应保留运营余量。一套经过高度针对性优化的 4-hi 系统,可能会在需求转向更大批次或更多同时运行的模型时失去优势。

更广泛的经验并非内存越少就一定越好,而是应根据工作负载实际消耗的资源来采购内存。

对于交互式推理,这一资源往往是带宽。四层 HBM 可在使用更少稀缺 DRAM 裸片的同时,保留完整的外部数据通路。

这使 SemiAnalysis 对 4-hi HBM 的分析,对行业中“堆叠越高越好”的假设构成了严肃挑战。下一批产品披露将显示硬件团队是否认同这一观点。

在确定未来加速器集群之前,请问三个问题:工作集是否能在机架规模下容纳,冷缓存数据能否安全迁移,以及额外容量是否会提升有效吞吐量?

如果答案指向带宽,那么这位“短堆叠之王”就值得被纳入路线图。

 
 

免费开始使用

一款本地优先的AI助手

为了获得更好的人工智能体验,

remio 目前仅支持Windows 10+ (x64)M-Chip Mac

你的 AI 工作伙伴

remio 一起高效工作

规划、创作、交付

一站式完成

bottom of page