把512 GiB闪存搬到xPU旁边,HBF能打破推理内存墙?
英文标题:把512 GiB闪存搬到xPU旁边,HBF能打破推理内存墙?
HBM已经证明,通过堆叠和共封装把存储介质迁移至GPU附近,可以缓解AI计算中的数据搬运瓶颈。现在,SK海力士联合闪迪,将类似的思路正式应用到NAND上,通过HBF将大容量闪存放到包括GPU在内的各类xPU旁,以缓解AI推理内存墙问题。近日,双方通过OCP发布《High Bandwidth Flash(HBF)High-Level Base Die Specification, Version 0.7.0》。谷歌和Tenstorrent在致谢中被列为规范的反馈与建议提供方。这份约130页的规范,首次明确了HBF的位置、边界与代价:介于HBM与SSD之间,HBF是紧邻xPU、由Base Die和
123.3 KB
2.3 KB
1.6 KB
37.5 KB
40.2 KB
33.2 KB
142.9 KB
779.3 KB
8.8 KB
36.9 KB
32.2 KB
34.1 KB
35.5 KB
21.6 KB
15.3 KB
12.5 KB
9.3 KB
1.8 KB
中文
HBM已经证明,通过堆叠和共封装把存储介质迁移至GPU附近,可以缓解AI计算中的数据搬运瓶颈。
现在,SK海力士联合闪迪,将类似的思路正式应用到NAND上,通过HBF将大容量闪存放到包括GPU在内的各类xPU旁,以缓解AI推理内存墙问题。
近日,双方通过OCP发布《High Bandwidth Flash(HBF)High-Level Base Die Specification, Version 0.7.0》。谷歌和Tenstorrent在致谢中被列为规范的反馈与建议提供方。
这份约130页的规范,首次明确了HBF的位置、边界与代价:
-
介于HBM与SSD之间,HBF是紧邻xPU、由Base Die和主机软件共同管理的大容量闪存。
-
应用范围从静态模型权重进一步延伸至KV Cache、多模型、MoE和Agent工作负载。
-
NAND的写入、耐久性和管理上的物理约束并未被消除。这些约束带来的复杂性,最终转移到了Base Die和加速器的软件栈上。
在不改变规范原意的基础上,雷峰网(公众号:雷峰网)对此进行编译和整理,重点解读HBF的系统定位、高带宽缘起、推理应用场景以及NAND介质带来的工程约束。
内存墙问题从CPU时代一直延续到当今以数据为中心的计算系统中。当GPU的性能提升速度持续快于内存响应时间,数据搬运也就越来越成为性能瓶颈。
与此同时,大语言模型规模和上下文长度的增长,对更高的内存带宽和大幅增加的内存容量都提出了需求。
AI处理所涉及的数据大致可分为两类:一类包括模型输入和连续处理层生成的中间结果,这些数据是动态的,通常被称为激活值 ;另一类包括定义模型的权重 (参数)。
在推理运行期间,模型权重一般保持不变。然而,它们的总量可能远超单颗处理芯片或其本地缓存所能容纳的规模。
对于足够大的模型来说,部分权重可能存储在机架内的SSD上,或位于距离处理器更远的网络附加存储中。
这就形成了一条多层级的数据路径:非易失性存储 提供长期容量,计算所需的权重被带入DRAM (可能是HBM),然后缓存在处理器侧的SRAM 中。
因此,一个权重第一次被访问时,数据可能要穿过好几层存储层级才能到达处理器。如果这个权重后来被挤出缓存,而之后又需要用到它,那同样的路径就得再走一遍。
HBF背后的构想与催生HBM的思路相似:通过堆叠和共封装,将存储介质移近计算单元。
但二者使用的介质和承担的角色不同。HBM以DRAM提供低延迟、高读写带宽的工作内存;HBF则试图利用容量更大的NAND,在保持较高聚合读取带宽的同时,承接部分原本存放在SSD或网络存储中的大规模、以读取为主的数据,例如模型权重。
在部分系统设计中,预先存入HBF的模型权重可以绕过传统的DRAM暂存环节,直接向处理器侧缓存传输。这样的设计尽管会使缓存和内存管理变得复杂,但的确省掉一部分从外部存储到DRAM的传输开销。
正如Expedera首席科学家兼联合创始人Sharad Chole所描述的,HBF旨在弥合“高带宽访问与高存储容量”之间的鸿沟。这个定位比简单地将HBF描述为更快的SSD或基于闪存的HBM更为精确。
HBF将模型权重放入处理器封装内的一种概念架构
图源Bryon Moyer / Semiconductor Engineering
而OCP规范将HBF正式定义为一个非一致性的、以内存为中心的闪存设备 ,紧邻GPU、TPU或其他xPU。其目的是通过在处理器附近附加TB级的额外内存容量来增强HBM。
因此,HBF既不是直接取代了HBM,也不是简单为后者增加容量。它在高带宽内存与传统存储之间增加了另一个内存层级,使更大比例的模型数据在物理上保持更靠近计算单元。
一个HBF设备由三个主要元素构成:
-
一个Base Die;
-
一个NAND Core Die堆叠;
-
连接Base Die与NAND堆叠的TSV通道。
Base Die不只是一个无源互连层。在与主机xPU保持通信的同时,Base Die管理UCIe协议并控制主机接口与NAND die之间的数据移动。
此外,它还负责处理主机和NAND命令、ECC编码和解码、错误报告、传输调度、读/写/擦除状态、NAND初始化和TSV冗余映射。
这种分工让HBF与“直接把闪存die放在处理器旁边”有了本质区别:NAND堆叠提供容量,而Base Die为堆叠提供了作为片上封装内存设备所需的控制、接口和可靠性机制。
HBF Base Die、NAND Core Die堆叠与xPU连接
图源OCP规范
xPU通过UCIe 3.0跟HBF连接,这是一种用于封装内die-to-die互连 的标准。在UCIe(Universal Chiplet Interconnect Express)接口之上,用AXI 作为通信协议。简单来说,UCIe负责物理层和链路层的基础,AXI则承载主机和HBF之间的读写操作。
规范里对UCIe协议层、Flit格式和AXI通道有非常详细的描述。但如果只关心HBF在系统里的角色,关键在于它需要一套专用的片上封装接口 ,xPU和HBF两边都得有对应的链路层实现,而不是像PCIe SSD那样,随便接到现有加速器上就能用的。
一个HBF堆叠最多可支持16个主机通道。每个通道使用独立的UCIe链路并提供对其自身NAND资源的访问。通过一个通道发出的请求不能访问连接到另一个通道的数据。
每个通道也有自己连续的本地地址空间。Base Die将该本地地址空间映射到物理NAND存储体、die和块上。在系统层面,主机软件负责将主机的全局地址映射到可用HBF通道的本地地址空间上。
其结果并非一个单一的、自动统一的闪存池,而是一种通道化架构,其性能部分取决于主机如何在多个独立资源之间分布数据和请求。
这种区别很重要,因为规范还要求HBF和HBM在同一个系统中使用时必须分开管理 。HBF不会自动成为HBM一致性地址空间的一部分。软件 必须决定哪些数据属于哪个内存层级,以及数据应如何移动、分区和访问。
规范定义了三个性能等级:
规范给出的参考配置采用16颗NAND Die、每通道16个Bank和4KiB NAND页,总容量为512GiB(GiB按二进制计量,GB按十进制计量,约合550 GB),并允许更高容量的HBF堆叠。
最高约3TB/s的带宽目标,并不是因为单颗NAND获得了接近HBM的性能,而是通过16条主机通道,以及多Die、多Bank和多阵列并行汇聚而成。最高配置下,每条通道采用64位接口,每条数据lane速率最高为32GT/s。
要真正利用这些并行资源,数据需要分布在足够多的通道、Die和Bank中,主机也必须维持足够的请求并发性,由Base Die完成相应调度。
因此,约3TB/s更准确地说是最高配置下的规范目标,而非真实芯片或推理负载的实测结果。
即使聚合读取带宽进入HBM量级,HBF也不等同于HBM。二者在延迟、写入能力、访问粒度、耐久性和内存语义上仍有明显差异。
HBF的核心优势,是以大容量NAND配合高并行读取,而不是在所有工作负载下获得与DRAM相同的表现。
模型权重仍然是HBF最自然的工作负载。
它们的范围可从数GiB达到数十乃至数百GiB,必须在Token生成期间被获取,且在推理期间通常保持不变。这使得它们比必须持续重写的数据更适合读取优化、高容量的NAND层级。
正如内存分析师Jim Handy所总结的区别:“训练不断改变模型权重,而推理 通常使它们保持不变”。
然而,OCP规范赋予HBF的范围超越了静态权重存储。其应用章节包括单一LLM服务、存储和切换多个LLM、混合专家模型、多模态模型、智能体工作负载、AI参数加载和KV Cache读写。
对于单一模型,规范描述了将模型参数分布到所有主机通道上,以便它们可以被并行读取。对于多个模型 ,它提供了两种可能的布局:
在HBF中保持多个模型,也可以减少当活动模型切换时从外部SSD重新加载整个模型的需求。虽然这并不意味着模型切换没有延迟,但它可以消除传统部署中单独的SSD到加速器加载步骤。
MoE、多模态和智能体工作负载 ,在HBF上的数据放置可以沿用多模型案例的两种策略:要么把数据打散到所有通道上以追求最大带宽,要么把数据放在指定通道里优先考虑容量分配和工作负载隔离。
更重要的扩展,是KV Cache 。
在Prefill预填充阶段,模型各层会计算并写入KV Cache;进入Decode(解码)阶段后,注意力模块(Attention)读取先前生成的KV Cache,并在生成后续Token时添加新的缓存内容。
因此,与推理期间基本保持不变的模型权重相比,KV Cache会在推理过程中持续增长,并不断发生读写。
规范期望主机理解LLM或AI工作负载的结构,并安排KV Cache数据以优化读写性能。因此,HBF不仅被定义为一个参数加载设备,还被定义为推理运行时生成数据的一个可能的存储目标 。
这扩大了HBF的潜在价值,尤其是在更长的上下文和智能体工作负载增加内存容量需求的情况下。但它也使该架构直接接触到NAND最弱的特性——频繁写入 。
尽管HBF改变了闪存的位置、接口和内部并行性,其底层介质仍然是NAND。
NAND闪存的物理结构决定了它的读写方式。闪存芯片内部被划分为若干块(block),每个块又进一步分为若干页(page)。
规范中使用的是4 KiB大小的NAND页,并支持4 KiB对齐的突发写入。小于4 KiB的写入请求不会立即写入NAND Core Die,而是先在Base Die中缓存,凑满一个完整的4 KiB页面后再写入。
在NAND块内部,HBF要求顺序写入。它不支持对已编程页面的直接随机覆盖写入。要重写一个块里的任何数据,不能直接覆盖,必须先把整个块擦除,然后从头开始,按规定的页面顺序重新写入一遍。
这些规则与大型、预定的模型权重布局相对兼容——权重是一次写入、反复读取的数据,写入时按顺序以完整页面写入即可。
但对于动态生成的数据来说却是一件困难的事,其大小、生命周期和更新模式在推理期间随时可能变化。
像KV Cache这类需要频繁进行小粒度写入的数据,规范并未声称所有KV Cache工作负载都能在HBF上表现良好,实际性能将取决于主机如何组合小写入、布局KV Cache页面,并避免产生NAND块低效使用的模式。
因为模型权重和KV Cache具有不同的读写模式,规范也指出,将两者混合在同一区域可能会降低耐久性和容量利用率。 因此,它建议以通道粒度 对HBF进行分区,并提供两种示例策略:
模型权重与KV Cache之间的通道分区
图源OCP规范
这也说明HBF的数据布局不能完全交给硬件自动完成。主机 必须了解工作负载的特点,估算权重和KV Cache各需要多少容量,再决定给两边各分配多少带宽和耐久性预算。
由主机参与管理的方式,还延伸到KV Cache之外。
由于各条HBF通道拥有独立的地址空间,主机软件还需要将全局地址映射到不同通道,决定数据如何交错,并分别管理HBF与HBM。
对NAND介质本身的维护,也并非全部封装在Base Die内部。磨损均衡既可以由Base Die 完成,也可以由主机 通过区域重映射进行控制。
主机可以调整逻辑地址与物理位置之间的映射,使编程和擦除次数更均匀地分布,但重映射命令不会自动迁移已有数据。主机需要先停止相关访问,再将数据重新写入新的位置。
数据保持和读取干扰 同样需要定期处理。Base Die负责检测并上报NAND状态,主机则可能需要刷新数据、重试读取、隔离故障容量,或等待设备完成恢复操作。
不过,HBF并未将传统SSD控制器承担的全部功能转移给主机软件。Base Die仍负责NAND命令、ECC、请求调度和错误检测,但数据布局、部分磨损管理和异常恢复需要主机共同参与。
因此,HBF的职责划分也不同于HBM和传统SSD。基于DRAM的前者,无需面对NAND存在的管理复杂度;后者虽然同样使用NAND,但地址转换、垃圾回收和磨损管理通常由SSD控制器完成,上层软件基本感知不到这些管理过程。
HBF则处于另一种状态:Base Die保留了设备侧控制能力,但没有将所有NAND介质管理完全封装起来。为了充分利用其容量和并行带宽,xPU主机及其软件仍需理解通道、数据布局和部分介质状态。
这正是HBF最核心的取舍:它把大容量NAND移到更靠近计算的位置,同时也要求硬件、固件、运行时软件与工作负载的数据布局进行更紧密的协同。
作者长期关注AI芯片上下游,更多信息可添加微信 Evelynn7778 交流。
English / 原文
HBM已经证明,通过堆叠和共封装把存储介质迁移至GPU附近,可以缓解AI计算中的数据搬运瓶颈。
现在,SK海力士联合闪迪,将类似的思路正式应用到NAND上,通过HBF将大容量闪存放到包括GPU在内的各类xPU旁,以缓解AI推理内存墙问题。
近日,双方通过OCP发布《High Bandwidth Flash(HBF)High-Level Base Die Specification, Version 0.7.0》。谷歌和Tenstorrent在致谢中被列为规范的反馈与建议提供方。
这份约130页的规范,首次明确了HBF的位置、边界与代价:
-
介于HBM与SSD之间,HBF是紧邻xPU、由Base Die和主机软件共同管理的大容量闪存。
-
应用范围从静态模型权重进一步延伸至KV Cache、多模型、MoE和Agent工作负载。
-
NAND的写入、耐久性和管理上的物理约束并未被消除。这些约束带来的复杂性,最终转移到了Base Die和加速器的软件栈上。
在不改变规范原意的基础上,雷峰网(公众号:雷峰网)对此进行编译和整理,重点解读HBF的系统定位、高带宽缘起、推理应用场景以及NAND介质带来的工程约束。
内存墙问题从CPU时代一直延续到当今以数据为中心的计算系统中。当GPU的性能提升速度持续快于内存响应时间,数据搬运也就越来越成为性能瓶颈。
与此同时,大语言模型规模和上下文长度的增长,对更高的内存带宽和大幅增加的内存容量都提出了需求。
AI处理所涉及的数据大致可分为两类:一类包括模型输入和连续处理层生成的中间结果,这些数据是动态的,通常被称为激活值 ;另一类包括定义模型的权重 (参数)。
在推理运行期间,模型权重一般保持不变。然而,它们的总量可能远超单颗处理芯片或其本地缓存所能容纳的规模。
对于足够大的模型来说,部分权重可能存储在机架内的SSD上,或位于距离处理器更远的网络附加存储中。
这就形成了一条多层级的数据路径:非易失性存储 提供长期容量,计算所需的权重被带入DRAM (可能是HBM),然后缓存在处理器侧的SRAM 中。
因此,一个权重第一次被访问时,数据可能要穿过好几层存储层级才能到达处理器。如果这个权重后来被挤出缓存,而之后又需要用到它,那同样的路径就得再走一遍。
HBF背后的构想与催生HBM的思路相似:通过堆叠和共封装,将存储介质移近计算单元。
但二者使用的介质和承担的角色不同。HBM以DRAM提供低延迟、高读写带宽的工作内存;HBF则试图利用容量更大的NAND,在保持较高聚合读取带宽的同时,承接部分原本存放在SSD或网络存储中的大规模、以读取为主的数据,例如模型权重。
在部分系统设计中,预先存入HBF的模型权重可以绕过传统的DRAM暂存环节,直接向处理器侧缓存传输。这样的设计尽管会使缓存和内存管理变得复杂,但的确省掉一部分从外部存储到DRAM的传输开销。
正如Expedera首席科学家兼联合创始人Sharad Chole所描述的,HBF旨在弥合“高带宽访问与高存储容量”之间的鸿沟。这个定位比简单地将HBF描述为更快的SSD或基于闪存的HBM更为精确。
HBF将模型权重放入处理器封装内的一种概念架构
图源Bryon Moyer / Semiconductor Engineering
而OCP规范将HBF正式定义为一个非一致性的、以内存为中心的闪存设备 ,紧邻GPU、TPU或其他xPU。其目的是通过在处理器附近附加TB级的额外内存容量来增强HBM。
因此,HBF既不是直接取代了HBM,也不是简单为后者增加容量。它在高带宽内存与传统存储之间增加了另一个内存层级,使更大比例的模型数据在物理上保持更靠近计算单元。
一个HBF设备由三个主要元素构成:
-
一个Base Die;
-
一个NAND Core Die堆叠;
-
连接Base Die与NAND堆叠的TSV通道。
Base Die不只是一个无源互连层。在与主机xPU保持通信的同时,Base Die管理UCIe协议并控制主机接口与NAND die之间的数据移动。
此外,它还负责处理主机和NAND命令、ECC编码和解码、错误报告、传输调度、读/写/擦除状态、NAND初始化和TSV冗余映射。
这种分工让HBF与“直接把闪存die放在处理器旁边”有了本质区别:NAND堆叠提供容量,而Base Die为堆叠提供了作为片上封装内存设备所需的控制、接口和可靠性机制。
HBF Base Die、NAND Core Die堆叠与xPU连接
图源OCP规范
xPU通过UCIe 3.0跟HBF连接,这是一种用于封装内die-to-die互连 的标准。在UCIe(Universal Chiplet Interconnect Express)接口之上,用AXI 作为通信协议。简单来说,UCIe负责物理层和链路层的基础,AXI则承载主机和HBF之间的读写操作。
规范里对UCIe协议层、Flit格式和AXI通道有非常详细的描述。但如果只关心HBF在系统里的角色,关键在于它需要一套专用的片上封装接口 ,xPU和HBF两边都得有对应的链路层实现,而不是像PCIe SSD那样,随便接到现有加速器上就能用的。
一个HBF堆叠最多可支持16个主机通道。每个通道使用独立的UCIe链路并提供对其自身NAND资源的访问。通过一个通道发出的请求不能访问连接到另一个通道的数据。
每个通道也有自己连续的本地地址空间。Base Die将该本地地址空间映射到物理NAND存储体、die和块上。在系统层面,主机软件负责将主机的全局地址映射到可用HBF通道的本地地址空间上。
其结果并非一个单一的、自动统一的闪存池,而是一种通道化架构,其性能部分取决于主机如何在多个独立资源之间分布数据和请求。
这种区别很重要,因为规范还要求HBF和HBM在同一个系统中使用时必须分开管理 。HBF不会自动成为HBM一致性地址空间的一部分。软件 必须决定哪些数据属于哪个内存层级,以及数据应如何移动、分区和访问。
规范定义了三个性能等级:
规范给出的参考配置采用16颗NAND Die、每通道16个Bank和4KiB NAND页,总容量为512GiB(GiB按二进制计量,GB按十进制计量,约合550 GB),并允许更高容量的HBF堆叠。
最高约3TB/s的带宽目标,并不是因为单颗NAND获得了接近HBM的性能,而是通过16条主机通道,以及多Die、多Bank和多阵列并行汇聚而成。最高配置下,每条通道采用64位接口,每条数据lane速率最高为32GT/s。
要真正利用这些并行资源,数据需要分布在足够多的通道、Die和Bank中,主机也必须维持足够的请求并发性,由Base Die完成相应调度。
因此,约3TB/s更准确地说是最高配置下的规范目标,而非真实芯片或推理负载的实测结果。
即使聚合读取带宽进入HBM量级,HBF也不等同于HBM。二者在延迟、写入能力、访问粒度、耐久性和内存语义上仍有明显差异。
HBF的核心优势,是以大容量NAND配合高并行读取,而不是在所有工作负载下获得与DRAM相同的表现。
模型权重仍然是HBF最自然的工作负载。
它们的范围可从数GiB达到数十乃至数百GiB,必须在Token生成期间被获取,且在推理期间通常保持不变。这使得它们比必须持续重写的数据更适合读取优化、高容量的NAND层级。
正如内存分析师Jim Handy所总结的区别:“训练不断改变模型权重,而推理 通常使它们保持不变”。
然而,OCP规范赋予HBF的范围超越了静态权重存储。其应用章节包括单一LLM服务、存储和切换多个LLM、混合专家模型、多模态模型、智能体工作负载、AI参数加载和KV Cache读写。
对于单一模型,规范描述了将模型参数分布到所有主机通道上,以便它们可以被并行读取。对于多个模型 ,它提供了两种可能的布局:
在HBF中保持多个模型,也可以减少当活动模型切换时从外部SSD重新加载整个模型的需求。虽然这并不意味着模型切换没有延迟,但它可以消除传统部署中单独的SSD到加速器加载步骤。
MoE、多模态和智能体工作负载 ,在HBF上的数据放置可以沿用多模型案例的两种策略:要么把数据打散到所有通道上以追求最大带宽,要么把数据放在指定通道里优先考虑容量分配和工作负载隔离。
更重要的扩展,是KV Cache 。
在Prefill预填充阶段,模型各层会计算并写入KV Cache;进入Decode(解码)阶段后,注意力模块(Attention)读取先前生成的KV Cache,并在生成后续Token时添加新的缓存内容。
因此,与推理期间基本保持不变的模型权重相比,KV Cache会在推理过程中持续增长,并不断发生读写。
规范期望主机理解LLM或AI工作负载的结构,并安排KV Cache数据以优化读写性能。因此,HBF不仅被定义为一个参数加载设备,还被定义为推理运行时生成数据的一个可能的存储目标 。
这扩大了HBF的潜在价值,尤其是在更长的上下文和智能体工作负载增加内存容量需求的情况下。但它也使该架构直接接触到NAND最弱的特性——频繁写入 。
尽管HBF改变了闪存的位置、接口和内部并行性,其底层介质仍然是NAND。
NAND闪存的物理结构决定了它的读写方式。闪存芯片内部被划分为若干块(block),每个块又进一步分为若干页(page)。
规范中使用的是4 KiB大小的NAND页,并支持4 KiB对齐的突发写入。小于4 KiB的写入请求不会立即写入NAND Core Die,而是先在Base Die中缓存,凑满一个完整的4 KiB页面后再写入。
在NAND块内部,HBF要求顺序写入。它不支持对已编程页面的直接随机覆盖写入。要重写一个块里的任何数据,不能直接覆盖,必须先把整个块擦除,然后从头开始,按规定的页面顺序重新写入一遍。
这些规则与大型、预定的模型权重布局相对兼容——权重是一次写入、反复读取的数据,写入时按顺序以完整页面写入即可。
但对于动态生成的数据来说却是一件困难的事,其大小、生命周期和更新模式在推理期间随时可能变化。
像KV Cache这类需要频繁进行小粒度写入的数据,规范并未声称所有KV Cache工作负载都能在HBF上表现良好,实际性能将取决于主机如何组合小写入、布局KV Cache页面,并避免产生NAND块低效使用的模式。
因为模型权重和KV Cache具有不同的读写模式,规范也指出,将两者混合在同一区域可能会降低耐久性和容量利用率。 因此,它建议以通道粒度 对HBF进行分区,并提供两种示例策略:
模型权重与KV Cache之间的通道分区
图源OCP规范
这也说明HBF的数据布局不能完全交给硬件自动完成。主机 必须了解工作负载的特点,估算权重和KV Cache各需要多少容量,再决定给两边各分配多少带宽和耐久性预算。
由主机参与管理的方式,还延伸到KV Cache之外。
由于各条HBF通道拥有独立的地址空间,主机软件还需要将全局地址映射到不同通道,决定数据如何交错,并分别管理HBF与HBM。
对NAND介质本身的维护,也并非全部封装在Base Die内部。磨损均衡既可以由Base Die 完成,也可以由主机 通过区域重映射进行控制。
主机可以调整逻辑地址与物理位置之间的映射,使编程和擦除次数更均匀地分布,但重映射命令不会自动迁移已有数据。主机需要先停止相关访问,再将数据重新写入新的位置。
数据保持和读取干扰 同样需要定期处理。Base Die负责检测并上报NAND状态,主机则可能需要刷新数据、重试读取、隔离故障容量,或等待设备完成恢复操作。
不过,HBF并未将传统SSD控制器承担的全部功能转移给主机软件。Base Die仍负责NAND命令、ECC、请求调度和错误检测,但数据布局、部分磨损管理和异常恢复需要主机共同参与。
因此,HBF的职责划分也不同于HBM和传统SSD。基于DRAM的前者,无需面对NAND存在的管理复杂度;后者虽然同样使用NAND,但地址转换、垃圾回收和磨损管理通常由SSD控制器完成,上层软件基本感知不到这些管理过程。
HBF则处于另一种状态:Base Die保留了设备侧控制能力,但没有将所有NAND介质管理完全封装起来。为了充分利用其容量和并行带宽,xPU主机及其软件仍需理解通道、数据布局和部分介质状态。
这正是HBF最核心的取舍:它把大容量NAND移到更靠近计算的位置,同时也要求硬件、固件、运行时软件与工作负载的数据布局进行更紧密的协同。
作者长期关注AI芯片上下游,更多信息可添加微信 Evelynn7778 交流。