llama.cpp 量化 和 gptq 区别

很多人本地跑模型时都会卡在这一步：Hugging Face 上同一个模型挂着 GGUF、GPTQ 好几套文件，下载哪个？听说 llama.cpp 能跑在 CPU 上，又听说 GPTQ 在显卡上更快，到底谁更适合自己？这篇不讲空理论，从「模型怎么被压小、谁来算、跑在哪块硬件」三个角度把两条路拆开，给一套能照着走的判断顺序。

同一个模型在网上下载时经常同时挂着好几套文件，名字后缀不一样，体积也差很多。很多人卡在这儿：到底下哪个？听说有个方案能在 CPU 上跑，又听说另一个在显卡上快，选错了要么加载不起来，要么等到天荒地老。其实两边不是同一层的东西，一个是推理工具顺带做量化，一个是专门针对显卡的权重量化方法，先把这一点掰开，后面的选择就简单了。

下面按「谁在算、精度差在哪、硬件怎么挑、按什么顺序决定」四步讲，每一步都给能直接动手的判断标准。只讲口径和排查方式，具体数字随硬件和模型变化很大，需要的时候到站内页面核对当时的情况。

两条路子在哪儿分岔：先搞清楚「谁在算」

最容易被忽略的一点是，这两者根本不在同一个层面。一边是自带推理内核和文件格式的整套工具，权重转好之后直接加载就能跑，重点是把 CPU、集显、独显都当成可用的算力；另一边是一种主要面向显卡的权重量化方法，量化出来的权重通常要靠别人的推理框架来加载执行。想清楚这一点，后面很多疑问自己就有答案了。

文件形态

一类是自包含的模型文件，一份就能加载；另一类是权重加配套代码，依赖框架和版本

计算资源

前者愿意把内存和显卡混着用；后者默认权重整体放显卡上算

换机成本

前者换系统换机器基本无痛；后者换环境常遇到依赖对不上

由此带来的直接后果是：一个模型文件走天下那种省事，属于自包含格式的优势；而环境折腾、依赖对不上，通常出现在需要配合特定框架的权重上。反过来说，如果你全程只用一张固定显卡、团队已经跑通了某个 GPU 推理栈，那跨平台这点优势对你没意义，别为了它专门换方案。

精度损失到底差在哪：别只看位数，要看量化方式和校准数据

很多人比精度只看位宽数字，这是最容易踩的误区。两边的量化粒度不一样，有的把整块权重一起处理，有的更细地照顾到每组权重，落到实际任务上表现就可能分叉。同样标称的位宽，占用的资源和对输出的影响未必能直接对齐，这个前提先记住。

还有一个关键差别在校准数据。偏显卡那条路线的量化常常依赖一批样本去调整权重，这批数据选得好不好，直接决定它在什么样的输入上守得住。如果换到风格差很远的输入，比如全是专业术语或成段代码，掉点可能更明显。而自带工具那条路线一般会提供多个量化档位，同一个模型常有偏保守和偏激进的版本，选择空间更细。

• 别信「哪个更准」的结论，拿你自己的一小段真实输入，两边各跑一遍对比输出
• 判断标准是「能不能用」而不是「谁分高」，任务不同结论完全不同
• 如果你要处理的是代码或垂直领域文本，尤其要拿这类输入去测，别只用日常闲聊
• 同一模型在自包含格式里选一档更保守的量化，常常比换方案更划算
• 连续多轮对话要连着测几轮，只看单次回答容易高估质量

硬件与速度：你有几张卡、能不能接受慢一点

速度这件事没有绝对答案，先看你手上有什么。显卡充足、要拼并发或低延迟的场景，偏显卡的量化路线更容易接到成熟的服务化方案上，方便做批量请求。只有 CPU、内存够大，或者显存装不下整个模型时，自包含格式那条路线更实用，它能把模型分散到内存和显卡之间跑，虽然慢一点但不至于完全跑不起来。

还有一个容易忽略的点：想让模型完全留在显卡里、吞吐要顶上去，选量化方案时要同时确认推理框架是否支持这套权重。权重和框架对不上，量化做得再好看也加载不了，等于白做。这不是方案好不好的问题，是配套支不支持的问题。

不适用的情况也说清楚：如果任务对首字延迟特别敏感、手上又只有 CPU，那这两条路都会让你难受。这时候该考虑的是换个更小的模型，或者直接走接口，而不是在量化方案上继续硬扛。

按场景选：一套能照着走的判断顺序

把上面的条件串起来，其实有一条约定的判断顺序。按这个顺序走，大部分情况不用纠结太久。每一步都给出可验证的动作，不是纯理论。

1. 第一步 看硬件手上是纯 CPU 或显存不够放整个模型，优先考虑自包含格式那条路线；有独立显卡且显存够放，再进入下一步。
2. 第二步 看用途只是自己聊天、写东西、做本地知识库原型，前者够用；要给多人用、要拼吞吐，往 GPU 侧方案靠。
3. 第三步 看依赖维护不想天天折腾环境和依赖版本，选文件式、依赖少的那条；团队已有成熟推理栈，就顺着现有栈走，别另起炉灶。
4. 第四步 小范围验证用两三个典型问题各跑一遍，记下能不能用、等待时间能不能忍，再决定把哪套铺开。
5. 第五步 补一次测算拿不准的时候，到 部署测算 按自己的模型和硬件口径算一遍，比凭感觉选靠谱。

这套顺序在一种情况下不适用：如果你的团队已经在一条路线上投入了很多，并且跑得挺稳，那就不必重来。判断标准是「现有方案有没有踩到硬伤」，有硬伤再考虑换，没有就继续用。

常见的四个坑，动手前先避开

最后把新手最常踩的四个坑列出来，动手前扫一眼，能省掉不少返工时间。这几个坑跟路线选得对不对无关，跟流程细节有关。

• 坑一：只按字面位宽比「谁更省」，忽略两边量化粒度不同，实际占用和效果不能直接对齐
• 坑二：下错文件。同一仓库里可能同时挂着几套格式，模型文件和后端对不上会直接加载失败
• 坑三：把量化当万能药。位宽压得太狠，长文连贯性和指令遵循会明显变差，这类任务建议留一档保守的量化
• 坑四：只看单次回答好不好，不考虑连续多轮之后的质量衰减，做对话类应用时尤其要连着测几轮

这四个坑里前两个属于操作失误，看一眼文件说明和加载日志就能避免；后两个属于判断失误，需要你拿真实任务去测。哪种量化档位更合适、当时各家方案的对照情况，可以到站内模型资料库核对，那里的信息更新比任何一篇静态文章都及时。