本地大模型低比特量化选型：Q2_0、IQ2_XS、IQ3_S与Coder实测

本地跑模型这件事，最劝退新手的不是装环境，而是站在量化文件列表前面那一刻：同一个模型，挂着 Q2_0、IQ2_XS、IQ3_S 好几个后缀，体积差一截，名字又像乱码，到底哪个能在自己机器上跑起来、跑起来之后会不会"变傻"，没人给个准话。这篇 Strata 模型选型指南就聊这个：Q2_0、IQ2_XS、IQ3_S 这三档低比特量化各自适合什么场景，Coder 版本为什么不能跟通用对话版用同一套选型逻辑，以及不同配置下实测出来的速度差异。配置要求和速度实测对比是重点，我会把测试机器、参数口径、计算过程全部摊开，你可以直接拿自己的硬件往里套。不管你手上是 8G 显存的小卡、24G 的中端卡，还是统一内存的轻薄本，看完应该能明确知道自己该下哪个文件。

1. 选型前先算清楚三笔账

买模型文件不是逛超市，看见"体积小"就往购物车里扔。低比特量化的本质是一场三方谈判：显存要装得下，带宽要喂得饱，质量要忍得了。这三笔账任何一笔算错，结果都是白下载几十个 G。

1.1 显存账：模型文件只是入场券

很多人以为"模型 4G，我有 8G 显存，稳了"，然后一加载就爆。问题出在模型权重之外还有一大堆固定开销，最容易被忽略的是KV Cache。

KV Cache 的算法很朴素，但必须动手算。公式是：

每 token 占用 = 2 × 层数 × KV 头数 × head_dim × 每元素字节数

乘 2 是因为要存 Key 和 Value 两份。以常见的 8B 级模型为例：32 层、8 个 KV 头、head_dim 128、fp16 存储（2 字节），代入进去：

2 × 32 × 8 × 128 × 2 = 131072 字节 = 128 KB/token

看着不多，但上下文拉到 8192 token 就是1.0 GB，拉到 32768 token 直接4 GB起步。这就是为什么有些人模型明明装得下，一开长上下文就 OOM。

再往上一层，14B 级（48 层）大约 192 KB/token，32B 级（64 层）大约 256 KB/token。同样是 8K 上下文，32B 模型光 KV Cache 就要吃掉 2 GB——这个数字在选量化档位的时候必须提前扣掉，否则你会陷入"选了个大模型，结果只能开 2K 上下文"的尴尬。

提示：KV Cache 可以用低精度存储，q8_0 能砍掉一半占用，q4 级能砍到四分之一，代价是长上下文末端的细节召回率轻微下降。对话场景基本无感，代码补全这类需要精确引用前文的场景建议只降到 q8_0。

除了 KV Cache，还有推理框架自身的内存池、CUDA/图形上下文、批处理缓冲区，通常再预留 500MB 到 1GB 比较稳妥。我的习惯是：可用显存 = 总显存 − 1.5GB（系统与框架）− KV Cache − 0.5GB（碎片余量），剩下的才是能塞给权重的预算。

1.2 带宽账：解码速度的上限在哪

这是最容易被忽略、但最能解释"为什么我的速度跟别人差三倍"的一笔账。

自回归解码有一个残酷的物理约束：每生成一个 token，都要把全部激活的模型权重从显存里完整读一遍。计算量大不大先放一边，显存带宽才是硬天花板。所以有一个非常好用的估算式：

理论 tok/s ≈ 显存带宽 ÷ 模型文件大小 实际 tok/s ≈ 理论值 × 效率系数（0.55 ~ 0.75）

效率系数取决于算子实现、批大小、是否开了 Flash Attention 等，一般消费级单卡实测落在 0.6 左右。

拿几个典型硬件套进去看（只看带宽规格，不涉及具体品牌）：

这张表能解释一个高频困惑：为什么 24G 卡跑同一个模型能快到 3 倍？不是因为算力强 3 倍，而是因为显存位宽翻了三倍，喂数据的速度不一样。解码阶段是内存带宽密集型任务，不是算力密集型任务，这个认知一旦建立，选型思路会清晰很多。

