导读：云知声 Atlas 超算平台作为底层基础架构，支持着公司在 AI 各个领域的模型训练与推理服务的开展。该计算集群可为 AI 计算提供高性能计算和海量数据的存储访问能力。该平台支持主流机器学习架构，开发者能够实现语音、语言、大数据、多模态等核心技术的高效研发。
Atlas 利用 Fluid + Alluxio 提高了平台模型生产效率，本次将会从云知声引入分布式缓存的背景、引入缓存遇到的挑战与解决、如何基于全新的技术进行架构的设计与优化、如何在内部进行推广与生产实践以及平台后续改进点进行分享。
图 1 分享题目
今天的分享包括四个方面的内容：
图2 分享目录
01
云知声 Atlas 超算背景
云知声是一家具有自主知识产权的语音公司。技术栈包括语音、语义理解、图像、文本理解等多模态的AI技术基础，通过云上、用户端、AI芯片端三大解决方案支撑AI技术的落地。目前已经在医疗、教育、智慧酒店、智慧家居等都有落地的解决方案。
Atlas作为公司AI模型研发与迭代的基础架构，为AI生产提供了高效的计算能力以及海量数据的访问能力。
图3 公司技术架构
1. Atlas超算的架构
下面介绍Atlas超算的架构。
图4 公司技术架构
上图是Atlas的深度架构，支持深度学习模型端到端的训练。深度学习的整个生命周期包含数据处理、模型训练以及模型推理。架构上从上层支持各种各样AI的应用，比如：语音语义、图像的处理。支持的计算包括数据的预处理、特征提取以及数据的分析。具体的模型包括了深度学习模型、大数据计算。倒数第二层是核心控制层，基于云原生的组件进行了二次开发以及早期自研的一些组件。具备的功能包括帮助用户自动分配任务、调度到后端底层硬件节点等。
最底层是海量GPU卡，包括A100、V100、RTX6000等高性能计算卡。底层存储包括多套分布式文件系统，以Lustre分布式文件系统为主。混部式网络包括100GB InfiniBand高性能网络以及40GB以太网。
用户提交作业流程，提供命令行及WebUI方式。用户可以用命令行提交任务；Atlas核心层帮助用户进行任务的分发与调度；最后到达底层硬件进行计算。
Atlas的模型训练是基于Kubernetes的容器化方式，容器读取存储基于hostpath 方式，在每个存储节点都安装分布式存储客户端。GPU的端口直接通过hostpath与存储客户端进行交互，客户端再与分布式存储进行数据交互。
2. Atlas 早期遇到的问题
下面介绍Atlas在早期遇到的问题。
图5 Atlas 早期遇到的问题
（1）存储带宽瓶颈
Atlas有上千块GPU计算卡，每块卡的计算能力非常强，存储带宽与IOPS要求比较高。但由于底层的分布式存储系统带宽有限，而且有些节点并发的带宽就达到数 GB/s,整个集群上千块 GPU 计算卡所需要的总体带宽非常大。带宽与计算能力之间存在差距，因此出现了部分任务计算效率较低。
（2）同GPU节点的IO带宽竞争
像TTS场景下链路是单机单卡、或单机双卡或叁卡，同GPU计算节点会有5-6个用户链路。多个链路在同GPU节点上，出现了IO带宽竞争。通过监控可以看到，由于IO没有跟上，导致GPU利用率低。
（3）海量小文件
大量的Wav格式语音以及JPG格式图像散文件，这样的小文件太多会造成存储系统元数据压力大。
（4）数据冗余
每个部门或组、合作单位，都以目录形式存储在分布式存储中。不同目录的权限不同，造成相同数据集分布在不同的目录上，重复存储，造成存储冗余和空间浪费。
3. 早期问题的解决方案
针对以上早期遇到的问题，提出了下面的解决方案。
图6 Atlas 早期解决方案
（1）存储资源限制
在每个计算节点上限制最高带宽；存储侧基于用户级别用户的uid和gid对带宽与IOPS进行限制。
（2）限制小文件
限制用户的文件数，要求用户将小文件聚合成lmdb、tfrecord 大文件的格式。但这种大文件格式对音频处理的模型降噪效果会产生影响；因此限制小文件并不能解决所有的问题。
（3）重构任务调度器
优先将任务调度到空闲的节点，添加调度策略，从根本上避免同节点竞争。但由于整体资源紧张，还是很难彻底解决。
（4）多级缓存
提供单节点的多级缓存，任务提交与完成时，自动复制数据和删除数据。但该方案缺少自动化机制与元数据管理，且为单点实现，缺乏对缓存的控制。
以上措施都未能从本质上解决所遇到的问题。
--
02
Atlas + Alluxio 适配
Atlas研发团队从2019年接触到Alluxio软件，并经过数月功能、性能和稳定性的测试。从功能上与业务系统进行适配，包括上层与业务系统的适配和底层与存储系统的适配。
1. Atlas + Alluxio
上层业务是基于Tensflow和Pytorch框架，它们全都用POSIX 进行文件读写。Alluxio Fuse正好提供了POSIX的接口方式，与Atlas业务可以进行天然适配。Atlas的底层存储与业界不同。大家通常是用PV/PVC方式访问对象和分布式存储，Atlas则是基于hostpath的方式。而Alluxio支持基于hostpath的存储挂载方式。以上两点是引入Alluxio的关键点。
Alluxio支持权限的继承，底层的权限能继承到缓存上，功能上Alluxio能够满足业务端的要求。Atlas对业务端的性能进行了测试，包括语音、降噪等方面。
在部署方面，Alluxio支持二进制、容器和Kubernetes方式进行部署。Atlas与Alluxio两者的技术栈匹配度非常高，并能以廉价的方式解决带宽与性能的瓶颈问题。
图7 Atlas + Alluxio 适配
2. 为什么选择Fluid
2020年Fluid早期开源时，Atlas作为第一批用户加入Fluid社区。选择Fluid主要有以下考虑：
图8 选择Fluid的收益
Alluxio有数百配置项，这样的调优配置非常适合于Atlas繁杂的应用和数据类型，包括小文件，中文件和大文件；但Alluxio的Docker方式并不适合。
Alluxio单套部署的爆炸半径大；而Atlas需要Fluid的轻量级、爆炸半径小，方便应对意外情况，尽力保证用户的应用继续进行。
在对性能方面进行测试时，发现把整套Alluxio作为缓存数据集，放在某台GPU节点上，会占用较多资源。
Fluid使缓存具有可观测性和可操作性。在而Alluxio的Docker方式，缓存会直接调度到机器，用户无法观察和管理。
通过Fluid可以添加更多调度策略。可以基于特定卡类型和网络类型，调度到特定节点，使调度会更加高效。
3. Atlas + Fluid + Alluxio
现在整体的架构如下图所示。现在是三层架构，核心控制层是Kubernetes + Kuberflow。在数据缓存的控制层部署了Fluid。Fluid有Dataset和Runtime的概念，用核心控制层部署相应Fluid组件。Fluid作为中间数据管控层管理、部署Alluxio集群，部署Alluxio Worker、Fuse和Master，让Alluxio做底层分布式存储的交互。
流程也发生变化：之前用户提交任务请求直接到核心控制层，任务调度器帮着做调度，分发到GPU计算节点，GPU节点通过hostpath直接去读取存储。
现在全新的架构流程变化为：用户首先创建一个缓存，比如调度到A100、V100节点，通过添加相应的策略，明确所需的缓存介质，交给API Server，之后请求会被转交给Fluid控制。Fluid会帮助用户进行调度，调度任务到相应的GPU节点。
下图所示启动了2个Alluxio Worker集群，会调度到2个节点，准备好与底层UFS的交互、FUSE跟PV/PVC相应的组件。缓存创建完成之后，再去提交带有缓存的任务，任务调度器会自动选择带有缓存的节点，通过与FUSE的交互直接读取数据，变成三层架构。
图9 Atlas + Fluid + Alluxio新架构
4. 业务适配#1 – nonroot 与 hostpath 支持
Atlas在早期进行适配时遇到了一些问题，主要是与底层存储系统的适配：
（1）使用hostpath方式访问存储。
（2）整个超算的权限控制体系基于LDAP。LDAP的运作方式是在所有CPU、GPU和存储节点都部署LDAP客户端，客户端才与服务端进行交互。用户信息存储在某个节点的SSSD数据库中，而非传统的/etc/passwd上，所以无法获取用户信息。
（3）分布式文件系统开启了nonroot存储功能，由于权限管控，root无法访问普通用户的目录。早期的权限运作方式是：当任务交到节点时，会通过webhook自动注入用户的uid和gid到training pod上。训练节点上就有了用户的uid和gid；然后再与存储客户端进行交互，通过uid和gid去读取存储系统。相当于用户只能用自己的权限，访问仅限于自己的数据。
图10 业务适配#1 - nonroot 与 hostpath 支持
通过与社区合作完成了以下存储适配方案，解决了以上问题。
（1）Fluid支持hostpath挂载缓存数据集。
（2）读取用户信息的方式：在Fluid Fuse加入Init container，初始化时注入用户信息。Fuse挂载时以用户uid和gid与用户数据集进行绑定。Training pod也以同样uid和gid读取缓冲。上图展示了访问缓存时的权限所属。
存储适配是Atlas最大的适配部分，也是支撑后续进化的关键。
5. 业务适配#2 – 统一资源视图
Atlas通过Alluxio提供了统一的资源视图。
Atlas具有多套分布式存储系统，每个用户可以访问多套存储系统。如果用户的数据集比较大（TB级），会分布在不同的存储系统上。为避免大量的无效数据迁移，通过Alluxio接口多套存储系统，具备了统一资源视图的能力。并具备了在主目录下挂载不同存储系统子目录的功能。实现多套分布式存储系统和资源的统一管理。
Fluid支持多挂载路径，并聚合在统一的目录下，实现统一访问不同存储系统下的缓存数据集。
图11 业务适配#2 – 统一资源视图
6. 业务适配#3 – 数据预热
在数据预热方面，基于Alluxio提供了distributed load功能，对于TB级海量小文件，可以提前把数据集预热好，而无需几十个小时的数据加载过程，就可以很快享受到缓存数据带来的收益。
图12 业务适配#3 – 数据预热
7. 业务适配#4 – 自动化提交工具
早期用户跑单节点的单机多卡和单机单卡。近期Atlas上了大量分布式训练任务，例如 Pytorch DDP。在创建时，Fulid直接封装为任务提交的接口，变成atlasctl cache create，只把必要的信息暴露给用户，如用户想选择的缓存类型、缓存大小、缓存节点等必要信息。目前的流程变成：
（1）预先创建好缓存数据集
（2）创建模型训练任务
图13 业务适配#4 – 自动化提交工具
--
03
基于Atlas全新架构的实验
1.业务场景#1 – 语音降噪（小文件）
上面介绍了主要架构和适配过程。下面介绍业务实例，如语音降噪。这些语音文件都是非常小（小于1MB）的wav格式元文件。之前直接读取，IO会非常高，效率低。
图14 业务场景#1 - 语音降噪
通过实验，在小文件场景下，采用10卡RTX6000、全部内存缓存读取数据，新的调度方式会有10倍速度的提升。
图15 业务场景#1 - 语音降噪 测试结果1
从结果发现：
（1）训练效率有提升。
（2）降低训练时的底层存储占用带宽；从监控上看，节点的带宽基本为0。
（3）GPU利用率也有比较大的提升；原因是数据供给的充分，GPU利用率得以提升。
图16 业务场景#1 - 语音降噪 测试结果2
2. 业务场景#2 – 图像分类（中等文件）
这里还做了Resnet50读取ImageNet (tfrecord) 格式数据集。在RTX 6000节点上，模拟独占、7卡（3卡另外有任务）。配置如下图所示。
图17 业务场景#2 - 图像分类
结果如下图所示，单位是每秒能处理图片的张数。
从第一和第二行来看，Lustre独占方式是效果最好的方式；而对比组Alluxio缓冲方式，则直接提升了2.5倍的效率，中等大小文件有着较大的收益。
图18 业务场景#2 - 图像分类 测试结果
3. 实验#3 – 大文件
第三个实验是大文件测试，整个数据集是125GB的LMDB，进行文本识别。通过以下三种方式测试后发现，速度有30倍的提升。
（1）Lustre 读取
（2）Alluxio读取（未数据预热）
（3）Alluxio读取（数据预热）
图19 实验#3 - 大文件
图20 实验#3 - 大文件 测试结果1
之前LMDB的带宽是1GB以上，而这里的收益是带宽基本达到了0。节点带宽占用立刻下降。从后端的性能监控来看，带宽明显下降。
图21 实验#3 - 大文件 测试结果2
4. 业务场景#4 – 语音识别（DDP+Alluxio）
第四个场景是最近和算法团队一起联测的方案。采用4机40卡、5 机50卡这种场景去做大量语音识别模型的训练。采用原生Pytorch DDP方案，数据提前转化为numpy格式。测试时，由于已经实现了数据异步读取，此时带宽利用率已经比较高。
实验是对200GB数据集在2机20卡进行Pytorch 分布式训练，在75 epoch 收敛。通过DDP每个节点是100GB规模的数据缓存。
图22 业务场景#4 - 语音识别（DDP+Alluxio）
通过Alluxio 方案调优，时间由原来的20分钟缩短为18分钟，提速10%。
这说明在数据处理较好的情况下，依然能有10%的提速。
图23 业务场景#4 - 语音识别（DDP+Alluxio）测试结果
--
04
收益与未来展望
1. 总体收益
通过Alluxio+Fluid方式帮助，获取了以以下的收益：
（1）提高了模型的生产效率，小文件场景有10倍的提速。
（2）降低底层分布式存储系统的负载，单个节点有1-2GB带宽。大量用户使用时，对带宽的占用得以大幅下降。
（3）增加集群GPU 利用率，提升用户数据的读取效率。
（4）更加高效的缓存管理，通过可视化方式观察算法占用缓存数量及进度并加以度量，提升工作过程的可观测性。
图24 总体收益
2. 后续工作
目前在单机单卡、单机多卡有较多用户，使用过程中依然发现一些问题并进行改进：
（1）用户使用的是Atlas所提供的调优参数，希望通过与算法团队合作与测试，对特定场景的调优参数进行优化，把调优参数做成标准数据集，回馈社区。
（2）之前的数据集不是太大，TB或小于TB就直接用内存来做缓存。现在每个节点上都部署了几块TB以上的SSD，计划在以后的缓存调度上，能更加高效的调度。Fulid社区一直在做这件事情，Atlas也一直在同步合作、跟进磁盘的调度能力。
图25 后续工作
今天的分享就到这里，谢谢大家。
分享嘉宾：吕冬冬 云知声 超声平台架构师
编辑整理：曾新宇 对外经贸大学
出品平台：DataFunTalk
01/分享嘉宾
吕冬冬｜云知声 超算平台架构师
负责大规模分布式机器学习平台架构设计与功能演进，负责深度学习算法应用优化与 AI 模型加速。研究领域包括大规模集群调度、高性能计算、分布式文件存储、分布式缓存等。云原生开源社区爱好者。
02/报名看直播 免费领PPT
03/关于我们
DataFun：专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100+线下和100+线上沙龙、论坛及峰会，已邀请超过2000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章700+，百万+阅读，14万+精准粉丝。
| 留言与评论（共有 0 条评论） “” |
