当前位置: 首页 > news >正文

【AIDC 04】存储架构专题——从全闪到存算分离:AI时代的数据底座

核心观点:AI时代,存储不再是算力的附属品,而是决定AI能力上限的关键因素。从"存算一体"到"存算分离",从"机械硬盘"到"全闪分布式",存储架构正在经历深刻变革。高性能全闪存储、并行文件系统、数据湖架构、向量检索引擎,正在共同构筑AI时代的"记忆系统"。

一、为什么存储是AI的核心瓶颈之一?

1.1 AI训练的"数据饥渴症"

大模型训练有句行话:"数据决定上限,模型只是逼近这个上限。"但很多人忽略了后半句:存储系统决定了数据能不能被高效地喂给模型。

在算法迭代步入"小时级"的2025年,企业级AI基础设施正经历从"算力为王"到"存算协同"的深刻转变。一个千亿参数的大模型,训练数据量达到TB甚至PB级别,而且这些数据需要被反复读取、预处理、增强。

如果存储系统跟不上,GPU就会像"等米下锅"的厨师——算力再强,没数据也白搭。

1.2 AI存储的五大挑战

AI场景对存储的要求,和传统业务场景有本质的不同:

1. 超高带宽需求

大模型训练需要持续、稳定的高带宽数据供给。一个千卡集群,每秒可能需要读取几十GB甚至上百GB的数据。传统存储的带宽根本喂不饱。

2. 海量小文件处理

AI训练数据往往是海量的小文件(图片、文本片段等),可能是几百万、几千万甚至上亿个文件。传统文件系统在处理海量小文件时,元数据操作会成为严重瓶颈。

3. 复杂的混合负载

AI存储不是只做一件事。训练时需要高带宽顺序读,推理时需要低延迟随机读,数据预处理时需要高并发随机读写。多种负载混合,对存储系统的QoS能力要求很高。

4. 数据生命周期管理

AI数据有明显的生命周期特征:热数据(正在训练的)、温数据(准备训练的)、冷数据(归档保存的)。不同温度的数据需要不同的存储介质和策略,才能平衡性能和成本。

5. 多模态数据统一管理

大模型是多模态的,数据也是多模态的——文本、图片、音频、视频、向量……这些不同类型的数据,需要统一存储、统一管理、统一检索,这对存储架构提出了全新的要求。

二、全闪化:存储介质的革命

2.1 从机械硬盘到全闪存储

传统数据中心,存储以机械硬盘(HDD)为主,SSD只用于缓存或高性能场景。但在AI时代,全闪存储正在成为标配。

原因很简单:HDD的性能跟不上了。一块HDD的随机读写性能只有几百IOPS,顺序带宽也就200MB/s左右。而一块NVMe SSD,随机读写能到几十万IOPS,带宽能到几GB/s——差了两个数量级。

对于AI训练这种对性能极度敏感的场景,全闪不是"奢侈",而是"刚需"。

2.2 SSD技术的快速演进

SSD技术本身也在快速迭代,不断刷新性能和容量的上限:

  • 接口协议:从SATA到PCIe 3.0、4.0、5.0,带宽翻了好几番。PCIe 5.0 SSD的顺序读取带宽已经达到12GB/s以上
  • 介质类型:从TLC到QLC,容量不断提升。QLC SSD的单盘容量已经突破60TB
  • 形态演进:从2.5寸到U.2、E1.S、E3.S,密度越来越高

更重要的是,SSD的成本在快速下降。每GB的价格,已经降到了几年前的几分之一。这让全闪存储的TCO(总拥有成本)越来越有竞争力。

2.3 全闪存储的优势

  • 性能强悍:带宽是HDD的10-20倍,IOPS是HDD的100-1000倍
  • 延迟极低:亚毫秒级甚至微秒级延迟,远低于HDD的几毫秒到几十毫秒
  • 稳定可靠:没有机械部件,抗震抗摔,故障率更低
  • 能耗更低:功耗只有HDD的几分之一,更符合绿色数据中心的趋势
  • 密度更高:单盘容量越来越大,单位空间的存储密度远超HDD

目前,主流AIDC的存储系统都已经全闪化。像华为OceanStor Pacific、焱融YRCloudFile等产品,都能提供11PB/2U甚至更高的容量密度。

三、分布式并行文件系统:AI存储的核心引擎

3.1 为什么需要分布式并行文件系统?

