H³ 完全拆解：HBM 与高带宽闪存（HBF）混合架构如何驯服长上下文推理的内存墙

推理速度 ≈ HBM 带宽，这件事我们讲过#

在Hot Chips 2026 全景拆解中我们详细推导过内存墙（Memory Wall）：2017-2027 年间 AI 加速器算力大约每两年涨 3 倍，而 HBM 带宽每两年涨不到 2 倍。LLM 推理的 decode 阶段（逐 token 生成）每个 token 的核心计算是 GEMV（矩阵向量乘），权重只被读一次、没有复用，算术强度只有约 1-2 OPs/byte，正落在 Roofline 模型的 memory-bound 区。结论是：推理吞吐几乎线性正比于 HBM 带宽。这也是为什么 HBM 每提一代带宽，推理性能就跟着提一截。

但容量是另一个维度的问题#

带宽之外，还有容量。论文给出了两个触目惊心的数字，都基于 Llama 3.1 405B（FP8 精度下模型权重约 405 GB）：

• 模型权重：405B 参数的模型，每处理一个批次就要读取约 405 GB 的权重（权重只读不写）。FP8 精度下 B200 的 192 GB HBM 连权重都装不下，更别说 KV cache。
• KV 缓存：KV cache 的大小与上下文窗口长度成正比（每层每头的 K、V 都要缓存）。Llama 3.1 405B 如果支持 100 万 token 上下文，预计算的 KV cache 约需 540 GB；如果扩展到 1000 万 token，则约需 5.4 TB。

为什么 KV cache 会这么大？一个 token 的 KV 大小约为 $2 \times d \times L$（K 和 V 各一份，$d$ 是注意力维度，$L$ 是层数），405B 模型层数深、维度大，乘上百万级的 token 数就是 TB 级。GQA（分组查询注意力，Llama 3 之后的主流做法）能把 KV 压缩 4-8 倍，但面对 10M token 级别的上下文依然是杯水车薪。

这就是论文开篇指出的困境：仅用 HBM 存这些数据，需要几十块 GPU，成本和功耗同比上升。注意这里”几十块 GPU”不是算力不够，而是纯粹的内存装不下——每块 GPU 的 192 GB HBM 是硬上限，而 GPU 数量和整机功耗是软预算，两者矛盾。

CAG：一个”海量只读”的典型场景#

论文强调的场景是缓存增强生成（Cache-Augmented Generation，CAG）。这个概念来自 Hive AI 等团队 2024 年底的论文 Don’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks（发表于 WWW 2025）：对于固定知识库（公司文档、代码库、教科书），与其每次查询都做检索（RAG），不如把文档一次性塞进上下文、预计算 KV cache 并缓存起来，查询时直接复用。相比 RAG 省掉了检索延迟和检索错误，相比每个请求重新 prefill 省掉了重复计算。

CAG 与普通对话推理的关键区别在于：预计算的 KV cache 是只读的、且被多个请求共享。论文用”共享 KV 注意力”（shared-KV attention）来描述这种计算模式：所有请求共享同一份预计算 KV，注意力计算中 KV 的读取开销被大批次摊薄，因此增大批次不会明显增加延迟，却能线性提升吞吐。

读这张图要抓住三个要素：左边是共享的预计算 KV 缓存（只读，被反复读取）；中间是模型前向计算；右边是多个并发请求。虚线框出的部分说明 KV 读取这条路径只进不出——这正是 HBF 的用武之地。

结构上向 HBM 看齐，介质换成 NAND#

**HBF（High Bandwidth Flash，高带宽闪存）**的思路非常直接：HBM 能提供超高带宽，是因为用 TSV（硅通孔）把多片 DRAM 垂直堆叠起来、再通过硅中介层以极宽并行总线连到 GPU；那么把堆叠的介质从 DRAM 换成 NAND 闪存，就能同时拿到 NAND 的高容量密度和 HBM 式的高带宽。

