B 站大模型存储加速实践

01

背景介绍

首先介绍 B 站模型训练的场景架构。

1. B 站模型训练存储架构

• 应用端：包括大模型、安全审核、搜索推荐、电商广告等站内场景。

  
  

• 机器学习平台：提供模型训练的全周期管理，包括交互式建模，数据管理，模型训练的部署等相关内容。

  
  

• 基础架构：底层存储依赖于 HDFS、NAS、本地磁盘及自研的对象存储服务 BOSS。这些存储各有优点，也有不足之处。

  
  

对大模型训练任务来说，这些存储服务可以解决部分问题，但还有很多方面无法支持训练的需求，我们通过进一步优化来满足模型训练中对存储的多样化诉求。

2. 模型训练场景数据处理环节

B 站模型训练对存储的需求主要集中在两方面：

• 数据归集和预处理阶段：需要高吞吐、大容量的存储介质，类似于大数据的批处理；依赖 GPU 的数据清洗过程需要统一的高速文件访问接口。

  
  

• 模型训练阶段：需要读取大量（200K 到 1 兆左右）的小文件，同时要求极低的延迟，因此要求存储系统具备高带宽、低延迟特性；在训练过程中有高频、快速的存储写入（如 Checkpoint 操作），需尽可能减少对算力资源的占用。

  
  

结合上述场景，B 站大模型训练场景对存储的总体需求为：

• 存储容量：大模型训练可能大多依赖于大容量存储和海量小文件，单个训练任务的文件数量就可能达到亿级别。

  
  

• 吞吐要求高：大模型训练对 IO 读写要求高，若吞吐性能不足，可能导致读写变慢。

  
  

• 使用成本：大模型数据来源多种多样，除 HDFS 外，可能还有对象存储、NAS 等。对于训练开发而言，希望通过 POSIX 协议实现一个类似本地磁盘的统一存储访问层，实现对异构数据的无缝融合，从而减少开发成本。

  
  

• 稳定性：存储系统的读写卡顿、失败以及服务器故障是导致训练任务异常的核心风险点。这类问题不仅会直接中断训练流程，还会因任务重启、数据恢复等环节造成大量计算资源的浪费，因此对稳定性有着较高要求。

  
  

当前 B 站底层存储还是以 HDFS 为主，总容量在 EB 级别，节点数量接近 1 万，从容量上是可以满足模型训练需求的。但由于主要采用 HDD 介质构建，吞吐性能明显低于 SSD，难以满足部分模型训练吞吐要求。其次由于 DN 节点的日常高负载，突发任务会导致这些节点的负载打满，影响数据读写性能。此外，HDD 磁盘故障率高，大概在每日 5‱  左右，也容易触发一些不确定风险。最后，HDFS 接入主要还是依赖于 Java/C SDK 等方式，对模型训练的兼容性也不够友好。

综上，尽管 B 站现有 HDFS 集群难以全面满足 AI 大模型训练对高吞吐、低延迟、高稳定性存储服务的核心需求，需通过存储架构升级与技术优化实现突破。

02

方案选型

1. 方案对比

为满足大模型训练需求，我们对内部现有存储方案与业界主流高速存储方案进行了多维度对比分析。

公司内部存储方案主要为 NAS 和 PFS 高速存储，全部采用 SSD 磁盘，IO 性能可以满足诉求，但成本高昂且扩展性不足。数据总量不高时，整体成本尚可控，而一旦数据量上升，成本就难以承受了。

我们对 NAS/PFS+ 冷热分层的方案进行了调研，该方案也存在显著问题。首先，需要跨文件系统的数据交换，复杂度较高；其次，数据一致性难以保证，当底层或上层数据发生变化时，数据同步实现困难；此外，数据迁移和维护代价高，需要额外人力维持相关数据运营。

最终，我们采用的是基于 Cache 的加速方案。利用 Alluxio 对缓存进行管理，相比前两种方案，此方案具有诸多优势。首先，使用闲置 SSD 存储，无额外采购，可节约成本；第二，Alluxio 可实现自动缓存加载和淘汰，数据管理复杂度较低；第三，支持 Fuse 高速统一访问，使用简单；最后，内部已有团队小规模使用，已具备一定运维经验，整体风险较低。