单机存储的性能和容量都是有限的。要满足AI训练的超高带宽和海量存储需求,必须把很多台存储节点组合起来,形成一个统一的存储池——这就是分布式存储。

但传统的分布式存储(比如Ceph),主要是为云存储、对象存储设计的,更看重容量和可靠性,对高性能计算场景的支持不够好。

AI训练需要的是并行文件系统——它的核心特点是:多个客户端可以同时、并行地访问同一个文件,每个客户端都能获得很高的带宽。所有客户端的带宽加起来,就是整个系统的聚合带宽。

这就像一条多车道的高速公路——车越多,总流量越大。

3.2 主流并行文件系统

目前AI存储领域,主流的并行文件系统有:

文件系统

代表厂商

技术特点

适用场景

Lustre

DDN、华为等

开源、成熟、超大规模

超算、大规模AI训练

GPFS

IBM

企业级、功能丰富

企业级HPC、AI

BeeGFS

ThinkParQ

轻量、易用、高性能

中小规模AI集群

OceanStor Pacific

华为

全闪、高密、多协议

企业级AI、大数据

YRCloudFile

焱融科技

全闪、高性能、国产化

智算中心、国产化替代

3.3 并行文件系统的关键技术

1. 分布式元数据管理

海量小文件场景下,元数据操作是最大的瓶颈。好的并行文件系统,会把元数据也分布到多个节点上,并行处理,避免单点瓶颈。

2. 条带化(Striping)

一个大文件,被切成很多小块,分散存到不同的存储节点上。读取时,多个节点同时往外读,聚合带宽就上去了。这是并行文件系统的核心技术之一。

3. 客户端缓存

在计算节点本地缓存热点数据,减少对后端存储的访问。对于AI训练这种反复读取同一批数据的场景,客户端缓存能大幅提升性能。

4. RDMA支持

和计算网络一样,存储网络也在用RDMA。通过IB或RoCE网络,存储节点和计算节点之间可以直接内存访问,延迟更低、CPU占用更少。

四、存算分离:架构理念的变革

4.1 从存算一体到存算分离

传统的HPC和AI集群,很多是"存算一体"的——每个计算节点自带硬盘,数据就存在本地。这种方式简单、直接,但问题也很明显:

  • 资源利用率低:有的节点存储不够用,有的节点存储空间闲着,没法调剂
  • 扩容不灵活:加算力就得加存储,加存储也得加算力,没法独立扩
  • 数据共享难:节点之间的数据要共享,得靠网络拷贝,慢还麻烦
  • 运维成本高:每个节点都要管存储,运维复杂度高

"存算分离"就是把计算和存储拆开,各自独立部署、独立扩展。计算节点只管计算,数据都存在统一的存储集群里。

4.2 存算分离的核心优势

  • 资源弹性伸缩:算力不够加计算节点,存储不够加存储节点,按需扩展
  • 数据统一共享:所有计算节点访问同一份数据,不用拷贝,一致性有保障
  • 资源利用率高:计算和存储各自池化,利用率都能提上来
  • 运维管理简单:存储集中管理,运维效率高
  • 成本优化:不同温度的数据存在不同介质上,整体TCO更低

4.3 存算分离的演进路径

存算分离不是一步到位的,而是有一个演进的过程:

第一阶段:简单分离

计算和存储物理上分开,通过网络连接。这是最基础的存算分离,也是目前大多数AIDC的状态。

第二阶段:分层存储

存储系统内部分层:热数据存在全闪层,温数据存在混闪层,冷数据存在大容量层。数据自动在各层之间流动,平衡性能和成本。

第三阶段:数据湖架构

构建统一的数据湖,支持多协议访问(文件、对象、大数据),多模态数据统一存储、统一管理。配合数据治理、数据血缘等能力,让数据真正成为资产。

第四阶段:存算协同

存储不再是被动的"数据仓库",而是主动的"数据引擎"。存储系统可以做数据预处理、特征提取、甚至部分计算,减轻计算侧的压力。

五、数据湖与向量检索:AI的"长记忆"系统

5.1 AI数据湖:统一的数据底座

AI时代的数据,种类多、规模大、来源杂。如果每种数据都存一套、管一套,不仅成本高,还会形成数据孤岛。

AI数据湖的理念是:把所有数据都放到一个统一的池子里,用一套架构、一套接口、一套管理体系来支撑。

