（六）753B 参数怎么跑得动？MoE 让你只激活 3.5%

MoE 混合专家封面

注意力解决了，但参数本身还在拖后腿

上一篇我们用 DSA + IndexShare 把墙 1（算不动）拆了，注意力的计算量从一万亿次降到两千次量级。加上第 4 篇的 MLA 解决了存储，长上下文的两大算法瓶颈都松动了。

但墙 3（推不动）还在。 它不在注意力，而在模型的”体量”本身。

进度感:本篇破墙 3(推不动 · 参数太多)
墙 1(算不动)→ 第 5 篇 DSA 已破
墙 2(放不下)→ 第 4 篇 MLA 已破
墙 3(推不动)→ 本篇 MoE 在破 ★
墙 4(蹦得慢)→ 第 7 篇 MTP

墙 3 量化：753B 参数，全算一遍太贵

GLM-5.2 是一个 753B（7530 亿）参数的模型（按权重文件累加约 753B，官方公布口径 744B，本文沿用 753B 与连载前篇一致）。这些参数主要堆在每一层的 MLP（前馈网络）里——就是地基篇说的”注意力之后、负责消化信息”的那部分。

如果每次预测下一个 token，都把这 753B 参数全乘一遍：

每生成 1 个 token → 要跑 753B 次乘加
生成 1000 个 token → 7530 万亿次乘加

哪怕注意力算得动了，这个前向传播本身就慢到不可接受。 这就是墙 3——不是”某个环节卡”，是”整个身体太重”。

墙 3:753B 参数,每 token 全算一遍太贵

这对你用 AI 意味着什么: 为什么大模型又强又慢、小模型又快又弱？因为”强”靠参数堆出来，“慢”也由参数决定。算力和智能在参数规模上是一根跷跷板——MoE 要解决的就是：能不能既要 753B 的智能，又只花小模型的算力。

核心思想：医院分诊

MoE（Mixture of Experts，混合专家）的原理，用医院分诊比喻最贴切。

你去看病，不可能是所有科室的医生一拥而上都来给你看——那既不可能也没必要。正确做法是先去分诊台，说”我胃疼”，分诊台把你分到消化内科，只有这个科室的医生给你看，其他科室该干嘛干嘛。

MoE 一模一样：

每个 token 进入 MoE 层:
  ❌ 不是所有专家都处理它
  ✅ 先过门控(router):
       "这个 token 是什么?" → "是个代码动词"
       门控判断 → 选 8 个最相关的专家

     只有这 8 个 + 1 个共享专家 = 9 个专家干活
     其余 248 个专家纹丝不动

关键：不是让所有专家都上，而是按需调用。 绝大多数专家在每个 token 上都在”休息”，只有被选中的少数在工作。

医院分诊:256 个科室,分诊台选 8 个 + 1 个全科

这对你用 AI 意味着什么: MoE 的”按需调用”其实是个很普遍的智慧——手里有全套能力，但每次只调动相关的部分。 就像一个全栈工程师会前后端运维，但修某个 bug 时只动用相关的知识，不会把所有技能都过一遍。模型也是：它”知道”的远比每次”用到”的多。

GLM-5.2 的 MoE 配置：256 选 8 + 1 共享

拆 config，这套分诊的规模写得很清楚：

n_routed_experts: 256        # 总共 256 个路由专家
num_experts_per_tok: 8       # 每 token 只用 8 个
n_shared_experts: 1          # 还有 1 个共享专家永远参与
moe_intermediate_size: 2048  # 单个专家的中间维度
scoring_func: sigmoid        # 门控打分函数
topk_method: noaux_tc        # 无 aux loss + 偏置修正的 top-k(防负载不均)

三个关键设计，逐个说。

256 个专家：知识分科

每个专家是一个独立的小 MLP，擅长不同的”知识领域”。训练让它们自动分化——有的偏代码，有的偏数学，有的偏中文表达，有的偏英文。256 个是知识容量和路由精度的平衡：太少则每个专家要扛太多领域、不够专；太多则单个专家训练样本不够、门控也难选。

