B、GGUF、MTP、A3B、E4B：模型名里这五个字符，说的不是一件事

先说一个结论，能省掉后面一半的困惑：这五个东西根本不在同一个维度上。B 是量词，A3B 和 E4B 是「哪一种量」，GGUF 是容器，MTP 是插件。把它们并排念出来像一串参数，实际上它们各自回答一个完全不同的问题。

具体分工是这样的：B 回答「多大」，A3B 回答「多少在干活」，E4B 回答「多少真的占内存」，GGUF 回答「用什么装」，MTP 回答「怎么加速」。一个文件名里同时出现四五个，是因为它们确实需要同时被表达——但混淆往往发生在把它们当成同一类信息的时候。

一、B：只是「十亿」这个单位

B 是 Billion，十亿。7B 就是 70 亿参数，235B 就是 2350 亿。它跟 GGUF 的命名规范里的量级前缀是一套东西：K 千、M 百万、B 十亿、T 万亿、Q 千万亿。

看起来最简单的一个，其实藏着三种完全不同的含义。这是全文最该先讲清的一件事：

写法	含义	决定什么
30B	总参数：全部权重	装不装得下（磁盘、显存）
30B-A3B	总参数 30B，单次激活 3B	算得多快、多贵
E4B	有效参数：运行时实际驻留的	能不能跑在手机上

这三行如果混着看，就会得出「30B 模型能在手机上跑」这种结论。它可能没错，但和你以为的那个 30B 不是一回事。

二、A3B：总参数和激活参数不是一回事

这个写法来自 MoE（Mixture of Experts，混合专家）。Qwen3 那批模型的命名把话说得很明白，官方博客的原话是：Qwen3-235B-A22B 是「2350 亿总参数、220 亿激活参数」的大模型，Qwen3-30B-A3B 是「300 亿总参数、30 亿激活参数」的小 MoE。

技术细节也很具体：30B-A3B 有 48 层，Q/KV 头数 32/4，128 个专家里每次激活 8 个，上下文 128K。235B-A22B 是 94 层，64/4 头，同样是 128 个专家激活 8 个。

所以 A3B 这个标记的实际意思是：显存按 30B 算，速度按 3B 算。

这就是 MoE 的全部诱惑，也是全部误解来源——你省的是算力，不是内存。很多人看到 A3B 就以为这是个 3B 模型，装到只有 4GB 显存的机器上，然后发现根本加载不了。权重一个都没少，只是每次前向计算不全部参与。

顺带一个容易忽略的写法：GGUF 的 SizeLabel 规范是 <expertCount>x<count><scale-prefix>，所以 8x7B 这种写法是「8 个专家 × 7B」，总共 56B。那个 x 不是乘号省略，就是乘号。Mixtral-8x7B 常被误读成「7B 模型」，实际总参数是 56B。

三、E4B：E 是 effective，不是「更小」

这个是最容易彻底误读的一个。Gemma 3n 的文档写得很清楚：

Gemma 3n 模型的参数标记（如 E2B、E4B）低于模型实际包含的总参数量。E 前缀表示这些模型可以用一组「更少的有效参数」来运行。

具体到什么程度？文档给了数字：E2B 标准执行时要加载 50 亿以上参数，靠参数跳过和 PLE 缓存，可以把有效内存负载压到 1.91B。

注意这句话的主语：模型本身没变小，是「运行时的驻留量」变小了。

靠两个机制实现：

• PLE 缓存（Per-Layer Embedding）。每层嵌入参数可以在模型内存之外单独生成、缓存到快速本地存储，运行时逐层加进去。等于把这部分参数请出了内存。
• MatFormer（套娃 Transformer）。一个大模型内部嵌套了若干小模型，小模型推理时不需要激活外层参数。所以能在 2B 到 4B 之间取任意中间档。

这就引出一个反直觉的事实：E4B 里包含 E2B 的全部参数。不是两个独立模型，是同一个弹性模型的两个档位。所以准确的说法不是「E4B 是个 4B 的小模型」，而是「E4B 是个最大能开到 4B 的弹性模型」。

