Architecture Note · 2026.09
一份关于大模型两种主干架构的深度对比:原理、代价、技术难度、当前格局与未来走向。
把 Dense 和 MoE 当成两种并列的"架构"来对比,是最常见的起点,也是最先出错的起点。
MoE 替换掉的,只是 Transformer Block 里的 FFN(前馈网络)。Self-Attention、残差连接、LayerNorm 全部原样保留。也就是说,MoE 是在 Transformer 内部做的一次局部稀疏化手术,而不是另一套骨架。
这个关系可以用一句话概括:
MoE 不是 Transformer 的替代品。准确的关系是:MoE = 把 Block 里的 Dense FFN,换成"路由器 + 一组稀疏激活的专家"。层数照旧堆叠,其余结构不动。
| 位置 | Dense 块 | MoE 块 |
|---|---|---|
| Self-Attention | 全量自注意力 | 完全相同 |
| FFN | 1 个前馈网络,100% 参数参与 | N 个专家 + 1 个路由器,每 token 激活 Top-k |
| 计算量 | ∝ 总参数 | ∝ 激活参数 |
| 显存占用 | ∝ 总参数 | ∝ 总参数(不省) |
所以真正的问题不是"选哪个架构",而是"在什么规模、什么部署条件下,值得为稀疏化付出那套工程代价"。这个问题在后面的章节里会有明确答案。
MoE 带来的最反直觉的后果:模型里"参数量"这一个数字,变成了两个。
稠密模型这两个数字永远相等,所以它天生无法解耦。MoE 把它们拆开,并且拆得越来越狠——下图是当前主流开源模型的真实数字,横轴为对数刻度。
两条柱子之间的落差,就是 MoE 全部价值与全部代价的来源。用两个坐标看得更清楚:横轴放激活参数(成本轴),纵轴放总参数(能力轴)。稠密模型只能落在对角线上,MoE 则整片浮到上方——离对角线越远,解耦越彻底。
DeepSeek V4-Pro 的解耦比约 33 : 1,而 2023 年的 Mixtral 8x7B 只有 3.6 : 1。这几年 MoE 领域的工程进展,本质上就是在推高这个比值。
从"看起来很美但落地麻烦",到几乎所有前沿模型的默认选择,中间走了三代。
到 2026 年,行业已经收敛出一套事实标准配方:细粒度 MoE + 1~2 个共享专家(或 Qwen3 式的零共享专家)+ 基于偏置的负载均衡。DeepSeek V3/V3.2、Qwen3、Kimi K2、GLM-4.5/4.6、混元-Large 基本都是这个模板的变体。
这几点如果搞错,后面所有判断都会跟着歪。
错。MoE 省的是算力和电,不是显存。因为任意专家都可能被选中,全部专家权重必须常驻显存。一个 1.6T 的模型即便每 token 只激活 49B,也得凑够能装下 1.6T 的硬件(FP8 下约 1.6TB,FP4 减半)。真正的省显存手段只有专家 offload,代价是 CPU–GPU 传输延迟。
记住这个分工:激活参数决定速度,总参数决定显存账单。
错。每个"专家"只是一个 FFN 层,不是独立模型。而且路由是逐层独立决策的——同一个 token 在不同层会走不同的专家。32 层 × 每层 8 个专家,一个 token 实际走的是 8³² 种组合中的某一条路径。
基本错。对 Mixtral、DBRX、DeepSeek 的路由分析反复发现,专家更多是按 token 类型分工(标点、专有名词、功能词),而不是按主题。主题专精偶尔涌现,但它不是设计目标,也不该被当成卖点。
错。这个概念 1991 年就提出了(Jacobs 等,Adaptive Mixtures of Local Experts)。2021 年 Google 的 Switch Transformer 把它推到 1.6T 参数,验证了稀疏模型可以在不同比抬高单 token 计算量的前提下扩展容量。2023 年 Mixtral 才让它进入普通开发者视野。
把两种架构放在同一张表上,逐维度对照。
| 维度 | Dense | MoE |
|---|---|---|
| 每 token 计算量 | ∝ 总参数 | ∝ 激活参数,可低一个数量级 |
| 显存占用 | ∝ 总参数 | ∝ 总参数(并不省) |
| 知识容量上限 | 受算力硬约束 | 可远超同算力 Dense |
| 推理吞吐 / 成本 | 成本高,随规模线性恶化 | 同能力下便宜 5–10 倍 |
| 训练稳定性 | 高,流程成熟可预测 | 低:路由坍塌、负载不均、通信调优 |
| 训练成本 | 同能力下更贵 | 同能力下更省 |
| 单卡部署 | 简单直接 | 困难,需专家并行 / offload |
| 微调 | 直接,行为可预期 | 敏感:专家漂移、路由分布被破坏 |
| 量化 | 方案成熟 | 更难,各专家敏感度不均 |
| 延迟确定性 | 稳定 | 有抖动(专家命中热点时) |
| 人才与工程门槛 | 低 | 高(通信、并行、调度) |
| 可解释性 | 无 | 路由可可视化,但别过度解读 |
MoE 用工程复杂度,换取单位算力的有效能力。它不是免费的午餐——它把"算力账单"转成了"工程账单"。
也正因为如此,MoE 从来没有、也不会完全取代 Dense。它减少的是激活计算量,而不是模型权重本身。容量与算力的解耦,只在一部分场景里是净收益。
"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 预测)作为辅助训练目标。
早期 Switch / Mixtral 允许丢弃超出容量的 token(capacity factor 1.0–1.25);现在主流是 dropless,不丢 token,完全靠均衡策略解决负载问题。
全参 SFT 会扰动路由分布,RL 阶段更敏感。实务上的稳妥做法是低秩微调(LoRA),或干脆把大 MoE 蒸馏成稠密小模型后再部署。
换个角度看,Dense 的难度并不低,只是形态不同:它难在如何把参数量压到能跑——靠蒸馏、激进量化、线性注意力来对抗算力天花板。两条路线的工程难度都不小,只是分布在不同环节。
开源侧已经一边倒,闭源侧是一笔糊涂账,稠密模型退守到了自己的生态位。
| 模型 | 总参数 | 激活参数 | 稀疏比 | 专家结构 |
|---|---|---|---|---|
| Qwen3.8-2.4T-A95B | 2.4T | 95B | 25 : 1 | 512 专家,10 routed + 1 shared |
| DeepSeek V4-Pro | 1.6T | 49B | 33 : 1 | 384 routed + 1 shared,Top-6 |
| Kimi K2 | 1.0T | 32B | 31 : 1 | 384 专家 |
| Mistral Large 3 | 675B | 41B | 16 : 1 | MoE |
| Llama 4 Maverick | 400B | 17B | 24 : 1 | 128 routed + 1 shared |
| DeepSeek V4-Flash | 284B | 13B | 22 : 1 | 256 routed + 1 shared,Top-6 |
| Qwen3-235B-A22B | 235B | 22B | 11 : 1 | 128 专家,Top-8 |
| ZAYA1-8B | 8B | 0.76B | 10 : 1 | 极端稀疏 |
最具象征意义的不是某一个模型,而是 Meta 从稠密转向 MoE(Llama 4 是 Llama 系列首次采用 MoE)。当最大的开源权重发布方放弃稠密,说明 MoE 已经从"可选优化"变成了"默认架构"。
| 厂商 | 架构披露 | 判断 |
|---|---|---|
| Google Gemini | 技术报告明确写明为 Sparse Mixture-of-Experts Transformer | 态度最透明,确认 MoE |
| OpenAI GPT-5 系列 | 系统卡描述为"路由器 + 若干命名子模型" | 属模型级路由(请求分流到不同模型),严格说不是层内专家路由;参数量从未公布 |
| Anthropic Claude | 架构完全未披露 | 外界只能推测 |
闭源模型的架构细节属于厂商未公开信息。市面上流传的部分聚合类参数表存在明显错误,本报告中闭源部分只做方向性判断,不给具体参数量。
≤30B 的端侧 / 单卡甜点区。这是稠密最舒服的生态位。Qwen3.8-27B(Apache 2.0、原生多模态、262K 原生上下文可经 YaRN 外推至 1M)能在 24–32GB 显存的消费级卡上运行,发布两天下载量破 100 万,社区贡献 500 余个量化版本。在这个尺寸上,MoE 的优势并不明显,反而引入延迟抖动。
高密度推理路线。Qwen3.8-27B 在 SWE-Bench Pro 上取得 61.7%、LiveCodeBench 90.3%,官方称在部分编码与办公任务上超过更大的前代模型。参数用得更"密",是稠密路线的核心论据。
蒸馏的落点。大 MoE 训完之后,蒸馏出稠密小模型再部署——这已经是最常见的工业闭环。云端用 MoE 攀能力上限,端侧用 Dense 保交付质量。
把所有动向归拢,会发现它们指向同一件事:把「每个 token 都必须计算」的东西,一个个变稀疏。
稀疏比从 Mixtral 的 3.6 : 1 推到今天的 25–33 : 1,方向没有停。更值得注意的是它催生了一种新的产品形态:「MoE-Flash」——以旗舰级的综合能力下探,换取一个数量级的成本下降。当成本下降来自架构而非补贴,厂商就可能在合理毛利区间里持续压价,而不是打赔本价格战。
这是 2025–2026 年最实质的变化。FFN 的稀疏化已基本收敛,而注意力本身的二次复杂度,随着上下文从 128K 走向 1M 甚至更长,反而成了新的硬约束。
市面上也出现了宣称把注意力整体降为次二次复杂度、在百万级上下文下把算力降低一个数量级的初创方案。这类数字目前多为厂商自测,尚未见到独立复现,方向可信,小数位存疑。
"每层都长一样"的标准 Block 正在消失。未来的模型更像是多种层类型交错拼装:MoE 层、稀疏注意力层、线性 / 门控层按比例搭配,配合更激进的数值精度(BF16 → FP8 → FP4 + 量化感知训练)。架构设计从"选一个方案"变成"配一个比例"。
如果你要在两条路线之间做决定,下面几条可以直接用。
| 场景 | 建议 | 理由 |
|---|---|---|
| 自建 / 私有化部署 | 显存按总参数算(FP8 ≈ 参数量 GB,FP4 减半),吞吐按激活参数估 | 这是最容易算错的一笔账,很多人按激活参数买卡,结果加载不进 |
| 单机、预算有限、要求确定性延迟 | 优先Dense(≤30B) | 同显存预算下稠密更划算,且无路由抖动 |
| 同成本下追求能力上限 | 优先 MoE | 稀疏比越高,单位算力买到的容量越多 |
| 调用 API 做选型 | 别看单价,看 cost per successful task | 要按你真实的上下文长度测延迟与成功率,不看榜单分 |
| 需要微调 | LoRA,或蒸馏到稠密小模型 | MoE 全参微调会破坏路由分布,门槛和风险都高 |
| 长上下文 / Agent 场景 | 先看注意力方案,再看专家数量 | 决定成本和可用性的瓶颈已经转移到注意力上了 |
Dense 和 MoE 不是新老交替的关系,而是按规模与部署条件分工的两条路。云端攀能力上限,MoE 几乎是唯一解;端侧保交付质量,稠密仍是更稳的选择。中间地带,正在被"小激活比的 Flash 级 MoE"快速填充。