HotChip/FMS 内存墙（二）：HBF、OCP HBF Spec 与 HBF-Compass，长上下文推理的容量层怎么设计

HBF 不是便宜 HBM，而是新的容量层#

上一篇讲了 HBM scaling 和 3D-DRAM/PIM/CXL-PNM，这一篇聚焦 HotChip/FMS Talk 的后半段：HBF（High-Bandwidth Flash，高带宽闪存）。HBF 最容易被误读成「便宜版 HBM」或「更快的 SSD」，但这两个说法都不准确。Talk 里最关键的一句话是：HBF is a capacity point, not a cheaper HBM。

所谓 capacity point，意思是它在设计空间里首先解决容量，而不是追求 HBM 级的带宽密度和随机访问延迟。它的价值来自两个参数：

$\alpha$ ：单位容量提供多少带宽，也就是 bandwidth/GB；
$\beta$ ：单位容量成本，也就是 $/GB。

HBM 的 $\alpha$ 高、 $\beta$ 也高；HBF 的目标是 $\beta$ 低得多、容量大得多，但 $\alpha$ 低于 HBM。于是它适合的不是「每个 token 都要高速全量扫描」的数据，而是「很大、要靠近加速器、访问有稀疏性或复用性」的数据。

为什么 LLM serving 会需要 HBF#

LLM serving 的内存压力来自三类数据。

第一类是模型权重。稠密模型每步 decode 要读全部激活权重；MoE 模型每步只读被激活的少量专家，但完整专家池可能非常大。权重本身是只读或低频更新数据，很适合分层放置：热层进 HBM，冷层进容量层。

第二类是 KV cache。它随 batch、层数、上下文长度线性增长，而且 decode 每步都要访问历史 KV。KV 是最危险的数据：容量需求巨大，但访问频率也高。若直接把长上下文 dense attention 的 KV 放到低带宽层，每 token 延迟会被拖垮；若配合稀疏注意力、prefix reuse、KV 压缩、分层缓存，HBF 才可能发挥容量优势。

第三类是 prefix cache / prompt cache。生产系统里大量请求共享系统提示词、工具说明、RAG 模板、代码仓库上下文或多轮对话前缀。前缀缓存的特点是「大、可复用、命中时收益高」，非常适合容量层，但仍需要调度器把即将使用的热前缀提前搬到更快层。

这三类数据决定了 HBF 的定位：它不是替代 HBM，而是让 HBM 不再被冷容量挤爆。

OCP HBF spec 的硬件形态#

Talk 里引用了 OCP HBF Architecture Specification v0.7.0。按这个 spec，HBF 与 xPU host compute die 紧耦合，通过分布式接口连接。每个 host channel interface 维护 64-bit full-duplex data bus，基于 UCIe standard guidelines 工作；每个 host channel 经 host side 和 NAND side 的 UCIe PHY 接到独立 NAND die。

HBF chipset 大体由三类实体组成：

实体	作用
Base die	管理 host traffic，与 core die 通信；包含 host-side PHY、UCIe controller、core die controller
Core die / NAND	承载实际非易失存储阵列和 NAND 侧控制
Host interface / channel	把 xPU 的请求拆到多个独立通道，每通道有自己的 local address space

这里的关键词是独立通道。HBF 不是一块被随机访问的单体盘，而是一组必须并行喂满的 channel。最大性能来自所有 UCIe channels 同时工作，因此软件和内存管理必须把大块数据按 channel interleaving 排布。

地址映射：global address 要拆成 channel-local address#

OCP spec 里的地址映射不是小细节，而是 HBF 性能的核心。Host software 配置 global address，然后把全局地址拆到各个 local UCIe channel address。每个 HBF 有 16 个 UCIe channels，每个 channel 有自己的线性 local address memory space。若 HBF 与 HBM 混用，由于两者容量差异巨大，内存管理必须分开做。

这和 GPU/HBM 的心智模型不同。对 HBM，程序员通常只关心一段连续显存，底层 channel/bank interleaving 由硬件和驱动隐藏。对 HBF，若要达到最大读带宽，host system page buffer 需要按类似 (4KiB × N) × all channels 的粒度一次性组织传输。也就是说，HBF 喜欢大块、跨通道、顺序化、并行化的数据流。

这会直接影响 LLM serving 的数据布局：

