H3

面向低成本 LLM 推理的 HBM+HBF 混合架构

Minho Ha, Euiseok Kim, Hoshik Kim
SK hynix Inc.
LCA 2026
Presenter: wzw
Date: 2026-05-24

三句话看懂

瓶颈: HBM 带宽高但容量太小，CAG/shared pre-computed KV cache 一上到 1M/10M 上下文，就会把系统逼成“多堆 GPU 才能存下”的成本问题。
方法: 论文提出 H^3 = HBM + HBF，把巨型只读的模型权重和 shared KV 放进 HBF，把生成期 KV cache 留在 HBM，再用 Latency Hiding Buffer (LHB) 预取遮住 HBF 的 us 级延迟。
结果: 在 Llama 3.1 405B 的模拟评估中，10M 场景最大 batch size 提升到 18.8x，throughput 提升 6.14x，throughput per power 最高 2.69x。

场景先讲清

这篇 paper 不是讨论通用 LLM serving，而是瞄准 Cache-Augmented Generation (CAG) 这类巨型只读 shared KV cache 的场景。
请求到来前，系统先把共享知识预计算成 KV cache；推理时主要是反复读取这份 cache，而不是频繁改写它。
这正好击中 HBF 的长处: 大容量 + 高带宽读取，同时避开其短板: 高写延迟 / 差写耐久。

真正卡住的是容量

文中用 Llama 3.1 405B 举例: shared pre-computed KV cache 在 1M 和 10M 序列长度下约为 540 GB 和 5.4 TB。
这意味着，哪怕不谈算力，只为了把数据放下，HBM-only 系统就得上很多 GPU。
所以本文的核心问题不是“让单卡更快”，而是能否在近 GPU 层级同时拿到 HBM 级带宽和远大于 HBM 的容量。

HBF 为何有吸引力

论文把 HBF 定义成一种 TSV 叠层 NAND flash，目标是提供接近 HBM 的带宽与约 16x HBM 的容量。
但它并不是免费午餐: 访问延迟从 ns 上升到 us，写耐久更差，单位功耗最高可到 HBM 的 4x。
所以 HBF 不能单独当通用主存，它需要一个只读、带宽敏感、且访问顺序可预测的 workload。

关键观察

CAG / gigantic shared KV cache 正好满足这个 workload 画像: 数据巨大、几乎只读、访问顺序可预测、且容量可以直接换 batch。
论文的核心判断是: 这种场景更缺容量，而不是更缺最后一点访问延迟。
因此，与其把所有数据都放在 HBM，不如把“只读大对象”和“可写敏感数据”分层放置。

H3 总览

HBM 直连 GPU shoreline，HBF 通过 HBM base die 级联，二者一起暴露为 GPU 的 main memory。
关键新增块是 address decoder & router + LHB，所以这不是 PCIe 外挂 Flash，而是近封装异构主存。

数据放哪一层

放在 HBF: model weights + shared pre-computed KV cache，因为它们巨大、只读、带宽敏感。
放在 HBM: generated KV cache 和其他需要低延迟、频繁写入的数据。
这不是传统 cache eviction，而是一个静态角色分工: HBF 负责“存得下”，HBM 负责“写得动”。

一次推理如何走

Step 1: GPU 读取 HBF 中的模型权重与 shared pre-computed KV，同时从 HBM 读取当前生成阶段的 KV。
Step 2: 当前层计算完成后，新生成的 KV cache 写回 HBM，而不是写去 HBF。
Step 3: 因为下一层要用的 tensor 是确定的，framework 可以提前发出 prefetch hint。
Step 4: LHB 在后台把后续层需要的 HBF 数据提前拉近，于是 HBF 的长延迟被尽量藏在 layer 间隙里。

LHB 是关键补丁

HBF 最大的问题不是带宽，而是 us 级访问延迟，直接裸读会把 GPU 卡死。
论文引入 Latency Hiding Buffer (LHB)，本质上是 base die 上的 tensor-level prefetch buffer。
它依赖的不是复杂 predictor，而是 LLM 推理的确定性层级访问顺序。

