Nemotron-3.5-Lightning 以 11.77 GiB 出现，为该模型提供了首个 16 GB 选项

TL;DR: 每个公开的低比特 GGUF 该模型文件实际上约为 4.70 bpw。将行调整到 256 后，它成为一个真正的 3.07 bpw / 11.77 GiB 文件，可在 16GB 上运行 262K 上下文。需要修补的 llama.cpp —— 不是 LM Studio 或 Ollama。在 AtomicChat HuggingFace 仓库中写着“目前没有人提供该模型的良好 16 GB 选项。”这是真的，我想找出原因，这是一个量化器问题，而不是模型问题。k-quants 和 i-quants 需要行宽度能被 256 整除。Nemotron 的不行，所以大约 99% 的参数无法合法使用。llama-quantize 替换为 32 块类型并保留您要求的文件名，这就是为什么该模型的每个低比特量化都大约为 4.70 bpw，无论标签如何。如果您昨天看到我的人口普查帖子，同样的错误，Nemotron 是我找到的最坏情况。有人发布的最小可用构建约为 18 GiB。ShimQuant 将每个受影响的行调整到下一个 256 的倍数，以便低比特类型实际适用，然后在推理时切片激活。这使其达到 3.07 bpw，11.77 GiB，在 16 GB 卡上运行 262,144 上下文。到目前为止，我已经用两种方式测量了它：针对 Q8_0 参考的 KL 散度和 HumanEval。与标准 IQ2_M 相比，它小了 6.2 GiB 且散度更小。在 HumanEval 上，它以 91.5% 与 AtomicChat 的 19.65 GB 构建打平，同时小了 7 GB。更多基准测试正在进行中，我会在结果出来时更新卡片。它在散度上并未胜过标准 IQ3_XXS。后者大 6.2 GiB 且更接近 Q8 三倍。因此，声称并非这是最好的文件，而是低于约 18 GiB 时，标准量化器为该模型提供不了任何可用选项，而此文件在间隙中可用。注意：这在标准 llama.cpp、LM Studio、Ollama 或任何未修补的工具中无法加载。它需要 ShimQuant 补丁。它立即失败而不是悄悄损坏：check_tensor_dims: tensor 'blk.0.ssm_in.weight' has wrong shape; expected 2688, 10304, got 2816, 10304。如果您不想构建修补的 llama.cpp，那么此文件不适合您。但它是 18 GiB 以下唯一的可用选项，因此如果您使用 16 GB 卡并想运行 Nemotron，只有这个或没有。模型：https://huggingface.co/BoldingBuilds/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-ShimQuant-GGUF 补丁：https://github.com/JoshBolding/shimquant 对 25 个仓库和 443 个量化的普查：https://github.com/JoshBolding/ggufaudit