Hot Chips 2026: 高带宽闪存（HBF）技术应用

# Hot Chips 2026：高带宽闪存（HBF）的应用 来源：https://chipsandcheese.com/p/hot-chips-2026-applying-high-bandwidth HBF（高带宽闪存）采用与当今固态硬盘相同的闪存技术。与SSD不同的是，HBF的实现方式更类似于HBM（高带宽内存）。HBF模块与计算芯片封装在同一基板上，甚至可能紧邻HBM。HBF的核心理念是提供远超HBM的容量，同时保持合理的内存带宽。在Hot Chips 2026的教程环节中，Anurag Agarwal和Radhakrishna Giduthuri的演讲探讨了HBF如何应用于机器学习工作负载。由于目前尚无HBF产品，演讲主要聚焦于模拟分析、性能预测以及软件如何适配以利用HBF的特性。 [](https://substackcdn.com/image/fetch/$s_!TXwa!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fa51c9bf3-0d5c-4fb9-9ccc-bc0915b15005_1901x1047.png)HBF的每个“模块”具备超高容量，且访问粒度极大 尽管HBF采用类似HBM的封装形式，其底层架构却截然不同。它不像英特尔傲腾（Optane）那样可作为独立内存池运作，而是更像集成在处理器上的固态硬盘。软件需通过DMA在HBF与DRAM之间传输数据。HBF的访问必须采用大型对齐数据块，类似于对存储设备的操作而非系统内存访问。主机软件还需承担SSD控制器的功能，例如管理磨损均衡和确保数据持久性。这意味着HBF无法实现即插即用。 [](https://substackcdn.com/image/fetch/$s_!iiSf!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F84023f8e-e6be-4c8d-9a90-90f898756ba4_1876x1061.png) 因此，要利用HBF优势需要制定特殊策略并集成到运行时环境中。Giduthuri以vLLM为例进行说明：该框架通常将模型权重存放在GPU显存中，目前正探索降低VRAM占用的方案。例如vLLM正研究在主机有充足空闲内存时将模型权重置于CPU锁页内存中。但此方案不适用于HBF——因其不支持细粒度随机访问——而其他方法可能更具潜力，例如将混合专家模型（MoE）的专家组件存储在HBF中，软件可按需通过DMA将活跃专家模块加载至HBM。 [](https://substackcdn.com/image/fetch/$s_!voib!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F71baf239-bbd3-4544-9f71-22a8b1f51de2_1899x1072.png) vLLM的KV缓存同样可置于HBF，但仅在稀疏注意力机制下能发挥较好效果——该机制每步仅从KV缓存顶部读取部分token。这使得大部分KV缓存能以“冷数据”形式存放在闪存中，既利用HBF的大容量特性，又减轻对其较低带宽的压力。潜在挑战在于Top-K读取操作是离散的，而HBF更适合顺序读取。或许软件可通过按需DMA传输Top-K行数据至DRAM来规避此问题。 [](https://substackcdn.com/image/fetch/$s_!AIZM!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fcfd806d6-55c9-40f4-aa7f-83e54e993759_1892x1057.png) 另一应用方向是利用HBF容量降低跨设备通信开销。大型模型常被分散部署在多个GPU上，导致性能受限于跨设备的数据分发与收集操作。跨设备通信可能成为比计算吞吐量或内存带宽更显著的性能瓶颈。HBF可通过在不同GPU间复制更多模型权重来缓解此问题。虽然从闪存进行DMA传输并非零成本，但仍低于跨设备通信的开销。 [](https://substackcdn.com/image/fetch/$s_!tJM4!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe8a0ccc3-df02-4c5f-aa46-8d681fe5391a_1893x1058.png) Agarwal从成本效益角度分析了HBF的适用场景。简言之，当工作负载未达到带宽极限时HBF具有优势——这适用于较小模型和/或较小批处理规模。若工作负载受带宽限制，则HBF的成本效益将下降，因为其总成本需综合考虑容量成本与带宽成本。HBF在单位容量成本上表现优异，但单位带宽成本劣于HBM。 [](https://substackcdn.com/image/fetch/$s_!hcsO!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Feddf33ad-8add-44fb-b126-43982d4bb7af_1887x1053.png) [](https://substackcdn.com/image/fetch/$s_!cJhw!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fcaef7a2b-25dd-46d6-aa78-ec1ac8f2cea6_1901x1060.png) 演讲还探讨了使用HBM缓存活跃专家模块的方案，但这同样面临巨大挑战。缓存机制必须高效运作，否则HBF带宽可能成为每token成本计算的制约因素。 [](https://substackcdn.com/image/fetch/$s_!BgnZ!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F22db33e5-d509-4ae3-95eb-215742c5bc5d_1896x1057.png) HBF或许能部分缓解DRAM容量不足的问题，但其软件适配挑战堪称艰巨。操作HBF非常类似于使用底层磁盘访问API（如Windows的FILE_FLAG_NO_BUFFERING或Linux的O_DIRECT）。软件必须以大型对齐数据块进行访问，无法像内存那样实现字节级粒度的自由寻址。修改单个字节可能需将整个64KB数据块读入DRAM，修改后再整体写回闪存。这更接近于块存储设备的操作模式而非内存访问。现有基于DRAM内存设计的软件框架要充分利用HBF特性，需要进行根本性重构。切换到其他框架意味着重新投入适配HBF所需的全部开发工作。 我认为，利用HBF所需付出的开发成本，与直接通过从SSD流式传输模型权重来降低DRAM需求的方案相比，两者工作量不相上下。实际上SSD流式方案似乎更易实现：操作系统内核可抽象化块对齐访问的复杂性（只要不使用FILE_FLAG_NO_BUFFERING或O_DIRECT）。内核缓冲机制能支持软件进行任意寻址的字节级读写操作，同时充当缓存层，自然隔离闪存效率低下的问题。虽然演讲未涉及此点，但我思考现有的SSD模型流式传输方案（https://github.com/tonbistudio/moe-ssd-streaming-windows）能否应用于HBF。或者，若HBF的软件适配难度过高阻碍其普及，我们可能需要等待HBF产品真正面市才能见分晓。我期待能有技术缓解当前DRAM短缺困境，但尚不确定HBF是否正是答案。