Towards MoE Deployment:Mitigating Inefficiencies in Mixture-of-Expert (MoE) Inference
# 问题
- 从理论上讲,MoETransformer 与基线密集模型相比执行的 FLOP 次数相似,但实际上它们的速度要慢得多。一个原因是需要AlltoAll通信,但不仅仅这一个原因。
- 存储专家内存消耗过大。
- 静态门控的低效率。每个专家接受的token数量是一样的,如果多了就会被丢弃,如果少了就会用0填充。
# 分析
- 专家具有稀疏性,有的专家根本就没有激活过几次,但也要放在内存。
- 通过机器翻译任务,发现专家稀疏性具有很强的时间局部性。也就是说,在一个时间段内,很多专家连续处于激活状态。
# 改进
动态门控优化。
为了解决所有的专家都必须接受相同数量的token,造成多了的丢弃少了的补0,首先把token按照分给专家的顺序排序,分给第一个专家的全部放在开头,然后是放在第二个专家的token,依次类推,然后再给专家一个size表,从而实现动态获取token。
效果:LM任务中内存占用减少79.6%,MT任务中减少44.2%。并且LM任务中静态门控batch_size最大为8,动态门控为64。MT任务中静态2,动态96。
专家缓冲
把活跃的专家放到GPU中,如果GPU中的专家已经满,则使用FIFO算法把已经很长时间不活跃的专家放到CPU上。
负载均衡
token分布高度不平衡,根据历史数据中的平均工作负载对专家进行排序,负载越小的专家分给越少的GPU资源。
效果:在LM任务中表现好,在MT任务中解码器效果差。
编辑 (opens new window)
上次更新: 2024/11/17, 13:04:13
- 02
- containerd高版本换源,containerd换源无效问题11-07
- 03
- apt-get使用代理11-05