🏠 返回首页

Architecture Note · 2026.09

Dense 与 MoE
把「容量」和「算力」拆开的那一刀

一份关于大模型两种主干架构的深度对比:原理、代价、技术难度、当前格局与未来走向。

主题 Dense / Mixture-of-Experts 数据截至 2026 年 9 月 覆盖 DeepSeek · Qwen · Kimi · Llama · Mistral · Gemini · GPT · Claude

01先厘清一件事:它们不在同一层

把 Dense 和 MoE 当成两种并列的"架构"来对比,是最常见的起点,也是最先出错的起点。

MoE 替换掉的,只是 Transformer Block 里的 FFN(前馈网络)。Self-Attention、残差连接、LayerNorm 全部原样保留。也就是说,MoE 是在 Transformer 内部做的一次局部稀疏化手术,而不是另一套骨架。

这个关系可以用一句话概括:

Relation

MoE 不是 Transformer 的替代品。准确的关系是:MoE = 把 Block 里的 Dense FFN,换成"路由器 + 一组稀疏激活的专家"。层数照旧堆叠,其余结构不动。

Dense 块与 MoE 块的差别

位置Dense 块MoE 块
Self-Attention全量自注意力完全相同
FFN1 个前馈网络,100% 参数参与N 个专家 + 1 个路由器,每 token 激活 Top-k
计算量∝ 总参数∝ 激活参数
显存占用∝ 总参数∝ 总参数(不省

所以真正的问题不是"选哪个架构",而是"在什么规模、什么部署条件下,值得为稀疏化付出那套工程代价"。这个问题在后面的章节里会有明确答案。

02参数分裂成两个数字

MoE 带来的最反直觉的后果:模型里"参数量"这一个数字,变成了两个。

稠密模型这两个数字永远相等,所以它天生无法解耦。MoE 把它们拆开,并且拆得越来越狠——下图是当前主流开源模型的真实数字,横轴为对数刻度。

总参数(显存 / 知识容量) 每 token 激活参数(速度 / 成本)
Qwen3.8-2.4T-A95B
2.4T / 95B
25 : 1
DeepSeek V4-Pro
1.6T / 49B
33 : 1
Kimi K2
1.0T / 32B
31 : 1
Mistral Large 3
675B / 41B
16 : 1
Llama 4 Maverick
400B / 17B
24 : 1
DeepSeek V4-Flash
284B / 13B
22 : 1
Qwen3-235B-A22B
235B / 22B
11 : 1
Qwen3.8-27B 稠密
27B / 27B
1 : 1
ZAYA1-8B
8B / 0.76B
10 : 1

两条柱子之间的落差,就是 MoE 全部价值与全部代价的来源。用两个坐标看得更清楚:横轴放激活参数(成本轴),纵轴放总参数(能力轴)。稠密模型只能落在对角线上,MoE 则整片浮到上方——离对角线越远,解耦越彻底

Key insight

DeepSeek V4-Pro 的解耦比约 33 : 1,而 2023 年的 Mixtral 8x7B 只有 3.6 : 1。这几年 MoE 领域的工程进展,本质上就是在推高这个比值。

03MoE 的三代演进

从"看起来很美但落地麻烦",到几乎所有前沿模型的默认选择,中间走了三代。

  1. 2023.12 — 第一代:粗粒度 Mixtral 8x7B 8 个专家、Top-2 路由,47B 总参数 / 13B 激活。它的意义不在于榜单分数,而在于证明了稀疏 MoE 可以作为公开权重模型进入真实开发生态,速度约为同级稠密模型的 6 倍,Apache 2.0 授权。此前 MoE 只活在超大规模内部训练系统里。
  2. 2024–2025 — 第二代:细粒度 + 共享专家 DeepSeekMoE → Qwen3 系列 核心思路是把专家切得更细、更多,让路由器能组合出更精确的知识单元;同时引入共享专家(shared expert)——少数几个专家对每个 token 恒定激活,专门承担"所有 token 都需要的公共能力",避免其余路由专家各自重复学习这些基础模式。
  3. 2026 — 第三代:极端稀疏 + 混合注意力 DeepSeek V4 / Qwen3.8-2.4T-A95B 总参数破万亿,激活比压到 25 : 1 以上(V4-Pro 达 33 : 1),专家数上升到 384–512 个,每 token 激活 6–10 个。更关键的是,稀疏化的战场从 FFN 转移到了 Attention 本身——这一点在第 8 节展开。
Recipe

到 2026 年,行业已经收敛出一套事实标准配方:细粒度 MoE + 1~2 个共享专家(或 Qwen3 式的零共享专家)+ 基于偏置的负载均衡。DeepSeek V3/V3.2、Qwen3、Kimi K2、GLM-4.5/4.6、混元-Large 基本都是这个模板的变体。

04四个必须先纠正的误解

这几点如果搞错,后面所有判断都会跟着歪。

误解一:MoE 省显存

错。MoE 省的是算力和电,不是显存。因为任意专家都可能被选中,全部专家权重必须常驻显存。一个 1.6T 的模型即便每 token 只激活 49B,也得凑够能装下 1.6T 的硬件(FP8 下约 1.6TB,FP4 减半)。真正的省显存手段只有专家 offload,代价是 CPU–GPU 传输延迟。

记住这个分工:激活参数决定速度,总参数决定显存账单。

误解二:MoE 是 8 个模型的集成

错。每个"专家"只是一个 FFN 层,不是独立模型。而且路由是逐层独立决策的——同一个 token 在不同层会走不同的专家。32 层 × 每层 8 个专家,一个 token 实际走的是 8³² 种组合中的某一条路径。

误解三:专家会自动专精数学、代码

基本错。对 Mixtral、DBRX、DeepSeek 的路由分析反复发现,专家更多是按 token 类型分工(标点、专有名词、功能词),而不是按主题。主题专精偶尔涌现,但它不是设计目标,也不该被当成卖点。

误解四:MoE 是新架构

错。这个概念 1991 年就提出了(Jacobs 等,Adaptive Mixtures of Local Experts)。2021 年 Google 的 Switch Transformer 把它推到 1.6T 参数,验证了稀疏模型可以在不同比抬高单 token 计算量的前提下扩展容量。2023 年 Mixtral 才让它进入普通开发者视野。

05优缺点全面对照

把两种架构放在同一张表上,逐维度对照。

维度DenseMoE
每 token 计算量∝ 总参数∝ 激活参数,可低一个数量级
显存占用∝ 总参数∝ 总参数(并不省
知识容量上限受算力硬约束可远超同算力 Dense
推理吞吐 / 成本成本高,随规模线性恶化同能力下便宜 5–10 倍
训练稳定性高,流程成熟可预测低:路由坍塌、负载不均、通信调优
训练成本同能力下更贵同能力下更省
单卡部署简单直接困难,需专家并行 / offload
微调直接,行为可预期敏感:专家漂移、路由分布被破坏
量化方案成熟更难,各专家敏感度不均
延迟确定性稳定有抖动(专家命中热点时)
人才与工程门槛高(通信、并行、调度)
可解释性路由可可视化,但别过度解读
One line

MoE 用工程复杂度,换取单位算力的有效能力。它不是免费的午餐——它把"算力账单"转成了"工程账单"。

也正因为如此,MoE 从来没有、也不会完全取代 Dense。它减少的是激活计算量,而不是模型权重本身。容量与算力的解耦,只在一部分场景里是净收益。

06技术难度:难在哪一层

"MoE 更便宜"这句话对训练方和部署方含义完全不同。分三段看。

训练侧:难度最高的一段

路由坍塌

路由器天然倾向把 token 集中分给少数几个专家,导致其余专家永远得不到训练信号。解决手段是负载均衡:DeepSeek 用"无辅助损失的偏置调整"(避免均衡损失干扰模型性能),多数模型用 aux loss + z-loss,Qwen3 走 global-batch 均衡。

通信墙

专家分布在多张卡上,每个 token 都要用 all-to-all 把特征发到目标专家所在卡、算完再收回。这是 MoE 训练里最烧工程的部分,也是 MoE 对集群互联带宽(NVLink / 拓扑结构)极度敏感的原因。

并行策略组合

专家并行(EP)× 张量并行(TP)× 流水并行(PP)的排布本身是个组合优化问题。配错了,直接浪费近一半算力。

精度与稳定性

FP8 已成常态,前沿进一步下探:DeepSeek V4 把 MoE 专家权重以 FP4 存储并做量化感知训练,相比 FP8 省一半显存;同时把优化器从 AdamW 换成 Muon,以改善万亿级参数规模下的收敛稳定性。此外还引入了 MTP(多 token 预测)作为辅助训练目标。

drop 策略

早期 Switch / Mixtral 允许丢弃超出容量的 token(capacity factor 1.0–1.25);现在主流是 dropless,不丢 token,完全靠均衡策略解决负载问题。

推理侧:难点换了地方

微调侧

全参 SFT 会扰动路由分布,RL 阶段更敏感。实务上的稳妥做法是低秩微调(LoRA),或干脆把大 MoE 蒸馏成稠密小模型后再部署。

Reality check

换个角度看,Dense 的难度并不低,只是形态不同:它难在如何把参数量压到能跑——靠蒸馏、激进量化、线性注意力来对抗算力天花板。两条路线的工程难度都不小,只是分布在不同环节。

07当前格局(2026.09)

开源侧已经一边倒,闭源侧是一笔糊涂账,稠密模型退守到了自己的生态位。

开源侧:MoE 一统天下

模型总参数激活参数稀疏比专家结构
Qwen3.8-2.4T-A95B2.4T95B25 : 1512 专家,10 routed + 1 shared
DeepSeek V4-Pro1.6T49B33 : 1384 routed + 1 shared,Top-6
Kimi K21.0T32B31 : 1384 专家
Mistral Large 3675B41B16 : 1MoE
Llama 4 Maverick400B17B24 : 1128 routed + 1 shared
DeepSeek V4-Flash284B13B22 : 1256 routed + 1 shared,Top-6
Qwen3-235B-A22B235B22B11 : 1128 专家,Top-8
ZAYA1-8B8B0.76B10 : 1极端稀疏

最具象征意义的不是某一个模型,而是 Meta 从稠密转向 MoE(Llama 4 是 Llama 系列首次采用 MoE)。当最大的开源权重发布方放弃稠密,说明 MoE 已经从"可选优化"变成了"默认架构"。

闭源侧:不透明,但方向清楚

厂商架构披露判断
Google Gemini技术报告明确写明为 Sparse Mixture-of-Experts Transformer态度最透明,确认 MoE
OpenAI GPT-5 系列系统卡描述为"路由器 + 若干命名子模型"模型级路由(请求分流到不同模型),严格说不是层内专家路由;参数量从未公布
Anthropic Claude架构完全未披露外界只能推测
Uncertainty

闭源模型的架构细节属于厂商未公开信息。市面上流传的部分聚合类参数表存在明显错误,本报告中闭源部分只做方向性判断,不给具体参数量。

稠密模型没有死,它退守到了三个位置

  1. ≤30B 的端侧 / 单卡甜点区。这是稠密最舒服的生态位。Qwen3.8-27B(Apache 2.0、原生多模态、262K 原生上下文可经 YaRN 外推至 1M)能在 24–32GB 显存的消费级卡上运行,发布两天下载量破 100 万,社区贡献 500 余个量化版本。在这个尺寸上,MoE 的优势并不明显,反而引入延迟抖动。

  2. 高密度推理路线。Qwen3.8-27B 在 SWE-Bench Pro 上取得 61.7%、LiveCodeBench 90.3%,官方称在部分编码与办公任务上超过更大的前代模型。参数用得更"密",是稠密路线的核心论据。

  3. 蒸馏的落点。大 MoE 训完之后,蒸馏出稠密小模型再部署——这已经是最常见的工业闭环。云端用 MoE 攀能力上限,端侧用 Dense 保交付质量。

08未来的四条主线

把所有动向归拢,会发现它们指向同一件事:把「每个 token 都必须计算」的东西,一个个变稀疏。

主线一:参数稀疏度继续上升

稀疏比从 Mixtral 的 3.6 : 1 推到今天的 25–33 : 1,方向没有停。更值得注意的是它催生了一种新的产品形态:「MoE-Flash」——以旗舰级的综合能力下探,换取一个数量级的成本下降。当成本下降来自架构而非补贴,厂商就可能在合理毛利区间里持续压价,而不是打赔本价格战。

主线二:Attention 成为真正的新战场

这是 2025–2026 年最实质的变化。FFN 的稀疏化已基本收敛,而注意力本身的二次复杂度,随着上下文从 128K 走向 1M 甚至更长,反而成了新的硬约束。

待验证

市面上也出现了宣称把注意力整体降为次二次复杂度、在百万级上下文下把算力降低一个数量级的初创方案。这类数字目前多为厂商自测,尚未见到独立复现,方向可信,小数位存疑。

主线三:混合架构成为常态

"每层都长一样"的标准 Block 正在消失。未来的模型更像是多种层类型交错拼装:MoE 层、稀疏注意力层、线性 / 门控层按比例搭配,配合更激进的数值精度(BF16 → FP8 → FP4 + 量化感知训练)。架构设计从"选一个方案"变成"配一个比例"。

主线四:评测口径与能力来源双变

09选型与落地建议

如果你要在两条路线之间做决定,下面几条可以直接用。

场景建议理由
自建 / 私有化部署 显存按总参数算(FP8 ≈ 参数量 GB,FP4 减半),吞吐按激活参数 这是最容易算错的一笔账,很多人按激活参数买卡,结果加载不进
单机、预算有限、要求确定性延迟 优先Dense(≤30B) 同显存预算下稠密更划算,且无路由抖动
同成本下追求能力上限 优先 MoE 稀疏比越高,单位算力买到的容量越多
调用 API 做选型 别看单价,看 cost per successful task 要按你真实的上下文长度测延迟与成功率,不看榜单分
需要微调 LoRA,或蒸馏到稠密小模型 MoE 全参微调会破坏路由分布,门槛和风险都高
长上下文 / Agent 场景 先看注意力方案,再看专家数量 决定成本和可用性的瓶颈已经转移到注意力上了
Closing

Dense 和 MoE 不是新老交替的关系,而是按规模与部署条件分工的两条路。云端攀能力上限,MoE 几乎是唯一解;端侧保交付质量,稠密仍是更稳的选择。中间地带,正在被"小激活比的 Flash 级 MoE"快速填充。