512GB闪存塞进HBM封装,AI芯片的内存荒真能靠它解吗

Hot Chips 2026的教程日上,Oxmiq Labs的Anurag Agrawal(部分资料写作Agarwal,应为同一人)和Radhakrishna Giduthuri讲了一件还没有产品、只有仿真数据的事:把闪存做成HBM的样子,塞进AI芯片的封装里。这东西叫HBF,High Bandwidth Flash。

听起来像是给显存扩容的救星——容量据披露最高可以做到单堆栈512GB,是HBM4单颗48到64GB的八到十一倍。但硬币的另一面是,带宽只有HBM4的一个零头,延迟差出一到两个数量级。这不是简单的"更大的HBM",而是把闪存的脾气原封不动搬进了内存插槽,谁想用它,谁就得先学会伺候闪存。

外壳是HBM,内脏是SSD

HBF在封装形态上确实和HBM一样,堆叠芯片、贴在计算芯片旁边。但打开来看,里面跑的是NAND闪存的逻辑。原文特意拿Intel的Optane做对照:Optane好歹能当成另一块内存字节寻址,HBF不行。它必须走DMA,以大块对齐的方式读写,访问粒度像操作硬盘而不是操作内存。

更麻烦的是,主机软件得自己承担一部分SSD控制器的活——写均衡、数据保持,这些原本由固态硬盘主控芯片默默处理的脏活,现在得算法工程师自己写进运行时里。这意味着HBF不是即插即用的硬件,它是一整套需要重新设计的系统。

数字骨架:容量赢了,带宽和延迟输惨了

原文只给了定性描述,没有一个具体数字。行业里流传的规格数字能把这个反差看得更清楚:

SK海力士等厂商推动的开放规格,把性能档位定在0.4到3.0TB/s之间,配置为8片或16片NAND堆叠。粒度这一栏还有个容易被搞混的细节:4KB是NAND本身的最小读取交易单位,但部分更新和管理路径要做整块的读—改—写,涉及的块可能到64KB。换句话说,你想改一个字节,系统可能得把一大块数据读进DRAM、改完再写回去。这跟操作内存完全是两回事,更像在操作一块硬盘。

软件要为它重写多少东西

原文举了vLLM的例子。vLLM本来把模型权重放进GPU显存,也在试探把权重放到主机内存里省显存。但这条路对HBF行不通——HBF不支持细粒度随机访问。

真正可能落地的场景有两个。一是MoE专家权重:把不常用的专家丢进HBF里"冷存",需要时再DMA进HBM,这跟MoE本身"按需激活"的稀疏特性正好对上。二是KV缓存,但前提是推理用的是稀疏注意力,每一步只读取一小部分top-k token,这样大部分KV缓存可以安心躺在闪存里睡大觉。麻烦在于top-k读取是分散的,而HBF喜欢顺序读——软件得先把这些零散的行DMA进DRAM再处理,等于又加了一层转换。

另一个思路是拿HBF的容量换跨设备通信开销。大模型分片跑在多张GPU上时,瓶颈经常不是算力也不是带宽,而是设备间的scatter/gather。把权重多复制几份放进HBF,让每张卡本地就能取到,虽然从闪存里搬数据也不便宜,但比跨设备通信划算。

经济账:什么时候划算

Agrawal给出的判断很直白:HBF只在工作负载没有跑满带宽的时候划算——小模型、小batch。一旦负载变成带宽受限,HBF的性价比反而会输给HBM,因为HBF在"每单位容量的成本"上占优,却在"每单位带宽的成本"上明显吃亏,而这两项都要算进最终成本里。用HBM缓存热门专家来补带宽短板是个思路,但缓存命中率一旦不理想,反而会把每token成本拖垮。

• 提醒.HBF目前没有任何量产产品,所有数据都来自厂商路线图和仿真推演,离真正上机器还有距离。

这套东西让我想起Optane。Intel当年也想打破内存和存储的边界,做出能当内存用、又比DRAM便宜、比SSD快的东西,结果技术没输,是生态没跟上,最后business线直接砍掉。HBF走的是反方向——它不装成内存,老老实实承认自己是闪存,把复杂度全部转嫁给软件层。这个选择更诚实,但代价也更直接:每一个想用HBF的推理框架,都得先把自己的内存管理逻辑拆了重装。

原文作者的判断我认可:改造一套框架去适配HBF这种块对齐、DMA驱动的访问方式,工作量未必比直接从SSD流式加载模型权重更轻松。而后者的好处是,操作系统内核已经把复杂度封装好了——只要不用O_DIRECT这类绕过缓存的接口,内核的页缓存天然帮你把闪存的坑填了大半。换句话说,HBF想要的软件生态,某种程度上已经有一条更省事的平替路径存在。

容量焦虑能靠堆芯片解决,访问模式的焦虑只能靠重写代码解决

真正值得盯的不是HBF的容量数字有多漂亮,而是SanDisk、SK海力士这些存储厂商能不能在标准还没定型前,先说服vLLM这样的主流推理框架去啃这块硬骨头。硬件路线图可以先画出来,但软件生态愿不愿意跟着改,才是决定HBF是昙花一现还是真能缓解AI内存荒的分水岭。