jasperzhong
commented
3 years ago fb的工作. 对于大规模分布式训练，出现机器故障是很常见的事情. 当今处理fault的方法是通过checkpoint，然后整个系统重新从上一个checkpoint地方启动. fb发现这种方法实际上overhead很大. 他们提出了partial recovery, 即只有failure node重新load上一个checkpoint（已经stale了）来降低overhead. 最后只损失一点点精度.
Use case
他们场景放在了推荐系统训练集群. 推荐系统模型一般分为两部分: 1) Embedding layer 2) MLP. Embedding layer一般非常非常非常大（几百GB到上TB），因为用户的数量是billions级别的，需要做模型并行. 因为embedding其实就是一个lookup table. 所以可以用parameter server进行存储，参数是in-memory的，数据结构是哈希表，并且做shard. 而MLP是计算密集型的，需要GPU机器，而且需要做数据并行. 如下图所示.
Motivation
takeaway
- 他们内部集群的平均故障时间(MTBF)在14h - 30h之间.
- checkpoint相关的overhead占到了总overhead 12%左右. 对于最严重的5%训练任务，其training job slowdown达到了43%.
- 在为期30天的时间内，分析了17000个训练任务，发现有1156 machine-year由于failure handling被浪费了
这些数据足以说明对于full-recovery + checkpoint对于处理故障是多么inefficiency.
failure
出现故障的原因一般有几个因素: 1) hardware failures. 2) system failures (比如OOM). 3) user errors (bug in the code). 4) maintenance failures (kernel update). 尽管单个节点出现failure概率很小，上千个节点几乎是必然会出现failure. #43 这篇对于DL集群的failure有很详细的介绍.
他们分析了2w条数据披露了不少有参考意义的数据:
他们观察到failure是服从gamma分布的. 这是自然的. gamma分布的数学意义，就是等待n个事情都发生所需要的时间. 而且随着机器数量增加，曲线变得更陡峭，说明发生故障的概率更大. 右图进一步说明，故障时间是比较均匀的. 开始阶段有大量error，可能是因为用户代码错误(比如路径找不到，缺少某个python包，某个lib等等)
checkpoint overhead
checkpoint的overhead来自于 1) checkpoint save overhead. 2) checkpoint load overhead. 3) lost computation. 4) rescheduling overhead. 这是集群要寻找新的available nodes所需要的时间. 所以总的时间为:
由此可以得到最优checkpoint interval.
他们分析了17000个训练时间超过10h的任务，做了个breakdown，如下图
可以看到overhead的主要原因还不一样. 对于failure比较少的场景，开销主要是saving checkpoint，8.8% for p75. 而对于faliure比较多的场景，开销主要是lost time和rescheduling.
partial recovery
144 提出了partial recovery. 只有failed node去load checkpoint. 这样其实只减少了上述开销中的3) lost computation. 其他还是保持不变. 但带来的代价是，使用stale的参数进行训练. #144 提议延长训练时间来弥补. 但实际上，延长训练时间也无法弥补. 如下图
https://proceedings.mlsys.org/paper/2021/file/b73ce398c39f506af761d2277d853a92-Paper.pdf
终于看到一篇不是讲byzantine failure的了...