大模型规模化训练正加速推动 AI 数据湖突破规模临界点，也让企业和科研机构陷入一个核心困境：数据湖“能存下”不难，“存得统一、用得高效”却愈发艰难。

对这类客户来说，存储系统已不只是“容量底座”，更是决定训练效率、平台复杂度与长期治理成本的核心环节——数据视图是否统一、单桶对象能否持续扩容、List 和元数据访问是否稳定，直接影响大模型研发的迭代速度。

针对此类场景，XSKY XEOS 对象存储，在国内某头部人工智能科研机构的 AI 数据湖建设中，给出了最优解：以单桶千亿级对象、EB 级容量横向扩展、多级元数据与 List 优化能力，让客户业务数据在规模增长中始终保持统一，为大模型研发扫清存储障碍。

需求：保持统一，是 AI 数据湖的核心

该客户长期聚焦大模型、多模态智能、科学智能及开源开放生态研发，数据来源广泛、类型繁杂且增长迅猛——从海量开源语料到自主标注数据，从模型权重到推理日志，这些数据并非孤立文件，而是贯穿训练、评测、迭代全链路的核心生产资料，这也决定了其 AI 数据湖必须满足四大核心刚需，缺一不可：

第一，容量需实现“永续增长”

大模型训练是持续迭代的长期项目，数据会随着新任务、新版本、新模态不断进入数据湖，容量需要从 PB 级持续走向 EB 级，无容量天花板限制。

第二，对象数量要能“长期承载”

AI 数据湖中存在大量小文件、样本分片、索引文件、Checkpoint 分片和模型产物。对象数量增长速度往往比容量增长更快，单桶对象数需要具备百亿级、千亿级扩展能力，杜绝因对象数量瓶颈影响业务。

第三，训练链路需“高效数据发现”

训练初始化、数据分片发现、全局遍历、Shuffle、ETL 扫描、Checkpoint 枚举等动作，均高度依赖对象存储的元数据和 List 能力，高效的数据发现能力直接缩短训练等待时间，提升 GPU 利用率。

第四，数据治理需“全链路统一”

权限管控、生命周期、审计、监控和数据版本管理，都希望围绕一个统一的数据湖视图展开，而不是被底层桶和集群边界打散。

挑战：数据规模增长后，存储边界会侵入业务架构

在 AI 数据湖规模变大后，真正的困难不是“再加一些容量”这么简单，而是存储规格不足会逐步传导到训练平台、数据工程和治理体系。最终拖慢大模型研发进度、增加运维成本，甚至带来合规风险，具体面临四大核心挑战：

挑战一：容量增长会导致多集群拆分

当单一存储域无法继续承载增长时，客户往往需要把数据拆到多个集群——短期看似解决了扩容问题，长期却会引发一系列业务痛点：跨集群访问、数据迁移、容灾策略、监控告警和运维边界的复杂化。更会让训练平台被迫感知数据位置，调度系统也额外需要处理不同集群之间的访问路径和性能差异，严重影响训练效率。

挑战二：对象数量增长会导致多桶拆分

当单桶对象数量达到瓶颈后，业务只能把数据拆进多个桶。但桶不仅是存储容器，也是访问路径、权限策略、生命周期和元数据治理的边界。拆桶之后，数据采集要增加路由规则，训练脚本要适配跨桶遍历，ETL 任务要聚合多个桶的对象列表，平台侧还可能需要额外维护索引层。原本统一的数据湖，开始变成多个逻辑碎片，大幅增加业务改造与运维成本。

挑战三：List 和元数据性能会影响训练效率

大模型训练非常依赖元数据访问——训练任务启动前要列出数据集对象、分布式训练要发现数据分片、Checkpoint 恢复要枚举版本和分片，数据清洗任务要扫描大量对象，这些操作均需稳定的 List 与元数据能力。

当对象数量达到百亿级甚至更高时，List 已经不是普通目录操作，而是对元数据系统的持续压力测试。如果响应不稳定，训练任务启动会变慢，Checkpoint 恢复会变慢，GPU 甚至闲置在“找数据”环节，造成资源浪费。

挑战四：治理策略会被多桶、多集群打散

