|
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;color: rgb(0, 0, 0);font-size: 14px;text-align: justify;visibility: visible;line-height: 2em;">导读随着大模型技术的蓬勃发展，提高大模型训练效率、降级训练成本已成为全球范围内的重要趋势。在大模型训练场景中，底层存储系统面临着双重核心挑战：一方面需满足数据读写的高性能需求，另一方面要保证海量文件存储服务的高可用。本文将分享B站在大模型训练场景下的存储优化实践及效率提升策略。ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;visibility: visible;">1.背景介绍 2.方案选型 ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;">3.挑战及应对方案ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;">4.未来规划ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;">5. 问答环节
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 17px;font-style: normal;font-variant-ligatures: normal;font-variant-caps: normal;font-weight: 400;letter-spacing: normal;orphans: 2;text-indent: 0px;text-transform: none;widows: 2;word-spacing: 0px;-webkit-text-stroke-width: 0px;white-space: normal;text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;text-align: left;line-height: 1.75em;">分享嘉宾｜陈世云 哔哩哔哩 资深开发工程师ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 17px;font-style: normal;font-variant-ligatures: normal;font-variant-caps: normal;font-weight: 400;letter-spacing: normal;orphans: 2;text-indent: 0px;text-transform: none;widows: 2;word-spacing: 0px;-webkit-text-stroke-width: 0px;white-space: normal;text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;text-align: left;line-height: 1.75em;">编辑整理｜李天烨ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 17px;font-style: normal;font-variant-ligatures: normal;font-variant-caps: normal;font-weight: 400;letter-spacing: normal;orphans: 2;text-indent: 0px;text-transform: none;widows: 2;word-spacing: 0px;-webkit-text-stroke-width: 0px;white-space: normal;text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;text-align: left;line-height: 1.75em;">内容校对｜李瑶ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 17px;font-style: normal;font-variant-ligatures: normal;font-variant-caps: normal;font-weight: 400;letter-spacing: normal;orphans: 2;text-indent: 0px;text-transform: none;widows: 2;word-spacing: 0px;-webkit-text-stroke-width: 0px;white-space: normal;text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;text-align: left;line-height: 1.75em;">出品社区｜DataFun
01
背景介绍
首先介绍B站模型训练的场景架构。
1.B站模型训练存储架构 存储服务
| 优点
| 不足
| HDFS
| 存储量大，扩展性好，无带宽限制
| 小文件不友好，容易读写抖动
| BOSS
| 对小文件比较友好
| 受网络带宽限制
| NAS
| 读写性能比较好
| 扩展性不足，成本较高
|
对大模型训练任务来说，这些存储服务可以解决部分问题，但还有很多方面无法支持训练的需求，我们通过进一步优化来满足模型训练中对存储的多样化诉求。
2.模型训练场景数据处理环节
B站模型训练对存储的需求主要集中在两方面：
结合上述场景，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）主节点稳定性问题
重启/主节点切换加速：
主从节点数据一致性：
通过上述优化，主节点重启时间从25分钟缩短到了5分钟，这样Master节点做异常切换时对业务也是无感知的。
（2）Worker节点稳定性问题
Alluxio作为缓存服务，经常需要同步数据，当Master节点切换时经常出现Worker节点负载上升，导致OOM的情况，甚至可能造成集群不可用。
分析发现，Alluxio在提交Load任务时，通过调度器将Load任务发送到对应的Worker节点上，在Worker节点上加载具体的目录。若出现Load任务失败或暂停，Leader Master节点切换时，失败和停止的任务会重新被拉起，如果任务较多，同时开始调度就会导致Worker负载上升。
我们做了如下修复来解决上述问题：
除了上述问题以外，在Load大量数据时，Worker节点也非常容易出现OOM。研究发现，Worker节点在Load数据时需要申请buffer用于存放临时数据，实现上采用了池化内存（NioDirectBufferPool）方式，以防止频繁的内存申请，而这一方式存在以下问题：
Block差异较大时利用效率不佳。
复用机制有缺陷（size=0时不复用）。
容量控制&回收机制缺失。
针对这些问题，我们做了如下优化：
（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磁盘。
数据读取方面：
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还是相当依赖于硬件，包括大块大容量磁盘。性能相比会有优势，但是其组织架构和运营成本高，也无法像我们的缓存方案一样能够适配异构场景。 | 
