SK hynix 向业界开放 HBF，但真正的考验在于硬件

SK hynix 发布了首份 High Bandwidth Flash 规范，将一项拟议中的 AI 内存层转化为开放的技术蓝图。8 月 4 日的公告通过 Google News 得到广泛传播，但更重要的矛盾隐藏在标题之下。HBF 承诺提供最高 512GB 的容量和高达 3.0TB/s 的带宽，但尚无商用 HBF 系统验证这些目标。

该规范由 SK hynix 与 Sandisk 通过 Open Compute Project 共同制定，描述了一种位于 High Bandwidth Memory 与传统固态硬盘之间的 NAND 闪存方案。它面向 AI 推理场景：加速器在响应用户请求时，需要反复读取庞大的模型权重。Google 和 AI 处理器开发商 Tenstorrent 已加入该联盟，使这一项目除了两家内存供应商之外，也拥有潜在用户。

这并不是 OpenAI 宣布推出一项内存技术。“开放”指的是该规范及其制定模式，而非 ChatGPT 的开发商。真正的竞争，是开放、容量优先的内存层与主要将模型置于昂贵 HBM 中这一既有做法之间的较量。SK hynix 现在拥有规范、可信的合作伙伴和雄心勃勃的目标，但仍需要可用的芯片、加速器支持以及量产经济性。

SK hynix 将 HBF 转化为开放规范

该发布为系统设计人员提供了共同的 HBF 目标，但并未提供一款成熟产品。

SK hynix 和 Sandisk 在加州圣克拉拉举行的 Future of Memory and Storage 会议开幕之际推出了这项规范。该活动于 2026 年 8 月 4 日至 8 月 6 日举行。此次公告是在 Open Compute Project 工作组框架下进行了约六个月标准化工作之后发布的。

两家公司于 2 月 25 日在 Sandisk 位于米尔皮塔斯的总部启动了该工作组。最初，它们将 HBF 描述为位于 HBM 与 SSD 存储之间的新层级。新发布的规范则为这一概念定义了容量、性能等级、接口、封装要求和可靠性指南。

首个版本涵盖采用 8 层或 16 层 NAND die 配置的封装。单个堆栈的最大容量可达 512GB。根据已发布的公告及后续技术报道，共有三个性能等级，带宽范围约为 0.4TB/s 至 3.0TB/s。

这一范围很重要，因为 HBF 并非只有一个固定性能点。较低等级可以侧重容量和能效，而后续实现则可追求接近先进 HBM 的带宽。这样的灵活性也意味着，3.0TB/s 的上限不应被误认为首代产品出货时的保证指标。

HBF 使用的是 NAND 闪存——即 SSD 中采用的非易失性技术——而不是 HBM 所使用的 DRAM。非易失性内存无需持续供电即可保留存储的数据。不过，普通 NAND 无法以接近 HBM 的速度为 AI 加速器供给数据。

HBF 通过堆叠专用 NAND die，并并行访问大量内部阵列来弥合这一差距。逻辑基底 die 负责管理这些连接，并向处理器提供更宽的数据通路。由此形成的封装延续了 HBM 的紧耦合设计理念，同时保留了 NAND 的密度优势。

该规范还采用 Universal Chiplet Interconnect Express，即 UCIe，作为 HBF 与主机处理器之间的连接方式。UCIe 是一种开放的 die-to-die 互连技术，可让 chiplet 在同一封装内交换数据。其纳入为 CPU、GPU 和加速器设计人员提供了共同的集成路径。

UCIe specification 并不会自动实现互操作性。供应商仍需提供控制器、内存管理、错误处理、封装、固件和软件支持。但它确实降低了每家 HBF 供应商各自创建不兼容物理链路的风险。

通过 Open Compute Project 发布同样重要。OCP 规范旨在建立可由多家公司实施的共享要求。其 contribution framework 区分了广泛适用的基础规范与细化、可直接用于制造的产品文档。

这一差异界定了 HBF 当前所处的阶段。SK hynix 和 Sandisk 已经让这一构想超越了演示文稿和私下讨论，但尚未交付可供服务器制造商订购和认证的量产就绪组件。

对于通过 Google News 看到这一消息的读者而言，这一区别是首先要记住的事实。SK hynix 发布的是一项标准规范，而不是一款已可商用的 512GB 内存堆栈。该公告定义了目的地及通往目的地的部分路径。

