存储系统
大模型任务需要持续读取数据集、保存检查点并分发权重。存储设计不当会让 GPU 等待数据，也会延长故障恢复时间。
快速开始¶
按访问模式选择存储：训练进程的临时缓存放在本地 NVMe，共享检查点和预处理数据放在分布式文件系统，原始数据与归档权重放在对象存储。不要让所有训练进程直接并发读取大量小对象。
三类存储¶
| 类型 | 优点 | 局限 | 适合内容 |
|---|---|---|---|
| NVMe | 延迟低、单机吞吐高 | 容量和共享能力有限 | 缓存、临时分片、编译产物 |
| 分布式文件系统 | 提供共享目录和并行读写 | 元数据和小文件可能成为瓶颈 | 训练数据、检查点 |
| 对象存储 | 容量大、耐久性高、接口统一 | 随机读和大量小对象效率较低 | 原始数据、模型归档、备份 |
数据布局¶
将大量样本打包成尺寸适中的顺序读取分片，通常比逐个读取小文件更高效。分片还应支持确定性打乱、断点恢复和数据版本追踪。训练前可把热数据预取到节点本地 NVMe，减少远程存储抖动。
检查点案例¶
分布式训练保存检查点时，可让各 rank 写入自己的状态分片，再由清单文件记录完整版本。写入完成前先使用临时名称，全部分片成功后再原子发布清单，避免故障产生看似完整但实际缺失的检查点。
检查点应包含模型参数、优化器状态、学习率调度器、随机数状态、数据位置和训练配置。仅保存权重通常无法精确恢复训练。
模型与数据基础设施负责保存、版本化、下载和分发权重、配置、Tokenizer 与数据集。
快速开始¶
下载模型前确认仓库、许可证、revision 和文件格式。使用 Hugging Face 或 ModelScope 时固定提交版本，并记录模型配置、Tokenizer、生成配置和数据集版本，避免同一个名称在不同时间得到不同结果。
具体命令见 Hugging Face。
模型文件格式¶
| 格式 | 特点 | 常见用途 |
|---|---|---|
| Safetensors | 只保存张量，支持安全、快速加载 | Transformers 权重分发 |
| PyTorch checkpoint | 可保存任意 Python 对象 | 可信环境中的训练状态 |
| GGUF | 面向 llama.cpp 生态，包含量化与元数据 | 本地 CPU / GPU 推理 |
| ONNX | 跨框架计算图 | 通用部署与图优化 |
从不可信来源获取文件时，优先使用不执行任意对象反序列化的格式。训练检查点若必须包含 Python 对象，只能在可信环境加载。
数据集存储¶
数据集版本应记录原始来源、许可证、清洗规则、去重参数、分片清单与内容哈希。原始层保持不可变，加工结果写入新版本。训练配置只引用固定版本，不能引用会变化的“最新版”。
发布案例¶
发布微调模型时至少包含权重、模型配置、Tokenizer、提示模板、许可证、基座模型、训练数据说明和评测结果。若只上传权重而遗漏聊天模板，相同模型在不同客户端可能产生明显不同的行为。