每 token 选 8 个：覆盖与省力的平衡

门控根据 token 的特征，从 256 个里选 8 个最相关的。这个”8”也是平衡：选太少（比如 2）知识覆盖不够、质量掉；选太多（比如 32）激活参数太多、失去省算力的意义。8 是近两年大 MoE 常见的取值（DeepSeek-V3、Qwen3 系列都选 8，据其公开资料）。

1 个共享专家：全科医生兜底

不管什么 token，都有一个共享专家永远参与。它像全科医生，保证基础能力不被路由遗漏。

为什么需要它？如果没有共享专家，某些罕见 token 可能在 256 个专家里找不到特别匹配的，质量就会塌。共享专家给所有 token 兜一个基础底盘，让”路由没选准”时也不至于翻车。

MoE config:256 选 8 + 1 共享,激活约 3.5%

门控怎么选专家

门控（router）是个小神经网络，工作流程很直接：

token 进入 MoE 层
   │
   ▼
门控 router:看 token 的特征向量
   │
   ▼ 输出 256 个分数(每个专家一个"匹配度")
   │
   ▼ 取分数最高的 8 个(配合 noaux_tc 偏置修正)
   │
   ▼ 只有这 8 个 + 1 个共享 = 9 个专家工作
   │
   ▼ 9 个专家的输出按权重加权混合 → MoE 层输出

noaux_tc：防止专家”旱的旱死涝的涝死”

这里有个工程上的坑：如果没有干预，门控很容易陷入马太效应——少数受欢迎的专家被反复选中（训练充分、越来越准），其他专家被冷落（训练不足、越来越差）。最后模型其实只用了十几个专家，剩下两百多个纯属浪费。

GLM-5.2 用 topk_method: noaux_tc 来治这个毛病：打分时加一个可学习的偏置项，给负载低的专家一个加成，把流量摊平到 256 个专家上。这是 DeepSeek 系列提出的 aux-loss-free 负载均衡方法（核心是不用传统辅助损失也能均衡），GLM 沿用（据其公开资料）。

门控 router:256 个分数取 top-8 + noaux_tc 负载均衡

收益：小模型的算力，大模型的容量

把这笔账算出来：

专家池:256 路由 + 1 共享 = 257 个
每 token 激活:8 路由 + 1 共享 = 9 个
激活比例:9 / 257 ≈ 3.5%

也就是说，模型有 753B 的”知识容量”，但每次推理只激活约 3.5% 的专家。

推理速度像个小模型——因为每次实际算的只有被激活的那一小撮。
知识容量像个 753B 大模型——因为所有专家都在那儿，只是按需调用。
两边的好处都占了。

这就是 MoE 的精髓：用小模型的推理成本，换大模型的知识容量。（这里的 3.5% 是按专家个数算的比例——9 个激活 / 257 个专家池；按参数量算会略有不同，因为共享专家、注意力层、dense 层的参数并不均等计入 MoE。）

这对你用 AI 意味着什么: 为什么 GLM-5.2 标 753B 却能在普通多卡上跑？因为 MoE 让它”推理时其实没那么大”。标称参数量≠每次推理的算力消耗——这点在选模型、估成本时很关键。一个 753B 的 MoE，部署成本可能远低于一个 753B 的稠密模型。

为什么浅层 Dense，深层才 MoE

你在地基篇可能注意到，GLM-5.2 的 78 层里前 3 层是 dense（普通 MLP），从第 4 层起才是 MoE。拆 config 能验证：

first_k_dense_replace: 3   # 前 3 层用 dense MLP
mlp_layer_types: dense×3 + sparse×75 = 78

（顺便兑现地基篇埋的一个伏笔：地基篇为了讲清楚，把每层都简化成”注意力 + MLP”，其实 GLM 从第 4 层起，MLP 就换成了 MoE。）

为什么这么设计？