为什么 AI 推理需要另一层内存

HBF 的存在，是因为 AI 推理既需要快速访问，也需要远超 HBM 经济上所能提供的容量。

训练获得了大多数公众关注，但推理才是将训练完成的模型转化为持续运行服务的过程。在推理过程中，处理器会反复访问模型权重、注意力数据和缓存上下文。更大的模型和更长的对话，会增加必须保留在计算单元附近的数据量。

HBM 承担这类工作负载中速度最快的部分。它将 DRAM die 堆叠在加速器旁边，并通过宽接口连接。该设计提供了卓越的带宽和低延迟，但容量仍然有限，制造也较为复杂。

SSD 以更低的每比特成本解决容量问题。然而，数据在到达加速器之前必须穿过存储控制器和接口。这一路径会引入延迟，且提供的带宽远低于封装级内存。

因此，系统构建者面临一个令人不适的选择。他们可以购买更多配备 HBM 的加速器来容纳大型模型，即使计算资源仍未被充分利用；或者，也可以从 SSD 迁移模型数据，并接受更慢的响应。

HBF 试图创造第三种选择。它将数百 GB 的持久性 NAND 放置得更靠近处理器，并通过高度并行的通道访问这些 NAND。频繁变化的数据可以保留在 HBM 中，而更大的权重集合则可存放在 HBF 中。

这种方法尤其适用于 mixture-of-experts 模型。这类模型包含许多专门的参数组，但每个 token 只激活其中一部分。即使每一步推理只触及较小的工作集，其总容量需求也可能极其庞大。

容量优先的层级可在每个加速器附近容纳更多专家模型。软件可以根据最终架构，将活跃数据迁移至 HBM，或直接从 HBF 访问。无论采用何种方式，都可能减少从远程 SSD 的传输，并降低仅为内存容量而需要的加速器数量。

Sandisk 此前使用 Meta 的 Llama 3.1 405B 模型对 HBF 进行了建模。该公司称，模拟的权重读取性能与拥有无限 HBM 容量的假设系统相比仅相差 2.2%。这一结果仍是公司模拟，而非独立的生产基准测试。

其 HBF architecture analysis 还描述了一个可容纳 512GB 的 16-die 堆栈。Sandisk 表示，该设计可在占地面积、堆栈高度和功耗特征上接近 HBM4。在实体产品经过测试之前，这些仍属于开发目标。

这种比较不应暗示 NAND 已经变成 DRAM。HBM 在延迟和耐久性方面仍具有根本性优势。HBF 的目标是补充 HBM，用于读密集型推理工作负载，而不是取代加速器内存中的每一个字节。

这一定位使该公告有别于另一则“更快 SSD”的故事。HBF 将闪存移入处理器封装，并通过面向内存的接口暴露出来。这一架构改变了数据的存放位置、处理器访问数据的方式，以及系统如何在各个内存层级之间分配工作。

它还可能影响 AI 服务成本。如果一枚加速器能够寻址显著更多的模型数据，运营商可能无需为受容量限制的工作负载部署那么多复制系统。当内存容量而非算术吞吐量决定服务器数量时，这一点尤为重要。

这一机会并不局限于前沿模型。检索系统、推荐引擎和向量搜索工作负载会维护大量需要处理器反复读取的数据集合。边缘系统也可以在本地保留更大的模型，而无需持续从较慢的存储中传输数据。

这些场景都无法得到保证。软件必须在 HBM、HBF 和 SSD 之间智能地放置数据。频繁写入或对延迟有严格要求的工作负载，可能仍不适合 HBF。HBF 的价值取决于是否能将合适的数据匹配到合适的层级。

主要竞争是 HBF 容量与对 HBM 的依赖之间的较量

SK hynix 并非试图在每项任务上击败 HBM；它挑战的是推理必须主要容纳在 HBM 内部这一假设。

这一区别使 HBF 提案更具可信度。NAND 与 DRAM 的直接竞争会暴露 NAND 在延迟和耐久性方面的局限。分层设计则提出另一个问题：是否每个模型权重都值得占据最快、最昂贵的内存空间。