一个典型的AI数据湖,应该具备这些能力:

  • 多模态存储:文本、图片、音频、视频、结构化数据、向量……都能存
  • 多协议访问:文件接口、对象接口、大数据接口、数据库接口……都支持
  • 海量扩展:从TB级到EB级,平滑扩展,性能不下降
  • 数据治理:数据目录、数据血缘、数据质量、数据安全……全生命周期管理
  • 智能检索:全文检索、语义检索、向量检索……快速找到需要的数据

像华为的DME Omni-Dataverse统一数据空间,就是这种理念的体现。它支持多模态、跨站点数据实时入湖与全局管理,具备千亿千维向量数据秒级检索能力。

5.2 向量检索:大模型的"记忆宫殿"

大模型有个痛点:它的"知识"都在参数里,更新不灵活,也容易"幻觉"。如果能让大模型在回答问题时,先去"知识库"里查一下相关资料,再基于资料回答,效果会好很多。这就是RAG(检索增强生成)的思路。

RAG的核心,就是向量检索。把文档、图片等数据转换成向量(embedding),存在向量数据库里。查询时,把问题也转成向量,然后找最相似的几个向量对应的原文,作为上下文喂给大模型。

向量检索对存储的要求很特殊:

  • 海量向量:千亿级甚至万亿级向量,每个向量几百到几千维
  • 低延迟查询:毫秒级响应,不能让用户等太久
  • 高召回率:要尽量找到最相关的结果,不能漏
  • 实时更新:新数据要能快速入库,实时可查

向量检索引擎正在成为AI存储栈中不可或缺的一层。

5.3 上下文记忆存储:推理的"短期记忆"

除了长期记忆(知识库),大模型推理还需要短期记忆——也就是对话上下文。

传统的推理,上下文存在GPU显存里。但如果上下文很长(比如几万、几十万token),显存就不够用了。而且,多轮对话、多用户共享上下文的场景,也需要把上下文存到外部。

上下文记忆存储(Context Memory Storage,CMS)就是为这个场景设计的。它支持异构算力与PB级共享KV Cache池,让大模型推理可以处理更长的上下文,同时降低显存成本。

六、AI存储选型:如何构建高效的数据底座?

6.1 选型评估维度

AI存储选型,建议从以下几个维度评估:

评估维度

关键指标

权重

性能

聚合带宽、IOPS、延迟、小文件性能

★★★★★

扩展性

最大集群规模、扩容方式、性能线性度

★★★★☆

可靠性

数据冗余机制、故障恢复时间、可用性

★★★★☆

易用性

部署难度、运维复杂度、监控工具

★★★☆☆

生态兼容

支持的框架、接口、硬件平台

★★★☆☆

成本

CAPEX、OPEX、TCO

★★★★☆

6.2 不同场景的存储方案建议

场景一:小规模AI实验与开发

建议:单机全闪存储或小规模分布式存储。性能要求不高,重点是易用性和成本。

场景二:中等规模模型训练(几十到几百卡)

建议:全闪并行文件系统,容量几十到几百TB。重点是带宽和小文件性能。

场景三:大规模大模型训练(千卡以上)

建议:高端全闪分布式存储,容量PB级。重点是聚合带宽、扩展性、稳定性。

场景四:推理服务

建议:高性能全闪存储+缓存层。重点是低延迟、高并发。

场景五:企业级AI平台(训推一体)

建议:分层存储架构+数据湖。热数据全闪、温数据混闪、冷数据归档,统一管理。

6.3 存储性能优化最佳实践

  • 数据预处理:把原始数据转成训练友好的格式(比如TFRecord、binary),减少小文件数量
  • 本地缓存:在计算节点配置本地SSD缓存,热点数据本地读取
  • 预取机制:训练前把数据预取到缓存或内存,避免训练时等待
  • 网络优化:存储网络用RDMA,带宽要足够,避免网络成为瓶颈
  • 条带优化:根据文件大小和访问模式,调整条带大小和数量

七、未来趋势:存算一体、近存计算与内存语义存储

7.1 存算一体:打破冯·诺依曼瓶颈

传统架构中,计算和存储是分开的,数据要在二者之间搬来搬去。这不仅慢,还费电——"存储墙"和"功耗墙"越来越成为瓶颈。

存算一体的思路是:把计算做到存储里面去,数据不用搬来搬去,在存储的地方就完成计算。

