Hot Chips 2026: Applying High Bandwidth Flash (HBF)

发表时间: 2026-08 · Blog post by Chester Lam (chipsandcheese.com)

原文: https://chipsandcheese.com/p/hot-chips-2026-applying-high-bandwidth

作者：Chester Lam (基于 Anurag Agarwal 和 Radhakrishna Giduthuri 在 Hot Chips 的演讲)
日期：2026年8月23日

速读

一句话结论 在 Hot Chips 2026 上探讨的 High Bandwidth Flash (HBF) 概念通过将闪存与计算芯片同封装来提供海量且廉价的存储，但由于其底层类似块存储设备的访问机制，需要对推理框架进行深度重构才能在专家混合模型加载、KV Cache 卸载和减少跨设备通信等场景中发挥作用。

要解决什么问题 机器学习工作负载对 DRAM 容量的需求无休无止，而 DRAM 的扩容成本极高。虽然传统的固态硬盘（SSD）在每千兆字节的成本上远低于 DRAM，但其带宽和延迟无法满足芯片内的高速计算需求。为了打破这一显存容量墙，业界提出了 HBF 的概念。HBF 在物理形态上类似于 High Bandwidth Memory (HBM)，它将闪存立方体与计算芯片封装在同一个封装内，甚至直接与 HBM 相邻，旨在提供比 HBM 大得多的容量，同时维持可观的内存带宽。然而，HBF 的核心卡点在于它并非即插即用的系统内存，而是更像一个集成在处理器上的 SSD。它不支持细粒度的字节级随机访问，必须像大容量存储设备一样以巨大的、对齐的数据块（例如 64 KB）为单位进行读写。如果只修改一个字节，软件必须先将整个 64 KB 的数据块读取到 DRAM 中，修改后再完整写回闪存。此外，主机软件还必须承担原本由 SSD 控制器负责的磨损均衡和数据保持等底层管理工作。这种底层机制导致现有的、基于常规 DRAM 内存系统设计的软件框架无法直接使用 HBF，必须进行大规模的底层重写。

怎么做的 由于目前尚无 HBF 的实体产品，研究人员主要通过模拟和预测来探索软件应如何调整运行时策略以利用 HBF。核心思路是避免将 HBF 作为直接的计算内存，而是将其作为海量的高速后备存储，通过直接内存访问（DMA）技术在 HBF 和 DRAM（或 HBM）之间显式地搬运大块数据。具体到大语言模型推理框架（如 vLLM）中，有三种关键的设计方案。第一是用于专家混合模型（MoE）的权重存储：由于 HBF 不支持细粒度的随机访问，无法像 CPU 锁页内存那样直接读取权重，因此可以将 MoE 的各个专家网络权重存储在 HBF 中，在推理时根据路由结果，通过 DMA 将当前激活的专家权重动态加载到 HBM 中参与计算。第二是用于 KV Cache 的卸载：将庞大的 KV Cache 存入 HBF，但这需要配合稀疏注意力机制使用。因为稀疏注意力在每一步只需读取 KV Cache 顶部的一小部分 Token，这使得大部分 KV Cache 可以“冷”在闪存中，从而缓解 HBF 带宽较低的压力。针对 HBF 偏好顺序读取而 Top-k 检索是分散读取的矛盾，软件需要按需将 Top-k 所在的整行数据通过 DMA 搬运到 DRAM 中再进行处理。第三是用于减少跨设备通信：在多 GPU 并行时，模型切片带来的跨设备 Scatter 和 Gather 操作往往比计算吞吐或内存带宽更容易成为性能瓶颈。利用 HBF 的超大容量，可以在不同 GPU 的 HBF 中完整复制更多的模型权重，从而将昂贵的跨设备通信转化为相对廉价的本地 HBF 到 HBM 的 DMA 搬运。

效果如何 由于 HBF 仍处于概念和模拟阶段，其实际效果评估主要基于成本和带宽的推演。从成本效益来看，HBF 的优势高度依赖于工作负载的特性。在模型规模较小或批处理大小较小、整体计算未触及带宽上限的场景下，HBF 凭借极低的单位容量成本表现出显著优势。然而，一旦工作负载变成带宽受限型，HBF 的成本等式就会恶化，因为在单位带宽成本上 HBF 远不及 HBM。如果使用 HBM 作为 HBF 中热点专家权重的缓存，一旦缓存命中率不佳，HBF 较低的带宽就会严重拖垮单个 Token 的生成成本。此外，该方案的工程代价极其高昂。开发者指出，适配 HBF 的难度堪比使用操作系统最底层的无缓冲磁盘 API（如 Windows 的 FILE_FLAG_NO_BUFFERING 或 Linux 的 O_DIRECT），这要求开发者手动管理大块对齐访问。相比之下，直接利用操作系统内核自带的缓冲机制从传统 SSD 中流式读取模型权重（即当前的替代基线方案），反而能自然地获得字节级读写抽象和缓存保护，这使得 HBF 在软件生态上面临着是否值得投入巨大重构成本的严峻拷问。

A1 主要贡献

A2 背景知识与设计原则

HBF的物理形态与技术基础。高带宽闪存（HBF）使用了当今固态硬盘（SSD）中常见的同款闪存技术。然而，与传统的SSD不同，HBF的实现方式非常类似于高带宽内存（HBM）。HBF数据立方体（cubes）与计算芯片封装在同一个基板上，甚至可能与HBM相邻放置。HBF的核心设计理念是提供比HBM高得多的存储容量，同时依然能够提供相当可观的内存带宽。由于目前市场上尚未存在真实的HBF物理产品，因此本次Hot Chips 2026的演讲主要聚焦于模拟、预测，以及软件系统应当如何进行调整以充分利用HBF的优势。
图1 HBF提供高容量和巨大的访问粒度

