MoE 是什么？

MoE（Mixture of Experts，混合专家）是一种大模型的网络架构。它把庞大的模型拆分成许多擅长不同任务的“专家网络”（Expert），并配备一个负责分派任务的“路由器”（Router）。用户提问时，模型不会让所有专家都参与计算，而是由路由器挑选最合适的少数几位专家“接单”干活。

可以把 MoE 想象成一家大型医院：挂号台（路由器）根据症状把患者分给对应的专科医生（专家），而不是让全院医生围着一个人会诊。

与之相对的是“稠密模型”（Dense Model）：稠密模型每处理一个请求，所有参数都要参与运算。MoE 则实现了“参数很多、每次只用一小部分”的稀疏激活，这正是它降本增效的关键。

MoE 是怎么运作的？

一次 MoE 推理大致分三步：

1. 输入分发：用户问题经过模型的公共层后，被送入路由器；
2. 专家挑选：路由器根据输入内容打分，从几十甚至上百个专家中选出得分最高的几位（例如 8 选 2）；
3. 结果合并：被选中的专家分别计算，输出结果按权重加权汇总，进入下一层或生成答案。

MoE 与传统稠密模型的区别可参考下表：

当然，MoE 也有代价：专家之间可能“忙闲不均”，需要负载均衡技术来调教；训练不稳定、显存占用高，也使它的工程门槛高于稠密模型。

哪些大模型在用 MoE？

MoE 概念早在 1991 年就已提出，近年因大模型的算力压力而“翻红”。以下国内可直连的主流产品均采用了 MoE 或专家化设计：

• DeepSeek（深度求索）：DeepSeek-V3/R1 总参数 6710 亿，每个 token 仅激活约 370 亿，以极低的 API 价格提供接近顶级闭源模型的能力，是国产开源 MoE 的标杆；
• Kimi（月之暗面）：新版模型转向万亿参数 MoE 架构，兼顾超长上下文与推理成本；
• 豆包（字节跳动）：主力模型采用稀疏 MoE 结构，支撑高并发、低成本的 AI 调用；
• 通义千问（阿里）：开源多款 Qwen MoE 模型，可在阿里云百炼平台直接调用或私有化部署；
• 智谱 GLM：旗舰模型引入 MoE 结构，智谱清言 App 内可直接体验；
• 可灵、即梦：快手可灵、字节即梦等图像视频生成产品，底层技术也普遍走向多专家分工的路线，由不同专家分管文本、图像、视频等模态。

普通用户无需关心架构细节，直接在上述 App 或官网对话即可；开发者则能享受更低的 token 单价和更宽松的部署条件。

MoE 的应用场景

• 低成本 API 服务：激活参数少、推理省算力，客服、搜索、写作等高并发业务受益明显；
• 超长文本处理：处理数十万字文档时，能在控制成本的同时维持能力，适合法律卷宗、代码库分析；
• 私有化部署：开源 MoE 模型可部署到企业内网，兼顾效果与硬件成本；
• 多模态与垂直领域：不同专家天然适合分管不同模态或行业知识，便于做领域增强。

常见问题

MoE 模型总参数很大，是不是更费钱、更慢？

恰恰相反。MoE 的推理成本取决于每次实际激活的参数量。以 DeepSeek-V3 为例，总参数 6710 亿，但每个 token 只激活约 370 亿，单次成本远低于同规模稠密模型。不过它对显存总量要求更高，部署时需要更多卡来“装下”所有专家。

MoE 会比稠密模型更“笨”吗？

在训练充分、路由设计合理的前提下，同等计算预算下 MoE 通常能学到更多知识、效果更好。早期 MoE 确实存在专家分工混乱、训练不稳定的问题，但经过负载均衡、共享专家等技术改进，主流 MoE 模型的表现已不输甚至超越同级稠密模型。

普通用户和开发者需要专门学 MoE 吗？

使用者不需要。调用 DeepSeek、Kimi、豆包的 API 或使用其 App 时，MoE 已在幕后默默工作，用法与普通模型完全一致。开发者若想深入，可关注各厂商开源的 MoE 模型权重与技术报告，学习其路由与负载均衡设计，这对优化推理成本、做二次开发都很有帮助。