📋 多平台草稿预览（12平台差异化改编）

512 GiB闪存搬到xPU旁边，HBF能打破推理内存墙？

当HBM用堆叠和共封装把存储搬到GPU身边，AI计算的数据搬运瓶颈似乎找到了出路。现在，SK海力士联合闪迪，要把同样的思路用在NAND上——HBF，一种紧贴xPU的大容量闪存方案，能否成为AI推理时代的内存破壁人？

大模型推理的瓶颈，从来不是算力，而是内存。

当GPT-4级别的模型动辄需要数百GB的权重参数驻留，而单张H100的HBM容量仅有80GB时，开发者们不得不面对一个残酷的现实：要么把模型切碎塞进多张GPU，要么让数据在CPU内存和GPU之间反复搬运——前者烧钱，后者烧时间。

英伟达的H100售价高达30万美元，其中HBM的成本占比超过一半。为了更大的内存容量，业内甚至出现了把H100云主机时薪炒到8美元的天价。这背后的根本矛盾在于，HBM虽快但贵，SSD虽便宜但慢，而中间那个“既快又便宜”的甜蜜点，一直是一片空白。

近日，SK海力士联合闪迪，通过OCP（开放计算项目）发布了《High Bandwidth Flash（HBF）High-Level B

U3JTlBJTg0JUU2JUE4JUExJUU1JTlFJThCJUU1JThBJUE4JUU4JUJFJTg0JUU5JTlDJTgwJUU4JUE2JTgxJUU2JTk1JUIwJUU3JTk5JUJFJTIwc3R5bGV8ZW58MXwwfHx8MTc4NjAwNTU2OHww&ixlib=rb-4.1.0&q=80&w=1080" alt="" style="max-width:100%;border-radius:8px;" loading="lazy">

ase Die Specification, Version 0.7.0》。谷歌和Tenstorrent作为反馈方被列入致谢名单。这份约130页的规范，首次明确了HBF的位置、边界与代价：介于HBM与SSD之间，紧邻xPU、由Base Die和...构成的全新存储层级。

HBF是什么？一张图看懂它的位置

如果给存储层级画一条金字塔，顶端是寄存器，往下依次是L1/L2缓存、HBM、DDR内存、NVMe SSD，塔底是机械硬盘。层级越靠上，速度越快，但容量越小、价格越贵。

HBF要插入的位置，恰恰是HBM和SSD之间那个空隙——一个此前只有“内存扩展卡”和“CXL设备”试图填补的领域。

从规范来看，HBF的核心思路极其直接：把NAND闪存颗粒通过3D堆叠和共封装技术，直接放到xPU（GPU、TPU、NPU等各类加速器）旁边，用类似HBM的接口设计，让xPU能以远超NVMe SSD的带宽直接访问大容量闪存。

HBF的定位非常清晰：不是替代HBM，而是成为HBM的“外挂仓库”。训练时，热数据留在HBM；推理时，模型权重可以部分驻留在HBF中，按需加载到HBM。这样一来，一个GPU的“有效内存”就从80GB扩展到了512GB甚至更大。

为什么是现在？推理场景的“内存饥渴”

大模型推理的内存消耗，远比训练时更棘手。

训练阶段，数据是流式处理的，batch size可以调整，显存压力相对可控。但推理阶段，每个token的生成都需要完整的模型权重驻留。以GPT-3 175B参数为例，仅FP16权重就需要350GB存储。即使是目前主流的7B-70B参数开源模型，加上KV cache和激活值，单卡部署也捉襟见肘。

更麻烦的是，推理场景的SLA要求决定了不能把数据换入换出太频繁。如果模型权重必须从SSD加载，PCIe 4.0 x16的带宽（约32GB/s）会让首token延迟飙升到无法接受的程度。

HBF的定位，就是把这个“加载”环节的带宽提升一个数量级。

按照目前公开的信息，HBF的目标带宽在数百GB/s级别，远超NVMe SSD，同时容量密度远高于HBM。这意味着，一个GPU可以“挂载”512GiB的闪存，而不用修改模型并行策略——这是目前解决大模型推理内存墙最具性价比的方案之一。

技术路线：从“堆”到“贴”

HBF规范中强调的两个关键词是“堆叠”和“共封装”。

堆叠，指的是3D NAND本身的垂直堆叠技术。SK海力士正在量产300+层的3D NAND，单颗die的容量已经超过1Tb。通过TSV（硅通孔）技术将多颗die垂直互联，可以在一块封装内实现数十TB的容量。