大模型权重加载时，应按所有 channel 交错写入，而不是把某层权重集中到少数 channel；
KV cache 写入时，要避免把读写模式完全不同的数据混在同一 zone，防止耐久和容量利用率双输；
多模型 serving 时，不同模型的权重和 KV 应该按 workload 做分区，而不是只按文件连续存放；
MoE 专家如果有冷热差异，热专家更适合进 HBM cache，冷专家可放 HBF，但 expert routing 的局部性必须被调度器看见。

读写行为：HBF 要求系统按它的并行性写程序#

Talk 里有两条很容易被忽略的 spec 级约束。

第一，read requests between channels do not maintain order。跨 channel 读请求不保证全局顺序，这对吞吐有利，但要求上层能处理乱序完成。若软件栈假设按发起顺序返回，就需要额外重排；若编译器/运行时直接按 channel 并行设计，就可以把乱序变成性能来源。

第二，best write performance requires writing to all banks in all host channels。写入时最好让所有 channel 的所有 bank 都忙起来；同一 NAND die 内的 bank 最好使用相同 page number，不同 die 或 channel 可使用不同 page number。直观地说，HBF 不适合被当成普通随机写存储；它需要批量化、条带化、布局感知的写入。

这对 KV cache 尤其重要。KV 是持续追加写、后续反复读的数据；权重是加载后只读的数据。若把两者混在同一 zone，读写模式差异会损害 endurance 和容量利用率。OCP spec 明确提出可按 endurance perspective 做 uniform channel partitioning，也可按 capacity utilization 做 non-uniform partitioning。翻译成系统语言：HBF 需要存储分区策略，而不是简单 malloc 一段大空间。

单模型 serving：为什么 channel interleaving 是第一原则#

单 LLM serving 使用 HBF 时，模型加载阶段应把数据以 4KiB × N × 16 的形式顺序写入所有 channel，其中 16 对应 host channels， $N$ 是每 channel 内 parallel banks/planes 数。这样做的目的只有一个：读模型权重时，所有 UCIe channel 能一起出数据。

如果只把权重按文件顺序放进 HBF，可能出现某些 channel 热、某些 channel 空的情况。容量看起来用满了，带宽却没有被打开。对推理来说，这会直接变成 TPOT 的尾延迟。HBF 的容量收益必须以布局换取：数据越大，越要条带化；访问越热，越要保证通道均衡。

多模型 serving：HBF 的价值来自容量复用#

多 LLM serving 是 HBF 的强场景。生产平台上常常同时服务多个模型：通用对话、代码、数学、翻译、embedding、rerank、工具调用小模型。若每个模型都要求完整驻留 HBM，HBM 容量会变成主要成本；若大量低频模型或低频层可以放 HBF，需要时按需拉入 HBM，HBF 的容量优势就能换成更高模型密度。

但多模型也会放大带宽风险。多个模型同时 miss 到 HBF，可能把 channel 带宽打满；多个模型的权重布局若互相交错不当，也可能导致读放大。调度器需要知道模型热度、SLO、并发和加载成本，把 HBF 当成服务系统的一层 cache/store，而不是被动块设备。

MoE expert pool：HBF 最自然的落点#

MoE 是 Talk 里最明确的 HBF 受益场景。完整 expert pool 容量很大，但每个 token 只激活一小部分专家。设每步激活专家导致的 HBF 读取强度为 $I$ ，batch 为 $b$ ，HBF 可用带宽为 $B_\text{HBF}$ ，那么只有当：

I \cdot b \le B_\text{HBF}

HBF 才是划算的。一旦 batch 太大、专家访问过于分散，HBF 带宽不足会抵消容量收益。

这和 DeepSeekMoE 的结构以及 DeepEP 的通信优化直接相连。MoE 推理的系统难点从来不是「专家参数总量大」这么简单，而是专家路由会在时间和设备上形成热点：热门专家会被反复访问，冷专家偶尔被访问。HBF 可以放下更完整的 expert pool，但它必须和 HBM cache、专家复制、请求聚类、路由均衡一起设计。

HBM-as-cache：能否成立取决于 expert locality#

Talk 提到一个重要判断：如果 HBM 只能缓存约 40% 的专家，在低 batch 下仍可能有效，因为每步只触达有限专家；但当 batch 混合了不同用户、不同查询和不同领域，专家访问会变得更均匀，hot/cold expert 的区别被削弱，HBM cache hit rate 下降，HBF 带宽瓶颈重新暴露。

