稀疏与稠密架构
一、概述
根据参数激活方式的不同，大语言模型可以分为稠密模型（Dense Model）和稀疏模型（Sparse Model）。
| 类型 | 核心特点 | 类比 |
|---|
| 稠密模型 | 每个输入都激活所有参数 | 全员上岗，每个人都工作 |
| 稀疏模型 | 每个输入只激活部分参数 | 专家会诊，只叫相关专家 |
[!比喻] 稠密 vs 稀疏类比
- 稠密模型 = 小公司，每个人都参与每个项目
- 稀疏模型 = 大医院，每个病人只看相关科室的医生
二、稠密模型
2.1 定义
稠密模型（Dense Model）是指对于每个输入 Token，模型的所有参数都参与计算的架构。
2.2 计算方式
输入 Token
↓
所有参数参与计算（100% 激活）
↓
输出
参数量 = 激活参数量
2.3 代表模型
| 模型 | 参数量 | 类型 | 发布年份 |
|---|
| LLaMA 2/3 (7B-70B) | 7B-70B | 稠密 | 2023-2024 |
| GPT-3 (175B) | 175B | 稠密 | 2020 |
| BERT | 110M-340M | 稠密 | 2018 |
| PaLM (540B) | 540B | 稠密 | 2022 |
2.4 优点
| 优点 | 说明 |
|---|
| 计算简单 | 无需路由机制，实现简单 |
| 延迟稳定 | 每个 Token 的计算时间一致 |
| 训练稳定 | 梯度流动稳定，易于收敛 |
| 显存可预测 | 显存占用与参数量严格对应 |
| 工具支持好 | 所有框架都支持稠密模型 |
2.5 缺点
| 缺点 | 说明 |
|---|
| 扩展成本高 | 参数增加→计算量线性增加 |
| 效率瓶颈 | 大参数模型训练/推理成本高 |
| 能力上限 | 受限于计算资源，难以扩展到万亿参数 |
| 专业化弱 | 所有参数处理所有任务 |
2.6 适用场景
| 场景 | 说明 |
|---|
| 中小模型 | 参数量<100B 的场景 |
| 端侧部署 | 对延迟敏感的应用 |
| 资源受限 | 显存有限、算力有限的场景 |
| 简单任务 | 无需复杂专业化能力 |
三、稀疏模型
3.1 定义
稀疏模型（Sparse Model）是指对于每个输入 Token，只有部分参数参与计算的架构。
3.2 计算方式
输入 Token
↓
路由机制选择部分专家（Top-K）
↓
只有被选中的专家参与计算
↓
输出
总参数量 >> 激活参数量
3.3 核心思想
稀疏模型的核心思想是按需计算：
稠密模型：全员上岗（所有参数都工作）
稀疏模型：专家会诊（只调用相关专家）
[!比喻] 稀疏模型类比
就像去医院看病：
- 不需要所有科室的医生都来看你的病
- 只需要相关科室的专家会诊
- 这样效率更高，专业性更强
3.4 优点
| 优点 | 说明 |
|---|
| 高参数低计算 | 总参数量大，但计算量小 |
| 扩展性好 | 可以扩展到万亿参数 |
| 效率高 | 相同计算量下能力更强 |
| 专业化 | 不同专家可以学习不同领域 |
| 训练快 | 相同算力下可训练更大模型 |
3.5 缺点
| 缺点 | 说明 |
|---|
| 实现复杂 | 需要路由机制和专家并行 |
| 通信开销 | 专家分布在多卡上需要通信 |
| 负载不均 | 某些专家可能过载或闲置 |
| 训练不稳定 | 路由策略影响训练稳定性 |
| 推理延迟 | 可能略高于同计算量的稠密模型 |
3.6 适用场景
| 场景 | 说明 |
|---|
| 超大模型 | 参数量>100B 的场景 |
| 云端训练 | 有充足计算资源的场景 |
| 多领域任务 | 需要处理多种类型任务 |
| 效率优先 | 追求相同成本下能力更强 |
四、稠密 vs 稀疏对比
4.1 核心指标对比
| 指标 | 稠密模型 | 稀疏模型（MoE） |
|---|
| 参数激活 | 100% | 10-25% |
| 训练效率 | 中等 | 高（相同算力下） |
| 推理延迟 | 低且稳定 | 略高（通信开销） |
| 显存占用 | 高 | 高（需加载所有参数） |
| 扩展上限 | 百亿 - 千亿 | 万亿+ |
| 实现复杂度 | 低 | 高 |
| 专业化程度 | 低 | 高 |
4.2 性能对比
假设同样使用 1000 TFLOPS 计算资源：
稠密模型：
├─ 可支持 ~100B 参数模型
├─ 训练速度：中等
└─ 能力：100B 水平
稀疏模型：
├─ 可支持 ~1T+ 参数模型
├─ 训练速度：更快（相同算力下）
└─ 能力：接近 1T 水平
4.3 成本对比
| 成本类型 | 稠密模型 | 稀疏模型 |
|---|
| 训练成本 | 高（参数扩展成本高） | 中等（相同能力下更低） |
| 推理成本 | 中等（参数量固定） | 中等（激活参数少） |
| 显存成本 | 高 | 高（需加载全部参数） |
| 工程成本 | 低 | 高（需要专家并行） |
4.4 直观对比图
稠密模型（70B）：
┌─────────────────────────────────────┐
│ ████████████████████ 100% 激活 │
│ 所有参数都工作 │
└─────────────────────────────────────┘
稀疏模型（8x7B = 56B 总参数）：
┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐
│ ███│ │ │ │ │ │ │ ███│ ← 只激活 2 个专家
│ 专家 1 │ 专家 2 │ 专家 3 │ 专家 4 │ 专家 5 │ 专家 6 │ 专家 7 │ 专家 8 │
└─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┘
25% 激活（8 个专家中激活 2 个）
五、技术演进
5.1 从稠密到稀疏
2017-2020：稠密模型主导
├─ Transformer、BERT、GPT-2/3 都是稠密架构
└─ 参数量从 110M 增长到 175B
2021-2023：稀疏架构兴起
├─ Switch Transformer（1.6T 参数）
├─ GLaM（1.2T 参数）
└─ 证明 MoE 可以实现更大规模
2024-2025：稀疏架构主流化
├─ Mixtral 8x7B（开源 MoE 代表作）
├─ DeepSeek-V3/R1（国产 MoE 代表）
├─ Grok-1.5（314B MoE）
└─ 几乎所有超大模型都使用 MoE
5.2 2025-2026 年趋势
| 趋势 | 说明 |
|---|
| MoE 成为标配 | 超大模型普遍采用 MoE 架构 |
| 稠密仍有市场 | 中小模型、端侧场景仍用稠密 |
| 混合架构 | 部分层稠密、部分层稀疏 |
| 动态稀疏 | 根据任务动态调整激活参数 |
六、混合专家模型（MoE）
MoE 是稀疏架构的代表性实现，详细内容见 04-混合专家模型 MoE。
6.1 MoE 核心概念
| 概念 | 说明 |
|---|
| 专家网络（Expert） | 独立的神经网络模块，每个专家专门处理某类输入 |
| 路由网络（Router/Gating） | 决定哪些专家处理当前输入 |
| 稀疏度 | 激活专家数 / 总专家数 |
| Top-K | 每次选择 K 个最合适的专家 |
6.2 MoE 示例
Mixtral 8x7B：
├─ 总参数：约 47B
├─ 激活参数：约 13B（每次 2 个专家）
├─ 计算量：相当于 13B 稠密模型
└─ 能力：接近 47B 稠密模型
DeepSeek-V3：
├─ 总参数：671B
├─ 激活参数：37B
├─ 稀疏度：约 5.5%
└─ 能力：接近千亿美元级别模型
七、选择建议
7.1 何时选择稠密模型
| 场景 | 理由 |
|---|
| 参数量<70B | 稠密架构效率更高，实现简单 |
| 端侧部署 | 延迟要求高、资源有限 |
| 简单任务 | 无需复杂的专业化能力 |
| 快速原型 | 工具支持好，开发效率高 |
7.2 何时选择稀疏模型
| 场景 | 理由 |
|---|
| 参数量>100B | 稀疏架构扩展性更好 |
| 多领域任务 | 不同专家处理不同领域 |
| 云端训练 | 有充足计算资源 |
| 追求效率 | 相同成本下能力更强 |
八、总结
| 维度 | 稠密模型 | 稀疏模型 |
|---|
| 激活方式 | 全参数激活 | 部分参数激活 |
| 效率 | 中等 | 高（相同能力下） |
| 扩展性 | 有限 | 优秀 |
| 复杂度 | 低 | 高 |
| 代表架构 | 标准 Transformer | MoE |
| 适用场景 | 中小模型、端侧 | 超大模型、云端 |
核心结论：
- 稠密模型和稀疏模型各有优劣
- 2025 年趋势：超大模型普遍采用 MoE
- 选择取决于具体应用场景和资源约束
延伸阅读
| 更新日期 | 更新内容 |
|---|
| 2026-04-09 | 初始版本 |
| 2026-04-12 | 增加直观对比图、技术演进时间线、选择建议 |