图中可以看到 HBM 与 HBF 几乎一模一样的封装范式：底层是基底裸片（base die），上面叠着多层存储裸片，TSV 垂直贯穿。区别只在介质：DRAM 靠电容电荷存储，NAND 靠浮栅/电荷俘获存储，后者单比特成本低一个量级、密度高得多（3D NAND 已做到 200+ 层）。论文作者在 II-B 节明确指出：HBF 尚未商用，论文基于其目标设计指标（target specifications）展开研究。

HBF 的目标参数：优点和缺点一样鲜明#

论文给出的 HBF 预期指标（与 HBM3E 对比）：

这是一组”优缺点同样鲜明”的规格：容量大 16 倍、带宽相当、成本五分之一，但延迟差三个数量级、写不坏的问题变成写几次就坏、功耗还更高。所以 HBF 不可能单独作为 GPU 主存使用——这就是 H³ 混合架构存在的理由：只把 HBF 擅长的事交给它（海量只读），其他事留在 HBM。

产业动态：标准化已经跑起来了#

HBF 不是论文里的空想，产业推进比很多人以为的要快：

• 2025 年 2 月：SanDisk 首次公开 HBF 概念，定位为”带宽优化的 NAND 产品”；
• 2025 年 8 月：SanDisk 与 SK 海力士签署谅解备忘录（MoU），共同定义 HBF 技术规范、推动标准化，并在 OCP（Open Compute Project） 框架下成立联盟，Google、Tenstorrent 等公司参与；
• 2025 年 12 月前后：联盟发布首批 HBF 规范，覆盖每封装最高 512 GB 容量、两种堆叠配置、0.4-3 Tb/s 三档带宽等级，互连采用 UCIe（Universal Chiplet Interconnect Express，通用芯粒互连标准）；
• 2025 年 10 月 OCP 全球峰会：SK 海力士发布面向 AI 的 NAND 产品家族”AIN”（AIN P 性能型 / AIN B 带宽型 / AIN D 密度型），其中 AIN B 系列即基于 HBF 技术；
• 时间表：样品预计 2026 年下半年，首批搭载 HBF 的推理系统预计 2027 年初；第一代 HBF 预计采用 16 层 NAND 堆叠，量产可能在 2028 年后。

而三星虽然也在自行开展 HBF 概念设计（成立了专门团队），但没有加入 SanDisk-SK 海力士的开放联盟，选择单干。美光目前没有公开 HBF 计划。HBF 被 TrendForce 等机构预测为 2030 年约 120 亿美元的市场（同期 HBM 约 1170 亿美元），定位是 HBM 的补充而非替代。

设计空间：HBM 和 HBF 在物理上怎么摆#

混合架构的第一个问题是物理布局：HBM 和 HBF 都放哪里？论文讨论了两种方案。

方案 A：把 HBM 和 HBF 并列放在 GPU 引脚区（pin field）旁边。 好处是两者都能直接以最高带宽连接 GPU。坏处是 GPU 裸片的引脚区面积有限——现代 GPU 的引脚区基本被 HBM 占满（B200 是 8 个 HBM3E cube），再放 HBF 就得挤占 HBM 的数量，等于用带宽换容量，得不偿失。

方案 B（论文的选择）：菊花链（daisy-chain）连接。 GPU 只直接连 HBM；HBF 挂在 HBM 后面，通过 HBM 的基底裸片中继访问。这样 GPU 的引脚区一个不多占，HBM 数量不变，HBF 的带宽虽然要经过 HBM 基底裸片中转，但只要中继路径做得足够宽，瓶颈就不在这里。

H³ 的三层结构（论文图 3 详解）#

这张图是全文的核心，三个子图分别回答三个问题：

（a）怎么连的？ 自上而下是 GPU → 硅中介层 → HBM 基底裸片（含 HBM 堆叠）→ 硅中介层 → HBF 基底裸片（含 HBF 堆叠）。注意 HBF 不直接连 GPU，而是”挂在 HBM 后面”——这就是菊花链。论文假设 GPU 与 HBM 基底裸片之间、HBM 基底裸片与 HBF 基底裸片之间都用裸片间（die-to-die，D2D）接口连接，且带宽等于基底裸片与核心裸片之间的带宽，也就是说中继路径不会成为瓶颈。