对于AI这种"数据密集型计算",存算一体的潜力巨大。目前,基于闪存、忆阻器等介质的存算一体芯片正在快速发展,预计未来几年会逐步商用。

7.2 近存计算:在数据旁边做计算

如果存算一体太激进,近存计算就是更务实的选择。把计算单元(比如CPU、GPU、DPU)放得离存储更近,减少数据搬运的距离和开销。

比如,在存储控制器里加计算能力,做数据压缩、加密、特征提取等操作;或者在存储节点上部署GPU,直接在数据所在地做预处理。

7.3 内存语义存储:内存级的存储体验

传统存储的访问方式是"块"或"文件",和内存的"字节寻址"完全不一样。这就导致程序访问存储的方式很复杂,性能也上不去。

内存语义存储(Memory Semantic Storage)的目标是:让存储用起来像内存一样——字节寻址、load/store指令、纳秒级延迟。

随着持久内存(PMem)、CXL、Gen-Z等技术的发展,内存和存储的边界正在变得模糊。未来的存储系统,可能会提供"内存级"的访问体验,同时拥有"磁盘级"的容量和持久性。

八、结语

如果说算力是AI的"大脑",那存储就是AI的"记忆系统"。没有好的记忆,再聪明的大脑也发挥不出来。

从全闪化到分布式,从存算分离到数据湖,从向量检索到存算一体——AI存储的技术演进之路,就是不断缩短数据和计算之间距离的过程。

在AI越来越深地融入各行各业的今天,存储的重要性只会越来越凸显。构建高效、可靠、可扩展的数据底座,是每一个AIDC都必须面对的核心课题。

下一篇预告:《供配电专题:800V HVDC与SST——供电架构的范式革命》,我们将深入探讨传统供电架构的瓶颈,800V高压直流技术的原理与优势,以及固态变压器(SST)的未来展望。

http://www.cnnetsun.cn/news/3108250.html

相关文章:

  • Windows系统文件auditcse.dll丢失找不到问题解决
  • 2026Word文档压缩实操指南,解决Word文件太大怎么变小问题
  • LTE Cat 1与PIC24微控制器在工业物联网中的设计与优化
  • 本地部署开源数据分析平台 Elastic Stack 并实现外部访问( Linux 版本)
  • 【鸿蒙ArkTS】极简登录注册页面+页面跳转+密码校验
  • 鸿蒙 ArkTS 最全完整版知识点总结
  • 工艺节点演进全解读:从180nm到3nm,芯片是怎么越做越小的
  • 【银河麒麟】管理cgroup内存资源的两个工具用法
  • CUPP 通用用户密码分析器:助力合法渗透测试与犯罪调查
  • ArkTS 入门实战:构建一个交互式信息展示页面
  • 降重后论文逻辑全乱,有哪些真正值得拥有的的降AIGC平台推荐?
  • 2026揭阳黄金回收白银回收铂金回收旧料回收怎么选?五家高实价铂金白银线下门店测评清单 + 联系方式
  • Photon光影包终极指南:为Minecraft打造电影级视觉体验的完整教程
  • [AI][编程模型]Larrabee 介绍
  • 提升办公效率|OpenClaw 本地部署全套排错与安装步骤(包含安装包)
  • Three.js 模型视图教程
  • 人工智能浪潮来袭,OverDrive的Libby应用如何应对书籍内容冲击?
  • 生成式引擎优化GEO哪个解决方案好
  • PEO113-PVP44-PS45三嵌段共聚物PS45-PVP44-PEO113
  • 数字控制振荡器(DCO)原理与LTC6903应用设计
  • CodeAgent 技术架构简易介绍
  • 工作中用AI省时又省力?小心“影子AI”导致数据泄露!
  • 拒绝环路+负载分担!MSTP实战配置
  • 拯救你的数字书库:novel-downloader小说下载器完整使用指南
  • 67|技能治理:版本、禁用回滚与共享策略
  • AI浪潮下SaaS行业震荡:估值重估、企业内卷,未来路在何方?
  • MySQL(十八)分库分表详解(介绍、Mycat概述安装、Mycat入门、Mycat配置、Mycat分片、Mycat管理及监控)
  • 这是关于选择器
  • TikTokDownload Cookie自动获取:告别手动烦恼的10分钟终极指南
  • 如何通过HWInfo插件实现FanControl智能风扇控制:完整配置指南