你买的美光、铠侠、长鑫，背后的HBM、DDR5、NAND都在算力中心哪里？

2026/07/24携剑陟峰人

摘要：HBM、DDR5和NAND经常被统称为存储芯片，但在AI服务器和算力中心中，它们承担的任务并不相同。本文从GPU侧内存、主机内存、本地NVMe、分布式文件系统到对象存储，梳理数据从长期保存到进入GPU计算的完整路径，并结合我从DAS、FC SAN到AI分布式存储的项目经历，说明传统存储技术为什么没有消失，而是在AI场景下被重新组织。

最近一段时间，存储成了AI产业和资本市场里反复出现的关键词，朋友圈很多人都在晒长鑫科技新股中签。

长鑫科技相关截图

与此同时，今年2月，三星宣布量产并向客户出货HBM4，并预计2026年HBM销售额将达到2025年的三倍以上。7月，三星又宣布量产面向AI和HPC服务器的PCIe 6.0企业级SSD PM1763。SK海力士也在7月公布了新的投资计划，理由不仅包括HBM和服务器DRAM，还包括AI带来的企业级SSD和NAND需求。美光6月发布的2026财年第三季度材料里，则同时提到了HBM4、256GB DDR5 RDIMM、PCIe Gen6 SSD和245TB QLC SSD的进展。

美光扩产

美光扩产

如果把标题中的三家公司和产品对应起来，会更容易理解它们在算力中心中的位置：

  • 美光的数据中心产品覆盖HBM、DDR5、NAND和数据中心SSD，对应GPU侧高带宽内存、CPU侧主机内存以及持久化存储等多个层级。

  • 铠侠主要位于NAND与SSD这一侧，其闪存和SSD产品会以企业级、数据中心级SSD等形态进入服务器和存储系统。

  • 长鑫专注于DRAM，其产品页面已经列出DDR5颗粒和模组，主要对应服务器的CPU侧主机内存。

AI热潮带火的不只是GPU，也包括GPU周围的内存与存储。

我们做算力相关工作，关注的不能只是某一种存储芯片涨价，或者哪家公司受到市场追捧。更应该弄清楚的是：同样被叫作存储芯片，HBM、DDR5和NAND进入一台AI服务器以后，为什么不在同一个位置，也不做同一件事？HBM紧挨着GPU，DDR5主要服务CPU，NAND更多以SSD的形式保存数据。再把视角从一台服务器拉到整个算力中心，还会看到本地NVMe、分布式文件系统、对象存储和数据湖。

理解AI时代的存储，不能只问硬盘有多大、读写速度有多快，还需要回答几个更具体的问题：

  • 模型、训练数据和检查点分别放在哪里？

  • 一份数据要经过哪些环节，才能真正进入GPU？

  • 为什么GPU性能越来越强，存储和内存反而变得更重要？

都叫存储，但不在同一层

在日常交流里，我们习惯把内存、硬盘、存储芯片都放进“存储”这个大概念里。但到了AI服务器中，需要先把它们分层，否则很容易把HBM、DDR5、NAND与DAS、NAS、SAN、分布式文件系统放在同一个层级比较。

可以把一座AI算力中心想象成一个大型中央厨房。GPU里的计算核心就像灶台前负责炒菜出餐的厨师，CPU负责后厨的调度和备菜，数据则是不断送进来的食材。HBM就像灶台边的操作台，DDR5像后厨的备菜区，NAND SSD像能够长期保存食材的冷库。再往外，还有面向多家门店的中央仓库，对应分布式文件系统、对象存储和数据湖。

它们都在“保存东西”，但保存的位置和目的完全不同。操作台追求的是厨师伸手就能拿到，面积不可能太大；备菜区需要容纳更多食材，还要完成拆包、清洗、切配和分份；冷库考虑的则是存放量、保存周期和库存管理。

放到AI服务器里，位置越靠近计算单元，通常速度越快、容量越受限制，单位容量成本也越高。

简单来看，这座“中央厨房”里的存储层级可以对应成下面这样：