根据初始规范，单个 HBF 堆栈最多可容纳 512GB。即使新一代 HBM 不断提升密度，当前 HBM 堆栈提供的容量仍远低于此。因此，HBF 可以在加速器旁放置更大规模的持久性数据池。

最高 HBF 性能等级标称可达 3.0TB/s。这一数字进入了与单个下一代 HBM 堆栈相关的带宽区间。不过，该规范涵盖了从接近 0.4TB/s 起的广泛范围，且带宽本身并不能说明访问延迟。

处理器还可以同时使用多个 HBM 堆栈。将一个 HBF 堆栈与一个 HBM 堆栈进行比较，并不能描述整个加速器的带宽。实际系统很可能会结合两种技术，并为各自分配不同角色。

开放规范带来的压力并不只针对 HBM 供应商。它同样挑战了掌控高度集成内存系统的加速器厂商。Nvidia、AMD、Google 及其他芯片设计商必须决定，HBF 是否带来足够价值，以证明开发新控制器、封装和软件的合理性。

Google 的参与为联盟带来了重要的工作负载知识来源。Google 运营大型 AI 服务，并设计自己的 Tensor Processing Units。其参与表明，至少有一家超大规模运营商认为，探索容量丰富的内存层级具有价值。

这并不确认 HBF 会被用于未来 TPU。联盟公告中没有 Google 的产品承诺、部署时间表或采购量。参与标准制定可以产生影响，而不一定带来商用设备。

Tenstorrent 则带来了不同视角。该公司开发 AI 处理器，并采用以 chiplet 为导向的开放架构策略。通过 UCIe 连接的 HBF 与这一思路相契合，尽管 Tenstorrent 尚未宣布搭载 HBF 的量产处理器。

公告中未出现的公司，与已出现的公司同样重要。Nvidia、AMD、Intel、Micron、Samsung、Kioxia、Broadcom、Marvell 和 Qualcomm 均未被列为参与者。它们未来的支持将扩大供应商和处理器生态系统。

开放规范可以降低采用门槛，但也会改变竞争格局。SK hynix 和 Sandisk 正在共享足够多的接口信息，以鼓励其他实现方案。如果 HBF 成功，竞争对手可能进入市场并压低价格或利润率。

这是成为标准所必需的取舍。专有接口或许能保护单一供应商，却难以获得广泛的处理器支持。开放接口则能吸引采用，同时将竞争重心转向制造、封装、良率和控制器质量。

SK hynix 深知这笔账的两面。该公司通过 HBM 制造和与加速器厂商的紧密合作，成为 AI 内存领域的重要力量。借助 HBF，它可以将自身的 DRAM 专长、NAND 产品组合和先进封装能力连接起来。

Sandisk 带来了最初的 HBF 概念和 NAND 制程技术。其 2025 年的标准化协议目标是在实现与 HBM 相当带宽的同时，提供 8 至 16 倍的容量。协议还制定了初步的送样路线图。

因此，这项合作结合了互补的利益诉求。Sandisk 希望让闪存更贴近 AI 计算。SK hynix 则希望供应更多内存层级，而不是仅仅将 HBM 保护为唯一的高端层。

这也是为何这一消息的意义超出了 Google News 的报道框架。首份规范为内存厂商、处理器设计商和云运营商提供了协商共享架构的平台。最终胜负不会仅由这份文件决定。

该规范仍存在硬件可信度缺口

HBF 最大的风险很简单：其最吸引人的数字描述的是一份规范和厂商预测，而不是经过验证的量产芯片。

在高密度堆叠中实现 512GB 容量带来了制造挑战。16 个专用 NAND Die 必须通过先进封装实现可靠连接。该堆叠需要具备可接受的热特性、可控的翘曲、足够的良率，以及能够协调大规模并行操作的逻辑 Die。

带宽带来了另一项挑战。NAND 阵列必须并发运行，才能接近拟议的性能等级。控制器必须调度读取、纠正错误、管理坏块，并在高要求工作负载下维持可预测的服务表现。

与带宽相比，延迟仍缺乏明确界定。3.0TB/s 的峰值速率说明在有利条件下能够移动多少数据，却无法说明小型请求返回的速度，也无法说明性能会如何随不规则访问模式而变化。

AI 推理通常会流式读取大型模型权重，这比随机事务性写入更适合闪存。不过，注意力缓存和其他运行时状态可能快速变化。这些结构可能仍需要 HBM 或传统 DRAM。