2. 基于 Alluxio 的存储加速方案

我们采用 2.9.4 版本 Alluxio 集群，Worker 节点使用 HDFS 上的空闲 SSD 磁盘进行部署，底层存储同时兼容了 BOSS 和 HDFS。

模型训练时，首先将需要依赖的数据加载到 Alluxio 集群中，接着在训练启动时启动 Alluxio Fuse，通过 Fuse 服务直接读写 Alluxio 集群中的数据。这套方案充分利用了大数据的闲置资源，资源弹性比较好，管理代价也较低。

然而，引入 Alluxio 服务也带来了一些挑战，主要包括以下三点：

• 元数据瓶颈的问题；

  
  

• 故障率变大，对恢复能力要求更强；

  
  

• 远程访问有潜在故障，对容错能力要求更高。

  
  

引入 Alluxio 缓存之后，存储服务性能显著提升，无论对大文件还是小文件的读写吞吐能力均大幅增强。尤其是针对大模型存储训练的小文件场景有接近六倍的性能提升，完全能够满足大模型训练在 IO 方面的需求。

03

挑战及应对方案

目前基于 Alluxio 的缓存加速方案已在B站得到了广泛应用，在实际生产过程中，我们也面临了许多挑战：

• 系统稳定性保障与优化：高并发、大规模数据持续读写场景下，需保障 Alluxio 缓存系统的高可用性和抗压能力。

  
  

• 元数据容量与扩展性瓶颈：面对海量文件规模的 AI 训练场景，Alluxio 集群元数据存储面临容量天花板。

  
  

• 写入性能与一致性平衡：Alluxio 缓存集群存在一定的写入稳定性问题，容易影响模型训练数据输出，导致训练中断。

  
  

• 平台化功能拓展与生态集成：为提升运营效率，降低AI开发者的使用门槛，需构建统一的接入平台，方便用户操作缓存数据。

  
  

接下来将展开介绍我们针对上述挑战的解决方案。

1. 系统稳定性保障与优化

系统稳定性方面的优化主要在主节点、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 任务时，通过调度器将 Load 任务发送到对应的 Worker 节点上，在 Worker 节点上加载具体的目录。若出现 Load 任务失败或暂停，Leader Master 节点切换时，失败和停止的任务会重新被拉起，如果任务较多，同时开始调度就会导致 Worker 负载上升。

我们做了如下修复来解决上述问题：

• Journal Entry 同步 Job 状态信息，Follower Leader 更新 Job 状态；

  
  

• Leader Master 节点切换时检查 Load 任务状态。

  
  

除了上述问题以外，在 Load 大量数据时，Worker 节点也非常容易出现 OOM。研究发现，Worker 节点在 Load 数据时需要申请 buffer 用于存放临时数据，实现上采用了池化内存（NioDirectBufferPool）方式，以防止频繁的内存申请，而这一方式存在以下问题：

• Block 差异较大时利用效率不佳。

  
  

• 复用机制有缺陷（size=0 时不复用）。

  
  

• 容量控制&回收机制缺失。

  
  

针对这些问题，我们做了如下优化：

• 申请 buffer 允许较大的空闲 buffer。

  
  

• 清理 size=0 的 buffer。

  
  

• 增加清理机制，当 DIRECT_MEMORY 使用量达到总容量80%时，触发 NioDirectBufferPool 清理机制，清理 NioDirectBufferPool 中空闲的零碎buffer 块。

  
  

（3）数据读取容错能力

在上述对 Master 和 Worker 节点优化的基础上，为进一步提升集群数据读取的稳定性，我们在 Fuse 的 Client 端采取了容错降级方案。

当 Alluxio 集群因发布、故障、Worker节点磁盘故障等原因造成读写卡顿时，Fuse Client 会自动降级到底层存储进行训练数据读取。后续其他读请求直接从 HDFS 读取，等待一定时间后（用户自定义配置），再次读取文件时将从 Alluxio 读取。

2. 元数据容量与扩展性瓶颈

大模型训练数据文件小，数量多，单 Alluxio 集群采用 Master/Slave 架构，存在元数据瓶颈。当前一组 Alluxio 集群可以维持 2 亿文件数稳定运行，仍然无法满足所有需求。