HBM、DDR5和NAND的存储层级

  • HBM：GPU旁边的操作台。 HBM是GPU侧的高带宽内存，只放当前计算要用的模型参数、激活值、梯度或KV Cache。操作台越大，能同时处理的数据越多；取用速度越快，GPU等待越少。以NVIDIA H200为例，它配备141GB HBM3e，内存带宽达到4.8TB/s。

  • DDR5：CPU侧的备菜区。 数据读取、解码、预处理和任务组织等工作通常由CPU完成，相关数据会放在DDR5中。它的容量通常更大，但距离GPU计算单元也更远。

  • NAND：可以长期保存数据的冷库。 NAND断电后仍能保存数据，它与控制器、固件和接口组成SATA SSD、NVMe SSD等设备，用来保存训练数据、模型文件、检查点和本地缓存。企业级SSD还会更强调耐久性、可靠性和性能一致性。

  • HDD：低成本、大容量的长期存储。 数据备份和冷数据存放仍然离不开传统机械磁盘。

AI算力中心中的存储产品位置

传统路径是“仓库→备菜区→操作台”，也就是“存储→DDR5→HBM”。GPUDirect Storage可以绕过DDR5中转，但数据最终仍要进入GPU侧内存才能参与计算。

AI存储架构要做的，不是从HBM、DDR5和NAND中选出一种“最先进”的产品，而是让操作台、备菜区、冷库和中央仓库在容量、速度、可靠性和成本之间配合起来。

从存储到GPU，数据不只有一条路

在上一篇《一提算力就想到显卡？算力中心里其实不只有GPU》中，我提到存储供不上数据，GPU就可能等待。继续用前面的厨房来理解，灶台和厨师已经准备好了，食材却迟迟没有送到操作台，出餐速度照样上不去。

但“数据进入GPU”并不只有一种固定方式。

训练：既要持续读取，也要周期性写回

传统训练中，数据从共享存储读取，进入DDR5，由CPU完成解码和预处理，再复制到HBM供GPU计算。支持GPUDirect Storage时，本地NVMe或远端存储可以通过DMA或RDMA把数据直接送入GPU内存，减少DDR5中转。

  • 传统训练路径： 分布式或共享存储 → 网络与文件系统 → DDR5 → CPU预处理 → HBM → GPU计算

  • GDS直达路径： 支持直达的本地或远程存储 → NVMe DMA或网卡RDMA → HBM → GPU处理与计算

这里的“直达”只是绕过CPU侧DDR5的数据中转，并不是绕过HBM。CPU仍然负责控制和调度；如果解码、数据增强等工作仍由CPU完成，数据依旧要经过DDR5。GDS还需要硬件、驱动、文件系统和RDMA等条件共同支持，否则会回退到传统路径。

训练过程中还要周期性地把检查点写回本地NVMe或共享存储。无论读取还是写回，只要其中一环跟不上，GPU都可能等待。

训练数据进入GPU的两条路径

推理：模型加载与在线请求是两段链路

推理服务启动时，模型权重需要先从持久化存储进入HBM。这一步同样存在传统路径与直达路径：

  • 传统加载： 持久化存储 → DDR5 → HBM

  • 直达加载： 支持GDS的存储 → HBM

模型加载完成后，参数和KV Cache主要驻留在HBM中，生成每个Token时不会重新读取一次分布式存储。普通在线请求通常经过：

  • 在线请求路径： 用户请求 → 网络 → DDR5与CPU处理 → HBM → GPU推理

在特定场景下，网卡也可以通过GPUDirect RDMA把适合GPU处理的数据直接送入HBM，但鉴权、分词和请求编排等工作通常仍需要CPU。存储会在模型切换、弹性扩容、RAG、多模态数据加载、KV Cache分层和故障恢复时重新进入推理链路。

推理数据进入GPU的不同路径

训练更关注持续读取和检查点写回；推理则更关注模型加载、在线请求，以及RAG和缓存分层等特定环节。

从DAS、NAS、SAN到分布式存储

今天的数据路径看起来很复杂，但其中很多技术并不是AI时代才出现。回到我刚参加工作的时候，服务器同样要解决数据放在哪里、怎样共享、磁盘坏了以后怎样恢复，只是当时的数据规模、访问方式和计算节点数量都不同。