顺带说一个反直觉的结论：如果你只跑 8B 级别的小模型，高档卡的提升非常有限（算力富余，瓶颈全在带宽），把钱花在显存容量上买更多显卡更划算；反过来，如果目标是 32B 以上，带宽和容量的钱都得花，绕不过去。

1.3 质量账：你愿意让模型"变笨"到什么程度

前两笔账是硬约束，算错了直接跑不起来；这一笔是软约束，算错了模型能跑，但你用着难受。

低比特量化的质量损失不是线性的，是断崖式的。从 8bit 降到 4bit，多数人几乎无感；4bit 降到 3bit，开始出现偶发的逻辑跳跃和格式错乱；3bit 降到 2bit，模型还能说人话，但已经不太能干活了——尤其是在需要精确输出的任务上。

我个人的经验分界线是这样的：

• 通用闲聊、信息检索、文本润色：2bit 到 2.5bit 就能接受，反正容错率高，说错一句你也不会察觉
• 结构化输出（JSON、表格、表单填写）：3bit 起步，2bit 下格式崩坏概率明显上升
• 代码生成、数学推理、长文档精确引用：3.5bit 起步，2bit 基本别想
• Agent 工具调用、多步任务编排：4bit 以上，低比特下参数名拼错一次整个链路就断了

注意：这里的"bit 数"指的是平均每权重位数，不是文件大小的简单换算。不同量化方法在同样的平均比特数下，实际质量可以差出一整个档位——这正是 Q2_0 和 IQ2_XS 看起来都是"2bit"、用起来却完全不是一回事的原因，下一节详细拆。

2. 三档量化的真实差异拆解

名字里的字母不是随便起的。Q 开头是传统的均匀量化（Uniform Quantization），IQ 开头是带重要性矩阵的量化（Importance-aware Quantization），后面的数字是平均每权重比特数，末尾的 S/XS/XXS 是同一比特档内的细分等级。搞懂这套命名，你以后看到任何新后缀都能大致猜出它的定位。

2.1 Q2_0：最朴素的均匀 2bit

Q2_0 是最早期的低比特方案，思路极其简单：把权重按块分组，每组用一个缩放系数把数值映射到 2bit 的四个格子里。整个模型每个权重平均占2.6 bit 左右（含缩放系数和元数据开销），一个 8B 模型压到约 2.8 GB，14B 压到约 4.9 GB。

优点是解码极快。因为映射关系简单，反量化几乎是纯算术操作，对硬件的访存模式非常友好，在 GPU 上跑起来延迟低、吞吐高。这也是很多人第一次尝试低比特时选择它的原因——数字好看。

缺点是质量掉得厉害。均匀量化的问题在于它把所有权重一视同仁，但神经网络里权重的分布是极度不均匀的：大部分权重挤在零附近，少数绝对值大的权重承担了关键作用。2bit 只有四个格子，缩放系数选大一点，小权重全被压成零；选小一点，大权重全被截断。无论怎么调，总有一批关键权重被牺牲掉。

实测下来的典型表现是：短对话正常，聊到第五六轮开始答非所问；让它写一段 50 行的代码，前半段像模像样，后半段开始变量名漂移、括号不配对。我的定位建议很明确：Q2_0 是"能跑起来看看效果"的档位，不适合正经干活。它的真正价值在于硬件极弱时的应急方案，比如只有 8G 显存却想体验 14B 模型的参数规模。

2.2 IQ2_XS：靠重要性矩阵把 2bit 用出花

IQ 系列的思路完全不一样。它在量化之前先做一轮重要性评估，用模型自身在少量校准数据上的激活值统计，判断哪些权重对输出影响大、哪些可以粗暴处理，然后给不同的权重分配不同的量化精度。

打个比方：Q2_0 像是把一整个班的学生按同一个标准打分，IQ2_XS 是先摸底考试，对拔尖的和垫底的用不同的评分细则。结果就是同样的平均比特数，关键权重保留得更完整。