这说明 HBM-as-cache 的成败不只取决于缓存大小，还取决于请求调度。把相似请求 batch 到一起，不只是提高 GPU 利用率，也是在提高 expert locality。若请求完全随机混合，HBF 后面的 expert pool 看似很大，实际每步都在跨容量层取不同专家，尾延迟会非常差。

All-HBF：短上下文可能赢，长上下文会暴露带宽#

All-HBF 指模型主要数据都放在 HBF 上。Talk 的判断很清楚：短上下文时，HBF 可能凭容量优势赢，因为 capacity wall 是主要约束；长上下文时，容量仍然有帮助，但 bandwidth wall 变成主约束。

用 KV cache 公式看更直观。若每层 KV 每 token 字节数为 $S_\text{KV/token/layer}$ ，层数为 $L$ ，上下文长度为 $T$ ，batch 为 $b$ ，那么每步注意力读 KV 的量近似与：

b \cdot L \cdot T \cdot S_\text{KV/token/layer}

成正比。 $T$ 越长，每步读量越大。All-HBF 短上下文能靠容量减少 GPU 数；长上下文 dense attention 则会因为每步都读大量 KV 而把 HBF 带宽打满。要让 HBF 继续可用，必须引入 GQA、MLA、KV 量化、稀疏注意力、滑窗、prefix reuse 这些减少读取量或提高复用率的技术。

rack scale 与 instance scale：同一种内存答案会反转#

Talk 里还有一个很有启发的对比：rack scale 和 instance scale 的结论可能不同。固定 72-GPU rack 下，HBM 更适合带宽密集 workload，因为总带宽是关键；instance scale 下，HBF 可能有价值，因为它让大模型用更少 GPU 放下。

这解释了为什么同一篇 HBF 分析不能给出「HBF 一定好」或「HBF 一定差」的结论。若你的目标是最大化一个满配机架的吞吐，HBM 的高带宽可能更重要；若你的目标是让一个 1T MoE 或超长上下文模型少用几张卡启动，HBF 的容量可能更重要。SLO、batch、上下文、专家局部性、模型大小共同决定答案。

attention sparsity 会把 HBF 拉进可用区#

Talk 提到 attention sparsity plays in HBF’s zone。这句话很关键。HBF 最怕的是 dense attention 每步全量扫 KV；稀疏注意力恰好减少每步读取的历史块数量。若注意力只访问 Top-K 块、局部窗口、少量全局 sink 或压缩摘要，HBF 需要提供的带宽就会下降，容量优势更容易体现。

这和本站已有的 NSA、DeepSeek-V4 混合注意力、DeepSeek-V4.1-Flash KV Cache、Prefix Sliding 都是同一条线：先用模型结构降低每步必须读取的 KV，再用容量层承接更长历史。没有稀疏性，HBF 是慢内存；有足够稀疏性，HBF 可能是长上下文容量的解锁器。

EP × HBF：容量买回通信，但不能买回所有延迟#

专家并行（EP）和 HBF 的关系也很微妙。EP 把专家分散到多设备，激活哪个专家就跨网络发 token；HBF 则试图用更大本地容量放下更多专家，减少部分跨设备取专家。但容量只能买回一部分通信，不能消除路由本身的动态性。

如果 HBF 让每个节点能放下更大专家子集，跨节点 expert traffic 会下降；如果专家访问局部性强，HBM cache + HBF backing store 可以让热专家留在快层、冷专家留在容量层。但若每个 batch 都激活大量不同专家，且路由分布随请求剧烈变化，HBF 仍会面对带宽和调度压力。EP × HBF 的正确打开方式不是「把所有专家塞进 HBF」，而是「让专家放置、复制、缓存和路由调度共享同一套统计」。

KV cache offload pool + prefix cache：HBF 最像一个推理状态仓库#

KV cache offload 和 prefix cache 是另一个自然场景。传统 KV offload 常常把冷 KV 放到 host DRAM、SSD 或远端存储，问题是延迟和带宽离加速器太远。HBF 的价值是把这层容量拉近封装，让 offload 不再穿过长 PCIe/网络路径。

但 HBF 作为推理状态仓库时，必须遵守几条规则：

热 KV 不应长期留在 HBF，每步都读的内容应该进 HBM；
可复用前缀适合放 HBF，因为命中时可避免 prefill 重算；
长尾 KV 只有在稀疏访问或延迟不敏感时适合 HBF；
写入要按 channel/bank 分区，避免 KV 追加写和权重只读混在同一区域；
调度器要能预测下一批请求会不会命中，提前预取到快层。

