本周 r/LocalLLaMA 论坛上，开发者 Daxfortuna 公开了一份审计：NVIDIA Nemotron 大模型市面上 443 个"低显存版本"里，没一个是真的低显存——文件标签写 2-3 bit（量化精度单位，数字越小压缩越狠），实测全是 4.70 bit 左右。

他审了 25 个仓库才挖出来：不是模型的问题，是 llama.cpp（本地跑大模型的主流开源引擎）的 k-quants 和 i-quants（两种量化算法）要求矩阵行宽能被 256 整除，Nemotron 的权重不满足，工具就悄悄换成了 32 块的类型，文件名保持原样。

他的解法叫 ShimQuant——把行宽补到 256 再压，最终做到 3.07 bit、11.77 GB，支持 26 万 token 上下文。HumanEval（代码能力基准测试）跑出 91.5%，跟官方 19.65 GB 版本持平，体积小了 7 GB。

这是什么

说人话：以前跑不动 Nemotron 的 16GB 显卡，现在能跑了，但有个硬条件——ShimQuant 必须在打过补丁的 llama.cpp 里跑，LM Studio、Ollama 这些"下载即用"的客户端用不了，一加载就报错。

这是个"能跑但难用"的方案。开发者自己也没说这是最优解，只是 18GB 以下目前唯一能跑的选项。

行业怎么看

乐观的看法：这正是开源该有的样子——一个人钻得够深，能发现厂商都没注意到的 bug。ShimQuant 这种"补丁文化"会推动整个量化工具链成熟。

但也有值得警惕的。第一，Josh Bolding 审了 443 个文件才找到一个明显的 bug，说明这条工具链缺乏标准化审计。第二，"假压缩"如果发生在别的模型上，用户可能一直没察觉——以为自己跑的是低显存版本，实际烧着显存。第三，他的方法比官方版本小 7GB，但 HumanEval 才持平，没证据证明更小就一定"够用"，只是"能跑"。

更长期的隐忧：随着"端侧大模型""AI 电脑"成为营销词，普通用户和企业 IT 部门很难分辨哪些是"真能跑"，哪些是"标签能跑"。

对普通人的影响

对企业的 IT 部门：本地部署大模型宣传的"16GB 起步"，目前还不能照单全收，采购前最好让团队实测一遍。

对个人职场：想用本地 AI 替代付费 API 省钱的，目前还得做好"自己编译、自己排错"的心理准备，"下载即用"还没到。

对消费市场：标着"AI 电脑""端侧大模型"的消费产品，短期内还是用厂商调好的版本最稳，自己折腾的空间有限。