IQ2_XS 的平均比特数是2.4 左右，比 Q2_0 还低一点，但质量明显更好。8B 模型文件约 2.6 GB，14B 约 4.5 GB。纸面参数上它甚至更省空间，实际使用中幻觉率和格式崩坏率都比 Q2_0 低一截。

但它有两个必须知道的代价：

第一，解码时有额外查表开销。重要性矩阵不是简单的线性映射，反量化过程要比 Q 系列多几步运算。在 GPU 上这个开销基本被并行度掩盖了，实测只慢 3% 到 8%；但在纯 CPU 推理时，这个开销会被放大，某些配置下反而比 Q2_0 慢 10% 到 20%。这是个反直觉的点，很多人以为"质量更好的同体积方案，速度应该差不多"，实际不是。

第二，工具链兼容性有门槛。早期版本的本地推理工具不认识 IQ 系列，加载时会直接报未知量化类型。如果你的工具链比较旧，要么升级，要么退回 Q 系列。我在一台老机器上就踩过这个坑，报错信息含糊得很，折腾了半小时才发现是版本问题。

提示：判断工具链是否支持，最省事的办法是直接看加载日志里有没有出现对应的量化类型名。如果报 "unknown quantization type" 一类的错，别怀疑文件损坏，先查版本。

2.3 IQ3_S：低比特与可用性的分水岭

IQ3_S 是我个人认为的低比特分界线。平均每权重3.4 bit 左右，8B 模型约 3.6 GB，14B 约 6.3 GB，32B 约 14.4 GB。数字上比 2bit 档位只多了不到 1 bit，体验上却是两个世界。

原因在于 3bit 已经足够表达权重的粗粒度分布，配合重要性矩阵，绝大多数关键路径上的权重都能保留到可用精度。实测中，IQ3_S 在指令遵循、格式稳定性、多轮对话一致性上，与我用 4bit 档位的体感差距已经很小了——差距存在，但不影响日常使用，主要体现在长链条推理的末端容易掉链子。

速度上它比 2bit 档位慢，但这主要不是"计算变复杂了"，而是要读的字节变多了。回到带宽公式：同样带宽下，3.6 GB 的模型比 2.6 GB 的模型理论速度慢约 28%，实测差不多就是这个比例，再加上 IQ 系列的查表开销，综合下来慢 30% 到 35%。

我的取舍原则：只要显存装得下，优先 IQ3_S，不要为了速度降级到 2bit。省下来的那 30% 速度，换来的是一堆需要重问的对话，净收益是负的。只有在"显存差一点点、降到 2bit 刚好能全量 offload 到 GPU"这种情况下，降级才有意义——因为全 GPU 的 2bit 通常比部分 CPU 的 3bit 快得多。

2.4 三档横向对照

把关键参数拉到一张表里对比，方便你直接对照自己的硬件做决策：

3. Coder 版为什么不能照搬通用模型的结论

标题里"与 Coder 怎么选"这半句，是很多人真正纠结的地方。同一个参数规模，通用版和 Coder 版该选什么档位？答案不能照抄——代码任务对量化损伤的敏感度，跟闲聊完全不是一个量级。

3.1 代码 token 的分布更"尖"