这条对判断「能不能跑在我的设备上」影响很大：E4B 在低配设备上可以按 E2B 的方式跑，在高配设备上才展开到 4B。而 A3B 没有这个弹性——它就是 30B，只是算得省。

四、GGUF：它不是模型，是装模型的盒子

前面三个是「模型多大」，从 GGUF 开始换了一个维度：这是文件格式。准确说，GGUF 是给 GGML 及其执行器（llama.cpp 这一系）用的模型存储格式。

它取代的是 GGML、GGMF、GGJT 三代格式。官方的设计目标有四条，每一条都对应一个过去的痛点：

设计目标	解决什么
单文件部署	不需要额外文件补信息，直接分发和加载
可扩展	加新元数据不破坏旧模型的兼容性
mmap 兼容	内存映射加载，快
信息完整	加载所需的一切都在文件里，用户不用另外提供

它和上一代 GGJT 的关键差别只有一句话，但很关键：超参数从「无类型的数值列表」改成了键值对元数据。这一步让「加字段不破兼容」成为可能——以前加一个字段，所有旧解析器都得改。

文件名是怎么拼出来的

官方给的命名规范是：

[].gguf

拿一个真实例子拆开看：

mtp-Qwen3-27B-v1.0-Q4_K_M.gguf

• mtp- → Sidecar（旁挂模块，见下一节）
• Qwen3 → BaseName（基础模型名）
• 27B → SizeLabel（参数档位）
• v1.0 → Version（版本）
• Q4_K_M → Encoding（权重编码 / 量化方式）

还有两个不常出现的组件值得知道：

• Type：LoRA 表示这是个适配器，不是完整模型；vocab 表示词表文件。
• Shard：00003-of-00009 表示分片，第 3 片共 9 片。注意编号从 00001 开始，不是 00000。

规范里还有一句很重要的免责声明：这个命名约定「不打算在野外做到完全可解析」，因为现存的 gguf 文件名实在太杂。所以别写正则去猜文件名里的信息，读元数据。文件里的 general.basename、general.size_label、general.finetune 才是权威。

五、Q4_K_M：文件名里最长的那段，是压缩率

这是实践中最影响你体验的一段，也是最没人讲清楚的一段。它表示权重被量化成了多少位。

llama.cpp 官方 README 拿 Llama-3.1-8B 做了一张实测表，我挑几档抄下来（原始模型 32.1 GB）：

量化方式	bits/weight	文件大小	生成速度
IQ1_S	2.00	1.87 GiB	79.7 t/s
Q2_K	3.16	2.95 GiB	79.9 t/s
Q3_K_M	4.00	3.74 GiB	71.7 t/s
Q4_K_M	4.89	4.58 GiB	71.9 t/s
Q5_K_M	5.70	5.33 GiB	67.2 t/s
Q8_0	8.50	7.95 GiB	50.9 t/s
F16	16.00	14.96 GiB	29.2 t/s

Q4_K_M 成为社区默认档，理由全在这张表里：4.89 位/权重，体积压到 F16 的 30%，速度还快 2.4 倍。往上到 Q8_0，体积翻倍、速度掉三成，换来的质量提升大多数人感知不到；往下到 IQ1_S，体积只省一点，质量风险大得多。

名字怎么读

• Q = 常规量化（Quantization）；IQ = 重要性矩阵量化（i-quant），同位数下质量更好、速度略慢。
• 数字 = 目标位数。Q4 是 4 位，Q8 是 8 位。
• _K = k-quant，分块量化（block-wise），比老的 _0 / _1 系列更细。
• _S / _M / L = small / medium / large，混合精度档。M 会挑一部分敏感张量保高精度，所以同为 Q4，K_M 比 K_S 略大也略好。

还有一个很多人不知道的事实：量化可以逐张量定制。官方工具支持按张量名指定不同类型，比如把 attn_v 和 ffn_down 单独设成 Q5_K_M，其余保持 Q4_K_M；也支持用正则按层号批量设置。这就是为什么同一个「Q4_K_M」，不同人压出来的文件大小会不一样——它是一套默认策略，不是一个精确规格。

