DeepSeek 的 MoE 到底省在哪里：专家、路由、MLA 与训练成本

2026-09-05 分类：Ai 标签：技术解读、大模型、开发者、开放权重

原载：荒岛书生 · 原文 · 作者：荒岛编辑部 · 原始发布日期：2026-09-05。迁移核对：2026-11-07，依据当前公开正文；保留原文资料截止日期、作者观点与核验说明，不将历史资料视作今日消息。

先把四个名字分开

DeepSeekMoE 是一条专家架构设计路线；V2 与 V3 是采用相关结构的模型；R1 重点讨论推理能力的后训练。把它们统称为“DeepSeek 技术”，很容易把不同层面的贡献混在一起。本文以 2024—2025 年的原始技术报告为主，不拿 V4 的后续变化解释旧版本。

稠密模型的大部分层，对每个 token 都执行相似计算。MoE 常把前馈部分拆成多个专家，由路由器选择其中一部分处理当前 token，再合并结果。

输出 ≈ 共享专家(x) + Σ 被选专家的路由权重 × 专家输出(x)

这是帮助理解的概念式，省略了具体模型中的归一化与实现细节。路由通常作用在 token 表示上，不是先判断整篇文章属于“法律”还是“医学”，再把它交给一个人工命名的部门。

想象有 8 个同样大小的计算分支，每次只走 2 个。总容量包含 8 个分支，而单次执行只使用其中 2 个；但注意力、共享层、路由和通信仍有成本，不能直接宣布整个系统便宜了四倍。

DeepSeekMoE 将专家划分得更细，并引入共享专家。直觉上，较细的模块提供更多组合方式；共享部分承接通用内容，让路由部分不必反复学习相同知识。

这里的“分工”是训练涌现的数值行为。并没有一张人工表格规定某个专家只会写 Python、另一个只会做数学。解释专家时，最好讨论激活分布和实验，而不是给神经网络随意贴人格标签。

如果多数 token 都挤向少数专家，其他设备空闲，热点设备排队，整体吞吐会变差。模型质量、专家容量与硬件负载因此相互牵制。

V3 报告讨论了不依赖传统辅助损失主导的负载均衡方法。阅读时仍应核对具体层级与训练细节，不要把方法名字扩张成“整个训练完全不存在任何辅助约束”。

工程上还要关注批量大小、跨设备通信和专家放置。一个激活参数较少的模型，在小批量、通信慢或显存不足的机器上，并不必然比更小的稠密模型响应快。

自回归生成通常缓存历史 token 的 Key 和 Value，避免每一步重算。上下文越长、并发越高，这份 KV cache 越显著。

V2 的 MLA 用潜在表示压缩相关缓存开销。它与 MoE 的分工不同：MoE 主要改变哪些前馈参数参与计算，MLA 处理注意力缓存等效率问题。两者互相配合，不能把它们当作同一个技巧。

一个实用判断是：机器先被什么卡住？若内存装不下，先看权重和缓存；若能装下却吞吐很低，再看带宽、通信、批处理和内核。单一“参数量”解释不了所有瓶颈。

V3 报告给出总参数 671B、每 token 激活约 37B。37B 不能被读成“部署只要加载 37B 权重”：未激活专家仍需在某处可访问，可能驻留显存、内存或通过分布式设备提供。

报告公布的 GPU 小时与训练成本也有统计边界。购买硬件、早期研究、失败实验、数据处理与持续服务不是天然包含在一个训练数字里。比较成本前，必须先对齐任务、精度、吞吐、上下文长度和核算范围。

R1 研究的是怎样利用反馈塑造推理行为，包括 R1-Zero 的直接强化学习探索，以及 R1 的多阶段流程。架构提供容量与效率，训练方法决定如何使用这些能力；两者都重要，却不是同一个解释。

如果要评估自己的业务，应选代表性任务，对比正确率、单次成功成本、延迟和人工返工量。不要仅凭“稀疏”判断便宜，也不要仅凭模型会输出较长推理就认定结果可靠。

先看模型版本和激活方式，再看缓存结构；接着看负载均衡和训练设置，最后看实验比较是否公平。把这几层拆开，才能看清 DeepSeek 的工程价值，也能把相同方法用于理解其他 MoE 模型。

本文为荒岛编辑部原创技术解读，公式示例与工程判断用于解释原理，不是对论文实验的独立复现。历史事实按上述原始资料核验，资料截止 2026 年 9 月 5 日。