LHB 约 40 MB/cube

$$ \mathrm{Capacity}{LHB} = 2 \times \mathrm{BW} $$} \times \mathrm{Latency}_{HBF

硬件账本

LHB capacity: 每个 HBF cube 约 40 MB SRAM。
Area: 按 3 nm SRAM density = 0.021 um^2/bit 估算，SRAM core 面积约 6.72 mm^2；算上 20% 额外电路后总计 8.06 mm^2。
Base-die overhead: 约占 121 mm^2 base die 的 6.7%，作者认为可接受。
风险: 所有收益都建立在 HBF bandwidth ~= HBM bandwidth 的假设上，真实产品化时这里最不确定。

方法学先交代

评估方式: 不是硅后测量，而是作者基于先前工作搭的 analytical simulator。
Workload: Llama 3.1 405B，并把 context 从原始 128K 扩到假设的 1M 和 10M。
System assumption: GPU 取 NVIDIA B200；HBM3e = 192 GB, 8 TB/s；HBF = 3 TB, 8 TB/s。
Topology: 1M 评估用 8 GPUs，10M 用 32 GPUs，这些都是为 HBM-only case 能跑起来设定的最小规模。

最大收益先来自 batch

先读图: 横轴是 GPU 数量，纵轴是最大 batch size，橙色是 HBM-only，红色是 H^3。
1M 场景下，8 GPU 时最大 batch size 约提高到 2.6x；10M 场景最高达到 18.8x。
论文还强调一个很实用的信号: 单 GPU 可跑 1M，双 GPU 可跑 10M，说明 H3 改变的是可部署门槛。

吞吐与每瓦吞吐

左图是 normalized TPS per batch，右图是 normalized TPS per batch per power。
1M 场景 throughput 提升 1.25x；10M 场景提升到 6.14x。
更重要的是，尽管 HBF 更耗电，H3 的 throughput per power 最高仍达到 2.69x，说明容量收益没有被功耗吞掉。

带宽减半也还成立

论文额外测了 H^3 (1/2 bandwidth HBF)，也就是把 HBF 带宽直接砍半。
结果并没有崩掉:
1M 场景 throughput 仍不差于 HBM-only；
10M 场景 throughput per power 仍有 2.09x。
这说明 H3 的收益不要求 HBF 在所有维度都完美复制 HBM，但也侧面说明: 真正敏感的还可能是 latency，而不是带宽减半本身。

这篇 paper 真正证明了什么

已经证明: 如果未来 HBF 真能接近文中目标规格，那么 HBM + HBF 对 gigantic read-only KV 场景确实有很强的系统收益。
没有证明: 真实 HBF 器件能否同时满足带宽、功耗、热设计与控制器复杂度要求。
最大的因果链: 更大容量 -> 更大 batch -> 更高 throughput -> 更好 throughput per power。
所以这篇 paper 更像架构方向判断，不是一个已经落地的 runtime / silicon 方案。

结论

论文提出 H^3，把 HBM 和 HBF 组织成统一编址的近封装异构主存。
它抓住了一个非常适合 HBF 的场景: 巨型只读模型权重 + shared pre-computed KV cache。
在作者的模拟设定中，H3 把 10M case 的最大 batch size 提升 18.8x，throughput 提升 6.14x，throughput per power 最高 2.69x。

我的评价

优点: 问题抓得准，故事很完整，而且不是空喊 HBF 概念，而是明确给出最合适的数据形态和一个可算账的 LHB。
局限: 证据完全来自 simulator，且 HBF 规格本身就是目标值，不是实测值，离真实产品还有明显距离。
缺的实验: 我最想看 HBF latency 敏感性、真实 runtime prefetch hint、以及和 CXL / host-side tiering 的正面对比。
后续方向: 做一个近似原型，验证 framework hint + LHB + heterogeneous placement 能否在真实软件栈里协同工作。