【云原生AI(1)，大厂高级测试面试题

大规模深度学习模型训练挑战

​

随着深度学习在微博业务场景中的广泛使用，微博深度学习平台扮演了非常核心的角色。该平台采用了存储与计算分离的架构，使得计算资源得以与存储资源解耦，从而实现了灵活的资源配比以及便捷的存储扩展，并且降低了存储成本。

然而，这种架构也带来了一些挑战，其中比较关键的问题体现在数据访问性能和稳定性方面：

​

计算存储分离架构导致数据访问高延时，导致训练慢：业务团队使用的深度学习任务（图像或语音模型）会访问海量小文件。实验表明，HDFS 读取海量小文件场景与本地读取对比性能相差近十倍甚至百倍。

Kubernetes 调度器数据缓存无感知，同一数据源多次运行访问依旧慢：相同模型、不同超参的；微调模型、相同输入的；AutoML 等深度学习任务运行会不断重复访问同一数据，产生可以复用的数据缓存。但是由于原生的 Kubernetes 调度器无法感知缓存，导致应用调度的结果不佳，缓存无法重用，性能得不到提升。

多数深度学习框架并不支持 HDFS 接口，导致开发难：比如 PyTorch，MxNet 等框架只支持 POSIX 协议接口，HDFS 接口需要额外的对接开发。因此需要同时支持模型开发阶段的 POSIX 接口以及模型训练阶段的 HDFS 接口，引入模型代码适配不同存储的复杂性。

HDFS 成为数据并发访问的瓶颈点，稳定性挑战大：微博机器学习平台上百台 GPU 机器同时训练都会并发访问 HDFS 集群，同时深度学习训练的 IO 压力比较大，HDFS 服务成为了性能单点，这对 HDFS 的性能和稳定性提出了巨大的挑战。一旦某个任务拖慢了 HDFS 系统，其他的训练任务也会受到影响。而且，一旦 HDFS 无法工作，整个训练集群也会受到影响。

通过对微博深度学习平台的监控分析，我们发现：一方面由于 IO 性能问题导致 GPU 等昂贵计算资源不能被充分利用；另一方面，我们也发现集群中的内存和本地硬盘的水位很低，余量较多并且稳定，这是由于多数的深度学习任务并不使用本地磁盘，同时内存使用率也不高。因此我们考虑如果能够充分利用集群自身的内存和磁盘资源加速数据访问会是一种更好的方案。

Fluid + JindoRu