共封装，则是把NAND die和Base Die（基础逻辑芯片）封装在同一基板上，类似HBM的“堆叠+逻辑”结构。Base Die负责控制NAND的读写、刷新、坏块管理等逻辑，同时通过高速接口与xPU通信。

规范将HBF定义为“紧邻xPU”，而非“在xPU内部”，这意味着HBF可以作为独立封装模块，与GPU/CPU/TPU封装在同一基板或同一封装体内。这种设计灵活度，使得HBF不仅适用于英伟达GPU，也能适配AMD、Intel、谷歌TPU以及RISC-V架构的AI芯片。

从代码层面看，HBF的驱动和管理也会是一个新的挑战。传统上，NVMe SSD通过块设备接口暴露给操作系统，而HBF更接近内存语义：

// 伪代码示意：HBF设备驱动初始化
struct hbf_device {
    void __iomem *base;
    size_t capacity; // 以GiB为单位
    u32 row_size;    // 行大小，类似HBM的row
};

static int hbf_probe(struct platform_device *pdev)
{
    struct hbf_device *hbf;
    
    hbf = devm_kzalloc(&pdev->dev, sizeof(*hbf), GFP_KERNEL);
    hbf->base = devm_platform_ioremap_resource(pdev, 0);
    hbf->capacity = 512; // 512 GiB per device
    
    // 注册为内存管理单元，而非块设备
    return hbf_memory_register(hbf);
}

这种“内存语义”的设计，意味着未来软件栈可能将HBF视为NUMA节点或异质内存，而非磁盘。对CUDA、ROCm等编程模型的适配，将是HBF能否落地的关键。

谷歌和Tenstorrent为何入局？

这份规范最值得玩味的细节，是谷歌和Tenstorrent被列为反馈方。

谷歌自研TPU已经迭代到v5，其推理集群面临的内存瓶颈同样严峻。TPU的HBM容量和带宽虽然可观，但面对多模态模型和长上下文窗口，依然捉襟见肘。谷歌对HBF的兴趣，显然源于其大规模推理部署的实战需求。

而Tenstorrent——由Jim Keller领导的AI芯片公司，主打RISC-V架构的Grayskull和Wormhole处理器——对HBF的兴趣则更具指标意义。Tenstorrent的芯片设计强调“异构计算”和“数据流架构”，对存储层级的需求更为激进。Jim Keller曾在多个场合表示，未来AI芯片的瓶颈在内存带宽而非计算能力，HBF正是对这一判断的实践。

更值得关注的是，这份规范由OCP发布，而非JEDEC（固态技术协会）。OCP更强调开放协作和快速迭代，这意味着HBF的规格可能会比HBM的演进速度更快，也可能更容易被超大规模数据中心采用。

HBF的代价与挑战

天下没有免费的午餐。HBF虽然容量大、带宽高，但它的代价也同样明显。

首先，是NAND的耐久性问题。 HBM使用DRAM，写入寿命近乎无限。而NAND的P/E周期通常在数千次级别，如果HBF被频繁写入（例如持续加载/卸载模型权重），寿命可能成为瓶颈。不过，推理场景以读为主，写次数相对有限，这个问题在短期内可控。 其次，是延迟的物理天花板。 NAND的读延迟通常在数十微秒级别，而HBM的延迟在纳秒级。这中间差了三个数量级。HBF规范中强调了“页缓存”和“预取”机制，试图在Base Die中集成SRAM缓存来弥补延迟差距。但对于延迟敏感型的推理场景（如在线对话），HBF仍然只能作为HBM的补充而非替代。 第三，是生态适配的难度。 目前主流AI框架（PyTorch、TensorFlow）的内存管理都基于“GPU显存”和“CPU内存”的二分法。HBF的引入，意味着需要新的内存管理层——类似UM（统一内存）但更细粒度。这需要框架级、驱动级和硬件级的多层协同。

打破内存墙，还是另一堵墙？

HBF的提出，本质上是对“内存墙”问题的又一次正面回应。从HBM到CXL，再到现在的HBF，业界一直在寻找“容量-带宽-成本”的平衡点。

HBM的问题在于成本和容量天花板，CXL的问题在于延迟和生态成熟度，而HBF的差异化在于——它把闪存放到了“足够近”的位置，用接近内存的接口，提供了远超内存的容量密度。

512GiB的HBF，意味着单卡可以加载完整的70B参数模型，而无需跨卡张量并行。对于推理服务商来说，这将直接降低部署成本和运维复杂度。