2012年左右，我给一家医院安装过一套IBM DS3512。它通过SAS直连HIS服务器，专门承载HIS文件存储。从连接关系看，这仍然属于DAS，只不过磁盘不在服务器机箱内部，而是放在一套独立的存储设备里。因为承载的是医院关键业务数据，当时考虑的不只是容量够不够，还包括RAID怎样选择、磁盘故障后怎样处理、数据怎样备份，以及出现问题后能不能恢复。

HIS文件存储的DAS与RAID架构

那时一套业务、一台服务器和一套存储之间的边界比较清楚。存储的首要任务是把关键数据安全、稳定地保存下来，性能和扩容也主要围绕这一套HIS系统评估。现在回头看，这些问题并没有过时，只是AI集群把一台服务器的需求，放大成了大量计算节点同时取数和写回的需求。

  • DAS解决直连访问。 硬盘直接连接在服务器上，结构简单、访问路径短，但数据不方便被多台服务器共享，扩容也受到单机空间和接口限制。今天AI服务器里的本地NVMe仍然继承了DAS的基本思路，只是从“整套业务数据都在本机”，变成了整个分层存储中的节点加速层。

  • NAS解决文件共享。 它通过网络以文件方式提供共享存储，对使用者来说更接近访问一个统一文件目录。传统NAS很好地解决了文件共享和集中管理问题，但面对大量GPU节点持续并发读取、海量小文件访问和集中写入检查点时，控制器、网络、元数据处理和横向扩展都可能成为新的瓶颈。

  • SAN解决集中块存储。 FC SAN和iSCSI SAN都是把远端存储以块设备的方式提供给服务器，只是使用的网络和协议路径不同。数据库、虚拟化和关键业务需要集中管理、多路径和高可用，SAN形成的冗余、链路保护、数据一致性和故障恢复思想，今天依然没有过时。

2017年，我给一个教育行业客户做VMware数据中心整体设计。客户选择了HPE BladeSystem c7000，机框中满配8台全高的HPE ProLiant BL660c Gen9刀片服务器，并配置了一套HPE 3PAR StoreServ 8400，通过FC SAN为VMware集群提供共享存储。

VMware集群的FC SAN共享存储

这套设计的重点不是服务器与存储选了同一个品牌，也不是配置有多高，而是虚拟化以后，业务不应该再固定在某一台物理服务器上。多台刀片组成计算资源池，虚拟机的数据则放在共享存储中。这样，虚拟机迁移、高可用和主机故障后的业务恢复才有统一的数据基础。计算节点可以调整和替换，数据不再跟着其中某一台服务器走。

虚拟化普及以后，计算与存储进一步分离。 一台物理服务器可以运行多台虚拟机，业务不再固定绑定某一台机器，共享存储则负责把数据稳定地保留下来。服务器慢慢从业务主机变成资源池节点，存储也从一台设备的附属部件，变成整个资源池的公共基础设施。

再往后，云计算和海量数据推动了分布式存储。数据被分散到多台设备上，通过软件实现容量扩展、冗余和故障恢复。相比依赖一套集中式设备，分布式架构可以通过增加节点横向扩展，这与今天大规模AI集群的扩展方式更接近。

从多台节点组成一套分布式存储系统

从2012年的SAS直连，到2017年的FC SAN共享存储，再到今天面向AI集群选择分布式存储，我对计算与存储关系的理解也在变化。以前一套存储只要能够稳定承载某个业务，容量、RAID和备份设计清楚，项目的边界就比较明确。虚拟化要求存储服务一组计算节点，而AI集群又往前走了一步：存储不但要被大量节点共享，还要在训练、推理和故障恢复过程中持续供应数据。

这也是我认为分布式存储在AI时代仍有很大发展空间的原因。它在横向扩展、并发访问和容量增长上更贴近AI集群的形态，但最终能不能用好，仍然取决于具体产品、数据类型、网络架构、软件兼容性和项目成本。

