Ollama 上 qwen3.8 的十二个标签：默认拉到的是哪一个
ollama pull qwen3.8 敲下去，你拉到的到底是哪个版本？
多数人不会追问这件事，直到某天发现自己跑的模型和同事的不一样。Ollama 官方库里 qwen3.8 挂着十二个标签，精度从 4 位量化到 bf16，还有几个面向特定硬件的变体。而默认那个 latest，指向的可能不是你以为的那份。
这篇把这十二个标签摊开对照。
这篇的依据
数据来自 Ollama 官方库 qwen3.8 的 tags 页面，采集时间 2026-08-24。
我们没有 pull 过任何一个标签、没有运行过这个模型。 下面的 digest 和体积都是页面上标注的值，你可以自己打开那个页面核对。标签列表会随时间变化，你读到时可能已经增减。
另外先声明一条：体积是模型文件大小，不是显存需求。 这两者的关系见 要多少显存，本文只谈文件。
十二个标签的完整对照
按 digest 分组排列：
| 标签 | digest 前缀 | 体积 |
|---|---|---|
latest | 22130167c4c2 | 18GB |
27b | 22130167c4c2 | 18GB |
27b-mtp-q4_K_M | 22130167c4c2 | 18GB |
27b-mlx | 5642e97495e1 | 18GB |
27b-nvfp4 | 5642e97495e1 | 18GB |
27b-q4_K_M | 25b843619e94 | 18GB |
27b-mtp-q8_0 | 8a1582877303 | 30GB |
27b-q8_0 | 8f5fb6b71ea0 | 30GB |
27b-mxfp8 | 464021588235 | 32GB |
27b-mtp-bf16 | 197257101a8c | 56GB |
27b-bf16 | 1aa85dae8b2d | 56GB |
27b-mlx-bf16 | 65e5e1c72d2d | 56GB |
十二个标签，八个不同的 digest。 所有标签的上下文都标着 256K。
发现一：默认拉到的是带 MTP 的版本
第一组三个标签的 digest 完全相同：
latest = 27b = 27b-mtp-q4_K_M → 22130167c4c2
latest 和 27b 是别名，这不奇怪——这个模型只有 27B 一个尺寸，所以两者指向同一份很自然。
值得注意的是第三个。 默认版本同时也是 27b-mtp-q4_K_M 这个标签，意味着 ollama pull qwen3.8 拉到的是带 MTP 的 4 位量化版本。
而列表里另有一个 27b-q4_K_M（digest 25b843619e94），同样是 18GB，但digest 不同——那是不带 MTP 的版本。
也就是说：27b-q4_K_M 和 27b-mtp-q4_K_M 是两份不同的内容，而默认给你的是后者。如果你想要不带 MTP 的那份，必须显式写全标签名，光写 qwen3.8:27b 拿到的是带 MTP 的。
MTP 指多 token 预测。这个模型的 model card 提到过多步训练，但配置里只有一层；在推理框架里，MTP 是单独注册的另一个模型，主模型加载时会直接丢弃 mtp. 前缀的权重（见 64 层在 vLLM 里怎么分流）。所以「带不带 MTP」在权重层面是实打实的差别。
发现二：MTP 版和非 MTP 版体积一模一样
把成对的标签放在一起看：
| 精度 | 带 MTP | 不带 MTP | 体积 |
|---|---|---|---|
| q4_K_M | 22130167c4c2 | 25b843619e94 | 都是 18GB |
| q8_0 | 8a1582877303 | 8f5fb6b71ea0 | 都是 30GB |
| bf16 | 197257101a8c | 1aa85dae8b2d | 都是 56GB |
三对，digest 全都不同，但每一对的标注体积完全相同。
这说明不了「内容一样」——digest 不同就是内容不同。合理的解释是页面上的体积是取整显示的，MTP 那一层带来的差量没有大到能改变取整后的数字。
实际意义：你不能靠体积来判断自己拉的是哪一份，只能看 digest 或写全标签名。
发现三：mlx 和 nvfp4 共享同一个 digest
这一组是最出人意料的：
27b-mlx = 27b-nvfp4 → 5642e97495e1 (18GB)
按命名惯例，mlx 通常对应 Apple Silicon 生态的框架，nvfp4 则指向 NVIDIA 的 4 位浮点格式——两个名字面向的是完全不同的硬件平台，却指着同一份内容。
Ollama 的页面没有对此作任何说明，我们也没有下载过这两个标签，所以无法解释成因。这里只如实记录页面上呈现的对应关系。
实际建议：如果你要在特定硬件上用特定格式，别只依赖标签名的字面含义，拉下来之后自己确认一下实际格式。标签名是人写的，会有历史包袱。
标签名里那些格式后缀是什么意思
页面上只给了名字和体积，没有解释任何后缀。下面是这些格式在业界的通行含义，属于命名惯例的一般性说明，不是 Ollama 页面上的官方定义：
q4_K_M：GGUF 的 4 位量化，K表示 K-quant 系列，M是中等档。这类混合量化不会把所有层压到同一精度，通常会给敏感的层留更高精度——这也解释了为什么 4 位版本的实际体积（18GB）比按 0.5 字节每参数粗算的结果要高。q8_0：GGUF 的 8 位量化，结构比 K-quant 简单。bf16：不量化，直接用 16 位脑浮点，等于原始权重精度。mxfp8：微缩放的 8 位浮点格式。列表里它标 32GB，比q8_0的 30GB 略大。nvfp4/mlx：分别指向 NVIDIA 的 4 位浮点格式与 Apple 生态的框架格式（但见上一节的注意事项）。
为什么该记 digest 而不是标签名
前面反复提到 digest，值得单独说说为什么。
标签是可变的引用，digest 是不可变的内容标识。 这两者的关系，和 Git 里分支名与提交哈希的关系是一样的。
latest 今天指向 22130167c4c2，官方发个新版本，明天它就可能指向别的。你的脚本里写 ollama pull qwen3.8，两次执行拉到的可能是两份不同的东西，而命令本身一个字都没改。
这在几个场景里会实实在在地咬人：
排查问题时。 同事说「我这边好好的」，你这边不对。如果双方只能说「我用的 qwen3.8」，这个信息量约等于零；如果能报出 digest，一秒就能确定是不是同一份。
复现结果时。 你三个月前跑出来的一批结果，现在想重跑对照。标签早就飘了，没记 digest 就没法确认基线。
团队协作时。 「大家都用最新版」听起来统一，实际上取决于每个人什么时候拉的。把标签名和 digest 一起写进文档，才是真的对齐了。
具体到这个模型，风险还要更高一点——因为 latest 恰好是三个标签共享的那个 digest，而其中一个是带 MTP 的。你以为拉的是「默认版」，实际拉的是「带 MTP 的 4 位量化版」。 这个差别在你需要对照 MTP 影响时会直接影响结论。
建议的做法：文档里写全标签名，比如 qwen3.8:27b-q4_K_M；关键场景再把 digest 也记上。多写十几个字符，省掉将来一整轮排查。
怎么选
按你的约束倒推：
只是想试试，机器一般 → 直接 ollama pull qwen3.8，18GB 那档。
想要不带 MTP 的干净版本 → 显式写 qwen3.8:27b-q4_K_M，注意别漏了它和默认版是两份东西。
要更高精度、机器扛得住 → 27b-q8_0 或 27b-mtp-q8_0（30GB 档）。
要原始精度做对照或后续处理 → 27b-bf16（56GB 档）。
在 Apple Silicon 上 → 可以试 27b-mlx 系列，但拉下来先确认实际格式。
无论选哪个，记得写全标签名并记下 digest。这是团队里保证「大家跑的是同一份」最省事的办法——比口头说「用最新版」可靠得多。
小结
qwen3.8有 12 个标签、8 个唯一 digestlatest=27b=27b-mtp-q4_K_M，默认拉到的是带 MTP 的 4 位量化版- 想要不带 MTP 的得显式写
27b-q4_K_M，它是另一份内容 - MTP 版与非 MTP 版标注体积完全相同，不能靠体积区分
27b-mlx与27b-nvfp4共享同一 digest，页面未作说明- 所有标签都标 256K 上下文；体积是文件大小，不是显存需求
最后提醒一句时效性。这十二个标签是 2026-08-24 那天的快照，官方随时可能增删标签、或者把 latest 指向别的 digest。本文真正值得留下的不是这张表，而是「先看 digest 分组、再决定写哪个标签名」这个习惯。 表会过期，习惯不会。
想知道拉下来之后怎么跑起来，看 标签写着 256K 你拿到的可能只有 4K；想知道其他框架的支持情况，看 支持哪些推理框架。更多拆解在 Qwen3.8-27B 专题。