适用于AI大模型的存储_ai训练模型存储结构-CSDN博客

AI大模型对存储的需求

AI大模型时代，存储介质将如何演绎新方向？
人工智能 - Ceph存储1：AI大模型各阶段对存储需求是怎样的？ - 个人文章 - SegmentFault 思否
 什么样的存储架构才是AI大模型时代的最佳选择?-华为企业业务
 面向大模型的存储加速方案设计和实践 - 知乎
 从DeepSeek-3FS聊到AI存储 - 知乎

207
208

性能
模型训练需要对海量素材（小文件）读取，需要低时延、高并发
模型训练的checkpoint存储的特点是大块写（CKPT文件很大）、高并发（多卡训练有多个CKPT）
模型训练的数据集随机打散（shuffle）的特点是对元数据的高密度访问，列表操作，不需要访问文件数据
模型推理多个用户并行请求，对模型的访问是高并发，大模型的模型文件很大，需要高带宽
生态
多种类型的海量数据的存储，需要存储支持对象存储、支持文件存储、支持POSIX文件操作

大模型文件大小

大模型的模型文件大小主要取决于参数量和量化方案，具体表现如下：
1 参数量与基础存储需求
全精度（FP32）：每个参数占4字节，1B参数的模型约需4GB存储空间。例如，70B参数的模型理论大小约为280GB，但实际文件可能更大（如Llama2-70B的FP16版本达141GB）。
半精度（FP16/BF16）：每个参数占2字节，文件大小为参数量的2倍。例如，7B参数的FP16模型约14.1GB，与理论值（7B×2B=14GB）基本一致。
2 量化影响
Int8量化：每个参数占1字节，文件大小约为参数量的1倍。例如，7B模型的Int8版本约7.54GB。
Int4量化：每个参数占0.5字节，文件大小约为参数量的0.5倍。例如，14B模型的Int4版本仅8.37GB，显存占用约10.5GB。
3 不同参数规模的实际案例
小模型（1.5B~14B）：适合本地部署，如Int4量化的14B模型文件约8.37GB，显存占用10.5GB，可在16GB显存的显卡上运行。
中大型模型（32B~70B）：例如Int4量化的70B模型文件约39.6GB，需48GB显存支持。
千亿级模型（如671B）：全精度版本文件达1.3TB，需服务器集群运行。

DeepSeek 3FS

DeepSeek 3FS 架构分析和思考（上篇） - 文章 - 开发者社区 - 火山引擎
 DeepSeek 3FS 架构分析和思考（下篇） - 文章 - 开发者社区 - 火山引擎
 陈巍：DeepSeek 开源Day（5）3FS&smallpond深入分析（收录于：DeepSeek技术详解系列） - 知乎
 Deepseek 3FS（ Fire-Flyer File System）设计笔记

特点：

小文件性能的主动弱化：3FS 将文件语义转化为 FoundationDB 的 KV 存储逻辑，天然增加了元数据操作开销。其设计文档明确建议用户通过 FFRecord 或其他开源数据格式合并小文件，这意味着系统并未针对传统文件系统的小文件读写进行深度优化。
元数据性能的架构瓶颈：FoundationDB 虽保障了元数据强一致性，但其事务型设计相比 Lustre 等并行文件系统的分布式元数据库（如 MDT），在超高并发文件创建/删除（如百万级/s）场景存在吞吐上限。
随机写入的双重约束：受限于链式复制协议的顺序提交特性与当前 3FS ChunkEngine 数据引擎的更新算法设计，3FS 在随机写入场景（如小规模覆盖写）中表现出明显的性能衰减。这种设计选择与其“大块连续写入优先”的目标高度一致，但也在客观上划定了系统的能力边界。

3FS 对于小文件场景和随机小块更新写入出现远低于行业一流水平的性能结果，但这个实际上也符合架构分析预期，核心场景的性能优势（如带宽、延迟）完全覆盖 AI 业务需求。这种设计验证了存储系统的关键原则——通过场景约束实现长板最大化，而非追求通用场景的均衡性。3FS 选择了一条“非对称竞争”之路：放弃对传统小文件、随机更新写场景的兼容，转而将 AI 场景的连续大块读写与高并发访问特性推向极致。这种“长板效应”的极致追求，使得 3FS 在模型训练、推理流水线和数仓加载等场景中展现出近乎线性的扩展能力，而其代价则是坦然接受在非目标场景中的性能短板。这种“不完美”恰恰体现了 DeepSeek 团队对系统工程本质的把握——存储系统从来不是抽象的理论模型，而是业务需求与硬件特性的动态平衡。