HBF 不能只看带宽:KV 卸载可能反而拖慢推理

2026 年 8 月 12 日，arXiv 出现了一篇标题很猛的论文：HBF Sucks!。作者保留 Mooncake 风格的 KV 卸载路径，把后端 SSD 换成带宽更高、访问更近的 HBF。

结果却是系统变慢。论文作者报告，完整 HBF-1/HBF-2 组织的平均端到端时延上升 2–5.5 倍，最大 SLO goodput，也就是满足服务级别目标的有效吞吐，下降 1.1–2.7 倍。这些数字来自扩展 TokenSim 对生产来源轨迹的重放，不是 HBF 实物或客户商用部署的测量。

但这个反直觉结果仍然重要。它提醒业界，存储层的价值不能只看介质带宽。真正要算的是一笔系统账：读 I/O 在不在关键路径，每次写入能不能被后续读取偿还，标称带宽能不能在功耗和寿命预算内持续交付。

一场不对称的比较

HBF，即高带宽闪存，希望用 NAND 容量配合更宽的封装级接口，填补 HBM 和 SSD 之间的层级空缺。2026 年 8 月，SK hynix 与 Sandisk 通过 OCP 公开首份 HBF 标准规范，厂商给出最高 512GB 容量和约 0.4–3.0TB/s 带宽分级。这是标准化与路线图进展，还不是大规模商用证据。

论文测的也不是一颗独立 HBF 芯片对一块 SSD。作者比较的是完整系统组织：SSD 基线保留 GPU 附近的 HBM；HBF-1 用 GDDR7 作为近端层，HBF-2 虽然恢复 HBM，仍要让出部分封装空间和近端容量给 HBF。

以 H100 配置为例，SSD 基线的每卡近端层是 96GB HBM、3.0TB/s；HBF-2 变成 48GB HBM3e、1.5TB/s，HBF-1 则是 48GB GDDR7、1.344TB/s。HBF 加速了远端存储，但近端可同时承载的活跃请求变少，排队和重算压力随之上升。

所以，“HBF 比 SSD 慢”会误读论文。作者实际测的是一笔系统账：Mooncake 风格运行时获得了更快的闪存层，完整 HBF-1/HBF-2 组织却付出了更大的近端机会成本，结果为负。

第一问：读 I/O 真在卡住请求吗

存储加速只能优化暴露在关键路径上的 I/O。如果二级存储读取已经被预取、异步化或其他计算遮蔽，再快的媒介也只能改善很小一段时间。

论文把 HBF 读/写时延从 30/300 微秒扫到 8/80 微秒，介质延迟改善 3.75 倍。平均端到端时延只变化 0.75% 和 0.88%。作者据此反推，暴露在关键路径上的二级存储 I/O 约占 1%。

有一个对比很典型。在 GLM-5.2、traceA、B200、32 QPS 设置下，HBF-1 的累计连接器服务时间比 SSD 低 3.2 倍，平均每请求端到端时延却高 2.6 倍。连接器明明快了，队列却因近端容量下降而更不稳定。

这一问应验收“关键路径 I/O 暴露比例”（exposed I/O fraction）。峰值 GB/s 只是设备上限；没有暴露比例，就无法估算能有多少设备收益真正传到请求时延。

第二问：写进去的 KV，会被读回几次

NAND 的写入成本在对象进入 HBF 时就已经发生，价值要靠后续读取来偿还。稳定的模型权重、大量请求共用的前缀 KV，一次写入可以换来多次读取。私有 decode KV，也就是解码阶段为单个请求生成的 KV，生命周期短得多，往往会随请求结束而失去价值。

作者重放了四组完整的 2 小时轨迹。结果是，闪存层的写入量始终高于读取量，写/读比介于 1.14 和 4.90，有效读/写比仅为 0.20–0.88。同时，前缀命中率还有 38%–53%。

这两组数看起来矛盾，其实正好描述了多级缓存的分工。复用高度集中在少数热块，热块留在 HBM 或 GDDR 近端层，被挤到 HBF 的是大量低复用长尾。运行时正在正确地保护热数据，但它同时给 HBF 造出了一条写密集、读稀少的冷流。

评估 HBF 放置策略时，应该把“KV cache”继续拆开。权重、共享前缀、会话历史、私有 decode KV 是不同对象，寿命、复用和写入频率完全不同。一个“KV 命中率”无法替代对象级的读写账本。

第三问：峰值带宽能持续多久

高带宽 NAND 仍然是 NAND。写入比读取更慢、更耗能，存储单元还有有限的编程/擦除预算。堆叠之后，散热路径和局部热点又会改变能够持续交付的带宽。

论文用 3D-ICE 搭了一个 16-Hi TLC HBF 堆叠模型。在它的假设下，单堆叠在 202.27GB/s、53.72W 时触及 80℃ 温度上限，低于接口峰值。作者进一步模拟关闭高温闪存平面、把写入转向较冷区域的降频策略。

这不是一颗真实 HBF 在实验室里跑到 80℃ 的测温结果。HBF 尚未成为可公开采购的产品，未来封装布线、控制器和散热设计都可能改变边界。它证明的是评估方法：写密集负载下，标称带宽必须经过热稳态验证。

寿命账更直接。作者将轨迹重放的 HBF 写入量归一化到 48–140TB/日；在一个对 HBF 有利、写放大为 1 的 TLC 假设下，五年目标预算为 21.7TB/日。容量匹配的四块 KIOXIA CM7-V SSD 池按 3 DWPD 折算是 38.4TB/日。作者由此得到名义 HBF 寿命仅为 SSD 池 0.56 倍的估算。

这个估算同样属于模型，但它把一个容易被忽视的问题摆上桌面：SSD 控制器长期处理的逻辑到物理映射、写缓冲、垃圾回收、磨损均衡和坏块管理，在 GPU 可见的 HBF 层里要由基底、内存控制器、驱动或运行时重新承担。

论文给出的不是否定，是放置地图

论文标题很猛，结论其实比较克制。作者反对的是将 HBF 当成更快 SSD，在原有二级 KV 结构中直接替换。他们仍然认为 HBF 适合读密集、复用明确的对象，例如模型权重和高共享前缀。

因此，导入策略要从“换设备”转向“分对象”。运行时至少需要知道一块 KV 的复用概率、预期生命、写入成本和热区状态，再决定它应该留在 HBM、进 HBF、落 SSD，还是直接重算。

这也意味着，供应商给出 HBF 峰值带宽后，系统团队还需要索要四类证据：容量与带宽一起变化时的端到端队列曲线；按对象分类的读/写与复用分布；写密集流量下的稳态带宽与温度；面向目标年限的日写入预算。

对 AI 基础设施团队来说，这是一个比“快多少”更难的工程问题。数据放置、调度、温控和寿命管理需要共用同一套状态，任何一层只看自己的峰值指标，都可能把成本推给另一层。

这类问题也很难靠一个独立工具解决。对高保密的芯片与 AI 研发环境，更实用的路径是把知识、流程、权限和运行状态纳入同一条可审计的研发链路，并保留人工 review 节点。

写在最后

HBF 的战略价值没有被这篇论文结束。SK hynix 与 Sandisk 已经把 HBF 推进 OCP 标准化，说明产业正在为 HBM 和 SSD 之间的新层级建立接口。论文做的，是提前暴露一种容易发生的误用。

同类方案的终局判断可以压缩成三句话：读 I/O 必须真在关键路径上；读取收益必须足以偿还写入；系统必须在热和寿命约束下持续交付带宽。只有三问同时答对，更快的闪存才可能带来更快的推理。