（b）访问怎么分流？ HBM 基底裸片内部集成了地址译码器（address decoder）和路由器（router）：GPU 发来的访存请求先到 HBM 基底裸片，译码器根据地址判断目标是 HBM 还是 HBF，路由器把请求送往对应路径。HBM 和 HBF 的控制器各放在自己的基底裸片上（论文注明：可根据芯片面积情况调整）。图中 HBM 基底裸片里还有一块延迟隐藏缓冲（Latency Hiding Buffer，LHB），这是针对 HBF 长延迟的关键组件，下一节单独讲。

（c）软件视角是什么样？ 对 GPU 和主机来说，HBM 与 HBF 是同一个统一地址空间里的两个内存区域——主机无需感知两者物理上的差异，只需要把数据分配到哪个区域。这个设计把”硬件上有两种介质”封装成了”软件上一种内存、两种 placement 策略”，大幅降低了集成难度。

为什么菊花链是对的：三个工程理由#

• 不牺牲 HBM 数量：方案 A 的致命伤是引脚区零和博弈，方案 B 完全不占额外引脚；
• 利用”带宽受限”的推理特征：LLM 推理是 memory-bound，访存是持续流水线式的，菊花链增加的是跳延迟（hop latency）而非带宽损失，延迟可以被流水线掩盖（下一节详述）；
• 复用成熟 HBM 基础设施：HBM 基底裸片在 HBM4 之后本来就要集成逻辑（控制器、缓存），把 LHB 和路由器做进去是顺水推舟。

数据放置策略：只读的进 HBF，动态的留 HBM#

架构搭好后，数据怎么放？论文的规则只有一条：只读数据放 HBF，其余放 HBM。

图中上层的 HBM 与下层的 HBF 各司其职：HBF 负责”喂”权重和共享 KV 这两条大流，HBM 负责快进快出的动态数据。论文指出，访问 HBF 时增加的跳延迟之所以可接受，是因为 LLM 推理受内存带宽限制——数据持续排队流入，偶尔的跳延迟被队列吸收，不会暴露为气泡。

三个”为什么 LLM 推理是 HBF 的理想场景”#

1. 为什么跳延迟可以隐藏？ 因为推理是带宽受限而非延迟受限：只要数据以足够快的速度持续供应，单个请求多等 20μs 不影响整体吞吐。这和后端排队理论是一个道理——吞吐看平均服务率，不看单个请求的等待。
2. 为什么确定性访问模式重要？ LLM 推理的数据访问是确定性的、顺序的：第 $i$ 层只用第 $i$ 层的权重和 KV，前一层不完成下一层不开始，且每个张量的读取时机可以精确预测。论文认为，配合深度学习框架的支持，可以做到张量级（tensor-level）调度：某个算子需要同时用到 HBM 和 HBF 里的数据时，因为需要哪些张量是事先知道的，HBM 与 HBF 之间的争用（contention）可以提前安排、保持可控。
3. 为什么只读是加分项？ NAND 最怕写。只读负载意味着垃圾回收（GC）和磨损均衡（wear-leveling）几乎不触发——这两个是 SSD 延迟抖动的最大来源，在只读场景下开销趋近于零。反过来，如果 KV 缓存要频繁更新（普通对话场景），HBF 的写耐久短板会直接暴露。

这套组合拳的结果是：H³ 用相同的 GPU 数量装下了 16 倍的内存，批次可以开得更大，吞吐随之提升，单位 token 的成本随之下降。

为什么需要它：三个数量级的差距#

HBM 的 DRAM 访问延迟约 10-20 纳秒；HBF 的 NAND 访问延迟按论文假设约 20 微秒（基于公开的 SLC NAND 读取延迟数据）。两者相差 1000 倍。如果没有中间层，GPU 每次访问 HBF 都要”干等”20μs——即便带宽够，延迟抖动也会让流水线频繁断流。

论文的方案是延迟隐藏缓冲（Latency Hiding Buffer，LHB）：一块集成在 HBM 基底裸片（或 HBF 基底裸片）里的预取缓冲区（prefetch buffer）。LLM 推理的确定性访问模式是它的底气：下一层需要哪些权重、哪些 KV，是可以提前精确预测的，于是可以提前把数据从 HBF 持续搬进 LHB，GPU 只从 LHB 读，NAND 的 20μs 延迟就”藏”在了预取流水线里，对 GPU 不可见。