DAS、NAS、SAN和分布式存储并不是一条“旧技术被新技术淘汰”的路线。 它们分别解决了直连访问、文件共享、集中块存储、可靠性和横向扩展问题。AI改变的是压力：更多GPU要在更短时间内读取更多数据，训练还要周期性写入大规模检查点，故障以后又希望尽快恢复任务。原来的问题都还在，只是很难再靠一套单一存储设备给出完整答案。

AI算力数据底座的新架构

所谓“AI算力数据底座”，不是一种更快、更贵的新存储产品，而是一套分层协同的数据系统。 数据会根据使用阶段和热度，在不同存储层之间流动：

  • 长期保存层： 原始数据、历史数据和模型版本通常保存在对象存储、数据湖或归档系统中。

  • 共享训练层： 进入训练阶段后，数据会进入高吞吐的分布式或并行文件系统。

  • 节点缓存层： 热点数据可以预取到本地NVMe，减少远端存储的读取压力。

  • 计算内存层： 当前计算所需的数据进入DDR5和HBM，越靠近计算，速度越快、成本越高，也越不适合长期保存。

这些层之间还需要高速网络、缓存、预取和任务调度协同。GPUDirect Storage可以减少数据在CPU内存中的一次中转，但海量小文件、网络拥塞、预处理不足或多任务争用，仍然可能让GPU等待。

分层的目的不是把所有数据都放在最快的介质上，而是在成本可控的前提下持续向GPU供数。

我最近正在参与一个算力集群项目，客户希望分布式存储支持GPUDirect Storage，并能根据数据热度自动分层。但选型不能只看产品资料上的功能名称，还要验证以下问题：

  • GPU、网卡、驱动和文件系统之间是否兼容；

  • 直达路径失效后能否正常回退；

  • 多任务并发、小文件处理和检查点写入能否达到预期；

  • 节点故障后能否快速恢复；

  • 运维复杂度和整体成本是否可以接受。

AI算力数据底座的两类核心能力

AI数据底座也不只解决性能问题。权限、版本追溯、校验、冗余、备份和灾难恢复仍然是基本职责。判断一套架构是否有效，不能只看容量和峰值带宽，更要看它能否缩短模型加载、减少数据等待，并在训练、推理和故障恢复过程中稳定供数。

写在最后

HBM、DDR5和NAND同时受到关注，不是因为它们是同一种产品，而是因为AI把从数据保存到进入GPU的每一层都推到了更高要求之下：

  • HBM让GPU高速取得当前计算所需的数据；

  • DDR5支撑CPU侧的系统运行和数据处理；

  • NAND SSD负责持久化保存与节点侧高速缓存；

  • 分布式和并行文件系统让大量计算节点共享数据；

  • 对象存储和数据湖承载需要长期保存的数据资产。

它们位于不同位置，没有谁能单独构成一座算力中心的数据底座。

今天我们谈论的HBM、NVMe、并行文件系统和AI数据湖，名词看起来已经和十几年前完全不同。但存储要解决的基础问题没有变：数据怎样安全保存，多台设备怎样共享，故障后怎样恢复，又怎样以足够高的效率被读取。RAID、DAS、NAS、SAN、文件系统、备份恢复和数据保护这些基础知识没有过时，它们仍然藏在最新的分布式存储和AI数据底座里。

AI把存储从后台推到了计算链路的前台。存储虽然不直接完成模型计算，却会影响GPU能够投入多少时间进行有效计算，也会影响整个算力中心的交付效率和运行成本。

理解算力中心，不能只看GPU有多快，还要看数据能不能跟上。

这么多年的数据中心建设和维护经验告诉我，GPU没有跑满，原因不一定在GPU，也可能出在存储、网络、调度或数据处理链路。服务器、存储和网络这些基础知识不是已经过时的旧技术，而是今天理解和定位算力中心问题的原点。

我们将继续沿着这条数据路径往前走。数据从存储到达GPU，无论采用传统路径还是直达路径，都离不开网络。存储系统本身足够快，并不代表GPU一定能够及时拿到数据，网络怎样让一组服务器和GPU真正协同起来，是算力中心里的另一个关键问题。