耐久性同样需要现场证据。HBF 基于 NAND，而 NAND 仅支持有限次数的编程和擦除循环。以读取为主的模型存储减轻了这一顾虑，但生产系统仍需要更新、再平衡和故障恢复。

功耗主张也需要独立验证。NAND 无需刷新供电即可保留数据，因此理论上优于 DRAM。然而，基底 Die、宽接口、纠错机制和并行阵列访问都会消耗能量。

Sandisk 早先的资料表将第一代目标描述为：在 16-Die 堆叠中实现 1.6TB/s 和 512GB。它还声称，其每比特成本处于各类内存技术中最低水平之一。SK hynix 和 Sandisk 均未公布最终商业价格或经过验证的总体系统成本。

经济性不止取决于 NAND Die。先进封装、控制器基底 Die、UCIe 集成、散热、板级设计和软件开发都会增加成本。在包含众多组件的高层堆叠中，良率损失尤其重要。

该规范覆盖 0.4TB/s 至 3.0TB/s 的宽泛范围，也带来了另一项不确定性。它可以支持多代产品，但也使关于“HBF 性能”的笼统说法价值有限。买方需要审视每种实现的等级、容量、延迟、耐久性和功耗。

此外还存在采用循环。内存供应商需要处理器承诺，才会大举投资生产。处理器厂商则希望在重新设计封装前获得可靠样品和多家供应商。云运营商希望在重写内存管理软件前先看到经过测试的系统。

开放标准可以通过为每个参与者提供稳定目标来打破这一循环，但无法消除财务风险。HBF 联盟必须将兴趣转化为参考设计、控制器、验证工具和采购承诺。

最乐观的公开路线图来自 Sandisk，发布于 2025 年。它计划在 2026 年下半年提供首批 HBF 内存样品，并预计在 2027 年初提供使用 HBF 的 AI 推理设备样品。

该送样路线图尚未变成量产时间表。样品可供合作伙伴测试可行性，却无法证明良率、供货能力或数据中心可靠性。

这一缺口应当影响读者对该公告的理解。SK hynix 并未证明 HBF 能解决推理内存墙问题。它发布的是一份关于如何构建和连接相关硬件的详细提案。

最有力的质疑并非 HBF 没有实际用途。内存容量问题确实存在，而分层架构是成熟的工程应对方式。担忧在于，这一具体实现是否能在计入延迟、封装、软件和成本后仍带来足够收益。

开放 HBF 给更广泛的内存市场带来压力

这份规范迫使内存和加速器公司作出回应，即使它们最终决定不采用 HBF。

Samsung 和 Micron 在 HBM 领域与 SK hynix 直接竞争。Kioxia 则在 NAND 领域竞争，并与 Sandisk 存在制造关联。它们如今都面临选择：参与其中、开发兼容实现，或推广另一种解决方案。

加入将增强 HBF 的正当性，却意味着参与者将接触到一项最初由 SK hynix 和 Sandisk 塑造的标准。留在体系之外能保留战略独立性，但也可能让两家竞争对手定义一个新兴接口。

加速器厂商也面临类似的权衡。一个容量丰富的闪存层可以帮助它们支持更大的模型，而无需增加等量的 HBM 容量。但它也可能使封装设计更复杂，并削弱现有内存架构的简洁性。

Nvidia 的立场尤其值得关注，因为其加速器支撑着当前 AI 基础设施市场的大部分。Nvidia 尚未宣布采用 HBF。如果缺少领先加速器平台的支持，HBF 可能仍局限于定制芯片和专用推理系统。

Google 的参与在一定程度上抵消了这一风险。拥有自研处理器的超大规模云服务商无需等待商用 GPU 路线图，便可采用新的内存架构。成功的内部部署能够提供技术证据和可观的规模。

Tenstorrent 可以测试这一开放接口是否适用于较小的处理器生态系统。它的参与也让联盟的构成超越了既有的内存和云计算公司。不过，目前两家参与者都无法保证市场的大规模接受。

HBF 项目遵循了数据中心硬件中既有的模式：少数公司定义通用接口，通过行业组织发布，并在产品成熟前招募用户。其成功取决于竞争者是否认为互操作性比控制权更有价值。