容量公式：双缓冲推导#

LHB 要多大？论文给出了一个干净的计算：为了不间断地以满带宽向 GPU 供数，采用双缓冲（double buffering）——一块缓冲在给 GPU 供数时，另一块正在从 HBF 预取下一批：

逐项解释：$\text{BW}_{\text{HBF}}$ 是 HBF 单 Cube 的带宽（论文假设 1 TB/s，与 HBM3E 单 Cube 相同），$\text{Latency}_{\text{HBF}}$ 是 HBF 的访问延迟（假设 20 μs）。单个缓冲要装下”延迟期间流过的数据量”，即带宽 × 延迟 = 1 TB/s × 20 μs = 20 MB；双缓冲意味着任意时刻一块在读、一块在写，所以总量 ×2，得 40 MB。

代入数值：

论文同时说明：20 μs 这个数字取的是当前商用 NAND 的读延迟，随着 HBF 商用化预计还会改善，届时 LHB 需求会低于 40 MB。

面积账：40 MB SRAM 占基底裸片的 6.7%#

40 MB 的 SRAM 不是小数目——SRAM 是六管单元（6T），单位比特面积远大于 DRAM 和 NAND。论文按最先进的 3 nm SRAM 工艺估算：3 nm SRAM 比特密度约 0.021 μm²/bit，40 MB（按十进制算 4000 万字节）的 SRAM 核心面积：

加上约 20% 的额外电路（译码、控制逻辑、接口），总面积约 8.06 mm²。作为参照，当前商用 HBM 基底裸片面积约 121 mm²，8.06 mm² 只占约 6.7%——考虑到基底裸片的可用空间（且未来 HBM4 及定制 HBM 的基底裸片会更大），这个开销处于可接受范围。

软件配合：预取提示#

LHB 不是硬件单方面就能工作的。论文明确指出，需要修改深度学习框架以提供预取提示（prefetch hints）：框架在调度某个算子时，顺带告诉硬件”接下来要读 HBF 里的哪块张量”。好在预取是确定性的（模式可预测）、粒度是粗粒度的张量级（不是细碎缓存行），论文预计预取开销很小。

但这里藏着一个论文没有明说的隐含假设：LHB 的命中率必须足够高——社区分析认为这隐含要求 80% 以上。预取对了，20μs 被隐藏；预取错了（命中率掉下来），GPU 就要实打实等一次 NAND 访问，性能断崖式下跌。而预取是否正确，完全取决于工作负载是否真的”确定性、顺序性”——这是后文批判性分析的关键点之一。

方法：基于解析模型的仿真器#

仿真器基于此前研究中已验证的解析模型（validated analytical model），从三个时间分量估算性能：

• 计算时间：由 LLM 模型运算量（FLOPs）与 GPU 峰值算力估算；
• 数据传输时间：由模型大小、KV cache 大小与器件带宽估算，计算时考虑**张量并行（TP）与数据并行（DP）**下的数据划分与复制；
• GPU 间通信时间：假设张量并行采用**环形全规约（ring all-reduce）**计算。

注意这套模型的关键取舍：它把内存系统抽象成了”容量 + 带宽”，对延迟的处理是”假设可被隐藏”——所以仿真结果天然偏向验证 H³ 的论点，论文自己也在局限中承认这一点（社区分析称之为”理想化场景”）。

配置：B200 + 8 个 HBM3E + 8 个 HBF#

两个细节值得注意。第一，共享 KV 占了系统容量的大头（10M 场景 84%）——这正是 H³ 发挥威力的区间，也是论文论证的”海量只读”特征的量化体现。第二，10M 场景要 32 块 GPU 打底，意味着 HBM-only 方案下光”装下 KV cache”就要 32 块 GPU，H³ 则把这 32 块的负担压到 2 块——这是后面”32 → 2”奇迹的由来。

结果一：批次大小最高 18.8 倍#

把共享 KV 移进 HBF 后，HBM 腾出了大量容量，同样的 GPU 数就能开更大的批次。

