Gemma 4 在大模型端给了两个选择：26B MoE（混合专家）和 31B Dense（稠密）。这两个模型工作方式完全不同，选哪个取决于你看重什么。来拆解一下。
MoE 是什么？简单说
26B MoE 模型有 260 亿个参数，但重点是——它不会同时用所有参数。它有多个「专家」子网络，一个路由机制会针对每个 token 选择激活哪些专家。每次实际只有约 38 亿参数在干活。
打个比方：一家医院有 20 个专科医生。病人来了不会 20 个医生都看一遍，而是根据病情分到 2-3 个相关科室。医院有 20 个医生的知识量，但每次就诊只用到一小部分人力。
MoE 26B 架构：
┌─────────────────────────────┐
│ 路由器："用哪些专家？" │
├──────┬──────┬──────┬───────┤
│ 专家1 │ 专家2 │ 专家3 │ ... │ ← 总计 26B 参数
├──────┴──────┴──────┴───────┤
│ 每个 token 只激活 ~3.8B │ ← 实际计算量
└─────────────────────────────┘Dense 是什么？
31B Dense 就很直接——所有 310 亿参数对每一个 token 都全部激活。没有路由，没有专家，一个大网络干所有事。
Dense 31B 架构：
┌─────────────────────────────┐
│ 每个 token 都用全部 31B 参数 │ ← 全量计算
└─────────────────────────────┘正面对比
| 指标 | 26B MoE | 31B Dense |
|---|---|---|
| 总参数量 | 26B | 31B |
| 激活参数量 | ~3.8B | 31B |
| 显存 (FP16) | ~52 GB | ~62 GB |
| 显存 (Q4_K_M) | ~15 GB | ~18 GB |
| 速度 (tok/s, RTX 4090) | ~45 | ~18 |
| 速度 (tok/s, M3 Max 36GB) | ~25 | ~10 |
基准测试对比
| 测试 | 26B MoE | 31B Dense | 赢家 |
|---|---|---|---|
| MMLU | 79.5 | 81.3 | Dense (+1.8) |
| HumanEval | 75.2 | 77.1 | Dense (+1.9) |
| GSM8K | 87.0 | 88.9 | Dense (+1.9) |
| MATH | 52.1 | 54.8 | Dense (+2.7) |
| ARC-Challenge | 68.3 | 69.1 | Dense (+0.8) |
| 平均 | 72.4 | 74.2 | Dense (+1.8) |
Dense 模型在纯质量上全面胜出，但差距不大——通常 1-3 分。问题是这个小质量优势值不值那么大的速度差距。
速度对比
MoE 的亮点在这里。每个 token 只激活 3.8B 参数，推理速度快得多：
| 硬件 | 26B MoE Q4 (tok/s) | 31B Dense Q4 (tok/s) | MoE 加速 |
|---|---|---|---|
| RTX 4090 24GB | ~45 | ~18 | 2.5 倍 |
| RTX 3090 24GB | ~30 | ~12 | 2.5 倍 |
| M3 Max 36GB | ~25 | ~10 | 2.5 倍 |
| M4 Max 48GB | ~32 | ~14 | 2.3 倍 |
MoE 稳定快 2-2.5 倍。对需要等回复的交互场景来说，这个差距体感非常明显。
显存对比
MoE 有个需要注意的地方——虽然只激活 3.8B 参数，但 26B 全部要加载到内存：
| 格式 | 26B MoE | 31B Dense | 差距 |
|---|---|---|---|
| FP16 | ~52 GB | ~62 GB | MoE 省 ~10 GB |
| Q8_0 | ~28 GB | ~33 GB | MoE 省 ~5 GB |
| Q5_K_M | ~19 GB | ~22 GB | MoE 省 ~3 GB |
| Q4_K_M | ~15 GB | ~18 GB | MoE 省 ~3 GB |
MoE 在每个量化级别都比 Dense 省显存，但省的幅度没有速度差距那么夸张。全精度下两个模型都需要很强的硬件。
使用场景推荐
选 26B MoE 的情况：
- 交互式聊天和编程辅助——2.5 倍的速度让对话更自然流畅
- API 服务多用户请求——更快的推理意味着更高的吞吐和更低的单次成本
- 硬件是瓶颈——显存占用更少，跑得更快
- 质量够用就行——大部分实际任务中 1-2 分的基准差距根本感觉不到
- 消费级硬件——Q4 MoE 在 16GB 显卡上真的能用
选 31B Dense 的情况：
- 微调——Dense 模型微调比 MoE 简单直接，不用处理专家路由的复杂性
- 高难度任务求极致质量——数学、推理、代码生成需要每一分的时候
- 批量处理——离线处理不在乎单 token 速度
- 研究和评估——需要绝对最优基线的时候
- 部署简单——Dense 模型框架支持更广，边角案例更少
快速决策表
| 你最看重的 | 选择 |
|---|---|
| 速度 | 26B MoE |
| 质量 | 31B Dense |
| 性价比 | 26B MoE |
| 微调 | 31B Dense |
| 交互使用 | 26B MoE |
| 离线批处理 | 31B Dense |
框架支持
不是所有框架都能完美处理 MoE 模型：
| 框架 | MoE 支持 | Dense 支持 |
|---|---|---|
| Ollama | 支持 | 支持 |
| llama.cpp | 支持 | 支持 |
| vLLM | 支持 | 支持 |
| SGLang | 支持 | 支持 |
| LM Studio | 部分支持 | 支持 |
| TensorRT-LLM | 支持 | 支持 |
| transformers | 支持 | 支持 |
MoE 的支持已经比较成熟了，但如果某个框架遇到问题，Dense 是更保险的选择。
下一步
- 还在纠结模型大小？ 看 Gemma 4 模型选择指南 了解包括小模型在内的完整阵容
- 想了解量化选项？ 看 GGUF 指南 有 Q4/Q5/Q8 的详细对比
- 准备跑了？ 跟着 Ollama 教程 几分钟就能跑起来
对大部分人来说，26B MoE 是更好的选择。快 2.5 倍，质量只差一点点。31B Dense 留给微调或者确实需要极致质量而且等得起的场景。
