反直觉真相：35B A3B 模型为什么比 12B Dense 模型跑得还快？

引言

这听起来像是在说谎：参数多了近 3 倍，推理速度反而更快？

在 llama.cpp 上实测数据：

35B 比 12B 快了 50%，这是怎么做到的？

一、理解 MoE（混合专家模型）

Dense 模型的局限

传统 Dense（密集）模型：每个 token 激活所有参数。

输入 → [FFFFFFFFFFFFFFFF] → 输出
       ↑ 全部 12B 参数都参与

无论问题多简单，12B 参数全部参与计算。

MoE 的核心思想

MoE（Mixture of Experts）将模型拆成多个”专家”子网络，每个 token 只激活其中几个：

输入 → [选路器 Router]
       ├── Expert 1  ✅ 激活
       ├── Expert 2  ❌ 休眠
       ├── Expert 3  ❌ 休眠
       ├── Expert 4  ✅ 激活
       └── ...       ❌ 休眠
         [仅 2/8 专家参与计算]

Qwen3.6-35B-A3B 结构解析：

• 总参数量：35B（看起来很大）
• 激活参数量：3B（实际参与计算的）
• 专家数量：64 个
• 每次激活：8 个专家（Top-8 routing）
• 激活率：8/64 = 12.5%

二、速度对比分析

计算量公式

推理速度 ≈ 激活参数量 × 计算效率

每步计算量（FLOPs）

12B Dense:   12B × 2 × seq_len  → 每步算满 12B
35B A3B:     3B  × 2 × seq_len  → 每步只算 3B

A3B 的计算量只有 12B Dense 的 1/4！

实测数据对比

为什么显存多、速度反而快？

这里需要区分 存储带宽瓶颈 和 计算瓶颈：

• 显存主要用于存储完整参数：35B 的总参数当然比 12B 多，所以显存占用更大
• 计算只涉及激活参数：每次推理只用 3B 参数做计算
• Q3_K 量化加持：35B 压缩到 17GB，参数量虽然大但传输效率高

对于 llama.cpp 来说，推理速度主要受计算量（激活参数）影响，而不是总参数大小。

三、A3B 的架构细节

Qwen3.6-35B-A3B 命名含义

Qwen3.6 - 35B - A3B
 ↑           ↑     ↑
 版本      总参数  激活参数

• 总参数 35B：存储量大，决定了显存需求
• 激活参数 3B：计算量小，决定了推理速度
• A = Activated（激活），精准描述了 MoE 特性

对比其他 MoE 模型

Qwen3.6-35B-A3B 的激活率极低（8.6%），所以速度极快。

四、更大的视野：MoE 的独特价值

MoE 的”大力出奇迹”机制

MoE 模型能做到 总参数大 + 激活参数小 的反直觉组合：

• ✅ 总参数大 → 模型容量大、知识丰富、能力天花板高
• ✅ 激活参数小 → 推理快、成本低

就像一座图书馆：

• 总馆藏（35B）：决定知识量的上限
• 每次借阅（3B）：决定找书的速度

质量对比：35B A3B vs 12B Dense

实践中发现，35B A3B 不仅在速度上胜出，输出质量也明显更好：

• 逻辑推理更严谨
• 多轮对话记忆更准确
• 对复杂指令理解更到位

这是因为总参数 35B 提供了更大的”知识容量”。

五、适用场景建议

推荐使用 A3B（35B）当…

• ✅ 有 20GB+ 显存
• ✅ 追求推理速度 + 质量
• ✅ 单用户交互场景

推荐使用 Dense（12B/9B）当…

• ✅ 显存有限（<12GB）
• ✅ 高并发生产环境（Dense 更易部署）
• ✅ 对延迟不敏感但要求吞吐量

总结

35B A3B 比 12B Dense 更快 并非魔法，而是 MoE 架构的必然结果：

1. MoE 仅激活小部分参数（3B vs 12B），计算量只有 1/4
2. 总参数量大不影响推理速度，只影响显存
3. Q3_K 量化让 35B 模型在 20GB 显存上运行成为可能
4. 速度更快的同时，质量反而更高

一句话：MoE 模型用”总参数换容量、激活参数换速度”，实现了速度和质量的兼顾，是大模型工程化的重要方向。