• NSDI 22

• 生产集群ML负载、系统与调度分析、阿里PAI

引入

• 背景

  • ML性能卓越，为加速大规模ML负载处理，大规模GPU集群数据中心建立

• 贡献

  • 分享PAI异构GPU生产集群工作负载分析，包含各种类型、各种配置的ML训练与推理任务

• 问题

  • 先前工作集群同构且模型种类少，异构集群挑战更多

• 挑战

  • 碎片化使用导致GPU利用率低

    • GPU粒度的分配利用率极低

    • 使用分时共享GPU，打包大量低GPU需求任务到少量机器上，干扰少

  • 短任务长排队时间

    • 短任务易受队头阻塞影响，9%等待超50%完成时间（排队+执行）

    • 预测耗时进行SJF，但生产集群上难实现，需要用户修改代码或使用修改的DL框架

    • 65%任务重复5次以上，可通过特征工程预测耗时

  • 高GPU需求任务难以调度

    • 独占型多卡任务依赖NVLink等硬件加速，通过预留-填充方式可降低排队时间

  • 负载不均衡

    • 低端机器CPU GPU>70%，高端机器CPU 35% GPU 50%

    • 8卡节点每卡CPU需求超配置（12）一倍，2卡节点每卡CPU需求为配置（32/48）50%

  • CPU瓶颈

    • 数据处理需要CPU，形成性能瓶颈

    • CPU利用率高的机器任务易降速，即使任务以GPU计算为主

• 目的

  • 分享集群运行观察，探讨优化方法

背景

略

负载特征

Trace信息

• 主流框架大部分多GPU的训练、推理

• job-task-instance级的到达时间、完成时间、资源需求、GPUCPU使用率、GPU显存、内存；部分负载类型；集群日志

• j-t-i，例如分布式训练job，PS task有多个instance，worker task有多个instance，同个task的instances使用组调度

• 高倾斜的实例分布，5%用户提交了77%任务

• 组调度任务实际占GPU总需求79%，20%组调度task需要超100GPU

• GPU局部性需求，分布式任务可使用NVLink加速10倍

• GPU共享，多实例根据用户设置的GPU占用比分时复用GPU

• GPU多类型可选，仅6%任务指定GPU

时间模式

每日job提交与资源请求

• 工作日提交量略高于周末，日间午夜均出现高峰，午夜任务实例数少算力需求低

实例运行时间范围大

• 中位数23min，P90 4.5h

排队时间不均匀

• 短任务排队时间占比长于长任务排队时间占比

• 共享GPU的实例被快速调度，P90 500s，独占一/多块GPU P90 1150s/8286s

• 请求高端GPU比低端GPU排队时间长很多

空间模式

资源请求重尾分布

• 20%请求大量资源，80%请求少量资源

• P95 12vCPU（6CPU）、1GPU、59Gmem，超过中位数两倍

GPU利用率低，CPU利用率高

• 用户倾向于申请远超实际的资源

• GPU低利用率源于CPU等资源竞争，数据处理等任务不使用GPU但占用CPU，19%实例超额使用CPU，3%超额使用GPU

GPU机器利用率

计算资源利用率

• 相比于内存和显存，GPU和CPU利用率更高（P90利用率）

  • 2卡节点，CPU利用率比8卡节点下降（因为CPU-GPU比提高）

  • 2卡节点和8卡节点内存与显存利用率均低于60

• GPU利用率比其他资源更加波动

  • P90 从40%到100%都有，与P50的差值也大于其他资源

  • 波动源于ML负载突发的GPU使用模式，也和调度策略优先装箱的设计有关

网络与I/O低利用率

• 分布式ML中，各类型GPU网络输入速率仅为带宽54%、48%、34%

• CPU在I/O等待比在用户态和内核态低三个数量级，CPU忙于处理数据

优化集群管理

目标

• 提高GPU机器的利用率

• 完成更多任务

GPU共享

• 独占方案强性能隔离，但是GPU利用率很低，因为大部分任务资源需求小

• PAI支持时空复用GPU

  • 实例可以请求并获得一部分的GPU显存，需要时也可获占用未分配的显存

  • 计算单元（SM）由共置的实例动态共享，不能预先分配

• 优势

  • 减少资源提供量，节约50%的GPU

• 竞争问题

  • 由于论文场景中实际极高使用率的GPU数少，并且运行多个实例的GPU数更少，并未发生严重的竞争

预估周期性任务的时长

• PAI的调度器为容器设计，任务语义不可感知，现有方法需要获得迭代次数等，需要框架支持

