Scheduling

workload白天和晚上不一样，不同的日子也不一样（例如双十一） 因为没有办法对workload估计得很准，云系统用户总是申请比所需要的多的资源，这些“slack”是一种浪费 Autopilot目标：减少slack的同时最小化OOM Autopilot操作：调整并行任务数，调整单个任务的资源使用量 scaling分为水平scaling和垂直scaling，水平scaling是调整并行任务数，垂直scaling是调整单个任务的资源使用量，这篇文章主要讨论内存的垂直scaling Preprocessing: 每秒记录一个usage数据点； CPU per-task histogram: 一个向量，每个分量表示在这个time window内每个usage buckets的usage数据点数量； memory per-task histogram: peak memory usage in a time window； per-job histogram: sum over per-task histogram； Moving window recommenders 希望需求上升时能很快上升，需求下降时能慢慢下降 提出了三种滑动窗口的方法，都比较保守，而且会在推荐值的基础上加一点余量 大概的思想是，不只根据数量去做平均，还要根据load的大小 (magnitude) 去做平均 max适合OOM最敏感的任务，Spj适合比较敏感的任务，Savg适合不敏感的任务 Recommenders based on machine learning 构造了一个损失函数包括过去采样的overrun，underrun，以及switching cost。 同时存在多个arg min的模型，它们的超参不一样，用的时候选择损失函数最小的。 这些模型是离线+A/B test调出来的，没有给具体方法，只有loss function。 horizontal 指定一个目标平均util，通过伸缩replica来维持这个值。 策略 实验结果是滑动窗口在减少OOM上更好，ML方法在减少slack上更好。 后面主要是讨论用户体验。 有一篇值得follow的工作：Hydra: a federated resource manager for data-center scale analytics，是微软的资源管理系统，在这篇论文之前。

分布式机器学习的梯度同步的通讯调度，先做前向传播的参数考虑先同步。 一个有限制的preemption。 用Bayesian Optimization去搜超参。

不同的DL训练任务在不同的阶段对资源的利用不一样，如果可以让多个DL训练任务交错地安排可以增加并行度和资源利用率 交错和流水线不一样，流水线是任务内的不同阶段重叠，比如网络IO同步和GPU计算前向后向传播之间的流水线，会受数据依赖的限制，交错是不同的任务之间在不同阶段利用不同的资源 交错的困难是任务之间不一定是对齐的，不一定达到理想加速比，而且怎么选择哪些任务在一组里交错以最小化JCT也是一个复杂的问题，还有就是多机多卡的任务不同的worker要和其他任务一起交错，同时又要和其他worker同步，就会有同步开销 两种资源，两个任务的interleave一般图最大权匹配——Blossom algorithm O(|V|^3)的时间复杂度 k种资源，k个任务：maximum weighted 𝑘-uniform hypergraph matching 多GPU的训练任务交错，一个group的任务间的交错和任务内的worker同步会相互影响，发生蝴蝶效应导致全体变慢，这篇文章的做法是使用相同GPU数量的任务之间才能交错 每个interval六分钟，将暂停所有任务重新组队