HBM 已经证明，通过堆叠和共封装把存储介质迁移至 GPU 附近，可以缓解 AI 计算中的数据搬运瓶颈。

现在，SK 海力士联合闪迪，将类似的思路正式应用到 NAND 上，通过 HBF 将大容量闪存放到包括 GPU 在内的各类 xPU 旁，以缓解 AI 推理内存墙问题。

近日，双方通过 OCP 发布《High Bandwidth Flash（HBF）High-Level Base Die Specification, Version 0.7.0》。谷歌和 Tenstorrent 在致谢中被列为规范的反馈与建议提供方。

这份约 130 页的规范，首次明确了 HBF 的位置、边界与代价：

介于 HBM 与 SSD 之间，HBF 是紧邻 xPU、由 Base Die 和主机软件共同管理的大容量闪存。

应用范围从静态模型权重进一步延伸至 KV Cache、多模型、MoE 和 Agent 工作负载。

NAND 的写入、耐久性和管理上的物理约束并未被消除。这些约束带来的复杂性，最终转移到了 Base Die 和加速器的软件栈上。

在不改变规范原意的基础上，雷峰网 ( 公众号：雷峰网 ) 对此进行编译和整理，重点解读 HBF 的系统定位、高带宽缘起、推理应用场景以及 NAND 介质带来的工程约束。

01

不是取代或者给 HBM 扩容，

HBF 到底补上哪块？

内存墙问题从 CPU 时代一直延续到当今以数据为中心的计算系统中。当 GPU 的性能提升速度持续快于内存响应时间，数据搬运也就越来越成为性能瓶颈。

与此同时，大语言模型规模和上下文长度的增长，对更高的内存带宽和大幅增加的内存容量都提出了需求。

AI 处理所涉及的数据大致可分为两类：一类包括模型输入和连续处理层生成的中间结果，这些数据是动态的，通常被称为激活值；另一类包括定义模型的权重（参数）。

在推理运行期间，模型权重一般保持不变。然而，它们的总量可能远超单颗处理芯片或其本地缓存所能容纳的规模。

对于足够大的模型来说，部分权重可能存储在机架内的 SSD 上，或位于距离处理器更远的网络附加存储中。

这就形成了一条多层级的数据路径：非易失性存储提供长期容量，计算所需的权重被带入DRAM（可能是 HBM），然后缓存在处理器侧的SRAM中。

因此，一个权重第一次被访问时，数据可能要穿过好几层存储层级才能到达处理器。如果这个权重后来被挤出缓存，而之后又需要用到它，那同样的路径就得再走一遍。

HBF 背后的构想与催生 HBM 的思路相似：通过堆叠和共封装，将存储介质移近计算单元。

但二者使用的介质和承担的角色不同。HBM 以 DRAM 提供低延迟、高读写带宽的工作内存；HBF 则试图利用容量更大的 NAND，在保持较高聚合读取带宽的同时，承接部分原本存放在 SSD 或网络存储中的大规模、以读取为主的数据，例如模型权重。

在部分系统设计中，预先存入 HBF 的模型权重可以绕过传统的 DRAM 暂存环节，直接向处理器侧缓存传输。这样的设计尽管会使缓存和内存管理变得复杂，但的确省掉一部分从外部存储到 DRAM 的传输开销。

正如 Expedera 首席科学家兼联合创始人 Sharad Chole 所描述的，HBF 旨在弥合 " 高带宽访问与高存储容量 " 之间的鸿沟。这个定位比简单地将 HBF 描述为更快的 SSD 或基于闪存的 HBM 更为精确。

HBF 将模型权重放入处理器封装内的一种概念架构

图源 Bryon Moyer / Semiconductor Engineering

而 OCP 规范将 HBF 正式定义为一个非一致性的、以内存为中心的闪存设备，紧邻 GPU、TPU 或其他 xPU。其目的是通过在处理器附近附加 TB 级的额外内存容量来增强 HBM。

因此，HBF 既不是直接取代了 HBM，也不是简单为后者增加容量。它在高带宽内存与传统存储之间增加了另一个内存层级，使更大比例的模型数据在物理上保持更靠近计算单元。

02

慢闪存，如何跑出 3TB/s 的高带宽？

Base Die 是真正的控制中枢

一个 HBF 设备由三个主要元素构成：

Base Die 不只是一个无源互连层。在与主机 xPU 保持通信的同时，Base Die 管理 UCIe 协议并控制主机接口与 NAND die 之间的数据移动。

此外，它还负责处理主机和 NAND 命令、ECC 编码和解码、错误报告、传输调度、读 / 写 / 擦除状态、NAND 初始化和 TSV 冗余映射。

