GGUF 量化文件名审计：443 个模型中 64 个精度虚标
对 25 个仓库 443 个 GGUF 量化文件审计发现，因 fallback 机制，64 个文件实际精度与文件名不符。
近日，有开发者在 r/LocalLLaMA 发布了一项针对 GGUF 量化模型的大规模审计结果：跨 25 个仓库、共计 443 个量化文件，有 64 个的实际位密度与其文件名声称的不符，根源在于 llama-quantize 中长期存在的「fallback」机制。
问题根源：tensor 维度不整除 256
K-quants 与 i-quants 要求首个 tensor 维度能被 256 整除。当模型架构不满足这一条件时（例如 Nemotron 系列 MoE 的 expert 宽度为 1856、3712），llama-quantize 会自动替换为兼容的 32-block 类型——i-quants 通常退化为 IQ4_NL，k-quants 通常退化为 Q4_0，最终整体精度落在 4.5 bpw 附近。
这一行为是 llama.cpp 自 2023 年 PR #3747 起就有的「有意设计」，量化器会在日志中打印警告。但警告只写入本地量化日志：若用户直接下载已经量化好的 GGUF 文件，根本看不到这条信息。结果就是：文件名写着 IQ2_XXS，模型卡写着 IQ2_XXS，元数据描述的也是 IQ2_XXS，但文件里装的其实是接近 4.58 bpw 的内容。
受影响最严重的案例
作者编写了一个纯标准库、单文件的 Python 审计工具，可对本地 GGUF 或整个 HuggingFace 仓库进行核查（对远程仓库使用 range request，仅拉取几 MB 的 header）。主要发现包括：
- Nemotron-3.5-Lightning：n_embd 为 2688，expert 宽度为 1856 与 3712，约 99% 的参数被强制进入 fallback 类型。四个 IQ2 档位文件名标注 2.06–2.56 bpw，实测全部为 4.58 bpw；同一密度却横跨看起来 2.2 倍的范围。
- Qwen3.8-Flash-Next：51.9% 的参数被 fallback；标称 1.56 bpw 的 UD-IQ1_S 实测 3.28 bpw。
- Nemotron-3-Super-120B：23 个量化档位中有 18 个包含 fallback，使 Nemotron-H MoE 家族的受影响仓库数达到 4 个。
值得注意的是，bartowski 与另外两位发布者上传的 Nemotron-3.5-Lightning 出现了同样的结果，这指向工具本身而非上传者的疏失。
干净的对照组
审计同样发现了不少「名副其实」的量化仓库：
- MiniMax-M2.1：23 个档位，包含真正的 IQ1_S，零 forced tensor。
- byteshape 的 Qwen3.6 量化：文件名直接标注实测 bpw，且与作者独立测量完全吻合，被认为是目前最佳标注实践。
- bartowski 的 Ornith-1.5：完整 27 档量化阶梯，零 forced tensor。
- 密集架构的 Llama 与 Qwen 对照组全部通过。
作者强调：每个出问题的发布者同时也有用相同流程产出的干净仓库，因此决定因素是模型的 tensor 维度，而非发布者的操作。
实际影响与建议
对本地部署用户来说，这意味着低档位量化的体积缩减可能远低于预期。当 IQ2_XXS 与 IQ2_M 实测密度相同时，仅凭文件名难以判断该选哪一个；直接选用诚实标注的 Q4_0 或 IQ4_NL 反而更省心。
这并非新问题。Issue #26616 中已有用户在期望 18 GB 的位置拿到 24.5 GB 后，请求加入 --no-fallback 选项；而此前缺少的是系统性测量：发生频率、涉及架构、受影响比例——正是本次审计补上的部分。
工具与后续
审计工具、完整清单与逐仓库原始 JSON 已开源在 https://github.com/JoshBlanding/ggufaudit ，可直接对本地或远程 GGUF 文件运行。作者预告了后续文章：对于受影响模型，在「只用 4.5 bpw 文件」之外还能做什么——毕竟低档位量化的初衷往往是塞进一张 16 GB 显卡。