SK 海力士联合闪迪发布 HBF 规范 0.7.0：把 512GiB 闪存搬到 xPU 旁边，缓解推理内存墙

AI 推理的内存墙有了新的应对方案。SK 海力士联合闪迪通过 OCP（开放计算项目）发布《High Bandwidth Flash (HBF) High-Level Base Die Specification》0.7.0 版规范，把大容量 NAND 闪存搬到 GPU、TPU 等 xPU 旁边，用高并行读取承接大模型的权重与 KV 缓存。这份约 130 页的规范，将 HBF 定位为介于 HBM 与 SSD 之间的一个新存储层：参考配置总容量 512GiB（约 550GB），最高聚合读取带宽目标约 3TB/s。谷歌与芯片公司 Tenstorrent 在规范的反馈与建议名单中被列为致谢提供方。

HBF 补上的是哪一块

内存墙从 CPU 时代延续至今：GPU 的性能提升快于内存响应时间，数据搬运越来越成为瓶颈。大语言模型的规模和上下文长度都在增长，对内存带宽与容量同时提出更高要求。

AI 处理涉及的数据大致分两类：一类是输入与中间结果构成的激活值，是动态变化的；另一类是定义模型的权重（参数），在推理期间基本保持不变。大模型的权重总量往往超过单颗芯片或本地缓存能容纳的规模，一部分权重只能放在机架内的 SSD 或更远的网络存储里。

这就形成一个多层数据路径：权重先从非易失性存储取到 DRAM（可能是 HBM），再缓存在处理器侧的 SRAM。某个权重第一次被访问时，要穿过好几层存储；一旦被挤出缓存后再次需要，同样的路径还得重走一遍。

HBM 已证明，通过堆叠和共封装把存储介质移到 GPU 附近可以缓解搬运瓶颈。HBF 沿用了同一思路，但介质与角色不同：HBM 用 DRAM 提供低延迟、高读写带宽的工作内存；HBF 则用容量更大的 NAND，承接原本放在 SSD 或网络存储中的、以读取为主的大规模数据，比如模型权重。OCP 规范把 HBF 正式定义为非一致性、以内存为中心的闪存设备，紧邻 GPU、TPU 或其他 xPU，目标是在处理器附近附加 TB 级额外内存容量来增强 HBM。

因此 HBF 既不取代 HBM，也不只是给 HBM 扩容，而是在高带宽内存与传统存储之间新增一层，让更大比例的模型数据在物理上靠近计算单元。半导体工程媒体引述 Expedera 首席科学家 Sharad Chole 的话，将 HBF 的目标概括为弥合"高带宽访问与高存储容量"之间的鸿沟——这比简单把它说成"更快的 SSD"或"基于闪存的 HBM"更准确。

慢闪存为什么能跑出 3TB/s

一个 HBF 设备由三部分组成：一个 Base Die、一个 NAND Core Die 堆叠，以及连接二者的 TSV 通道。

Base Die 是控制中枢。 它不是无源互连层：在跟主机 xPU 通信的同时，Base Die 管理 UCIe 协议、控制主机接口与 NAND die 之间的数据移动，还负责 NAND 命令、ECC 编解码、错误上报、传输调度、读写擦状态管理、NAND 初始化和 TSV 冗余映射。这种分工让 HBF 与"直接把闪存 die 放在处理器旁边"有本质区别——NAND 堆叠只提供容量，Base Die 才给出片上封装内存设备所需的控制、接口与可靠性机制。

xPU 通过 UCIe 3.0 连接 HBF，这是封装内 die-to-die 互连的标准，其上再用 AXI 承载读写操作。关键点在于：HBF 需要一套专用的片上封装接口，xPU 和 HBF 双方都要实现对应的链路层，而不是像 PCIe SSD 那样接上现有加速器就能用。

16 条独立通道彼此独立。 一个 HBF 堆叠最多支持 16 个主机通道，每个通道用独立的 UCIe 链路、有连续独立的本地地址空间，只能访问挂接在自己名下的 NAND 资源，不能跨通道取数据。这意味着 HBF 不是一个自动统一的闪存池，而是一个通道化架构，性能部分取决于主机怎样在多个独立资源间分布数据和请求。规范还要求：HBF 与 HBM 在同系统内使用时必须分开管理，软件要决定哪些数据属于哪个层级、如何移动与分区。

