大模型之GLaM详解：1.2 万亿参数，为什么每个 Token 只需动用 8% 模型

写在前面【从零走向AGI】旨在深入了解通用人工智能AGI的发展路径从最基础的概念起逐步构建完整的知识体系。项目地址https://github.com/AI-mzq/From-Zero-to-AGI.git魔方AI空间猫先生从零走向AGI面试面经AIGC算法岗/开发岗面试面经交流社群涵盖AI Agent、AIGC图像创作、AI视频、LLM大模型、AI多模态、数字人、传统深度学习、具身智能等AIGC面试干货资源欢迎大家加入https://t.zsxq.com/YtJ09GLaM1.2 万亿参数为什么每个 Token 只需动用 8% 模型大模型并不一定要让所有参数同时工作。Google 的 GLaM 把“模型总容量”和“每个 Token 的实际计算量”拆开它在 2021 年用稀疏 MoE 做到 1.2 万亿参数却让单个 Token 只激活约 966 亿参数。这是后来大规模 MoE 路线真正站稳脚跟的一个关键节点。论文标题GLaM: Efficient Scaling of Language Models with Mixture-of-Experts版本 / 会议arXiv v22022-08ICML 2022作者 / 机构Nan Du 等Google论文地址arXiv PDF01 先抓住问题参数变大不该等于每步都更贵稠密模型的规则很直接参数越多每生成一个 Token 就要穿过越大的网络。它的好处是实现与并行相对规整代价则是训练和推理的计算量随容量一起上涨。GLaM 问的是另一件事能否把大量“知识容量”放进模型里但每个 Token 只调用其中一小部分答案是 Mixture-of-ExpertsMoE保留共享的 Transformer 骨架把部分前馈网络换成一组专家网络再由路由器按 Token 选择专家。MoE 的核心不是“参数更多”而是让不同 Token 在相近的计算预算下拥有通往更多参数的条件路径。02 GLaM 的做法隔层放 MoETop-2 路由GLaM 是 decoder-only 语言模型。它没有把每一层都替换成专家层而是在每隔一层把原本的 FFN 换成 MoE 层一个 MoE 层内有 64 个独立 FFN 专家。对来到这里的每个 Token门控网络给所有专家打分选出得分最高的两个并将两者输出加权合并。图 1Token 不会广播给所有专家GLaM 为每个 Token 从 64 个专家中选择 Top-2。这使总参数容量可以膨胀而每次前向的专家计算仍保持稀疏。图片来自论文 HTML 版CC BY 4.0。可以把一次 MoE 前向理解成三步Token 表示进入 gate得到 64 个专家的概率gate 仅保留 Top-2 专家将 Token 分发过去计算按门控权重合并两份专家输出回到 Transformer 主干。这并不等于每个专家都学成固定的“语法专家”或“代码专家”。论文真正保证的是动态、按 Token 的条件计算专家的可解释分工通常只是训练后可能出现的结果不能把它当成架构承诺。规模总参数每 Token 激活参数路由配置GLaM 64B/64E1.2T96.6B约 8%64 专家、Top-2GPT-3对照175B175B稠密计算GLaM 还使用每层相对位置偏置与 GEGLU并采用二维切分来放置超大权重。前者是架构细节后者则提醒我们MoE 的论文贡献不只是“加一个 router”还包括让专家并行和模型并行能一起运行。03 结果看什么同一任务面上计算账能否更好看论文将最大 GLaM 与 GPT-3 在 29 项公开 NLP 任务上比较其中包含 21 项理解任务和 8 项生成任务。报告的平均分数为zero-shot 62.7 对 56.9one-shot 65.5 对 61.6few-shot 68.1 对 65.2。更有代表性的不是单个分数而是这组对照发生在不同计算账本上GLaM 报告每 Token 推理为 180 GFLOPsGPT-3 为 350 GFLOPs训练能耗分别为 456 MWh 与 1287 MWh。也就是说在论文所用的模型、数据和系统设置下GLaM 用约一半推理 FLOPs、约三分之一训练能耗取得了更高的平均 few-shot 表现。这些数字是与 GPT-3 的论文内对照不是今天任意 MoE 服务的通用成本承诺。实际延迟还会被跨设备通信、batch 大小、专家负载是否均衡所左右。04 另一条主线数据质量没有被规模取代GLaM 的训练语料为 1.6 万亿 Token。作者没有只按“量”堆网页而是用由 Wikipedia、书籍和部分高质量站点构成的参考集合训练文本质量分类器再按分数进行采样最终混入网页、对话、论坛、书籍、新闻等来源。论文的消融结论很朴素即使模型很大更多低质量数据也不能简单替代更干净的数据。MoE 解决的是“如何更经济地扩容量”不是数据筛选、污染检查和评测设计的替代品。05 GLaM 留下的难题恰好也是今天 MoE 工程的难题稀疏计算节省了算术量但没有免费午餐。Token 分发到不同设备上的专家会带来 all-to-all 通信如果 gate 长期偏向少数专家就会出现负载不均、容量溢出或训练不稳定。小 batch、低并发、跨机带宽不足时“FLOPs 更少”也未必自动变成“端到端更快”。因此读 GLaM 最有用的方式不是记住 1.2T 这个数字而是建立一个成本观总参数、激活参数、通信量、专家容量和服务 batch 是五个不同的量。后续 Switch、GShard、DeepSeekMoE 与在线推理系统基本都在继续处理这几笔账。06 最后怎么看GLaM 证明了 decoder-only 语言模型可以把稀疏 MoE 带入大规模 in-context learning模型容量不再必须绑定到每 Token 的全部计算。但它也把问题从“怎样堆参数”推进到“怎样路由、放置与服务专家”。这正是理解今天 MoE 大模型时最该先抓住的坐标系。参考资料Du et al.,GLaM: Efficient Scaling of Language Models with Mixture-of-Experts, ICML 2022论文 HTML 版。推荐阅读► 技术资讯 魔方 AI 新视界► 项目应用开源视界► 技术专栏 多模态大模型最新技术解读专栏 | AI 视频最新技术解读专栏 | 大模型基础入门系列专栏 | 视频内容理解技术专栏 | 从零走向 AGI 系列