如果把CPU和GPU看成工厂,那么内存并不是简单意义上的“仓库”,而更接近连接仓库与生产线之间的高速物流系统。计算单元每秒能够执行多少次运算是一回事,内存系统能否持续把数据送到计算单元,又是另一回事。
这也是理解HBM和DDR区别的关键。
DDR的优势是容量大、成本相对可控、扩展灵活,而且经过多年产业化之后,主板、CPU、内存控制器和服务器平台都已经形成成熟生态。HBM则完全不同,它的设计目标并不是用最低成本堆出尽可能大的容量,而是在处理器附近建立一个极宽的内存接口,让大量数据能够以极高吞吐率进出计算芯片。
因此,HBM和DDR并不是简单的“谁更快、谁更先进”的关系,而是两个针对不同瓶颈设计出来的内存体系。
HBM最核心的变化来自封装和接口。
传统DDR内存通常安装在主板DIMM插槽上。CPU通过内存控制器连接多个DDR通道,数据需要经过封装引脚、主板走线以及DIMM上的内存颗粒。服务器可以通过增加内存条获得非常大的容量,这使DDR特别适合操作系统、数据库、虚拟机、大型缓存以及CPU应用服务器。
HBM则把多个DRAM裸片垂直堆叠,通过TSV,也就是硅通孔,把不同DRAM层连接起来。HBM堆栈再通过先进封装与GPU、AI加速器等计算芯片放置在非常近的位置。它最重要的特征并不是“3D内存”这几个字,而是极宽的内存接口。
这使HBM能够在相对有限的信号频率下获得极高的总带宽。
例如NVIDIA A100使用HBM2或HBM2e,80GB版本的理论内存带宽已经超过2TB/s;A100 40GB版本的带宽约为1.555TB/s。
到了H200,HBM3E进一步达到141GB容量和4.8TB/s带宽。
而当前HBM4已经进入下一代AI加速器的技术路线。Micron公布的HBM4 12-high产品单stack容量为36GB,带宽超过2.8TB/s,并采用2048位I/O接口。2026年的16-high产品则可以达到48GB级别。
这几个数字能够说明一个很容易被忽略的问题:HBM的价值主要不是“能装多少”,而是“能以多快的速度持续搬运”。
例如一个AI加速器拥有几百个甚至更多计算单元,Tensor Core可以在极高的吞吐率下进行矩阵乘法。如果每次计算都需要等待外部内存提供数据,那么计算单元越强,内存瓶颈反而越明显。
这就是所谓的memory wall。
计算芯片的算力增长速度长期高于传统内存带宽增长速度。GPU已经能够达到数十甚至数百TFLOPS、乃至PFLOPS级别的特定精度计算能力,但如果内存系统无法及时供应权重、激活值和中间数据,理论算力就无法转换成实际吞吐量。
AI模型恰好属于非常典型的数据密集型计算。
以Transformer为例,矩阵乘法、注意力机制、MLP等操作会反复读取权重和激活数据,并不断产生新的中间结果。GPU需要同时维持大量线程和计算单元运行。如果数据供应跟不上,Tensor Core就会出现空转或者利用率下降。
HBM的作用,就是尽可能把这个数据供应瓶颈往后推。
这里需要特别纠正一个常见误解:并不是“AI计算天然需要把所有数据从DDR搬到HBM,然后HBM越大越好”。
实际GPU内存层级远比这个简单描述复杂。
GPU内部首先有寄存器、共享内存以及L1/L2 Cache,然后才是HBM这样的片外高带宽显存。NVIDIA H200的内存层级中就包括寄存器、Shared/L1、L2 Cache以及141GB HBM3E,HBM带宽达到4.8TB/s。
高性能CUDA程序会通过数据复用、缓存、tile/block划分、异步拷贝等方式,尽量减少对HBM的无效访问。
因此,HBM不是简单的“GPU硬盘”,也不是所有数据都必须反复从HBM读取。它更接近GPU能够直接高吞吐访问的大容量工作集。
DDR承担的角色则不同。
在AI服务器中,CPU内存通常负责操作系统、数据预处理、数据集缓存、DataLoader、CPU端计算以及其他系统任务。训练数据可能最初存放在NVMe SSD、分布式文件系统或者对象存储中,然后经过CPU内存和预处理阶段,再送入GPU。
如果数据管线本身已经成为瓶颈,那么即使GPU拥有4.8TB/s甚至更高的HBM带宽,也无法解决问题。
例如GPU每秒能够处理数百GB的数据,但CPU端tokenization、图像解码、数据增强或者文件系统读取只能提供几十GB/s,那么GPU依然会等待。
所以大型AI服务器实际上存在多个不同的带宽瓶颈:存储到主机内存、主机内存到GPU、GPU HBM内部带宽,以及多GPU之间的NVLink或高速网络通信。
这些链路不能混为一谈。
尤其是PCIe。
当模型或者工作集超过单个GPU的HBM容量时,确实可以通过CPU内存进行offload,但这并不意味着“DDR就是HBM的慢速扩容版”。PCIe链路的带宽和延迟远低于GPU本地HBM,因此频繁发生GPU HBM与CPU DDR之间的数据交换,会产生明显的性能损失。
这也是为什么大模型系统越来越强调模型并行、张量并行、流水线并行、量化、KV Cache优化以及多GPU高速互联,而不是简单地把更多数据丢进主机DDR。
H200就是一个非常直观的例子。
NVIDIA把HBM3E容量提升到141GB,并把带宽提高到4.8TB/s。更大的本地GPU内存意味着更多模型参数、KV Cache以及工作数据能够留在GPU附近,减少跨PCIe或者跨GPU的数据搬运。NVIDIA在LLM推理测试中也明确指出,更大的HBM可以减少部分模型并行需求,从而降低通信开销。
这实际上说明了HBM的另一个价值:它不仅仅提高“每秒读写多少GB”,还可以改变整个计算任务的映射方式。
假设一个模型刚好能够装进单张GPU的HBM,那么系统可以直接在本地完成大量计算。
如果模型装不下,就可能需要模型切分到多张GPU,或者把部分数据offload到CPU内存。这时候问题就从单纯的计算性能变成了计算、显存容量和互联带宽之间的系统工程问题。
因此,大模型硬件设计越来越强调三个指标的组合:计算能力、HBM容量和HBM带宽。
只看TFLOPS已经不足以判断一块AI GPU的实际性能。
同样,单纯比较“显存有多少GB”也不够。
一块GPU如果拥有更大的HBM容量,却无法提供足够的内存带宽,计算单元仍然可能受到memory bandwidth限制;反过来,如果带宽极高但容量不足,系统就可能被迫频繁进行offload或模型切分。
这也是为什么HBM的发展方向一直在同时追求容量、带宽和能效。
HBM4就是这个方向的典型代表。Micron目前公布的HBM4 12-high单stack为36GB,带宽超过2.8TB/s;相比HBM3E,带宽增长幅度非常明显。
需要注意的是,HBM的容量应该按照“每个stack、每颗GPU、每个系统”来理解,而不能简单写成“HBM通常可以达到几TB”。例如H200单GPU是141GB HBM3E,而NVIDIA最新的HGX B300平台则可以达到每GPU 288GB HBM3E,8 GPU节点的HBM总容量达到2.30TB。这里的TB级容量属于整台多GPU服务器,而不是单个HBM堆栈。
DDR则会继续在另一个方向发展。
对于CPU服务器,内存容量依然非常重要。数据库、虚拟化、缓存服务器、大规模内存计算以及大量传统企业应用,并不需要GPU那样数TB/s级别的局部内存带宽,却经常需要数百GB甚至数TB的系统内存。
在这种场景下,如果为了追求HBM带宽而牺牲容量、可扩展性和成本,并不合理。
因此未来的数据中心不会出现“HBM取代DDR”这样的简单结局。
更现实的结构是分层。
存储系统负责保存海量数据,DDR承担CPU侧的大容量工作集,HBM承担GPU或AI加速器附近的高带宽工作集,而GPU内部的缓存和寄存器负责更低延迟、更高复用率的数据。
真正的性能优化,往往不是简单地问“应该买多少内存”,而是判断数据在这些层级之间移动了多少次,以及每一级带宽是否足以支撑计算单元的吞吐量。
对于AI训练尤其如此。
如果模型计算属于compute-bound,继续增加HBM带宽可能带来的收益有限;如果工作负载属于memory-bound,那么HBM带宽就可能成为决定实际性能的关键参数。对于推理任务,模型权重读取、KV Cache访问以及batch size变化又会进一步改变内存带宽和容量的压力。
所以,HBM之所以成为AI时代最重要的存储器件之一,并不是因为AI“特别喜欢一种叫HBM的内存”,而是因为现代AI加速器的计算能力已经高到传统DDR内存系统很难直接喂饱这些计算单元。
GPU算力继续增长以后,问题就不再只是“计算单元够不够多”,而是“数据能不能及时到达计算单元”。
HBM解决的正是这个问题。
而DDR不会因此失去价值。它负责更大的容量、更灵活的系统级内存以及更成熟的成本结构;HBM负责计算芯片旁边的高带宽数据通道。两者并不是竞争关系,而是现代AI服务器内存层级中的不同组成部分。
从这个角度看,未来AI硬件真正的竞争,也不会只是GPU核心数量的竞争,而会越来越集中到HBM容量、HBM带宽、封装技术、GPU互联、缓存体系以及整个数据供应链的协同效率。计算芯片再强,如果数据无法以足够快的速度送到计算单元,昂贵的算力最终也只能等在那里。
HBM 与 DDR 内存分别适合什么场景,AI 计算为什么特别依赖 HBM
喜欢这篇报道?
使用下面的功能,方便以后继续阅读和分享 MNewsTV
关于文章收藏
收藏不需要注册帐号,收藏信息仅保存在当前浏览器中。
删除收藏请进入「我的收藏」进行管理。
分享 Facebook | X | WhatsApp | LinkedIn
捐助(Paypal): https://www.paypal.me/observeccp 订阅中国观察电报 Telegram : https://t.me/s/ObserveCCP