HBM 则通过 JEDEC 标准和内存供应商、处理器设计商之间的紧密协作，走过了不同的制度路径。HBF 的 OCP 路径让云运营商和系统架构师更接近规范制定过程。

这种方法符合其目标工作负载。AI 推理基础设施横跨处理器、内存、存储、网络、编排和应用软件。仅优化内存组件会忽略重要的系统瓶颈。

当软件反复请求细小、分散的数据块时，512GB HBF 堆叠无法提升性能。只有当编译器和运行时将权重组织为长距离顺序读取时，它才更有用。系统架构决定了所宣传的带宽能否转化为有效工作。

因此，开发者可能会先通过软件接触 HBF，之后才会接触硬件规范。框架需要分配策略、性能分析工具和放置控制。运营商则需要跨 HBM、HBF 和 SSD 层级的可观测性。

这类似于根据相关性和访问频率管理信息的更广泛工作。一个可搜索知识库同样会将活跃上下文与更大的保留集合分开。HBF 则以硬件速度将类似的层级应用于机器数据。

这一类比存在局限，但其原则颇具参考价值。最快的资源依然稀缺。系统在将即时所需信息留在近处、将不那么紧急的材料移至更大支撑层时会得到改善。

这正是 HBF 的战略论点。它无需取代 HBM 才能变得重要。它需要做的是，让 HBM 容量对于一组有意义的推理工作负载不再那么决定性。

当 Google News 头条淡出后应关注什么

三项信号将决定 HBF 是成为 AI 内存标准，还是停留在雄心勃勃的纸面架构。

第一个信号是实体样品交付。Sandisk 的公开路线图计划在 2026 年下半年提供 HBF 内存样品。可工作的封装将让合作伙伴在可重复条件下测量延迟、持续带宽、耐久性、热特性和功耗。

接近所述性能等级的结果，将强化“大规模并行 NAND 可作为近处理器内存”的论点。若出现延迟，或峰值与持续性能之间存在巨大差距，则会削弱该规范以容量为先的论点。

最有价值的基准测试应比较完整系统，而非孤立封装。它应衡量每秒 token 数、首个 token 时间、每 token 能耗和服务器总成本，并披露有多少数据仍保留在 HBM 中。

第二个信号是具名的处理器设计。Google 和 Tenstorrent 已加入联盟，但均未宣布采用 HBF 的量产加速器。一款具体芯片、封装或参考平台将表明，集成工作已超越顾问式参与。

若在 2027 年初出现推理设备样品，与 Sandisk 早先的时间表相符，将支持联盟的执行主张。处理器合作伙伴若保持沉默，则意味着封装或软件工作可能仍未解决。

Nvidia、AMD 或其他商用加速器厂商的加入将格外重要。它们的参与会将 HBF 扩展到定制系统之外，并提高其吸引多家内存供应商的机会。

第三个信号是更广泛的供应商和软件支持。当独立公司能够构建兼容组件时，开放标准才会变得坚韧。因此，Samsung、Micron、Kioxia、控制器厂商、封装公司和云运营商都至关重要。

软件支持同样重要。AI 框架必须将 HBF 识别为独立层级，并根据访问模式放置数据。缺少这一层，开发者将面临手动调优和不一致的性能。

SK hynix 的 8 月公告设立了一个重要检查点。该公司与 Sandisk 已定义容量、性能等级、堆叠配置、连接方式和可靠性目标。Google 和 Tenstorrent 则增添了可信的行业参与。

这项发布并未解答更棘手的问题。尚无任何公开量产系统展现出所宣称的容量、带宽、延迟、功耗与成本之间的平衡。也没有任何领先的商用加速器厂商承诺采用该接口。

通过 Google News 关注此事的读者，应当留意这三个信号，而非又一轮理论比较：经过实测的芯片、具名的加速器，以及更多独立实现者。

如果三者都出现，HBF 有望成为 HBM 和 SSD 的实用补充。如果积累的只有规格参数与模拟结果，行业仍将通过更多 HBM、传统存储和软件优化来应对推理容量问题。

因此，下一条决定性新闻应当包含产品名称和实测工作负载结果。在此之前，SK hynix 已为突破 AI 内存壁垒开辟了一条颇具前景的路径，但硬件尚未真正跨越这道壁垒。