A3 方法细节

HBF的底层架构与访问机制。尽管HBF采用了类似HBM的外观形态，但其底层运行机制却截然不同。它不像英特尔的Optane那样可以作为另一个透明的内存池来运作。相反，HBF几乎等同于一个直接集成到处理器封装上的固态硬盘（SSD）。软件必须使用直接内存访问（DMA）技术在HBF和DRAM之间移动数据。对HBF的访问操作必须以巨大的、对齐的数据块（chunks）形式进行，就如同它是一个大容量块存储设备，而不是系统级内存。此外，主机端的软件还必须承担起传统SSD控制器的功能，例如管理磨损均衡（write leveling）并确保数据保持力（data retention）。这意味着HBF绝对不是一个即插即用的硬件解决方案。
图2 HBF底层架构与访问机制

vLLM框架的适配策略与MoE专家存储。为了充分利用HBF，必须制定特殊的策略并将其深度实现到运行时（runtime）系统中。演讲者Giduthuri以vLLM框架为例进行了说明。vLLM通常将模型权重保存在GPU内存中，并且已经在积极探索减少显存（VRAM）使用的各种选项。例如，vLLM正在研究如果主机有大量空闲内存，则将模型权重放入固定的（pinned）CPU内存中。虽然这种方法对HBF不起作用，因为HBF不支持细粒度的随机访问，但其他架构选项可能具有潜力。例如，可以将混合专家模型（MoE）的各个专家（experts）存储在HBF中。接着，软件可以根据计算需求，通过DMA将处于活跃状态的专家数据动态传输到HBM中。
图3 vLLM框架的适配策略与MoE专家存储

KV缓存的HBF存储与稀疏注意力机制。vLLM的KV缓存（KV cache）同样可以被放置到HBF中。然而，这种设计可能只有在稀疏注意力（sparse attention）实现中才能良好运作，因为该实现每一步仅从KV缓存的顶部读取一部分标记（tokens）。这种方式允许大部分KV缓存以“冷数据”的形式驻留在闪存中，从而充分利用了HBF的高容量优势，同时减轻了HBF较低带宽带来的性能压力。这里存在一个潜在的缺陷：top-k的读取操作在物理内存位置上是分散的（scattered），而HBF在架构上更倾向于顺序读取。为了解决这个问题，软件或许可以通过DMA按需将top-k的行数据统一传输到DRAM中，以此来绕过这一限制。
图4 KV缓存的HBF存储与稀疏注意力机制

利用HBF容量减少跨设备通信开销。另一个重要的优化机会是利用HBF的巨大容量来减少跨设备（cross-device）之间的通信。大型模型通常被分片（sharded）部署在多个GPU上，这导致系统性能往往受限于跨设备的分散（scatter）和收集（gather）操作。在许多情况下，跨设备通信可能会成为比计算吞吐量或内存带宽更大的性能障碍。HBF可以通过在不同GPU之间复制更多的模型权重来缓解这一问题。虽然通过DMA从闪存中提取数据并不廉价，但它比进行跨设备的片外通信要便宜得多。
图5 利用HBF容量减少跨设备通信开销

HBF的成本效益分析。演讲者Agarwal详细探讨了从成本角度来看HBF在何时是有意义的。基本上，如果一个工作负载没有达到其带宽极限，那么使用HBF是非常合适的。这种情况通常适用于较小的模型和/或较小的批处理大小（batch sizes）。如果一个工作负载变成了受带宽限制（bandwidth bound）的状态，这对于HBF的成本等式来说是非常不利的，因为每容量成本和每带宽成本都会共同影响最终的整体成本。与HBM相比，HBF在每容量成本方面表现极为出色，但在每带宽成本方面则表现较差。
图6 HBF的成本效益分析-带宽限制
图7 HBF的成本效益分析-成本等式

HBM缓存热点专家的挑战。Agarwal还讨论了使用HBM来缓存热点专家（hot experts）的方案，但这似乎也是一个非常困难的解决方案。缓存机制必须运作得非常完美，否则HBF的带宽瓶颈将会像扳手卡在齿轮中一样，彻底破坏每token成本（cost-per-token）的经济性。
图8 HBM缓存热点专家的挑战

A4 实验环境

A5 实验结果

A6 结论

HBF在一定程度上可以缓解机器学习面临的DRAM容量短缺问题，但其带来的软件挑战是极其巨大的。处理HBF非常类似于使用底层的磁盘访问API，例如在Windows中使用 FILE_FLAG_NO_BUFFERING 或在Linux中使用 O_DIRECT。软件必须以巨大的、对齐的数据块进行访问，而不能以字节级粒度自由寻址存储。修改单个字节意味着需要将一个完整的64 KB大块读取到DRAM中，修改该块，然后再将整个块写回闪存。这更像是在操作一个块存储设备，而不是在操作内存。

为了利用HBF，原本为常规基于DRAM的系统设计的软件框架将需要进行大规模的重构。作者指出，利用HBF所需的软件开发精力，似乎与直接通过传统的SSD流式传输模型权重来减少DRAM使用的难度相差无几，甚至利用传统SSD可能更容易。因为操作系统内核在使用非直写API时可以抽象掉块对齐访问的复杂性，内核中的缓冲机制允许软件进行任意的寻址和字节级读写操作，并自然地作为缓存屏蔽闪存的低效性。未来需要观察现有的SSD流式传输方案是否能应用于HBF，以及HBF高昂的软件门槛是否会阻碍其最终的市场普及。

A7 引用汇总