AI 数据湖需要统一权限、生命周期、审计和监控。但在多桶、多集群架构下，这些策略需要重复配置、同步和校验，不仅增加运维工作量，更可能出现策略不一致，进而引发数据访问异常、合规审计失败、故障定位困难等问题，埋下业务隐患。

可见，AI 数据湖的核心诉求，从来不是“能否扩容”，而是“扩容后能否保持统一的数据视图与简单的业务边界”——这正是 XSKY XEOS 的核心价值所在。

解决方案：把规模复杂度留在存储系统内部

面对该客户的核心痛点，XSKY XEOS 的设计思路是：将容量、对象数量、元数据访问的规模复杂度，全部留在存储系统内部，不将任何负担传导给训练框架、数据平台与业务团队，让业务侧“无需改造、无感扩容”，具体解决方案如下：

• 单桶千亿级对象，保持统一数据视图

XEOS 支持单桶千亿级对象能力，可在统一桶视图下，无缝承载训练样本、小文件、数据分片、索引文件、Checkpoint 分片、模型权重和推理日志等全链路数据资产。

这意味着，业务路径不需要因为对象数量增长而频繁调整，训练脚本不需要感知底层分桶逻辑，数据采集和清洗任务也不需要维护复杂的分桶路由。从根源上避免数据湖碎片化，解决“拆桶带来的业务改造”痛点。

• EB 级容量横向扩展，支撑长期增长

针对 AI 数据湖持续增长的特点，XEOS 通过多集群管理和统一命名空间能力，将多个数据集群纳入同一逻辑命名空间。对上层训练框架、数据平台和业务应用而言，底层容量可以按需横向扩展至 EB 级，上层仍保持统一桶视图、统一访问路径和统一治理边界。彻底解决“多集群拆分带来的业务复杂度”问题，区别于传统多集群拼接容量的粗放模式。

• 多级元数据与 List 优化，减少训练等待

XEOS 面向 AI 场景中的高并发元数据访问和 List 操作进行优化，提升大规模对象场景下的数据发现和路径遍历效率——无论是训练初始化、数据分片发现，还是 Checkpoint 恢复、ETL 扫描，都能实现快速响应，避免 GPU 闲置在“找数据”环节，直接提升训练效率与资源利用率，精准解决“元数据性能不足”的核心痛点。

案例价值：让 AI 数据湖在增长中保持统一

对于该头部人工智能科研机构而言，XSKY XEOS 承载的不仅是海量对象数据，而是贯穿大模型研发全流程的数据资产——从训练语料、标注结果、数据分片、到模型权重，从 Checkpoint、评测数据、到推理日志，XEOS 以“统一、高效、可扩展”的核心能力，为客户带来实实在在的业务收益，真正实现“AI 数据湖在增长中保持统一”。

• 无需拆分集群

统一命名空间支持 EB 级容量横向扩展，避免因容量增长过早拆分集群，减少跨集群数据迁移、运维管理的成本，提升研发效率；

• 无需改造业务

单桶千亿级对象能力，避免因对象数量增长调整业务路径、适配分桶逻辑，为研发团队节省大量业务改造时间；

• 提升训练效率

多级元数据与 List 优化，显著缩短训练初始化、分片发现、Checkpoint 恢复的等待时间，充分释放 GPU 算力，减少资源浪费；

• 简化治理难度

统一桶视图与治理边界，让权限、生命周期、审计、监控策略实现“一次配置、全域生效”，降低运维成本，规避合规风险。

大模型时代，存储的选型已经不再是“选择容量”，更是“选择未来 AI 平台的复杂度边界”。

XSKY XEOS 对象存储以单桶千亿级对象、EB 级容量横向扩展和面向 AI 数据湖优化的元数据核心能力，打破存储规模与数据统一的矛盾，让客户无需在“扩容”与“统一”之间做选择——把复杂留给存储，把简单留给业务。

这不是新概念，而是大模型时代对对象存储提出的新要求：让 AI 数据湖扩容不拆桶、增长不添乱，让训练链路少一点等待，让业务团队少一点负担，为大模型研发筑牢统一、高效、可持续扩展的存储底座。