MoE：LLM终身学习的可能性

本文分享自华为云社区《DTSE Tech Talk | 第47期：MoE：LLM终身学习的可能性》，作者：华为云社区精选。

在DTSE Tech Talk的第47期直播《MoE：LLM终身学习的可能性》中，昇思MindSpore技术专家吕老师与各位开发者分享有关于LLM lifelong learning的概念，帮助大家了解持续学习的特性与理论知识，同时也详细介绍了MoE的发展史，让我们更为直观的去理解其中技术要点。

Continual lifelong learning（终身学习）

终身学习系统被定义为一种能够从连续的信息中学习的自适应算法，随着时间的推移，这些信息逐步可用，并且所要学习的任务数量（例如，分类任务中的成员类）不是预先定义的。关键的是，新信息的容纳应该在没有灾难性遗忘或干扰的情况下发生。

持续学习的目标与特性

持续学习的目标是在模型持续输入学习新数据的同时避免旧知识的遗忘，以下是其性质与定义。

参考文献：Continual Lifelong Learning in Natural Language Processing: A Survey-2020年发表

性质	定义
知识记忆（knowledge retention）	模型不易产生遗忘灾难
前向迁移（forward transfer）	利用旧知识学习新任务
后向迁移（backward transfer）	新任务学习后提升旧任务
在线学习（online learning）	连续数据流学习
无任务边界（no task boudaries	不需要明确的任务或数据定义
固定模型容量（fixed model capacity）	模型大小不随任务和数据变化

LLM的性质：

参考文献：A Survey-2020年发表

性质		说明
知识记忆（knowledge retention）	√	LLM预训练后，具备世界知识，小规模finetune不易对LLM造成遗忘灾难。但大规模数据续训会造成。
前向迁移（forward transfer）	√	基于世界知识的Zero shot、few shot、finetune。
后向迁移(backward transfer)	-	Finetune后会可能会造成部分任务的性能下降。二次finetune会损失首次finetune性能。
在线学习(online learning)	×	离线预训练、微调。
无任务边界(No task boudaries)	√	Unsupervised预训练、微调，不区分任务。
固定模型容量(Fixed model capacity)	√	LLM预训练后大小不变。

以上可以看出LLM实际上已经满足了大部分持续学习的性质，百亿千亿级别的大模型经过充足的预训练后，具备大量世界知识以及涌现能力，基于此进行终身学习成为可能。

常见的LLM终身学习方法有Rehearsal（排练）, Regularization（正则）, Architectural（结构改造）等方式在LLM的参数量和训练模式下其实都不太适用。而LLM本身为了增大参数量和减少推理成本的混合专家方法(Mixture of Experts, MoE) 似乎成了LLM终身学习的新途径。

MoE的简介

MoE即混合专家模型，英文叫Mixture of Experts, 发展至今已有30多年历史。MoE是一种模型设计策略，它通过将多个模型直接结合在一起，以获得更好的预测性能。在大模型中，MoE方案可以有效的提高模型的容量和效率。

一般来说，大模型的MoE有一个门控机制和一套门控输出机制来合并和平衡专家的选择，用于决定每个专家对最终预测的；有一套专家模型选择机制，会根据门控机制的输出选择一部分专家模型进行预测。这样可以较少计算量，并使模型能够针对不同的输入选择最合适的专家模型。

MoE示意图

图中多个Export Network用于学习不同数据，一个Gating Network用于分配每个个Expert的输出权重。对于一个输入样本c，第i个expert的输出为，Ground truth是

则损失函数为：

将提前，使得每个专家模型单独计算损失函数，鼓励不同专家模型的竞争，使得每个数据样尽可能被一个专家处理。专家模型的竞争、合作，以及Gating Network的分发方式，也成为了MoE演进过程中不断更迭出新的方向。2017年MoE已初见成型。

Sparse MoE

Google Brain的Shazeer,Noam,等人提出使用稀疏的MoE结构来将模型容量做大的方法，即：训练时使用海量的专家模型，推理时激活少数专家模型。

Sparse MoE示例图