• 大多数任务有周期性

  • 实例运行时间可通过历史记录准确预测，但周期性无法通过ID等直接识别

  • 可通过识别作业元信息识别任务的周期性，65%的任务重复至少5次

  • 批量推理任务，收集多个请求数据后一次性推理出结果，可由用户设置任务启动间隔，平均实例运行时间稳定

• 周期性任务实例运行时间预估

  • 通过用户名、资源请求、群组标签构建树回归模型

  • 数据使用至少重复5次的任务，78%的实例预测误差低于25%，此精度足以进行高质量调度决策

• 调度收益

  • 模拟结果显示预估+SJF比FIFO减少63%-77%avgJCT，引入越多特征训练预测器，调度效果越好

调度挑战

高-GPU任务案例研究

• 少量任务高算力需求

NLP等先进语言模型

• 73%必须使用16G或以上显存GPU，40%实例请求至少一块GPU，实际消耗算力超0.4GPUs

大规模输出的图像分类

• 一些分布式训练任务需要配备NVLink等的GPU

  • 一些商品图像分类任务需要输出10万种类别，使用超大全连接层导致交换梯度更新时的通信成为瓶颈

  • 此类任务需要使用一组本地GPU保证高通信带宽

低-GPU任务案例研究

• 任务主体，CPU数据处理大量耗时

点击率预测模型训练和推理

• 占总任务6.7%，25%训练，75%推理，推理比训练CPU利用率高，所有任务75%使用少于0.1GPUs

• 主流模型推理时，80%时间花在CPU上，I/O和GPU各占10%

• 高CPU占用导致同一机器上的任务（容器运行），由于CPU缓存、功耗、内存带宽等共享资源的竞争，训练速度最多下降28%

GNN训练

• 占2%，CPU利用率高于GPU，因为图特征需要shiyongCPU进行边遍历、邻居采样等预处理得到

强化学习训练

• 普遍需要在CPU上并行模拟交互生成一批数据，再使用GPU进行训练

• 需要大量实例运行模拟，72%超过10组实例，大量时间用于CPU和网络传输，最多使用0.05GPUs

调度策略

• 高GPU需求任务对调度更加敏感，并且通常是重要商用应用，优先级更高

预留与打包

• 预留高性能GPU给高需求任务，将低需求任务打包到中低算力GPU机器上

• 使用性能模型预测任务计算效率，特征包括并行度、模型类型、嵌入向量维度、同类历史数据等（无感知任务？）

• 对每项任务生成多个有序方案和超时时间，超时时尝试下一方案

• 高GPU需求任务优先分配高端GPU，其余任务相反

负载均衡

• 由于共置任务的CPU等资源竞争问题，调度器优先将实例分配至资源利用率低的同规格机器上

性能验证

• 在模拟器上对比纯负载均衡和纯预留打包策略

• 预留打包大幅降低尾排队时间，使任务平均排队安驰降低45%；使请求V100的任务平均排队延迟降低68%

开放挑战

机器配置和实例请求不匹配

• 请求的vCPU-GPU比与机器实际配置不匹配，8GPU节点请求高一倍，2GPU节点请求低一半

• 2GPU机器CPU利用率比8GPU机器的低，但所有机器总体上vCPU-GPU比相近，因此优化调度策略可以解决不匹配问题

低端GPU机器过度拥挤

• 77%CPU和74%GPU被请求，但CPU实际利用率明显高于GPU

• 源于调度策略将低GPU需求任务分配至低端GPU机器

高端GPU机器负载不均

• 高端GPU机器总在预留资源，导致低利用率

• 负载不均，表明负载均衡策略有待优化

CPU成为瓶颈

• 将周期性任务实例按周期内运行时间分为加速-一般-延迟三组，延迟任务机器的CPU利用率明显高于另外两组，但GPU利用率无相关性

• CPU利用率越高，出现延迟实例的概率越高

• 调度策略不仅需要考虑GPU，还需考虑CPU、内存、I/O、网络等资源

讨论

支持弹性训练

• 相比组调度更能适应集群负载变化，但可能导致非确定的模型准确率

机器与资源解耦

• 为解决不匹配问题，将机器分解为分布式的硬件组，但会带来显著通信开销

• 从框架层次解耦数据预处理和GPU训练，但需要用户修改代码

相关工作

GPU共享

• 硬件层

  • MIG，只支持新型计算卡且不能任意分割

• 软件层

  • CUDA劫持，属于时分复用但上下文切换开销显著且缺乏性能隔离

  • MPS，无法隔离进程错误

• 框架层

  • 修改TensorFlow或Pytorch代码实现细粒度共享和显存管理，但需要用户适配

略