AI 基础
什么是混合专家模型？稀疏 AI 详解
将 Unite.AI 添加到您在 Google 上的首选来源
混合专家（MoE）模型包含多个带参数的专家网络以及一个路由器，后者为每个输入或 token 选择一小部分专家。由于仅执行被选中的专家，模型能够在不在每次前向传播中激活所有参数的情况下提升总体参数容量。
稀疏激活并不意味着计算或内存免费。MoE 系统必须存储并移动大量参数、在专家之间平衡 token、协调设备，并防止路由不稳定。总参数量与活跃参数量代表了不同的成本。
要点概览
- 路由器计算专家得分并将 token 分配给前 k 名专家。
- 容量限制和负载均衡目标防止少数专家接收所有 token。
- 稀疏计算可以提升每次操作的容量，但会增加通信和内存的复杂度。
- 需综合评估质量、活跃计算、延迟、内存、路由行为以及服务拓扑。
路由器与专家层
在 Transformer MoE 模型中，选定的前馈层通常会被专家前馈网络取代。路由器为每个 token 打分并将其发送至一个或多个专家；这些专家的输出经过加权后返回主残差流。
注意力仍可能保持密集。因此，周围的 transformer 使用了共享计算与条件专家计算的混合方式。
容量与负载均衡
每个专家在一个批次中能够处理的 token 数量是有限的。如果过多 token 选择同一专家，一些实现会丢弃或重新路由溢出部分。辅助损失鼓励使用的均衡，而路由噪声可以在训练期间提升探索性。
流量均等并不等同于有意义的专精。可以按领域、位置和任务检查专家的使用情况，但应避免在缺乏因果证据的情况下为其分配可读的角色标签。
为何服务部署困难
尽管只有一小部分专家是活跃的，但所有专家的权重可能需要分布在加速器内存中。专家并行会在设备之间传输 token，使得网络带宽和全互联通信变得至关重要。小批量可能导致专家利用率不足。
量化、缓存、批处理以及拓扑感知路由可以提供帮助。比较 MoE 与密集模型时，应在相同的输出质量、上下文、硬件和服务水平目标下进行，而不仅仅看活跃 FLOPs。
MoE 的含义与局限
MoE 提供条件计算和容量，但并不保证事实性、模块化推理、可解释性或一组独立的代理。专家网络是联合学习的，可能共享模糊的特征。
MoE 可补充 generative-AI 的后训练和压缩。在部署后需监控路由漂移、尾部延迟、专家失效、内存以及领域质量。
路由、专家容量与稀疏计算
混合专家层包含多个专家网络和一个路由器，后者将每个 token 分配给少数专家，通常是排名前一至两名的专家。模型可以拥有大量参数，却仅在每个 token 上激活其中的一小部分。稀疏激活相较于参数总量相似的密集模型可降低计算量，但并不一定比所有更小的模型都更省算。
路由器生成专家得分，依据选择规则分配 token 表示。每个专家的容量是有限的。如果过多 token 选择同一专家，系统必须丢弃、重新路由或填充 token。容量因子、辅助平衡损失、路由噪声以及专家并行在质量、利用率和通信之间进行权衡。
专家并不一定能清晰对应人类概念或领域。专精是通过优化产生的，可能呈分布式、不稳定或依赖 token。可解释性主张应检查跨层和跨上下文的路由行为，并使用干预手段，而非仅依据少数高分 token 推断的标签。
分布式 MoE 模型的训练与服务
训练结合了数据并行、张量并行、流水线并行和专家并行。Token 常常需要在加速器之间传递以到达选定的专家，因此全互联通信可能抵消算术上的节省。模型放置、批次构成、网络带宽、token 打包以及通信与计算的重叠是系统设计的关键选择。
负载不均会导致专家闲置或设备过载。辅助目标鼓励路由均衡，但可能干扰主要学习目标；新方法可能会调整偏置或路由动态。应监控每个专家的 token 数量、丢弃的 token、熵、梯度以及设备时间，而不是仅依赖整体损失。
服务部署困难在于即使每个 token 只使用少数专家，所有专家权重仍可能需要保持可用。内存容量、互连、批处理、缓存行为以及路由变动都会影响延迟。量化和专家卸载在某些场景下有帮助，但可能增加数据传输。应对具体模型和硬件拓扑进行基准测试。
质量、评估与部署权衡
在质量、训练计算、推理计算、内存、延迟和成本相匹配的前提下，将 MoE 模型与密集基线进行评估。仅比较参数数量会产生误导。应测试长上下文、不同语言、领域、稀有 token 以及对抗性提示，因为路由行为可能随分布变化而导致能力不均。
路由会带来额外的失效模式: 专家崩溃、专精不稳定、token 丢弃、相关性故障以及对批次构成的敏感性。确定性评估应控制运行时和路由设置。运营监控应包括专家利用率和通信健康，以免将系统问题误认为模型的普通波动。
当总容量的扩展至关重要且基础设施能够支持稀疏分布式执行时，MoE 具有吸引力。对于小批量、边缘设备或受限互连，密集模型可能更简洁、更快速。该架构是一种系统权衡，而非密集 Transformer 的通用替代方案。
案例演示：评估 MoE 语言模型
一个研究团队使用匹配的训练 token 以及多种资源视角: 每 token 的活跃参数、总参数、加速器内存、网络流量、训练时间、推理吞吐量和延迟，对 MoE Transformer 与密集基线进行比较。团队记录了路由概率、每专家的 token 数、溢出、丢弃的 token 以及按层、语言和领域划分的辅助损失。如果通信开销或利用率不足导致总体成本上升，仅凭算术计数降低并不被视为效率提升。
质量评估涵盖知识、推理、长上下文、稀有领域、多语言任务、安全性和校准。团队通过扰动批次构成和提示分布，观察路由和输出是否出现意外变化。因果专家消融测试专精主张，而专家失效和网络退化则揭示其韧性。结果在相同的服务水平目标下进行比较，因为仅在大批量下表现良好的模型可能不适用于交互式使用。
在部署时，专家的放置旨在最小化全互联流量，权重仅在完成每个专家的敏感性检查后进行量化，运行时监控用于检测不均衡或设备不可用。容量和路由设置随模型进行版本管理。团队仅在额外的参数容量显著提升所需任务且能够证明其在内存和分布式系统复杂性上的合理性时才选择 MoE；否则，密集模型可能更便宜、更易运维且更可预测。
实用实现清单
将概念转化为有界、可测试的工作流: token → router → top‑k → experts → combine → output。指定负责人，记录数据和依赖，建立简易基线，设定接受和停止标准，测试代表性故障，并在扩大范围前定义监控、回滚和审查。记录版本和假设，以便其他团队能够复现结果并了解变更内容。
上线前，需与构建、运维、保障以及受系统影响的人员进行有文档记录的就绪评审。测试正常情况、边界条件、依赖失效和误用；保存证据和未解决的风险。明确谁有权批准发布、修改阈值、覆盖输出或停止运行。实际数据到来后重新评估决策，因为技术上成功的试点并不保证在更大规模下的可靠表现。
- 容量: 大量存储的专家参数。
- 活跃计算: 每个 token 的少量子集。
- 系统成本: 内存、调度、平衡和延迟。
常见问题
MoE 专家是独立模型吗？
通常不是。它们是同一训练模型内部的子网络，由路由器和共享层连接。其学习到的专精可能并不符合直观的领域划分。
为什么 MoE 可以拥有大量参数却只有适度的计算量？
每个 token 只会激活少量的前 k 名专家。未激活的专家参数仍然占用存储和内存，并可能产生通信开销。
主要参考文献