如上图所示，模型共有n个Expert，Gating Network选择少数Expert进行计算。此外，在训练过程中前期编号的expert会更容易被gating network选择，导致只有少数几个expert有用，这被称为Expert Balancing问题。这时的Sparse MoE目标方向是将模型做大，以及经济高效地进行训练推理。同年，能够并行训练的Transformer的出现将所有人的目光都汇聚了过去。

Transformer MoE

当模型参数量到了千亿这个级别以后，再想向上扩展变得愈发困难，经济实用的MoE又被重启。还是Google，提出了GShard[4]，首个将MoE思想拓展到Transformer的工作，而后Siwtch Transformer[5]、GLaM[6]等工作持续改进着Transformer MoE的结构，也将LLM的参数量从千亿推向了万亿级别。

Gshard:首个MoE+Transformer模型

Gshard的论文最早于2020.6.30发表（Gshard Scaling Giant Models with Conditional），Transformer的encoder和decoder中，每隔一个（every other）FFN层，替换成position-wise MoE层。

Switch Transformer号称拥有万亿级别的Transformer类模型

2021年1月，Google大脑团队发布文章“Switch Transformer：scaling to trillion parameter models with simple and efficient sparsity”，其简化了MoE的routing算法，并且gating network 每次只 route 到 1 个 expert。

GlaM：降本增效，精度更为精确

同年，Google的GlaM模型表明，Transformer和MoE风格的层可以组合在一起生成一个模型，在29个基准测试中平均超过GPT-3模型的精度，而使用3倍少的能耗进行训练和2倍少的计算进行推理。

PanGu-Sigma

Pangu-sigma[8]是今年3月华为诺亚方舟实验室基于Pangu-alpha模型进行MoE扩充实现的Lifelong-MoE模型。其提出了随机路由专家（RRE）方法，使得Gating Network也可以随着Expert进行裁剪。下图是PanGu-Sigma的示意图：

这里着重讲一下RRE的设计。前面提到既然可学习的Gating Network很难裁剪，那么可以简单粗暴地使用手动Gating地方式。RRE就是这样地思路，只是为了缓解过于粗暴的领域区分（持续学习的性质之一就是无任务边界，手动Gating一定程度上违背了这一点），RRE做了双层的设计：

第一层，根据任务分配给不同的专家组（多个expert构成一个专家组，供一个task/domain使用）。
第二层，使用组内随机Gating，让专家组的expert可以负载均衡。

这样带来的好处是显而易见的，只要对专家组进行裁切，可以完全剥离出某个领域的子模型进行推理部署，同时也可以不断地更新迭代新的专家组，实现Lifelong-learning。下图是预训练好的MoE模型进行子模型抽取的示意图。

以上两个工作，是Lifelong-MoE的两个典型工作，也分别延续了两家公司LLM的能力。但值得额外一提的是，MoE LLM实际上从训练起点分为了两派，分别是from scratch和from pretrained，而GPT4据称是from scratch的8个Expert集合，某种意义上可能更像是回到了ensemble阶段，更多是为了业务效果而非LLM的持续演进。

MoE存在问题

Lifelong-MoE看起来很好用，但是万事皆无完美，但MoE方法本身还是有一些问题，下面进行简单的介绍，也算是后续演进方向的探讨。

MoE结构复杂度

Transformer的MoE会对FFN层进行MoE扩展，但是Transformer结构本身还有Multihead Attention结构，这使得MoE扩展会变成Transformer结构的侵入式改造，而不管是训练前并行化的侵入式改造，还是训练完成后进行子模型的抽取，都会因为复杂的结构而需要投入大量人力。

Expert balancing

总会有一部分任务或领域占据所有数据的大部分，也一定会有长尾数据，使用等参数量、随机Gating的方式进行强制的均衡分配，实际上也是在伤害模型对现实世界的拟合。神经网络特点决定的嬴者通吃。Gating Network可学习会很自然的朝着几个拟合较好的Expert进行数据分配，这一点仍需要大量的尝试和研究，也许可以缓解，也许可以解决。

分布式通信问题

当下的LLM预训练必然是要使用分布式并行切分的，而MoE结构和普通的Dense模型的差异在于，其需要额外的AllToAll通信，来实现数据的路由(Gating)和结果的回收。而AllToAll通信会跨Node（服务器）、跨pod（路由），进而造成大量的通信阻塞问题。

点击关注，第一时间了解华为云新鲜技术~