HBF或高带宽闪存，使用我们今天在SSD中看到的相同闪存技术。与SSD不同，HBF的实现方式类似于HBM（高带宽内存）。HBF立方体与计算芯片在同一个封装上，甚至可能与HBM相邻。HBF的概念是提供比HBM更高的容量，同时仍然提供合理的内存带宽。在热芯片2026的教程日，Anurag Agarwal和Radhakrishna Giduthuri的演讲探讨了HBF如何应用于机器学习工作负载。目前没有HBF产品，因此演讲集中于模拟、预测，以及软件如何调整以便利用HBF。HBF每个“立方体”提供非常高的容量，并具有巨大的访问粒度。尽管HBF使用类似于HBM的外形，但其内在机制完全不同。它不同于英特尔的Optane，后者可以作为另一种内存池。相反，HBF几乎像是集成在处理器上的SSD。软件使用DMA在HBF和DRAM之间移动数据。HBF访问必须以大型对齐块的方式进行，就像它是一个大容量存储设备，而不是系统内存。主机软件还必须承担SSD控制器的功能，例如管理写入均衡和确保数据保留。这意味着HBF不是即插即用的解决方案。相反，利用HBF需要制定特殊策略并将其实施到运行时中。Giduthuri以vLLM为例。vLLM通常将模型权重存放在GPU内存中，并已经在探索减少VRAM使用的选项。例如，vLLM正在研究将模型权重放入固定的CPU内存中，前提是主机有大量可用内存。虽然这对HBF不起作用，因为HBF不支持细粒度随机访问，但其他选项可能有希望。例如，MoE专家可以存放在HBF中。软件可以根据需要将活跃专家DMA到HBM中。vLLM的KV缓存也可以放在HBF中。然而，这可能仅在稀疏注意力实现中有效，该实现每一步仅从KV缓存的顶部读取一部分标记。这允许大多数KV缓存“冷”静置在闪存中，利用HBF的容量，同时对HBF的低带宽施加较小的压力。一个潜在的警告是，top-k读取是分散的，而HBF更倾向于顺序读取。也许软件可以通过按需将top-k行DMA到DRAM来解决这个问题。另一个机会是利用HBF的容量减少跨设备通信。大模型通常分片到多个GPU上，这导致性能受到跨设备散射和聚集操作的限制。跨设备通信可能成为比计算吞吐量或内存带宽更大的性能障碍。HBF可以通过在不同GPU之间复制更多模型权重来缓解这个问题。从闪存中DMA数据并不便宜，但比出设备的成本要低。Agarwal讨论了从成本的角度看HBF何时有意义。基本上，如果工作负载没有达到带宽限制，HBF就不错。这适用于较小的模型和/或较小的批量。如果工作负载变得受带宽限制，那么HBF的成本方程就会变得糟糕，因为容量的成本和带宽的成本都会影响最终成本。HBF在每单位容量的成本上表现优良，但在带宽成本方面与HBM相比就差了。他还讨论了使用HBM来缓存热专家，但那似乎也是一个困难的解决方案。缓存需要运作良好，否则HBF带宽会对每个token的成本方程造成影响。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，操作系统内核可以抽象出进行块对齐访问的难度。内核中的缓冲将允许软件任意寻址并执行字节级的读/写操作。它还将充当缓存，自然使软件免受闪存内存效率低下的影响。虽然在演讲中没有提到，但我想知道现有尝试从SSDs流式传输模型权重的做法是否可以应用于HBF。或者，软件挑战是否...