摘要大模型训练把集群规模推到了万卡级别存储随之成了限制训练效率的关键因素。本文从 Kubernetes 存储体系出发梳理 CSI 架构与驱动生态并介绍近两年进入 Beta/GA 的几项新能力Changed Block Tracking增量快照、VolumeGroupSnapshot多卷一致性快照、VolumeAttributesClass在线调整卷性能以及面向对象存储的 COSI。最后结合万卡集群的实际负载给出一套分层存储方案的设计思路。适用读者有一定 Kubernetes 基础的平台工程师、AI Infra 工程师、存储工程师。版本说明本文内容基于 2026 年 10 月的社区状态涉及 Kubernetes v1.33 ~ v1.36。各特性的成熟度变化较快落地前请以官方文档为准。1. 背景大模型训练对存储提出的新挑战1.1 从能存到喂得饱 GPU在传统的微服务场景里存储主要解决的是数据放哪儿、丢不丢。到了大模型训练场景问题变成了存储能不能跟上 GPU 的速度。一张高端 GPU 每小时的成本很高如果因为数据读取慢或 Checkpoint 写入慢导致 GPU 空转浪费会随着卡数线性放大。AI 训练对存储的压力主要来自三类 I/OI/O 类型典型特征主要瓶颈训练数据读取海量小文件 / 大量分片随机读多 epoch 重复读元数据性能、IOPS、读带宽Checkpoint 写入周期性突发、大块顺序写所有节点几乎同时写聚合写带宽、尾延迟Checkpoint 恢复故障后所有节点同时读同一份 Checkpoint聚合读带宽、热点1.2 Checkpoint 有多大一个直观的估算以 70B 参数的模型、使用 Adam 优化器的混合精度训练为例BF16 权重70B × 2 Byte ≈ 140 GBFP32 主权重 Adam 一阶/二阶动量70B × 12 Byte ≈ 840 GB一份完整 Checkpoint 接近1 TB。如果要求 Checkpoint 期间训练暂停不超过 60 秒存储需要提供的聚合写带宽大约是1 TB / 60 s ≈ 17 GB/s而万卡规模下故障是常态GPU、网卡、光模块都可能出问题Checkpoint 越频繁故障时损失的训练进度越少但对存储带宽的要求也越高。1.3 Kubernetes 在其中的角色越来越多的 AI 平台把 Kubernetes 作为统一的调度底座。存储能否通过 Kubernetes 的标准接口被声明式地申请、扩容、快照、备份直接决定了平台的自动化程度。这也是 CSI、COSI 等标准接口持续演进的原因。2. CSI 架构与驱动生态2.1 为什么需要 CSI早期 Kubernetes 的存储插件是 in-tree 的即驱动代码直接写在 Kubernetes 主仓库里。这带来几个问题存储厂商要跟着 Kubernetes 的发布节奏走修个 Bug 也要等新版本驱动代码的缺陷可能影响 kubelet、controller-manager 等核心组件的稳定性社区维护成本高。CSIContainer Storage Interface定义了一套与容器编排系统无关的 gRPC 接口把存储驱动从 Kubernetes 主仓库中解耦出来驱动以独立容器的形式部署。2.2 CSI 的三类 gRPC 服务一个 CSI 驱动通常需要实现以下三类服务服务部署位置主要职责Identity ServiceController 与 Node 均需实现上报驱动名称、能力、健康状态Controller Service通常以 Deployment/StatefulSet 部署创建/删除卷、Attach/Detach、快照、扩容Node Service以 DaemonSet 部署在每个节点将卷挂载Stage/Publish到节点和 Pod一次典型的申请 PVC → Pod 使用卷的流程如下PVC 创建 └─ external-provisioner 监听到 PVC ── CreateVolumeController Pod 调度到节点 └─ external-attacher 处理 VolumeAttachment ── ControllerPublishVolume └─ kubelet ── NodeStageVolume ── NodePublishVolumeNode Pod 启动卷可用2.3 Sidecar 容器Kubernetes 与驱动之间的翻译层驱动本身只需要实现 CSI gRPC 接口监听 Kubernetes 资源并转化为 gRPC 调用的工作由社区维护的一组 sidecar 容器完成Sidecar作用external-provisioner监听 PVC调用CreateVolume/DeleteVolumeexternal-attacher监听 VolumeAttachment调用ControllerPublishVolumeexternal-resizer处理 PVC 扩容同时负责 VolumeAttributesClass 的ModifyVolumeexternal-snapshottercsi-snapshotter处理 VolumeSnapshot 与 VolumeGroupSnapshotexternal-snapshot-metadata提供快照变更块元数据服务CBT见第 3 节node-driver-registrar向 kubelet 注册 Node 插件livenessprobe暴露驱动健康检查端点2.4 用 CSIDriver 对象声明驱动能力Kubernetes 通过CSIDriver对象了解驱动的行为特征从而决定是否需要 Attach 流程、是否向驱动传递 Pod 信息等apiVersion:storage.k8s.io/v1kind:CSIDrivermetadata:name:example.csi.driverspec:attachRequired:true# 是否需要 ControllerPublishAttach流程podInfoOnMount:true# 挂载时是否向驱动传递 Pod 名称、命名空间等信息fsGroupPolicy:File# 卷权限如何随 Pod 的 fsGroup 调整storageCapacity:true# 是否上报存储容量供调度器参考volumeLifecycleModes:-Persistent# 支持 PV/PVC 形式的持久卷-Ephemeral# 支持 CSI 临时内联卷2.5 驱动生态CSI 的标准化带来了丰富的驱动生态公有云AWS EBS/EFS、阿里云云盘/NAS/CPFS、Azure Disk/Files、GCP PD/Filestore 等均提供官方 CSI 驱动开源存储CephCeph-CSI、Longhorn、OpenEBS、JuiceFS 等并行文件系统Lustre、GPFSIBM Storage Scale等也都有对应的 CSI 实现这是 AI 训练场景的重点。3. Changed Block Tracking增量快照与数据保护3.1 背景Kubernetes 的 VolumeSnapshot 早已 GA但备份工具要把快照数据导出到外部例如对象存储时一直面临一个问题它不知道两次快照之间哪些数据块发生了变化只能全量读取整块卷。对于 TB 级别的卷这意味着每次备份都要读完整块盘备份窗口长、网络和存储压力大。而很多存储后端本身是能追踪变更块的只是之前缺少一个标准接口把这些信息暴露给 Kubernetes 生态。Changed Block TrackingCBT就是为了解决这个问题。3.2 发展历程时间进展2025 年 9 月CBT 以 Alpha 形式发布2026 年 3 月external-snapshot-metadata发布 v1.0.0特性进入BetaBeta 版本的兼容性要求Kubernetesv1.33 及以上CSI 规范v1.10 及以上Sidecar 镜像registry.k8s.io/sig-storage/csi-snapshot-metadata:v1.0.0⚠️ 注意Beta 版本把 SnapshotMetadataService CRD 从v1alpha1升级到cbt.storage.k8s.io/v1beta1并且直接移除了 v1alpha1没有自动转换。从 Alpha 升级时需要重新应用 CRD并更新相关清单和客户端代码。3.3 架构与核心组件CBT 由三部分组成CSISnapshotMetadatagRPC 服务由 CSI 驱动实现提供两个核心接口GetMetadataAllocated返回某个快照中已分配的数据块列表用于首次全量备份时跳过空洞GetMetadataDelta返回两个快照之间发生变化的数据块列表用于增量备份。SnapshotMetadataService CRD驱动通过它声明元数据服务的访问地址、认证受众audience和 CA 证书供备份工具发现。external-snapshot-metadatasidecar部署在驱动旁边负责校验客户端身份和权限并把请求转发给驱动。一个 SnapshotMetadataService 的示例apiVersion:cbt.storage.k8s.io/v1beta1kind:SnapshotMetadataServicemetadata:name:example.csi.driver# 与 CSI 驱动名称一致spec:address:csi-snapshot-metadata.csi-driver.svc:6443audience:example-cbt-audiencecaCert:base64 编码的 CA 证书3.4 增量备份的工作流程1. 备份工具创建 VolumeSnapshotsnap-1通过 GetMetadataAllocated 获取已分配块只读取这些块完成首次备份 2. 一段时间后创建 VolumeSnapshotsnap-2 3. 调用 GetMetadataDelta(snap-1, snap-2)拿到变更块列表 4. 只读取并上传变更块完成增量备份相比每次全量读取增量备份在数据变化率低的场景下可以大幅缩短备份时间、降低带宽消耗。需要注意CBT 面向块设备模式volumeMode: Block的卷驱动需要先支持 VolumeSnapshot并部署external-snapshot-metadatasidecar备份工具需要具备相应的 RBAC 权限社区提供了snapshot-metadata-lister作为参考客户端。3.5 对 AI 场景的意义在 AI 平台上CBT 主要适用于块存储上的有状态组件例如训练平台元数据库、实验追踪系统MLflow 等的数据库卷向量数据库、特征存储的块存储卷推理服务所依赖的模型仓库如果使用块存储。对于 Checkpoint 本身由于通常写入并行文件系统或对象存储一般不依赖 CBT而是由训练框架或存储系统自身的机制做增量和分层。4. VolumeGroupSnapshot多卷一致性快照4.1 背景很多应用的数据分布在多个卷上例如数据库的数据卷和日志卷分离。如果分别对每个卷做快照各快照的时间点不一致恢复后数据可能出现不一致。VolumeGroupSnapshot允许对一组卷在同一时间点做崩溃一致性crash-consistent快照。4.2 发展历程版本状态Kubernetes v1.27AlphaKubernetes v1.32BetaKubernetes v1.34第二个 Betav1beta2Kubernetes v1.36GAAPI 版本为groupsnapshot.storage.k8s.io/v14.3 使用示例首先定义 VolumeGroupSnapshotClassapiVersion:groupsnapshot.storage.k8s.io/v1kind:VolumeGroupSnapshotClassmetadata:name:csi-group-snap-classdriver:example.csi.driverdeletionPolicy:Delete然后通过标签选择器选中一组 PVC 做快照apiVersion:groupsnapshot.storage.k8s.io/v1kind:VolumeGroupSnapshotmetadata:name:mysql-group-snapshotnamespace:demospec:volumeGroupSnapshotClassName:csi-group-snap-classsource:selector:matchLabels:app:mysql# 所有带此标签的 PVC 会被一起快照 VolumeGroupSnapshot 相关的 CRD 和控制器由external-snapshotter项目提供需要单独安装同时 CSI 驱动需要实现组快照相关的能力。5. VolumeAttributesClass在线调整卷性能5.1 背景以前PVC 创建后能改的基本只有容量。如果想把一块盘的 IOPS 或吞吐调高通常只能新建一块盘再迁移数据。VolumeAttributesClassVAC允许管理员定义多个性能档位用户只需修改 PVC 引用的 VAC 名称就能触发驱动在线调整卷的属性。该特性在Kubernetes v1.34 GA。5.2 使用示例定义两个性能档位参数含义由各驱动决定下面以 AWS EBS CSI 风格为例apiVersion:storage.k8s.io/v1kind:VolumeAttributesClassmetadata:name:silverdriverName:ebs.csi.aws.comparameters:type:gp3iops:3000throughput:125---apiVersion:storage.k8s.io/v1kind:VolumeAttributesClassmetadata:name:golddriverName:ebs.csi.aws.comparameters:type:gp3iops:16000throughput:1000PVC 中引用apiVersion:v1kind:PersistentVolumeClaimmetadata:name:feature-store-dataspec:accessModes:-ReadWriteOncestorageClassName:ebs-gp3volumeAttributesClassName:silverresources:requests:storage:500Gi在业务高峰前把volumeAttributesClassName从silver改为goldexternal-resizer会调用驱动的ModifyVolume接口完成在线调整。需要注意VAC 只能用于 CSI 驱动且驱动需要实现ModifyVolumeVAC 对象中的parameters创建后不可修改要调整档位应切换到另一个 VAC各云厂商对调整频率通常有限制例如一段时间内只能修改一次使用前请查阅驱动文档。5.3 对 AI 场景的意义AI 平台中的负载往往有明显的阶段性数据预处理阶段 IOPS 需求高模型评测阶段需求低。借助 VAC可以按阶段调整性能档位在不迁移数据的情况下平衡性能和成本。6. COSI对象存储的标准化接入6.1 背景CSI 解决的是块存储和文件存储的标准化但 AI 场景里大量数据原始语料、数据集、Checkpoint 归档存放在对象存储中。对象存储没有挂载的概念CSI 的模型并不合适。COSIContainer Object Storage Interface是 Kubernetes SIG Storage 下的子项目kubernetes-sigs/container-object-storage-interface目标是让应用像申请 PVC 一样声明式地申请 Bucket 和访问凭证。6.2 COSI 的核心抽象资源作用类比 CSIBucketClass定义 Bucket 的供给方式驱动、删除策略、参数StorageClassBucketClaim用户声明对一个 Bucket 的需求PVCBucket实际创建出来的 Bucket 资源PVBucketAccessClass定义访问方式如密钥认证或 ServiceAccount 认证—BucketAccess申请对 Bucket 的访问权限凭证写入 Secret 供 Pod 使用—6.3 使用示例⚠️ COSI 目前仍处于 Alpha 阶段。下面的示例基于v1alpha2API该版本在撰写本文时仍为预发布状态字段在正式发布前可能有不兼容变更请以项目文档为准。申请一个 BucketapiVersion:objectstorage.k8s.io/v1alpha2kind:BucketClaimmetadata:name:ai-training-datanamespace:trainingspec:bucketClassName:minio-standardprotocols:-S3申请访问权限凭证会写入名为training-data-creds的 SecretapiVersion:objectstorage.k8s.io/v1alpha2kind:BucketAccessmetadata:name:trainer-accessnamespace:trainingspec:bucketAccessClassName:minio-key-authprotocol:S3bucketClaims:-bucketClaimName:ai-training-dataaccessModes:objectData:ReadOnly# 训练任务只需要读取数据集accessSecretName:training-data-creds训练 Pod 通过挂载该 Secret 获取 endpoint 和访问凭证不需要再手动在对象存储控制台创建账号、复制 AK/SK。6.4 进展与生态COSI 当前支持S3、Azure Blob、GCS三种协议v1alpha2对 API 做了较大调整例如细粒度的访问模式对象数据、对象元数据、Bucket 元数据分别控制读写、ServiceAccount 认证方式等社区和部分对象存储厂商正在推进驱动实现。未来COSI 有望与 CSI 形成互补CSI 负责块/文件存储COSI 负责对象存储让 Kubernetes 上的存储资源都能以统一的声明式方式管理。7. 实战为万卡集群设计存储方案下面结合前文内容给出一套万卡集群存储方案的设计思路。具体选型需结合自身的硬件、网络和预算情况。7.1 需求分析万卡集群的存储设计首先要明确负载特征训练数据集总量、文件数量与平均大小、读取模式顺序/随机、是否多 epochCheckpoint单份大小、写入频率、可接受的训练暂停时间、保留份数故障恢复可接受的恢复时间RTO恢复时所有节点同时读取的并发量其他数据日志、指标、实验元数据、模型仓库等。用第 1 节的估算方法可以推导出关键指标。例如Checkpoint 大小1 TB 可接受写入暂停60 s → 所需聚合写带宽 ≈ 17 GB/s 恢复时间目标5 min → 所需聚合读带宽 ≈ 3.4 GB/s还需考虑并发热点7.2 分层存储架构单一存储很难同时满足高性能和低成本推荐采用分层架构┌──────────────────────────────────────────────────────────┐ │ L0 节点本地 NVMe │ │ · 数据集缓存、Checkpoint 第一落点 │ │ · 带宽最高、延迟最低但节点故障即丢失 │ ├──────────────────────────────────────────────────────────┤ │ L1 高性能并行文件系统Lustre / GPFS / CPFS / 3FS 等 │ │ · 热数据集、近期 Checkpoint │ │ · RDMA 网络支持 GPUDirect Storage 等加速 │ ├──────────────────────────────────────────────────────────┤ │ L2 对象存储S3 兼容 │ │ · 原始语料、全量数据集、历史 Checkpoint 归档 │ │ · 容量大、成本低通过 COSI 统一申请和授权 │ ├──────────────────────────────────────────────────────────┤ │ 块存储云盘 / Ceph RBD 等 │ │ · 平台数据库、向量库等有状态服务 │ │ · 用 VAC 调整性能用 VolumeGroupSnapshot CBT 做备份 │ └──────────────────────────────────────────────────────────┘7.3 关键设计点1Checkpoint 采用异步多级落盘训练进程先把 Checkpoint 写到内存或本地 NVMe立即恢复训练后台进程再异步把 Checkpoint 上传到并行文件系统和对象存储。这样训练暂停时间主要取决于本地写入速度而不是远端存储带宽。2数据集读取做好缓存与预取把海量小文件打包成大文件如 WebDataset、TFRecord 等格式减轻元数据压力使用分布式缓存如 JuiceFS、Fluid Alluxio 等把对象存储中的数据集预热到计算节点附近第一个 epoch 后后续 epoch 尽量命中缓存。3恢复时避免读热点故障恢复时成千上万个进程会同时读取同一份 Checkpoint。可以通过按 rank 分片保存、读取后在节点间广播等方式避免把压力集中到少数存储节点。4平台有状态服务的保护平台数据库的数据卷和日志卷使用VolumeGroupSnapshot做一致性快照备份工具基于CBT只导出变更块缩短备份窗口根据业务阶段使用VolumeAttributesClass调整性能档位。7.4 选型对比存储类型优势劣势适用数据本地 NVMe带宽最高、延迟最低容量有限、不持久、不共享缓存、Checkpoint 第一落点并行文件系统高聚合带宽、POSIX 兼容、可共享成本高、运维复杂热数据集、近期 Checkpoint对象存储容量大、成本低、可靠性高延迟高、非 POSIX原始数据、归档块存储稳定、快照能力成熟一般只能单节点挂载数据库等有状态服务8. 总结与展望回顾本文内容CSI已经是 Kubernetes 块存储和文件存储的事实标准sidecar 架构让驱动开发和 Kubernetes 演进互不干扰CBTBeta让备份工具可以只导出变更块补上了增量备份的标准接口VolumeGroupSnapshotv1.36 GA解决了多卷一致性快照的问题VolumeAttributesClassv1.34 GA让卷性能可以在线调整不再需要迁移数据COSIAlpha正在把对象存储纳入 Kubernetes 的声明式管理体系。对万卡集群来说单一存储无法满足所有需求。比较可行的思路是用分层架构平衡性能与成本用异步 Checkpoint 降低训练暂停时间用 Kubernetes 标准接口实现存储资源的自动化管理。随着 CBT、COSI 等特性逐步成熟AI 平台的存储管理会越来越标准化。