为提升元数据服务能力，我们引入了 Router 机制。首先，在配置中心配置路径和集群间的路由信息，Master 节点定时从配置中心获取最新的路由表信息。当 Fuse Pod 启动时，会向 Master 获取路由表信息，并通过心跳连接不断更新路由表信息。当 Fuse Client 访问目录时，就会根据路由表信息访问对应的 Alluxio 集群以获取数据。基于这种方式，我们已将 Alluxio 集群从 1 组扩展到了 7 组。

大模型训练海量小文件问题通过平行扩容得到了一定缓解，但仍然存在元数据节点资源浪费和 IO 性能问题。

因此引入了文件折叠方法，将批量小文件合并成大文件，通过版本与 Meta Offset 信息读取，从而减少元数据总量。

3. 写入性能与一致性平衡

Alluxio 异步写入稳定性不足，Worker 节点异常会导致远程写入失败，多副本写入也无法提升稳定性，会导致训练数据内容丢失、训练任务中断。

Worker 故障不可避免，通过 Alluxio Fuse 直连 HDFS 方案提高稳定性。

• HDFS 采用分层存储，支持 SSD 存储热数据。

  
  

• CheckPoint 直接落 HDFS SSD 磁盘。

  
  

• 样本预处理场景落 HDFS HDD 磁盘。

  
  

数据读取方面：

• 支持用户配置写入完成后立刻触发元数据同步，以保证数据一致性。

  
  

• 支持用户自定义配置(小时/天级)数据同步策略。

  
  

• 数据读取仍通过 Alluxio 缓存。

  
  

4. 平台化功能拓展与生态集成

为提升运营效率，降低 AI 开发者使用门槛，我们构建了统一接入平台——BCFS（Bilibili Cache FileSystem），支持用户自定义管理缓存数据集。用户可以自由配置底层存储类型，如 HDFS 或 BOSS 对象存储等。同时，支持多种挂载方式，可以直连 HDFS，也可以通过 Alluxio 缓存访问，还支持写入 HDFS 再通过 Alluxio 读取。

设置好数据集后，用户就可以自定义同步底层存储，包括 Alluxio 缓存。

BCFS 平台可有效降低运维压力，用户可自主管理其数据集，并对其数据容量有了更清晰的认知。

针对特大型目录，底层数据同步时按子目录拆分，以减少数据同步期间对集群访问的影响。

部分用户变更了底层存储信息，但未触发同步，可能导致数据读取异常。因此提供了自动触发元数据同步的功能，用户可以自定义配置同步策略，BCFS 平台按策略定时触发底层数据同步，从而更好地保证数据一致性。

04

未来规划

最后分享一下正在推进中和计划中的主要工作。

1. 完善缓存管理策略，定制适合 AI 数据特征的缓存策略。

当前缓存淘汰等还是依赖集群自身的 LRU 机制，我们计划更全面地管控 Alluxio 集群缓存使用，提升使用效率。

2. 进一步完善读写稳定性，拓展用户场景。

当前 Alluxio 对 Posix 协议的支持还不够完善，存在一些稳定性问题，我们计划进一步提升集群稳定性，同时拓展更多的用户场景。

3. 打造满足 AI 大模型训练全环节的存储加速方案。

完善大模型训练存储产品，提供 AI 大模型训练全环节的存储解决方案。

05

问答环节

Q1：老师您好，在实施这个项目中遇到的最大的困难是什么？以及是如何解决的？AI 大模型的训练存储有没有考虑过对象存储？

A1：最大困难主要还是从无到有的过程，会遇到各种各样的突发情况，我和同事们一起去努力了解各个组件，学习业界的先进经验去解决。对象存储主要是有带宽问题，性能满足的情况下，后续有考虑。

Q2：在 DeepSeek 推出后，开源的 3FS 性能也非常的好。有没有对比过其优缺点？

A2：整体而言，3FS 还是相当依赖于硬件，包括大块大容量磁盘。性能相比会有优势，但是其组织架构和运营成本高，也无法像我们的缓存方案一样能够适配异构场景。