最高 3TB/s 靠并行汇聚。 规范给出三个性能等级，参考配置采用 16 颗 NAND Die、每通道 16 个 Bank、4KiB NAND 页，总容量 512GiB。约 3TB/s 的带宽目标，并不是单颗 NAND 获得了接近 HBM 的性能，而是靠 16 条主机通道加上多 Die、多 Bank、多阵列并行汇聚而成；最高配置下每条通道 64 位接口、每条 data lane 速率最高 32GT/s。因此约 3TB/s 更准确说是最高配置下的规范目标，而不是真实芯片或推理负载的实测结果。即使聚合读取带宽进入 HBM 量级，HBF 在延迟、写入、访问粒度、耐久性和内存语义上与 HBM 仍有明显差异，其核心优势是大容量 NAND 配高并行读取，而不是在所有负载下达到 DRAM 的同等表现。

不只存权重，还接 KV 缓存

模型权重是 HBF 最自然的负载：规模从数 GiB 到数百 GiB，Token 生成期间必须被读取，推理期间基本不变，很适合读取优化、高容量的 NAND 层。内存分析师 Jim Handy 对这个区别的概括是：训练不断改变模型权重，推理通常让它们保持不变。

OCP 规范把 HBF 的范围扩大到静态权重之外，应用章节覆盖单一 LLM 服务、多模型存储与切换、混合专家（MoE）、多模态模型、智能体（Agent）负载、AI 参数加载和 KV Cache 读写。单一模型可把参数分布到所有主机通道以便并行读取；多个模型则有两条路——要么把每个模型交错到所有通道、让活动模型用满聚合带宽，要么把不同模型分到专用通道组、避免争用。在 HBF 中常驻多个模型，还能省掉模型切换时从外部 SSD 重新加载整个模型的单独步骤。

更重要的扩展是 KV Cache。Prefill 预填充阶段各层计算并写入 KV Cache，进入 Decode 解码阶段后注意力模块读取先前生成的缓存并追加新内容。与推理期间基本不变的权重不同，KV Cache 在推理过程中持续增长、不断读写。规范期望主机理解 LLM 或 AI 负载的结构，安排 KV Cache 数据以优化读写。这让 HBF 不仅是一个参数加载设备，也成为推理运行时生成数据的存储目标——在长上下文与智能体负载推高内存容量需求的背景下，价值进一步放大，但也让该架构直接撞上 NAND 最弱的环节——频繁写入。

换位置换不来免维护

HBF 改变了闪存的位置、接口和内部并行性，但底层介质仍是 NAND，物理约束没有被消除。

规范使用 4KiB 的 NAND 页，支持 4KiB 对齐的突发写入；小于 4KiB 的写请求先在 Base Die 缓存，凑满一页再写。NAND 块内要求顺序写入，不支持对已编程页面的随机覆盖——要重写块里任何数据，必须整块擦除后按序重写。这些规则对大块、一次写入反复读取的权重布局相对友好，但对大小、生命周期、更新模式随时变化的动态数据是负担。

像 KV Cache 这类频繁小粒度写入的数据，规范并未声称所有 KV Cache 负载都能在 HBF 上表现良好，实际性能取决于主机如何合并小写入、布局页面、避免产生块的低效使用模式。由于权重与 KV Cache 读写模式不同，规范提示两者混在同一区域会降低耐久性和容量利用率，因此建议以通道粒度分区：均匀分区把通道均分、简化磨损管理；非均匀分区只分配足够通道存活跃权重、其余容量给 KV Cache。

数据布局不能全交给硬件自动完成。主机必须了解负载特点，估算权重与 KV Cache 各需多少容量，再决定带宽与耐久性预算。磨损均衡既可由 Base Die 完成，也可由主机通过区域重映射控制——但重映射命令不会自动迁移已有数据，主机要先停止相关访问、把数据写入新位置。数据保持与读取干扰同样需要定期处理：Base Die 负责检测上报，主机则可能需刷新数据、重试读取、隔离故障容量或等待恢复。

这就是 HBF 最核心的取舍：把大容量 NAND 移到更靠近计算的位置，同时要求硬件、固件、运行时软件与负载的数据布局做更紧密的协同。与 HBM 相比，基于 DRAM 的前者无需面对 NAND 的管理复杂度；与传统 SSD 相比，后者的地址转换、垃圾回收、磨损管理通常由 SSD 控制器包办、上层软件几乎无感知。HBF 处于两者之间：Base Die 保留了设备侧控制，但没有把 NAND 介质管理完全封装起来，主机及其软件仍需理解通道、数据布局和部分介质状态。

综合看，HBF 的定位已经清楚：它不是 HBM 的替代品，也不是一块更快的 SSD，而是在 Agent 时代容量缺口之下，用大容量闪存贴近算力、以高并行读取换带宽的一次工程尝试。它能否真正缓解推理内存墙，最终取决于主机软件能否把通道、分区、磨损管理和负载数据布局这几件事协同做好。