浅层处理基础特征（语法、词法、字符模式）——这些特征几乎所有 token 都需要，而且浅层时 token 的语义还没清晰，门控很难准确路由。用 dense 更稳。
深层处理高阶知识（推理、代码、领域知识）——这时 token 语义已经明确，门控能精准选专家。用 MoE 更划算。

这是当前大 MoE 模型的主流范式：DeepSeek-V3、GLM-5.2、Qwen3-Next 等大 MoE 模型都是”前几层 dense + 其余 MoE”的路子。

78 层:前 3 dense + 后 75 MoE,浅层基础深层专精

MoE 不是 GLM 原创，但它是这套组合拳的一环

诚实地说，MoE 不是 GLM-5.2 的原创。DeepSeek、Mixtral、Qwen3 都用 MoE，GLM-5.2 的 MoE 设计理念和 DeepSeek 一脉相承（细粒度专家 + 共享专家 + 负载均衡）。

那为什么连载还要单开一篇讲它？三个原因：

它是 GLM-5.2 能跑起来的必要条件。 没有 MoE，753B 全算根本跑不动，DSA 和 MLA 再厉害也救不了”身体太重”这件事。
它和 DSA/MLA 是配套的，各管一处。 MoE 省 MLP 层的算力，DSA 省注意力层的算力，MLA 省 KV Cache 的存储——三者分工，谁也不替代谁。
“两轴稀疏”这个理念值得点出来（“两轴稀疏”是本文为方便记忆起的说法，不是正式术语）。DeepSeek 系列带起来的思路是：FFN 用 MoE 稀疏（每 token 只激活部分专家），Attention 用 DSA 稀疏（每 token 只算部分注意力）。两个维度同时稀疏，超大模型才跑得动。

两轴稀疏:FFN 用 MoE + Attention 用 DSA,两个维度同时省

一句话总结这个分工：MoE 让参数便宜，DSA 让上下文便宜，MLA 让存储便宜。 三者叠加，才让 753B 的模型在 1M 上下文下还能跑得动、装得下。

墙 3 拆完了，但还剩最后一道：蹦得慢

MoE 把墙 3（推不动）拆了：753B 的模型现在能用一小撮激活专家的算力跑起来。

但墙 4（蹦得慢）还在。

回忆地基篇：模型是”自回归”的，每生成一个字，都要把 78 层从头跑一遍。哪怕 DSA、MLA、MoE 让每次前向更快，它还是一次只能蹦一个字。生成 1000 个字，就要跑 1000 次完整前向。

有没有办法一次蹦多个？答案是下一篇的 MTP（Multi-Token Prediction，多 token 预测）——也叫投机解码。它的思路很妙：用一个轻量的 MTP 头快速猜后面几个字，再让主模型一次性并行验证。

这里有个最反直觉的点：验证不是”对错判断”，而是”主模型愿不愿认领 MTP 头的草稿”。 主模型自己也没有标准答案，它只能算概率——那怎么用概率判断对错？这是下一篇最烧脑、也最精彩的地方。

下篇预告：《一字一字蹦太慢？MTP 投机解码》

本篇涉及的 config 字段——n_routed_experts: 256、num_experts_per_tok: 8、n_shared_experts: 1、moe_intermediate_size: 2048、scoring_func: sigmoid、topk_method: noaux_tc、first_k_dense_replace: 3、mlp_layer_types（3 dense + 75 sparse）、moe_layer_freq: 1、norm_topk_prob: true、routed_scaling_factor: 2.5——均来自 GLM-5.2 公开的 config.json。激活比例 3.5% 按 9 激活 / 257 专家池（8 路由 + 1 共享 / 256 路由 + 1 共享）的专家个数比例估算，非按参数量。753B 总参数按权重文件累加、官方公布口径 744B。MoE 及 noaux_tc 负载均衡为 DeepSeek 系列方案，GLM-5.2 沿用，据其公开资料；“前 3 dense + 其余 MoE”为 DeepSeek-V3 / GLM-5.2 / Qwen3-Next 共有范式。无任何闭源或未公开信息。