这种分工让 HBF 与 " 直接把闪存 die 放在处理器旁边 " 有了本质区别：NAND 堆叠提供容量，而 Base Die 为堆叠提供了作为片上封装内存设备所需的控制、接口和可靠性机制。

HBF Base Die、NAND Core Die 堆叠与 xPU 连接

图源 OCP 规范

xPU 通过 UCIe 3.0 跟 HBF 连接，这是一种用于封装内 die-to-die 互连的标准。在 UCIe（Universal Chiplet Interconnect Express）接口之上，用AXI作为通信协议。简单来说，UCIe 负责物理层和链路层的基础，AXI 则承载主机和 HBF 之间的读写操作。

规范里对 UCIe 协议层、Flit 格式和 AXI 通道有非常详细的描述。但如果只关心 HBF 在系统里的角色，关键在于它需要一套专用的片上封装接口，xPU 和 HBF 两边都得有对应的链路层实现，而不是像 PCIe SSD 那样，随便接到现有加速器上就能用的。

16 条独立通道彼此独立

一个 HBF 堆叠最多可支持 16 个主机通道。每个通道使用独立的 UCIe 链路并提供对其自身 NAND 资源的访问。通过一个通道发出的请求不能访问连接到另一个通道的数据。

每个通道也有自己连续的本地地址空间。Base Die 将该本地地址空间映射到物理 NAND 存储体、die 和块上。在系统层面，主机软件负责将主机的全局地址映射到可用 HBF 通道的本地地址空间上。

其结果并非一个单一的、自动统一的闪存池，而是一种通道化架构，其性能部分取决于主机如何在多个独立资源之间分布数据和请求。

这种区别很重要，因为规范还要求HBF 和 HBM 在同一个系统中使用时必须分开管理。HBF 不会自动成为 HBM 一致性地址空间的一部分。软件必须决定哪些数据属于哪个内存层级，以及数据应如何移动、分区和访问。

靠多层并行达到最高 3TB/s

规范定义了三个性能等级：

规范给出的参考配置采用 16 颗 NAND Die、每通道 16 个 Bank 和 4KiB NAND 页，总容量为 512GiB（GiB 按二进制计量，GB 按十进制计量，约合 550 GB），并允许更高容量的 HBF 堆叠。

最高约 3TB/s 的带宽目标，并不是因为单颗 NAND 获得了接近 HBM 的性能，而是通过 16 条主机通道，以及多 Die、多 Bank 和多阵列并行汇聚而成。最高配置下，每条通道采用 64 位接口，每条数据 lane 速率最高为 32GT/s。

要真正利用这些并行资源，数据需要分布在足够多的通道、Die 和 Bank 中，主机也必须维持足够的请求并发性，由 Base Die 完成相应调度。

因此，约 3TB/s 更准确地说是最高配置下的规范目标，而非真实芯片或推理负载的实测结果。

即使聚合读取带宽进入 HBM 量级，HBF 也不等同于 HBM。二者在延迟、写入能力、访问粒度、耐久性和内存语义上仍有明显差异。

HBF 的核心优势，是以大容量 NAND 配合高并行读取，而不是在所有工作负载下获得与 DRAM 相同的表现。

03

从多模型到动态缓存，HBF 不只存权重

模型权重仍然是 HBF 最自然的工作负载。

它们的范围可从数 GiB 达到数十乃至数百 GiB，必须在 Token 生成期间被获取，且在推理期间通常保持不变。这使得它们比必须持续重写的数据更适合读取优化、高容量的 NAND 层级。

正如内存分析师 Jim Handy 所总结的区别：" 训练不断改变模型权重，而推理通常使它们保持不变 "。

然而，OCP 规范赋予 HBF 的范围超越了静态权重存储。其应用章节包括单一 LLM 服务、存储和切换多个 LLM、混合专家模型、多模态模型、智能体工作负载、AI 参数加载和 KV Cache 读写。

对于单一模型，规范描述了将模型参数分布到所有主机通道上，以便它们可以被并行读取。对于多个模型，它提供了两种可能的布局：

将每个模型交错在所有通道上，使活动模型能够使用完整的聚合带宽。

将不同模型分配到专用的通道组，允许多个模型被访问而不会争用相同的通道。

在 HBF 中保持多个模型，也可以减少当活动模型切换时从外部 SSD 重新加载整个模型的需求。虽然这并不意味着模型切换没有延迟，但它可以消除传统部署中单独的 SSD 到加速器加载步骤。

MoE、多模态和智能体工作负载，在 HBF 上的数据放置可以沿用多模型案例的两种策略：要么把数据打散到所有通道上以追求最大带宽，要么把数据放在指定通道里优先考虑容量分配和工作负载隔离。

更重要的扩展，是KV Cache。

