Gemma 4 一口气放出了五个尺寸：E2B、E4B、12B Unified、26B A4B 和 31B。名字里的字母不是版本号，是三种不同的架构手段，直接决定了哪个变体适合你的机器。这篇把五个变体的架构差异、官方 benchmark、真实体积和显存占用摊开讲，最后给一份按显存分档的选型建议。只想知道自己的卡该选哪个，可以直接用文中的选择器或显存计算器。
体积数字全部是从 HuggingFace API 查到的真实文件字节数，benchmark 全部来自官方模型卡。显存占用那部分是我在一台 8G 显卡的笔记本上实测的，会标注清楚哪些是实测、哪些是外推。
名字里的字母各是什么意思
E = effective，有效参数
E2B 和 E4B 里的 E 指「有效参数」。这两个模型用了 PLE（Per-Layer Embeddings）：不是给模型加层或加宽，而是给每个解码层配一张自己的小 embedding 表，每个 token 在每层都能查到一份专属向量。
关键在于这些表只用于查表，不参与矩阵运算。所以官方给出两个参数量：E2B 是 2.3B 有效 / 5.1B 含 embedding，E4B 是 4.5B 有效 / 8B 含 embedding。计算量按有效参数走，存储按含 embedding 走。
这个设计的实际后果，会在后面「体积陷阱」一节变得非常具体——它既是 E 系列能在手机上跑的原因，也是它的量化版本大得离谱的原因。
Unified = 没有独立编码器
其他 Gemma 4 模型处理图片和音频时，要先过一个专门的编码器，再把结果送进语言模型。12B Unified 把这些编码器整个去掉了：图像 patch 和音频波形通过轻量线性层直接投影进 LLM 的 embedding 空间，所有模态汇进同一个 decoder-only transformer。
好处有两个：多模态延迟更低，以及整个模型可以一次性微调，不用分阶段处理编码器。代价是它没有独立编码器带来的那部分专用能力——不过从 benchmark 看，视觉指标并没有掉队。
顺带一提，这也解释了 12B 的多模态投影文件为什么特别小：其他变体的 mmproj 有 0.9 到 1.1 GiB，12B 只有 0.17 GiB，因为它本来就没有要单独加载的编码器。
A4B = 激活参数只有 4B
26B A4B 是这一代唯一的 MoE 模型：总参数 25.2B，但推理时只激活 3.8B。128 个专家里每次选 8 个，外加 1 个共享专家。
意思是它的速度接近一个 4B 模型，质量接近一个 26B 模型。官方的说法是「比稠密的 31B 快得多，跑起来几乎和 4B 一样」。代价是显存要按 25.2B 准备——专家权重全都得在显存里待命，你没法预测下一个 token 会路由到哪几个专家。
27B 和 32B 去哪了
从 Gemma 3 过来的人经常会找 27B——那是上一代的旗舰。Gemma 4 没有 27B，也没有 32B。官方仓库里能查到的 Gemma 4 尺寸标识只有五个：e2b、e4b、12b、26b-a4b、31b。
大致的对应关系是：上一代 27B 那个位置，这一代拆成了两个方向。想要吞吐就用 26B A4B（MoE，激活只有 3.8B，跑起来像 4B 模型）；想要最强质量就用 31B（稠密，60 层）。1B 和 4B 这两个小尺寸则被 E2B / E4B 取代，用 PLE 换来了更好的参数效率。
所以如果你在找「Gemma 4 27B」，要么是记成了上一代，要么你想要的其实是 26B A4B 或 31B 中的一个。
架构参数对照
| 属性 | E2B | E4B | 12B Unified | 26B A4B | 31B |
|---|---|---|---|---|---|
| 总参数 | 2.3B 有效 5.1B 含 embedding |
4.5B 有效 8B 含 embedding |
11.95B | 25.2B 总 3.8B 激活 |
30.7B |
| 层数 | 35 | 42 | 48 | 30 | 60 |
| 滑动窗口 | 512 | 512 | 1024 | 1024 | 1024 |
| 上下文 | 128K | 128K | 256K | 256K | 256K |
| 词表 | 262K | 262K | 262K | 262K | 262K |
| 模态 | 文本 / 图像 / 音频 | 文本 / 图像 / 音频 | 文本 / 图像 / 音频 | 文本 / 图像 | 文本 / 图像 |
| 视觉编码器 | 约 150M | 约 150M | 无（Unified） | 约 550M | 约 550M |
| 音频编码器 | 约 300M | 约 300M | 无（Unified） | 不支持 | 不支持 |
有两行值得单独拎出来。
音频只有 E2B、E4B、12B 支持。这条经常被忽略：如果你的场景涉及语音转写或语音翻译，26B 和 31B 直接出局，哪怕你显存够。也就是说，「想要音频 + 想要最强性能」这个组合的上限是 12B Unified，往上没有选项。
滑动窗口 512 vs 1024。E 系列的窗口只有一半，加上部分层直接共享上层的 KV，这两点合起来让 E 系列的 KV cache 增长极慢。实测 E4B 从 8K 开到 128K 上下文，KV 只涨了约 1.1 GB。同尺寸没有这些设计的模型，涨幅是好几倍。长上下文场景下这是个被低估的优势。
官方 benchmark
以下数字来自官方模型卡，均为指令微调版本。最后一列是上一代 Gemma 3 27B（关闭思考）作为参照。
| 基准 | 31B | 26B A4B | 12B Unified | E4B | E2B | Gemma 3 27B |
|---|---|---|---|---|---|---|
| MMLU Pro | 85.2% | 82.6% | 77.2% | 69.4% | 60.0% | 67.6% |
| AIME 2026（无工具） | 89.2% | 88.3% | 77.5% | 42.5% | 37.5% | 20.8% |
| LiveCodeBench v6 | 80.0% | 77.1% | 72.0% | 52.0% | 44.0% | 29.1% |
| Codeforces ELO | 2150 | 1718 | 1659 | 940 | 633 | 110 |
| GPQA Diamond | 84.3% | 82.3% | 78.8% | 58.6% | 43.4% | 42.4% |
| Tau2（三次平均） | 76.9% | 68.2% | 69.0% | 42.2% | 24.5% | 16.2% |
| BigBench Extra Hard | 74.4% | 64.8% | 53.0% | 33.1% | 21.9% | 19.3% |
| MMMLU（多语言） | 88.4% | 86.3% | 83.4% | 76.6% | 67.4% | 70.7% |
| MMMU Pro（视觉） | 76.9% | 73.8% | 69.1% | 52.6% | 44.2% | 49.7% |
| MATH-Vision | 85.6% | 82.4% | 79.7% | 59.5% | 52.4% | 46.0% |
| MRCR v2 128K 长上下文 | 66.4% | 44.1% | 43.4% | 25.4% | 19.1% | 13.5% |
断层在哪
把这张表按「哪一档掉得最狠」重读一遍，比看绝对分数有用。
推理类任务在 12B 和 E4B 之间有一道悬崖。AIME 从 77.5% 掉到 42.5%，Codeforces ELO 从 1659 掉到 940，BigBench Extra Hard 从 53.0% 掉到 33.1%。这不是渐变，是断崖。多步推理需要模型在长链条上保持一致，这个能力对规模的依赖远比知识检索强。所以如果你的任务是解数学题、写有一定复杂度的代码、或者跑多步 agent，E 系列基本不在候选范围内——不管你多想省显存。
知识和多语言类任务的坡度平缓得多。MMLU Pro 从 77.2% 到 69.4%，MMMLU 从 83.4% 到 76.6%。翻译、摘要、分类、问答改写这类任务，E4B 的表现是可用的。我自己把 E4B 接进沉浸式翻译做网页翻译，日常读英文资料完全够。
E4B 全面超过上一代 27B，但不是每一项。AIME 42.5% vs 20.8%、Codeforces 940 vs 110，进步巨大。但 MMLU Pro 是 69.4% vs 67.6%，MMMLU 甚至是 76.6% vs 70.7%——知识面上的领先没有推理上那么夸张。一个 4.5B 有效参数的模型在推理上碾压上一代 27B，主要归功于训练方法而不是架构。
26B A4B 是性价比最高的一档。MMLU Pro 82.6%、AIME 88.3%，离 31B 只差一点，但推理速度接近 4B 模型。它明显掉队的只有两处：长上下文（MRCR 44.1% vs 66.4%）和 HLE（8.7% vs 19.5%）。前者说明 MoE 在超长上下文上的检索一致性还是弱于稠密模型，后者是极难题的天花板差距。日常任务里这两项都不常触及。
体积陷阱：参数量算不出显存
这是选型时最容易翻车的地方。我第一次做选型表就是按「参数量 × 位宽」估的，结果整张表都是错的。
下面是从 HuggingFace API 查到的真实权重文件总字节数，换算成 GiB：
| 变体 | bf16 | QAT W4A16 | q4_0 GGUF | mmproj |
|---|---|---|---|---|
| E2B | 9.54 | 7.75 | 3.12 | 0.92 |
| E4B | 14.89 | 10.72 | 4.80 | 0.92 |
| 12B Unified | 22.28 | 9.56 | 6.50 | 0.17 |
| 26B A4B | 48.07 | — | 13.45 | 1.11 |
| 31B | 58.25 | 21.67 | 16.44 | 1.12 |
盯着 QAT 那一列看。E4B 的 W4A16 是 10.72 GiB，而参数量是它三倍的 12B Unified 只有 9.56 GiB。如果你按「参数少的一定更小」去选，会挑到一个又大又弱的模型。
原因在 QAT 检查点的配置里写得很清楚：
{
"quantization_config": {
"config_groups": {
"group_0": {
"targets": ["Linear"]
}
}
}
}targets: ["Linear"]——只量化线性层，embedding 层原封不动保持 bf16。对普通模型这没什么，embedding 占比不高。但 E 系列的 PLE 表本身就有 2.8B 参数（E4B），这一大块完全没被压缩，直接把量化后的体积撑了上去。
GGUF 的 q4_0 就没这个问题，它连 embedding 一起量化，E4B 降到 4.80 GiB。这也是为什么小显存机器上应该走 GGUF + llama.cpp，而不是 QAT 权重 + vLLM。
顺带说清楚一件事：vLLM 不是「更好的引擎」，它是给显存充裕的机器准备的。它的优势在批处理吞吐和并发调度，不在体积。单人自用、显存紧张的场景，llama.cpp 是更合适的选择。
GGUF 的文件体积也不等于显存占用
还有一层。E4B 的 q4_0 文件是 4.80 GiB，但实际进显存的只有 2.2 GiB 左右。
因为 llama.cpp 把 PLE 表和 token embedding 留在了系统内存里。这两块加起来是：
PLE 表 = 词表 262144 × 层数 42 × PLE 维度 256 = 2.82B 参数
token embd = 词表 262144 × hidden 2560 = 0.67B 参数
合计 3.49B 参数，在 GGUF 里约占 2.6 GiBPLE 表本来就只用于查表，放在内存里按需读取完全合理——GPU 不需要拿它做矩阵乘法。但结果是：如果你按 GGUF 文件大小去估显存，会凭空多算 2.6 GB。在一张 8G 卡上，这足以让 E4B 被误判成跑不了，而实际上它跑得很轻松。
我在一台 8G 显存的笔记本上实测过 E4B q4_0（llama.cpp Vulkan 后端，KV cache 量化到 q8_0）：
| 上下文 | 实测显存 | 说明 |
|---|---|---|
| 8K | 2.90 GiB | 纯文本，未加载 mmproj |
| 32K | 4.25 GiB | 含 mmproj |
| 64K | 4.54 GiB | 含 mmproj |
| 128K | 5.14 GiB | 含 mmproj，满上下文 |
128K 满上下文加图片输入，一张 8G 卡还剩接近 3 GB 余量。吞吐是 63 到 66 tok/s。这个结果和「E4B 的量化版本有 10.72 GiB」形成的直觉落差，正是这一节想说明的问题。
按显存怎么选
把上面的数字合起来，得到这样一份分档建议。假设用 q4_0 GGUF + llama.cpp，KV 量化到 q8_0，留出显示输出占用：
| 显存 | 建议 | 理由 |
|---|---|---|
| 4 GB | E4B（上下文压到 64K） | 扣掉 PLE 后上卡权重只有 2.16 GiB，比想象中能塞。想要更多余量再退回 E2B。 |
| 6 GB | E4B | 能开满 128K。翻译、摘要、日常问答够用，别指望它解数学题。 |
| 8 GB | E4B + 图片输入 | 实测 128K 满上下文加 mmproj 共 5.14 GiB，还剩近 3 GB。吞吐 63–66 tok/s。 |
| 12 GB | 12B Unified | q4_0 权重 6.50 GiB，能开到 32K。这是推理能力断崖的上沿，也是支持音频的最强变体。 |
| 16 GB | 12B Unified（可上 W4A16） | 能开到 64K。26B A4B 在这一档只是勉强装下，上下文要压到 8K，不划算。 |
| 24 GB | 26B A4B | q4_0 权重 13.45 GiB，能开满 128K。MoE 的吞吐优势从这一档开始真正发挥。 |
| 32 GB | 31B | q4_0 权重 16.44 GiB，能开到 64K。追求最强推理和长上下文一致性时选它。 |
| 48 GB+ | 31B W4A16 | 不必再靠 4bit 压体积，上下文能开到 128K 以上。 |
这些是粗略分档。具体到你的卡、你想要的上下文长度和并发数，可以直接用下面的选择器或显存计算器算——两者用的是同一个估算器，把上面所有的体积数字、PLE 扣减和 KV cache 结构都编了进去，公式拿这四个实测点校准过。选择器推荐的是留出余量后能装下的最强变体，默认按 16K 上下文算；上表每档按各自注明的上下文长度给建议，还考虑了吞吐（比如 24 GB 档选 MoE），所以个别档位的结论会不一样。
按单卡、每卡已被占用 0.3 GB、KV cache 量化到 q8_0、不加载图片投影（mmproj）计算，和完整计算器的默认设置一样。推荐规则也相同：先选留得出余量（「装得下」）的最强变体，再在这个变体里选体积最大的格式。多卡、图片输入和每种格式的逐行拆解在完整计算器里。
三个不在 benchmark 里的实用细节
E2B 和 E4B 关不掉思考模式。官方模型卡写得很直白：除 E2B 和 E4B 外的所有模型，关闭思考后仍会生成标签但思考块为空。E 系列不吃这一套。如果你要接沉浸式翻译这类对延迟敏感、且不需要推理过程的场景，得在 API 层做处理，靠 chat_template_kwargs 传 enable_thinking: false，而不是指望模型自己收敛。
滑动窗口模型必须开 flash attention。不开的话 prompt 处理速度会掉到个位数——我实测过一次 39.6 tok/s 的 prompt processing，加上 --flash-attn on 之后才恢复正常。这不是可选优化，是必需项。
llama.cpp 的 --ctx-size 是总量，要除以 --parallel。默认 parallel 是 4，所以写 --ctx-size 16384 实际每路只有 4096。想要每路 16K 就得写 65536，KV cache 也会按 65536 分配。这个默认值坑过不少人。
小结
五个变体的定位其实相当清晰：E2B/E4B 是边缘设备和小显存的选项，能做语言任务但推理能力有硬上限；12B Unified 是推理能力的起跳点，也是支持音频的天花板；26B A4B 用 MoE 换来了接近 31B 的质量和接近 4B 的速度，是消费级显卡上性价比最高的一档；31B 在长上下文一致性和极难推理上仍有不可替代的领先。
选型时真正容易出错的不是性能判断，而是体积判断。参数量算不出显存，量化格式的体积经常和直觉相反，GGUF 的文件大小也不等于显存占用。这三层认知差每一层都能让人选错模型——第一层让你以为小模型一定省显存，第二层让你在 E4B 和 12B 之间选反，第三层让你以为 8G 卡跑不了 E4B。
所以查真实字节数，然后实测。
延伸阅读
- 显存计算器：输入显存和上下文长度，直接算出每个变体的权重、KV cache 和运行开销拆解。
- 本地部署大模型第一步：按显存选对模型和推理引擎并跑起来：从
nvidia-smi到 systemd 服务的完整操作步骤。 - 自建 Gemma 4 网关：实跑才会撞上的坑：部署过程中真实踩到的问题记录。