从这个角度看，HBF 更像数据库/缓存系统里的分层存储，而不是 GPU 显存的简单扩容。

HBF-Compass：把架构选择变成相图问题#

Talk 最后一部分介绍 HBF-Compass。它的核心主张是：在固定封装预算和 serving SLO 下，识别不同 workload 对应的可行、高效 HBM/HBF 架构。它不是问「HBF 好不好」，而是问：给定模型、上下文、batch、SLO、成本和物理预算，HBM/HBF 应该怎样混合。

HBF-Compass 定义的设计空间包含两个维度：

维度	选项	含义
放置方式	Separate / Mixed	HBM 与 HBF 是分离池，还是在同一系统内混合承担数据
访问关系	Hierarchy / Parallel	HBF 是 HBM 后面的层级，还是和 HBM 并行服务不同数据

它用细粒度 HBM/HBF 模型校准端到端 serving DSE（Design Space Exploration），最后形成 workload × architecture phase map：哪些区域有稳定 winner，哪些区域是 crossover，哪些区域不可行，哪些区域不确定。这个思想非常重要：未来推理系统的内存选型会更像编译器 auto-tuning，不是靠一句经验判断。

一个实用判断框架#

把 Talk 中的 HBF 内容整理成工程判断，可以得到下面这张表：

workload 特征	HBF 是否适合	原因
大 MoE expert pool，低 batch，专家访问有热点	适合	容量收益大，带宽压力稀疏
多模型 serving，低频模型多	适合	模型密度提升，冷权重可放容量层
prefix cache 命中率高	适合	可复用状态大，命中避免 prefill
短上下文、大模型放不下	可能适合	容量是主瓶颈
长上下文 dense attention	风险高	每步 KV 读取带宽太高
高 batch、请求混合强、专家局部性弱	风险高	HBM cache hit rate 降，HBF 带宽被打满
稀疏注意力 + KV 压缩 + prefix reuse	更适合	降低 HBF 读强度，容量收益显现

这张表也说明为什么 HBF 需要和模型结构一起看。仅靠硬件容量，无法解决 dense attention 的线性 KV 读取；但模型一旦通过稀疏、压缩、复用降低访问强度，HBF 的容量就会变成系统优势。

与 H³、Jalapeño 的关系#

本站此前的 H³ 文章讲的是 HBM + HBF 混合架构如何用延迟隐藏缓冲和数据放置策略提高长上下文吞吐；Jalapeño 讲的是 OpenAI 如何为推理热路径定制 ASIC。现在把它们放在一起，会得到一条完整路线：

Jalapeño：热路径专用化，目标是每 token 延迟和每焦耳 token；
H³/HBF：容量层扩展，目标是让更多权重、专家、KV 和前缀靠近加速器；
HBF-Compass：在物理预算和 SLO 下，为不同 workload 自动找 HBM/HBF 混合点。

这三者不是替代关系，而是层次关系。热路径越快，容量层的 miss penalty 越显眼；容量层越大，调度器越需要知道哪些数据应该提前搬到热层。

小结#

HBF 的技术意义不在于「Flash 终于能接近 HBM」，而在于它把推理系统的内存层次补上了一个新点：比 HBM 便宜且大得多，比远端存储更靠近 xPU，适合承载有稀疏性、局部性和复用性的推理状态。

但 HBF 不能被浪漫化。它要求 channel-aware address mapping，要求大块跨通道并行读写，要求权重/KV 分区，要求调度器理解 workload。它对 MoE expert pool、prefix cache、多模型 serving、短上下文容量瓶颈很有吸引力；对长上下文 dense attention、高 batch 混合请求则很危险。

真正的结论是：未来推理内存不是 HBM 或 HBF 二选一，而是 HBM/HBF/CXL/远端存储共同组成的相图问题。谁能把模型结构、缓存策略、专家路由、稀疏注意力和硬件通道一起调度，谁就能把容量层变成推理成本优势，而不是新的尾延迟来源。

参考资料#

本站：HotChip/FMS 内存墙（一）：HBM scaling、3D-DRAM、PIM 与 CXL-PNM
本站：H³ 完全拆解：HBM 与高带宽闪存（HBF）混合架构如何驯服长上下文推理的内存墙
本站：OpenAI Jalapeño 完全拆解
本站：DeepSeekMoE 完全拆解
本站：DeepEP 完全拆解
本站：DeepSeek-V4.1-Flash 推理侧完全拆解

音乐

音乐