读图要点：横轴是 GPU 数量，纵轴是能承载的最大批次大小（对数刻度）。纯 HBM 方案在 GPU 数量不足时会直接”装不下”（图中的 × 号）——1M 场景至少要 8 块、10M 场景至少要 32 块；而 H³ 曲线从 1 块 GPU 就存在。论文特别指出两个观察：

1. 10M 场景下，H³ 用 2 块 GPU 就能跑，批次最大为纯 HBM 方案的 18.8 倍；
2. 1M 场景下，H³ 用 1 块 GPU 就能跑（纯 HBM 需要 8 块），批次最大 2.6 倍。

“虽然性能会有所下降（毕竟 GPU 变少了），但可以以极低的成本处理长序列”——这是论文认为 H³ 在成本敏感场景的核心价值。

结果二：吞吐量 1.25 倍 / 6.14 倍#

更大的批次直接转化为吞吐。论文用 TPS/request（每秒生成的 token 数）作为吞吐指标，主要由批次大小与执行时间决定。

• 1M 场景：吞吐为纯 HBM 方案的 1.25 倍；
• 10M 场景：吞吐为纯 HBM 方案的 6.14 倍；
• 论文预测：序列越长，差距越大——因为 KV cache 容量占比越高（10M 场景 84% vs 1M 场景 35%），HBF 的大容量越能转化为批次优势。

结果三：每瓦吞吐最高 2.69 倍#

吞吐上去了，但 HBF 的功耗更高（单堆栈 160 W vs HBM3E 单 cube 40 W），会不会”省了 GPU、费了电”？论文把吞吐除以系统总 TDP（GPU 680 W + 各内存器件功耗）得到每瓦吞吐：

• 尽管 H³ 系统总功耗更高（8 个 HBF 堆栈多出约 8 × 120 W = 960 W），每瓦吞吐最高仍为纯 HBM 方案的 2.69 倍；
• 账是这么算的：10M 场景吞吐 6.14 倍，功耗只增加了约 1.2-1.4 倍（32 块 GPU 变 2 块，GPU 功耗大幅下降），吞吐增幅远超功耗增幅，所以每瓦吞吐大涨。

结果四：HBF 带宽减半的敏感性分析#

HBF 产品化后实际带宽可能达不到目标值，论文因此测试了HBF 带宽减半（4 TB/s）的影响：

• 1M 场景：吞吐仍优于纯 HBM 方案；
• 10M 场景：每瓦吞吐仍有纯 HBM 方案的 2.09 倍。

论文给出的解释很有洞察：H³ 并非所有数据都放在 HBF 里（动态 KV 和中间数据在 HBM），所以整体性能不会随 HBF 带宽成比例下降。换句话说，混合架构自带”带宽降级韧性”。

只读假设：在真实生产中能撑住吗？#

论文把模型权重和共享预计算 KV cache 都归为”只读”，但生产环境里”只读”是相对的：

• 模型权重：生产系统普遍使用 LoRA/QLoRA 等参数高效微调（PEFT），适配器权重小但更新频繁；A/B 测试与灰度发布意味着同时服务多个模型版本；INT8/FP8/FP16 动态切换是常见优化手段。这些都会让”权重只读”打折扣。模型切换尤其麻烦——HBF 里存着几百 GB 的旧权重，换版本意味着大规模写入，撞上 NAND 写耐久和 20μs 写延迟的枪口。
• KV 缓存：CAG 确实是论文引用文献中提出的有效用例，但它只覆盖 LLM 推理的一小部分——ChatGPT、Claude 这类通用对话服务每请求都生成新 KV cache，动态写入为主，与 HBF 的定位正好相冲；共享文档更新时缓存如何刷新（写！）；管理几百 GB 共享缓存池需要 LRU 等淘汰策略，淘汰本身就是写操作。

NAND 的物理极限：1000 倍的延迟差距不是架构能抹平的#

即使”只读”假设成立，还有更根本的问题：DRAM 和 NAND 的延迟差异来自物理机制，不是缓存技巧能消除的。

• DRAM 单元：读写在电容中存取电荷，本质是电开关操作，10-20 ns；
• NAND 单元：通过隧穿效应把电子移入/移出浮栅，需要高电压、长耗时，读取 25-100 μs（写入更慢）。