六、MTP：一个「猜下一个词」的小模块

最后这个最容易被当成模型特性，其实它是文件角色标记。GGUF 文档里把 mtp 定义为 Sidecar（旁挂模块），说明是：

Multi-Token Prediction heads（多 token 预测头），投机解码的草稿模块，设计上要与架构和版本匹配的基础模型一起加载。

它干的事很简单：先猜出后面好几个 token，再让主模型一次性并行验证。猜对的直接采纳，猜错的丢弃重来。因为验证一次前向能确认多个 token，平均下来每个 token 的耗时下降——这就是投机解码（speculative decoding）的全部原理。

但文档里紧接着有一句话，是这一节最该记住的：「MTP 权重经常被直接打包进基础模型里，这种情况下就没有单独的 mtp- 旁挂文件。」

所以正确的理解是：看到 mtp- 前缀，说明它是外挂的；没看到，不代表没有。这也是为什么在模型列表里找 MTP 常常找不到——它已经在主文件里了。

另一个 Sidecar 是 mmproj（multimodal projector，多模态投影器），视觉和音频的编码器加投影层。这个通常是独立文件，必须和基础模型配对加载。所以如果你下了一个多模态模型的 GGUF 却发现不能看图，八成是漏了 mmproj 那个文件。

七、五个字符的完整读法

把上面所有内容压成一次完整的读法。假设你看到这个文件名：

mtp-Qwen3-30B-A3B-v1.0-Q4_K_M.gguf

片段	属于哪一层	说明
mtp-	文件角色	旁挂的投机解码模块，需与主模型配对
Qwen3	模型身份	基础模型名
30B	规模	总参数 300 亿 → 决定装不装得下
A3B	计算	每次激活 30 亿 → 决定跑多快
v1.0	版本	权重版本
Q4_K_M	存储	4.89 位/权重，中等混合精度
.gguf	容器	给 llama.cpp 这一系用的格式

一句话总结这个文件：一个总参数 300 亿、每次算 30 亿的 MoE 模型，被压到约 4.9 位存进 GGUF 容器，另外附带一个投机解码加速模块。

八、四个最常见的误读

1. 把 A3B 当成 3B 模型。省的是算力不是内存。30B 的权重一个都没少，4GB 显存照样装不下。
2. 把 E4B 当成「4B 小模型」。它是弹性模型的最大档，E4B 里包含 E2B 的全部参数。低配设备上它按 2B 跑，不是按 4B 跑。
3. 把 GGUF 当成模型。同一个模型可以有 F16、Q8_0、Q4_K_M 好几个 GGUF。GGUF 是容器，量化是内容。问「Q4 和 GGUF 哪个好」等于问「瓶子和水哪个好」。
4. 以为文件名能精确解析。官方明说这个约定不追求完全可解析。要准确信息就读文件元数据，别写正则。

还有一个隐藏的第五个：把 8x7B 读成 7B。那是「8 个专家各 7B」，总共 56B。GGUF 规范里 <expertCount>x<count> 的那个 x 就是乘号。

九、实用判断顺序

最后给一个可以照着走的顺序。看任何一个模型名，按这个次序问自己：

1. 先看容器和量化。.gguf + Q4_K_M 意味着这是本地跑的量产版本，质量和体积已经在出厂时定好了。
2. 再看总参数。决定你的显存/内存够不够。这条是硬门槛，不够就是跑不了。
3. 再看是不是 MoE。有 A??B 说明速度按激活参数算，但内存仍按总参数算。
4. 再看有没有 E 前缀。有 E 说明这是个弹性模型，实际驻留量可能远低于标称值——这条决定了它能不能进手机。
5. 最后看 Sidecar。有 mmproj- 记得一起下；有 mtp- 记得配对；都没有也不代表没有加速能力。

模型名不是参数表，是一份标签。标签的作用是让你少下一次错的文件，不是让你算出它的分数。

真正决定「这个模型在我这儿表现如何」的，永远是跑一遍。但把标签读对，至少能让你在下载 15GB 之前就知道它装不装得下——这件事省下来的时间，比任何基准分数都实在。