大模型训练的热潮正席卷而来，效率与成本是每个团队都在全力攻克的课题。然而，在训练流程的背后，存储系统往往是被低估的关键环节——它既要承受数据读写的高性能压力，又要保障海量文件的高可用服务。B站的技术团队在这一领域做了不少扎实的优化工作，今天就来聊聊他们在大模型训练场景下的存储实践，以及如何通过一系列方案把性能提上去、把风险降下来。
整篇文章将围绕五个部分展开：背景介绍、方案选型、挑战及应对方案、未来规划，以及问答环节中的关键思考。
背景介绍
先看看B站模型训练的整体存储架构。
B站模型训练存储架构
应用端覆盖了很大范围：大模型、安全审核、搜索推荐、电商广告等站内场景。这些场景的数据处理依赖机器学习平台，提供模型训练的全周期管理——交互式建模、数据管理、训练部署等。底层存储则是混合形态，包括HDFS、NAS、本地磁盘，以及自研的对象存储服务BOSS。每种存储各有优劣，下面这张表一目了然：
| 存储服务 | 优点 | 不足 |
| HDFS | 存储量大，扩展性好，无带宽限制 | 小文件不友好，容易读写抖动 |
| BOSS | 对小文件比较友好 | 受网络带宽限制 |
| NAS | 读写性能较好 | 扩展性不足，成本较高 |
对大模型训练任务而言，这些存储能解决部分问题，但远谈不上完美。很多场景需要额外优化才能满足训练的多样化诉求。
模型训练场景数据处理环节
B站模型训练对存储的需求主要集中在两个阶段：
- 数据归集和预处理阶段：需要高吞吐、大容量的存储介质，类似大数据批处理；依赖GPU的数据清洗过程需要统一的高速文件访问接口。
- 模型训练阶段：需要读取大量小文件（200K到1兆左右），同时要求极低延迟，因此存储系统必须兼具高带宽和低延迟特性；训练过程中还有高频、快速的存储写入（如Checkpoint操作），要尽可能减少对算力资源的占用。
结合这些场景，B站大模型训练对存储的总体需求可以概括为四点：
- 存储容量：大模型训练往往依赖大容量存储和海量小文件，单个训练任务的文件数量就可能达到亿级别。
- 吞吐要求高：大模型训练对IO读写要求很高，吞吐性能不足将导致读写变慢，直接拖累训练效率。
- 使用成本：数据来源多种多样，除了HDFS，还有对象存储、NAS等。训练开发希望用POSIX协议实现一个类似本地磁盘的统一存储访问层，无缝融合异构数据，降低开发成本。
- 稳定性：存储系统的读写卡顿、失败以及服务器故障是训练任务异常的核心风险点。中断之后的重启、数据恢复会浪费大量算力资源，稳定性要求相当高。
目前B站底层存储以HDFS为主，总容量EB级别，节点数量接近1万，容量上满足需求没问题。但HDFS主要用HDD介质，吞吐性能明显低于SSD，部分模型训练的吞吐要求难以达标。另外，DN节点日常负载高，突发任务容易把负载打满，影响读写性能。HDD磁盘故障率大约每天5‱，也容易带来不确定风险。而且HDFS接入主要依赖Java/C SDK，对模型训练的兼容性不够友好。
换句话说，现有HDFS集群难以全面满足AI大模型训练对高吞吐、低延迟、高稳定性的核心需求，必须通过存储架构升级和技术优化来实现突破。
方案选型
方案对比
为了满足大模型训练需求，团队对内部现有存储方案与业界主流高速存储方案做了多维度对比。
公司内部主要有NAS和PFS高速存储，全部用SSD磁盘，IO性能没问题，但成本高昂且扩展性不足。数据量小的时候成本可控，一旦数据量上来，就难以承受。
调研过NAS/PFS加冷热分层的方案，但问题也很明显：跨文件系统的数据交换复杂度高，数据一致性难以保证，底层或上层数据变化时同步困难，数据迁移和维护代价大，需要额外人力维持运营。
最终选的是基于Cache的加速方案——用Alluxio管理缓存。相比前两种方案，优势很突出：使用闲置SSD存储，无额外采购成本；Alluxio可以自动缓存加载和淘汰，数据管理复杂度低；支持Fuse高速统一访问，使用简单；内部已有团队小规模使用过，积累了一定运维经验，整体风险可控。
基于Alluxio的存储加速方案
团队采用Alluxio 2.9.4版本集群，Worker节点使用HDFS上的空闲SSD磁盘部署，底层存储同时兼容BOSS和HDFS。
训练时，先把依赖数据加载到Alluxio集群，训练启动时启动Alluxio Fuse，通过Fuse服务直接读写集群中的数据。这个方案充分利用了大数据的闲置资源，资源弹性好，管理代价低。
当然，引入Alluxio服务也带来了新挑战，主要包括三个：元数据瓶颈、故障率变大（对恢复能力要求更强）、远程访问有潜在故障（对容错能力要求更高）。
引入缓存后，存储性能显著提升——无论大文件还是小文件，读写吞吐能力都大幅增强，尤其针对大模型训练的小文件场景，性能提升了接近六倍，完全能满足训练在IO方面的需求。
挑战及应对方案
目前这套缓存加速方案已经在B站广泛应用，实际生产中遇到了不少挑战：
- 系统稳定性保障与优化：高并发、大规模数据持续读写场景下，要保障Alluxio缓存系统的高可用和抗压能力。
- 元数据容量与扩展性瓶颈：面对海量文件规模的AI训练，Alluxio集群元数据存储面临容量天花板。
- 写入性能与一致性平衡：Alluxio缓存集群存在一定写入稳定性问题，容易影响模型训练数据输出，导致训练中断。
- 平台化功能拓展与生态集成：为了提升运营效率、降低AI开发者使用门槛，需要构建统一的接入平台，方便用户操作缓存数据。
下面逐一展开解决方案。
系统稳定性保障与优化
系统稳定性的优化主要从主节点、Worker节点和Client端三个方向入手。
（1）主节点稳定性问题
重启/主节点切换加速：默认Checkpoint机制依赖Journal数量，训练场景下恢复时间较长。团队增加了基于时间间隔的Checkpoint触发机制，保障恢复时效性。同时把审计日志、Journal、Metastore日志拆分到不同盘，进一步提高恢复效率。
主从节点数据一致性：开启Worker节点上报到所有状态Master，减少服务就绪耗时；Worker节点等待Follower Master节点Journal日志回放完成后，再开启Block上报，保证切换过程中加载数据不丢失。
经过优化，主节点重启时间从25分钟缩短到5分钟，Master节点异常切换时对业务几乎无感知。
（2）Worker节点稳定性问题
Alluxio作为缓存服务经常需要同步数据，Master节点切换时，Worker节点负载容易上升甚至OOM，导致集群不可用。分析后发现，Alluxio提交Load任务时，调度器把任务发送到对应Worker节点上加载目录。如果Load任务失败或暂停，Leader Master切换时失败和停止的任务会被重新拉起，任务太多同时调度就会导致Worker负载上升。
修复方案：Journal Entry同步Job状态信息，Follower Leader更新Job状态；Leader Master节点切换时检查Load任务状态。
另外，大量加载数据时Worker节点也容易OOM。原因是Worker节点加载数据时需要申请buffer存放临时数据，实现上用了池化内存（NioDirectBufferPool）来防止频繁申请，但这个方式存在几个问题：Block差异较大时利用效率不佳；复用机制有缺陷（size=0时不复用）；容量控制和回收机制缺失。
优化措施：申请buffer时允许较大的空闲buffer；清理size=0的buffer；增加清理机制，当DIRECT_MEMORY使用量达到总容量80%时，触发NioDirectBufferPool清理，释放空闲的零碎buffer块。
（3）数据读取容错能力
在Master和Worker节点优化的基础上，为了进一步提升集群数据读取稳定性，Fuse Client端做了容错降级方案。当Alluxio集群因发布、故障、Worker节点磁盘故障等造成读写卡顿时，Fuse Client自动降级到底层存储（HDFS）进行训练数据读取。后续其他读请求直接从HDFS读取，等待用户自定义配置的时间后，再恢复从Alluxio读取。
元数据容量与扩展性瓶颈
大模型训练数据文件小、数量多，单Alluxio集群采用Master/Slave架构，存在元数据瓶颈。当前一组Alluxio集群可以维持2亿文件数稳定运行，但仍然无法满足所有需求。
引入Router机制来解决。在配置中心配置路径和集群间的路由信息，Master节点定时从配置中心获取最新路由表。Fuse Pod启动时向Master获取路由表信息，通过心跳连接不断更新。当Fuse Client访问目录时，根据路由表访问对应的Alluxio集群获取数据。基于这种方式，Alluxio集群从1组扩展到了7组。
海量小文件问题通过平行扩容得到缓解，但元数据节点资源浪费和IO性能问题仍然存在。因此引入了文件折叠方法——把批量小文件合并成大文件，通过版本与Meta Offset信息读取，减少元数据总量。
写入性能与一致性平衡
Alluxio异步写入稳定性不足，Worker节点异常会导致远程写入失败，多副本写入也无法提升稳定性，进而导致训练数据内容丢失、训练任务中断。
Worker故障不可避免，所以通过Alluxio Fuse直连HDFS的方案提高稳定性：HDFS采用分层存储，支持SSD存储热数据；Checkpoint直接写入HDFS SSD磁盘；样本预处理场景写入HDFS HDD磁盘。
数据读取方面：支持用户配置写入完成后立刻触发元数据同步，保证数据一致性；支持用户自定义配置（小时/天级）数据同步策略；数据读取仍通过Alluxio缓存。
平台化功能拓展与生态集成
为了提升运营效率、降低AI开发者使用门槛，团队构建了统一接入平台——BCFS（Bilibili Cache FileSystem），支持用户自定义管理缓存数据集。用户可以自由配置底层存储类型（HDFS或BOSS对象存储等），同时支持多种挂载方式——直连HDFS、通过Alluxio缓存访问，或者先写入HDFS再通过Alluxio读取。
设置好数据集后，用户可以自定义同步底层存储，包括Alluxio缓存。BCFS平台有效降低了运维压力，用户能自主管理数据集，对数据容量也有更清晰的认知。
针对特大型目录，底层数据同步时按子目录拆分，减少同步期间对集群访问的影响。另外，部分用户变更了底层存储信息但未触发同步，可能导致数据读取异常。因此提供了自动触发元数据同步的功能，用户可自定义配置同步策略，BCFS平台按策略定时触发底层数据同步，更好地保证数据一致性。
未来规划
最后聊聊正在推进和计划中的主要工作。
- 完善缓存管理策略，定制适合AI数据特征的缓存策略。目前缓存淘汰主要依赖集群自身的LRU机制，团队计划更全面地管控Alluxio集群缓存使用，提升使用效率。
- 进一步完善读写稳定性，拓展用户场景。目前Alluxio对Posix协议的支持还不够完善，存在一些稳定性问题，计划进一步提升集群稳定性，同时拓展更多用户场景。
- 打造满足AI大模型训练全环节的存储加速方案。完善大模型训练存储产品，提供AI大模型训练全环节的存储解决方案。
问答环节
Q1：在实施这个项目中遇到的最大困难是什么？以及是如何解决的？AI大模型的训练存储有没有考虑过对象存储？
A1：最大困难主要是从无到有的过程，会遇到各种各样的突发情况，团队一起去了解各个组件，学习业界先进经验来解决问题。对象存储主要有限带宽问题，性能满足的情况下，后续有考虑。
Q2：在DeepSeek推出后，开源的3FS性能也非常好。有没有对比过其优缺点？
A2：整体而言，3FS相当依赖于硬件，包括大块大容量磁盘。性能相比会有优势，但其组织架构和运营成本高，也无法像我们的缓存方案一样适配异构场景。
以上就是本次分享的核心内容。从方案选型到落地优化，每一步都踩过坑、填过坑，最终形成了一套兼顾性能、成本和稳定性的存储加速方案。希望对大家有所启发。