但HBF能否真正打破内存墙，还需要时间的检验。毕竟，从规范发布到产品落地，再到生态成熟，通常需要2-3年。在这期间，HBM的容量也在快速攀升（HBM4预计将达48GB/颗），CXL 3.0也在推进中。

技术路线的竞争，从来不只是性能的比拼，更是生态和时间的赛跑。HBF的牌面已经亮出，接下来看谁先落子。

排版建议：

标题字号 18px，加粗
正文 15px，#333333
引用块 #888888 14px
代码块使用深色背景
段落间距 1.75 倍行距
图片居中，宽度 100%

雷锋网：把512 GiB闪存搬到xPU旁边，HBF能打破推理内存墙？ 标签：[HBF], [存储技术], [AI芯片], [内存墙], [SK海力士], [闪迪]

知乎回答

问题：如何看待 512 GiB闪存搬到xPU旁边，HBF能打破推理内存墙？？

当HBM用堆叠和共封装把存储搬到GPU身边，AI计算的数据搬运瓶颈似乎找到了出路。现在，SK海力士联合闪迪，要把同样的思路用在NAND上——HBF，一种紧贴xPU的大容量闪存方案，能否成为AI推理时代的内存破壁人？

当HBM用堆叠和共封装把存储搬到GPU身边，AI计算的数据搬运瓶颈似乎找到了出路。现在，SK海力士联合闪迪，要把同样的思路用在NAND上——HBF，一种紧贴xPU的大容量闪存方案，能否成为AI推理时代的内存破壁人？

大模型推理的瓶颈，从来不是算力，而是内存。

近日，SK海力士联合闪迪，通过OCP（开放计算项目）发布了《High Bandwidth Flash（HBF）High-Level B

HBF是什么？一张图看懂它的位置

HBF要插入的位置，恰恰是HBM和SSD之间那个空隙——一个此前只有“内存扩展卡”和“CXL设备”试图填补的领域。

为什么是现在？推理场景的“内存饥渴”

大模型推理的内存消耗，远比训练时更棘手。

HBF的定位，就是把这个“加载”环节的带宽提升一个数量级。

技术路线：从“堆”到“贴”

HBF规范中强调的两个关键词是“堆叠”和“共封装”。

从代码层面看，HBF的驱动和管理也会是一个新的挑战。传统上，NVMe SSD通过块设备接口暴露给操作系统，而HBF更接近内存语义：

// 伪代码示意：HBF设备驱动初始化
struct hbf_device {
    void __iomem *base;
    size_t capacity; // 以GiB为单位
    u32 row_size;    // 行大小，类似HBM的row
};

static int hbf_probe(struct platform_device *pdev)
{
    struct hbf_device *hbf;
    
    hbf = devm_kzalloc(&pdev->dev, sizeof(*hbf), GFP_KERNEL);
    hbf->base = devm_platform_ioremap_resource(pdev, 0);
    hbf->capacity = 512; // 512 GiB per device
    
    // 注册为内存管理单元，而非块设备
    return hbf_memory_register(hbf);
}

这种“内存语义”的设计，意味着未来软件栈可能将HBF视为NUMA节点或异质内存，而非磁盘。对CUDA、ROCm等编程模型的适配，将是HBF能否落地的关键。

谷歌和Tenstorrent为何入局？

这份规范最值得玩味的细节，是谷歌和Tenstorrent被列为反馈方。

HBF的代价与挑战

天下没有免费的午餐。HBF虽然容量大、带宽高，但它的代价也同样明显。

打破内存墙，还是另一堵墙？

HBF的提出，本质上是对“内存墙”问题的又一次正面回应。从HBM到CXL，再到现在的HBF，业界一直在寻找“容量-带宽-成本”的平衡点。

512GiB的HBF，意味着单卡可以加载完整的70B参数模型，而无需跨卡张量并行。对于推理服务商来说，这将直接降低部署成本和运维复杂度。

技术路线的竞争，从来不只是性能的比拼，更是生态和时间的赛跑。HBF的牌面已经亮出，接下来看谁先落子。

总结：

这个事件/技术的核心价值在于它推动了一个重要方向的发展。作为从业者/关注者，我们既要看到短期的影响，也要理解其长期意义。

雷锋网：把512 GiB闪存搬到xPU旁边，HBF能打破推理内存墙？ 原文链接：https://www.leiphone.com/category/chips/P0IOl7W4ZU6ERUnt.html

抖音口播脚本