在 Prefill 预填充阶段，模型各层会计算并写入 KV Cache；进入 Decode（解码）阶段后，注意力模块（Attention）读取先前生成的 KV Cache，并在生成后续 Token 时添加新的缓存内容。

因此，与推理期间基本保持不变的模型权重相比，KV Cache 会在推理过程中持续增长，并不断发生读写。

规范期望主机理解 LLM 或 AI 工作负载的结构，并安排 KV Cache 数据以优化读写性能。因此，HBF 不仅被定义为一个参数加载设备，还被定义为推理运行时生成数据的一个可能的存储目标。

这扩大了 HBF 的潜在价值，尤其是在更长的上下文和智能体工作负载增加内存容量需求的情况下。但它也使该架构直接接触到 NAND 最弱的特性——频繁写入。

04

权重和缓存分开存，HBF 就能绕开闪存难题吗？

尽管 HBF 改变了闪存的位置、接口和内部并行性，其底层介质仍然是 NAND。

NAND 闪存的物理结构决定了它的读写方式。闪存芯片内部被划分为若干块（block），每个块又进一步分为若干页（page）。

规范中使用的是 4 KiB 大小的 NAND 页，并支持 4 KiB 对齐的突发写入。小于 4 KiB 的写入请求不会立即写入 NAND Core Die，而是先在 Base Die 中缓存，凑满一个完整的 4 KiB 页面后再写入。

在 NAND 块内部，HBF 要求顺序写入。它不支持对已编程页面的直接随机覆盖写入。要重写一个块里的任何数据，不能直接覆盖，必须先把整个块擦除，然后从头开始，按规定的页面顺序重新写入一遍。

这些规则与大型、预定的模型权重布局相对兼容——权重是一次写入、反复读取的数据，写入时按顺序以完整页面写入即可。

但对于动态生成的数据来说却是一件困难的事，其大小、生命周期和更新模式在推理期间随时可能变化。

像 KV Cache 这类需要频繁进行小粒度写入的数据，规范并未声称所有 KV Cache 工作负载都能在 HBF 上表现良好，实际性能将取决于主机如何组合小写入、布局 KV Cache 页面，并避免产生 NAND 块低效使用的模式。

因为模型权重和 KV Cache 具有不同的读写模式，规范也指出，将两者混合在同一区域可能会降低耐久性和容量利用率。因此，它建议以通道粒度对 HBF 进行分区，并提供两种示例策略：

均匀分区将通道均匀划分，简化了主机控制的磨损管理。

非均匀分区仅分配足够的通道来存储活动模型权重，并将剩余容量分配给 KV Cache。

模型权重与 KV Cache 之间的通道分区

这也说明 HBF 的数据布局不能完全交给硬件自动完成。主机必须了解工作负载的特点，估算权重和 KV Cache 各需要多少容量，再决定给两边各分配多少带宽和耐久性预算。

由主机参与管理的方式，还延伸到 KV Cache 之外。

由于各条 HBF 通道拥有独立的地址空间，主机软件还需要将全局地址映射到不同通道，决定数据如何交错，并分别管理 HBF 与 HBM。

对 NAND 介质本身的维护，也并非全部封装在 Base Die 内部。磨损均衡既可以由Base Die完成，也可以由主机通过区域重映射进行控制。

主机可以调整逻辑地址与物理位置之间的映射，使编程和擦除次数更均匀地分布，但重映射命令不会自动迁移已有数据。主机需要先停止相关访问，再将数据重新写入新的位置。

数据保持和读取干扰同样需要定期处理。Base Die 负责检测并上报 NAND 状态，主机则可能需要刷新数据、重试读取、隔离故障容量，或等待设备完成恢复操作。

不过，HBF 并未将传统 SSD 控制器承担的全部功能转移给主机软件。Base Die 仍负责 NAND 命令、ECC、请求调度和错误检测，但数据布局、部分磨损管理和异常恢复需要主机共同参与。

因此，HBF 的职责划分也不同于 HBM 和传统 SSD。基于 DRAM 的前者，无需面对 NAND 存在的管理复杂度；后者虽然同样使用 NAND，但地址转换、垃圾回收和磨损管理通常由 SSD 控制器完成，上层软件基本感知不到这些管理过程。

HBF 则处于另一种状态：Base Die 保留了设备侧控制能力，但没有将所有 NAND 介质管理完全封装起来。为了充分利用其容量和并行带宽，xPU 主机及其软件仍需理解通道、数据布局和部分介质状态。

这正是 HBF 最核心的取舍：它把大容量 NAND 移到更靠近计算的位置，同时也要求硬件、固件、运行时软件与工作负载的数据布局进行更紧密的协同。

作者长期关注 AI 芯片上下游，更多信息可添加微信  Evelynn7778  交流。

▼