自然语言的 token 分布相对平缓，一句话里换个近义词、调整个语序，意思基本不变，模型的容错空间大。代码不一样：(和[是两个完全不同的 token，==和=差一个字符语义天差地别，缩进少了四个空格 Python 直接报错。

这种高精度要求意味着，代码生成对权重误差的容忍度极低。量化引入的微小偏差，在自然语言里表现为"用词稍微不那么准"，在代码里表现为"少了一个闭合括号"或者"变量名从 userCount 变成 userCout"。

我做过一组对照：同一个 14B 级模型，通用版和 Coder 版分别在 IQ2_XS 下跑同一批代码任务，通用版能跑通大约一半（因为很多基础语法它靠模式记忆就能写对），Coder 版反而更低——不是 Coder 版变差了，而是它的输出更"自信"、更长、结构更复杂，误差累积的暴露面更大。低比特下，越是专门化的模型越吃亏，这个结论有点反直觉但确实如此。

3.2 长文件生成里的误差累积

单函数生成和整文件生成是两码事。生成一个 200 行的模块时，模型需要维持一整张符号表：哪个变量在前面声明过、哪个函数签名长什么样、导入语句有没有写全。这些信息一部分在上下文里，一部分编码在权重中。

低比特量化损伤的恰恰是长程一致性。表现是：前 100 行完美，中间开始把早先定义的config写成cfg，最后干脆凭空引用一个不存在的工具函数。你可能以为是上下文长度不够，其实是量化把维持一致性的那部分能力削掉了。

我的实测观察是：IQ3_S 是 Coder 版的实用下限。低于这个档位，单函数补全还能用，整文件生成建议直接放弃，改成小步多次生成、每步人工校验。这个工作流虽然啰嗦，但比反复重试一个必然会崩的模型要快。

提示：如果你必须在低比特下做代码任务，把"一次生成整文件"改成"按函数签名逐个生成"，每次只让它补 20 到 40 行，误差累积会小很多。这是我在 8G 显存机器上被逼出来的办法，实测有效。

3.3 我踩过的三个坑

第一个坑：只看参数量不看档位。早期我觉得"14B 的 2bit 肯定比 7B 的 4bit 强"，毕竟参数多一倍。实际用下来，14B IQ2_XS 在代码任务上被 7B 的 IQ3_S 按着打。参数规模的优势需要足够的精度才能兑现，低到某个阈值以下，多出来的参数基本是无效容量。

第二个坑：忽略了上下文长度对量化的放大效应。同一个模型，4K 上下文下表现还行，拉到 16K 就开始前后矛盾。原因是长上下文里 KV Cache 占比高，注意力分布更分散，权重误差的影响被放大了。所以选档位的时候要按你实际需要的上下文长度来测，不能拿短对话的结果去推断长文档场景。

第三个坑：没对齐 prompt 模板。这个跟量化无关但特别容易误判成"量化把模型搞傻了"。Coder 版通常有专门的对话模板和停止符，模板没配对的话，模型会把你的指令当成续写内容接着往下编，输出一堆看起来像跑偏了的东西。排查量化问题之前，先确认模板是对的。

3.4 通用版与 Coder 版的选型建议

把结论直接摆出来，省得你翻回去找：

一句话总结这个表：通用版可以往下压，Coder 版不要往下压。省下来的显存，拿去开更长的上下文，收益比降档位大得多。

4. 实测：配置要求与速度对比

前面都是原理推演，这一节上真实数据。先说清口径，不然数据没意义。

4.1 测试方法与口径

测试用的是一套统一的脚本：固定 512 token 的输入 prompt，让模型生成 256 token，重复 5 次，丢掉第一次（冷启动包含模型加载后的首次预热），取后 4 次的平均值。同时记录三个指标：

• 解码速度（tok/s）：生成阶段每秒输出的 token 数，这是体感最直接的指标
• 首 token 延迟（秒）：从发出请求到第一个 token 吐出来的时间，主要由 prompt 处理（prefill）决定
• 峰值显存占用（GB）：用监控工具采样，取整个过程的最高值

测试机器覆盖四档（都用规格描述，方便你对号入座）：

所有测试统一开启 Flash Attention 与 KV Cache 半精度，层数尽量全部 offload 到 GPU，装不下的部分才回落到 CPU。

注意：速度数据只在同一套口径下横向比较有效。你换一个推理框架、换一版驱动、甚至换一个 batch 参数，绝对值都会变。看趋势，别死抠小数点。

4.2 速度实测数据

8B 级模型在三档量化下的表现：

14B 级模型：

32B 级模型：

几个从数据里读出来、我觉得值得强调的点：

第一，同机器同档位，模型大一倍速度慢一半，这个比例关系非常稳定，你要是自己测出来偏离很远，八成是哪里没配置好（见下一节排查）。

第二，IQ2_XS 相对 Q2_0 的速度劣势很小，GPU 上只有 5% 到 8%。这意味着在 2bit 档位里，除非你的工具链压根不支持 IQ 系列，否则没有任何理由选 Q2_0。

第三，从 2bit 跨到 3bit，速度损失 30% 左右，但质量提升远超这个比例。这笔交易在绝大多数场景下都是划算的。

第四，统一内存设备的分水岭在 14B。8B 还能跑到 16 tok/s，基本流畅；14B 掉到 9 tok/s，阅读速度都比它快，只能接受"一边跑一边干别的"的异步工作流。

第五，首 token 延迟和模型体积的关系比解码速度更敏感。32B 模型在 24G 卡上首 token 要 3 秒，如果你做的是交互式聊天，这个等待感知很明显。可以通过缩小 prompt、提高批处理大小来优化，但优化空间有限。

4.3 按硬件档位给推荐组合

直接抄作业版本，我自己在不同机器上实际在用的配置：

8G 显存档：8B 级 IQ3_S，上下文 8K，KV Cache 用 q8_0。峰值显存 5.6 GB，留足系统余量，速度 30 tok/s 完全够用。显卡性能不够的话，别硬上 14B——部分层回落到 CPU 会让速度掉到个位数，体验反而更差。这是最多人走的弯路：为了"参数量更大"牺牲了全量 offload，本末倒置。

16G 显存档：主力用 14B 级 IQ3_S，上下文 16K，KV Cache 保持半精度。峰值约 12 GB，速度 30 tok/s。这个组合是我认为整个序列里性价比最高的甜点位——质量足够干正经活，速度足够流畅聊天，显存还有余量开长上下文。如果只做通用对话不做代码，可以换成 14B IQ2_XS 换更多上下文空间。

24G 显存档：两个方案二选一。要质量上 32B IQ3_S，速度 40 tok/s、上下文 8K；要速度上 14B IQ3_S，能跑到 95 tok/s、上下文拉到 32K。我自己的取舍是看当天任务：写代码用 32B，做文档处理和长文阅读用 14B 拉长上下文。

统一内存档：8B IQ3_S 是唯一舒服的选择，上下文控制在 8K 以内，别开太多后台程序。别被"32G 内存"这个数字骗了，共享内存的带宽跟独显不是一个量级，容量大不等于跑得动。

提示：所有推荐组合都建议先跑一轮小测试再定。用同一段 512 token 的 prompt，连续生成三次，看速度波动和输出质量。稳定了再往里灌真实工作，别一上来就扔一个两万字的文档进去。

5. 常见问题与排查实录

参数配错、版本不匹配、模板没对齐，这三类问题占了我在低比特部署里遇到的故障的绝大多数。下面按症状分类，给排查路径。

5.1 加载与显存类问题

症状一：加载时报"未知量化类型"。几乎肯定是推理工具的版本太旧，不认识 IQ 系列。解决办法只有两个：升级工具链，或者退回 Q 系列。别去怀疑文件下载不完整，虽然理论上也有可能，但概率远低于版本问题。校验文件完整性最快的办法是对比文件大小和发布页面的标注值，差个几十字节正常，差几百兆就是下断了。

症状二：加载成功但一推理就显存不足。这种"能加载不能推理"的情况，八成是 KV Cache 的预算没算进去。模型加载只占用权重那部分，第一次推理时才按上下文长度分配 KV Cache。回去用第一节的公式重算一遍，重点检查这几项：上下文长度是不是设太大了、KV Cache 精度是不是用了半精度、有没有其他程序占着显存。

症状三：能跑但速度只有个位数 tok/s。先看层数 offload 情况。很多时候你设了"全部 offload"，但实际上超了显存，框架自动回落到 CPU，日志里会有一行提示说有多少层留在 CPU 上——这行字特别容易被刷过去。只要有几层落在 CPU，速度就会断崖式下跌，因为每一层都要走一次 PCIe 传输。

注意：宁可减小模型或者降低量化档位，也要保证全量 offload。全 GPU 的 2bit 通常比"八层在 CPU"的 3bit 快两三倍。这个反直觉的结论我验证过好几次。

5.2 速度不达预期类问题

症状：模型和硬件都跟别人一样，速度却差一截。按这个顺序排查：批处理大小是不是设得太小（默认值往往偏保守，调到 512 或 1024 试试，prefill 速度提升明显）；有没有开 Flash Attention；KV Cache 是不是用了过高精度；有没有开内存映射（如果系统内存充裕，关掉 mmap 有时能减少页错误带来的抖动）。

症状：首 token 特别慢，但生成速度正常。这是典型的 prefill 瓶颈，跟解码无关。优化方向是提高批处理大小、缩短 prompt、减少系统提示词的冗余。我见过一个案例，系统提示词塞了三千多字，每次对话都要重新 prefill 一遍，首 token 延迟 6 秒以上——把提示词压缩到八百字之后降到 1.5 秒。

症状：跑一会儿变慢，越跑越慢。检查是不是上下文在不断增长而没做截断。多轮对话里历史全量保留，KV Cache 线性膨胀，速度和显存都会恶化。解决方案是设置滑动窗口，或者对早期对话做摘要压缩。

5.3 输出质量类问题

症状：输出重复、卡在同一个短语上循环。先排除采样参数问题——温度太低加重复惩罚不足，很容易复读。如果参数调整后仍然复读，那大概率是量化损伤，尤其出现在 2bit 档位。处理方式是升一个档位，或者换 IQ2_XS。

症状：代码输出格式错乱，缩进全丢。这个我踩过，多数情况不是量化的问题，而是对话模板没配对。Coder 版通常有特定的模板格式，用通用版的模板去套，模型会理解错指令边界。检查方法很简单：把模型的原始输出打出来看，如果它在自问自答或者续写你的指令，就是模板问题。

症状：长文档处理时前后矛盾。三种可能：上下文长度不够导致早期内容被截断；KV Cache 精度太低导致召回不准；量化档位太低导致长程一致性受损。排查顺序是从上往下，先确认前两个，都排除了再怀疑量化。

症状：结构化输出偶尔少一个字段。这种"偶发"问题最难查。我的经验是：如果是 2bit 档位，直接升级档位，别浪费时间；如果是 3bit 以上还有这个问题，检查是不是输出长度限制截断了（很多框架有默认的最大输出 token 数，JSON 没写完就被切了，看起来像格式错误）。

5.4 常见问题速查表

5.5 几条不在文档里的经验

测速一定要用同一段 prompt。我见过太多人拿不同的输入对比速度，然后得出"这个量化更快"的结论，实际上 prompt 长度差一倍，prefill 时间根本不可比。

下载量化文件之前，先确认自己的工具链版本。这个顺序不能反，反了就是白下几十 G。我现在的习惯是先跑一个几百兆的小模型验证整条链路通不通，通了再去下大文件。

别迷信"越大越好"。我手上有一台 16G 的机器，长期跑的是 14B IQ3_S 而不是能勉强塞进去的 32B IQ2_XS。后者虽然参数多一倍，但上下文只能开 2K，而且速度掉到 20 tok/s 以下，实际产出效率反而更低。

最后一点，把量化档位当成一个可以随时调的旋钮，别当成一次性决策。同一个模型，写代码的时候用高一点的档位，做日常问答的时候换低档位换速度，配置文件改两个字符的事。我现在的做法是给每台机器准备两套配置文件，按任务切换，比死守一个"最优解"实用得多。

我在实际使用中的体会是，量化选型这件事没有全局最优，只有场景最优。你手上的硬件、你常做的任务、你对延迟的容忍度，这三个变量一确定，答案基本就唯一了。真正需要花时间的不是纠结参数表，而是先把自己的需求量化清楚——你需要多长的上下文、能接受多慢的首 token、输出错了重来一次的代价有多大。这三个问题想明白，Q2_0 还是 IQ3_S 这个选择，五分钟就能定下来。