前车之鉴是英特尔傲腾（Optane / 3D XPoint）：延迟约 100 ns，已经比 NAND 快两个数量级，依然没能替代 DRAM——因为与 DRAM 的 10-20 ns 相比，100 ns 的差距在内存层级里就足以致命。HBF 的 20 μs 比傲腾又慢两个数量级，靠 40 MB SRAM 缓冲”缓解”可以，“解决”不可能：一旦 LHB 未命中，20 μs 的访问延迟会完整暴露给 GPU，而推理流水线在 1 TB/s 的带宽下 20 μs 能流过的数据量是 20 MB——正好是一个缓冲区的容量，一次未命中就可能让整个流水线断流一拍。

“廉价 NAND”陷阱：系统成本的真实构成#

HBF 的支持者说”NAND 晶圆成本只有 HBM 的五分之一”，这话单看芯片没错，但 HBF 不是一片裸的 NAND。把 HBF 做成能用的内存系统，每一项附加组件都在侵蚀成本优势：

社区分析的结论很直白：从廉价材料出发没错，但所有把它变成可用产品的环节都会推高总成本。HBF 要证明经济性，不能只比每 GB 单价，要比真实工作负载下的总拥有成本（TCO）。另一个容易被忽略的点是初始良率：HBM 也是经过几代改进才把良率拉起来的，HBF 采用更复杂的异构堆叠，早期良率大概率更低——良率减半，成本翻倍。

替代路线：HBF 面对的竞争#

在 HBF 从样品走向量产（2026-2027）的窗口里，其他技术正在快速成熟：

• HBM4（2026 年量产）：每堆栈带宽 1.5 TB/s（比 HBM3E 提升 50%）、容量 32-48 GB，单 GPU 有望达到 384 GB（8 × 48 GB）。HBM4 的容量优势会压缩 HBF 的”容量救星”叙事空间，而且延迟、可靠性、生态系统全部继承已验证的 HBM 路线。
• HBM-PIM（三星）：在内存内部执行向量加、激活等简单运算，减少数据搬运，提升有效带宽——比 HBF 更激进，但依托现有 HBM 生态。
• CXL 内存池化：CXL 2.0/3.0 通过 PCIe 连接 GPU/CPU 与内存池，容量可扩展到 TB 级，x16 链路带宽 256 GB/s、延迟 200-400 ns。带宽低于 HBF，但可池化、按需分配、行业标准。我们在FPGA 加速器完全拆解（二）里拆解过的 CXL-SpecKV（FPGA 2026）正是用 CXL 内存池放 KV cache 的路线——与 H³ 目标高度重合，路径完全不同。
• 软件优化：GQA 把 KV 缩小 4-8 倍（Llama 3 已采用）；FP8/INT4 量化把内存占用减半以上；vLLM 的 PagedAttention（本站有完全拆解）和连续批处理把有限内存的利用率拉到极限；FlashAttention 系列优化 KV 访问模式。这些都不需要新硬件。

等到 HBF 真正量产（2028 年后），模型侧的 KV 压缩与量化可能已经让”内存不够”的痛感减轻了一大截。这是 HBF 最大的时间风险：解决需求的速度可能赶不上需求本身被软件抹平的速度。

产业格局：为什么三星单干、美光缺席、NVIDIA 不动#

把视野拉高，会发现 HBF 的推进节奏其实由存储厂商的商业战略主导：HBM 让存储厂商从”标准品供应商”变成了”与 GPU 深度绑定的系统组件供应商”，而 HBF 是这一趋势的延伸——它不只是卖内存，而是提出重新设计整个内存层级的平台方案（NAND + SRAM + DRAM + 控制器 + 接口），让存储厂商能在系统架构层面与客户协作、把影响力延伸到软件栈、积累 IP 壁垒。即便 HBF 最终不能取代 HBM，异构堆叠技术、NAND 内存化经验、与 GPU 厂商的系统级协作经验本身就有战略价值。这也是 SK 海力士（DRAM/HBM 强）与 SanDisk（NAND 强）联手、而三星选择独立路线的深层原因。