Nemotron-3.5-Lightning达到11.77 GiB，为没有16 GB选项的模型提供了一种选择

简而言之：每个公开的低位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上下文。到目前为止，我通过两种方式进行了测量，KL散度与Q8_0参考和HumanEval。与标准的IQ2_M相比，它小了6.2 GiB且差异更小。在HumanEval上，它与AtomicChat的19.65 GB构建并列，达到91.5%，同时小了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' 形状错误；预期2688, 10304，得到2816, 10304。如果您不想构建一个修补的llama.cpp t