Reference · FAQ 0001 · 配套第 0001 课
架构、路由与 Token —— 第一课答疑实录
一、什么是 MoE 稀疏？还有别的架构吗？
"稀疏"说的是：不是所有参数都参与每个 token 的计算。
- 稠密（Dense）：每个 token 流经模型的全部参数。参数越多，计算越贵——参数量和计算量被锁死在一起。
- MoE（稀疏）：把 Transformer 层里的 FFN 换成 N 个并行的"专家 FFN"，每个 token 只走其中 top-k 个。这样总参数（容量）和每 token 计算量解耦了——Kimi K2 总参 1T，但每个 token 只算 32B 的量。
要分清"架构"这个词的两个层次：
| 层次 | 问题 | 主要选手 |
|---|---|---|
| 宏观 （序列怎么建模） |
用什么主干网络？ | Transformer（2017 至今统治）、RNN/LSTM（2017 前）、状态空间模型 Mamba/SSM、RWKV、混合架构（如 Jamba = Mamba+Transformer） |
| 微观 （层内部件怎么设计） |
FFN 用稠密还是稀疏？注意力用哪种？ | FFN：Dense ↔ MoE；注意力：MHA ↔ GQA ↔ MLA |
所以第一课说"MoE 稀疏"时，指的是微观层 FFN 的设计选择，不是取代 Transformer。对照表里三家的分歧（注意力列）和共同点（MoE 列）是两个正交的维度。
宏观层上 Mamba/混合架构仍存活在长上下文、端侧等细分场景，但旗舰大模型的主干至今全是 Transformer——MoE 解决的是"容量瓶颈"，Mamba 解决的是"序列长度瓶颈"，前者当前更致命。
二、为什么有"路由"？为什么加"共享"？
路由是 MoE 的必然产物。稀疏化的前提是"每个 token 走的路不一样"——那必须有个东西决策谁走哪条路。这就是门控（gate/router）：一个小网络给每个 token 对所有专家打分，选 top-k。没有路由，就没有"条件计算"，MoE 就退化成一个大稠密层。
但路由带来一个新麻烦：赢者通吃——训练早期某几个专家碰巧被选得多，就越练越强、被选得更多，其他专家永远得不到训练，1T 参数里大半成了死参数。所以需要负载均衡机制——这是 DeepSeek-V3"无辅助损失负载均衡"要解决的问题（后续课程重点）。
共享专家解决的是知识重复存储。没有共享专家时，语法、基础语义这类每个 token 都需要的共性知识，会被路由专家各自存一份——384 个专家里可能 100 个都存了"这是一个中文句子"。共享专家是每个 token 必经的固定通道，专门承载共性知识；路由专家由此腾出手来，专注存"区分性"知识。来源是 DeepSeekMoE 论文（2024），Kimi K2 和 GLM 都沿用了"1 个共享"。
三、Token 是什么？和上下文什么关系？
Token 是模型读写文本的原子单位：tokenizer（BPE 算法）把文本切成小片段，每个片段映射成一个整数 id。它不等于"词"：
unbelievable可能切成 3 个 token；高频短语整个是一个 token- 汉语大约 1 个字 ≈ 1~2 个 token（取决于词表设计——第 0002 课主题）
- 词表大小 = 有多少种不同的 id（GLM 约 15 万，Kimi K2 是 16 万）
Token 和上下文的关系：token 是砖，上下文是墙。
- 上下文（context）= 模型当前能"看到"的 token 序列，不是 token 本身
- "上下文长度 128K" = 窗口里最多装 131072 个 token
- 推理时：输入被切成 prompt tokens → 模型一次生成一个 token（自回归），生成结果又拼进上下文——上下文是动态增长的
- KV Cache 显存随 token 数线性增长——这正是 MLA/GQA 要压缩的对象
直观换算：API 按 token 计费，128K 上下文 ≈ 一本 20 万字的中文长篇小说。
四、BPE 追问三连（第二课）
Q：BPE 是训练出来的模型吗？
都不是——精确说法是确定性统计算法：程序代码 + 对语料的统计（数相邻对频次 → 合并最高频 → 重复）。全程没有梯度、没有 loss、没有权重；同一份语料跑两遍，结果逐字节相同。此"训"非彼"训"（非神经网络训练）。
Q：所以产物是一张查询表？
对，而且是两张协调的表：有序合并规则表（merges，顺序即优先级——你在模拟器里点的每一步就是行序）+ 词表映射（vocab：token 字符串 → 整数 id）。编码 = 按优先级迭代查表应用规则，直到没有规则可套，最后查 vocab 拿 id。规则的优先级顺序决定切分结果。
Q：训练大模型时，这两块表怎么用？
- merges：数据管线的"切分器"，把全量训练语料变成子词序列；
- vocab：双重角色——映射 id，以及决定嵌入矩阵/LM Head 的行数（模型每步预测 = 对整个词表做一次分类），所以词表一变、模型结构就变，必须先冻结 tokenizer 再训模型；
- 特殊 token（BOS/EOS/pad、聊天模板）也注册在 vocab 里，如 GLM 的
eos_token_id: [151336, 151338]； - 训练与推理都只读这两张表，从不修改。
工作用途三句话：① 它是文本 ↔ 数字 id 的双向翻译器；② 训练时把语料统一切成 id 流（造好即冻结）；③ 推理时编码你的输入、解码模型的输出。算钱、算上下文占用都按 token 数，词表必须与模型配套。