你可能遇到过这种场景：同一份开源权重，直接跑显存不够，换成本地常见的 4-bit 量化版本又能跑起来了，但回答偶尔变得不太对劲——代码少个括号、算术绕远路、长文总结漏点。这不是错觉，是量化在起作用。这篇不列配置表，只讲原理：量化到底对权重做了什么、GGUF 和 AWQ 为什么是两套思路、精度损失体现在哪种任务上、什么时候量化根本不划算。
同一份开源权重，直接拉原版可能显存不够，换成本地常见的 4-bit 版本就能跑起来，但回答偶尔变得不太对劲：代码少个括号、算术绕远路、长文总结漏掉关键点。这不是错觉，是量化在起作用。
这篇不列配置表，只讲原理。量化到底对权重做了什么、GGUF 和 AWQ 为什么是两套思路、精度损失体现在哪类任务上、什么时候量化根本不划算——把这几件事想清楚，你自己就能判断该不该压、压到哪一档。想要现成的参数对照，去站内的模型资料库页面看当时的数字。
量化解决的是哪一类问题
很多人把量化当成「让模型变快」的开关，这个预期一开始就偏了。量化首先解决的是显存能不能装下，其次才可能顺带提高吞吐。同一张卡上，压得越狠，能塞的模型越大，但模型本身并不会因此变聪明，只可能在某些任务上变钝。
- 先分清三件事：权重占用、KV 缓存占用、激活值。量化主要动的是前两项，KV 缓存还涉及缓存量化这一独立话题，别混在一起聊
- 显存不够时，量化、张量分片、CPU offload 是三条不同路线，代价不一样：量化牺牲精度换空间，分片换来的是通信开销，offload 换来的是延迟
- 量化的收益是「能跑起来 + 吞吐可能更高」，不是「效果更好」。如果你本来就跑得动原版，量化的边际价值要重新算
权重从 16 位压到 4 位，中间发生了什么
把权重从 16 位压到 4 位，本质是有损压缩。做法是拿一个缩放因子，把一段连续的浮点数值映射到有限个格点上，再把格点索引存下来。推理时反着还原。格点数量有限，原本相邻但不同值的权重就可能被压到同一个格点，这个不可逆的对应关系就是精度损失的来源。
分组粒度决定误差大小
一组权重共享一个缩放系数。组越小，每组能覆盖的数值范围越贴合局部分布，还原越准，但缩放系数本身要占空间、要算，开销也越大。组越大越省，但拿一个系数去套一大段分布差异明显的权重，误差就上来了。各家量化方案在分组粒度上的取舍，是拉开差距的第一处。
不是所有权重一样重要
权重分布里总有一些离群值通道，它们数值特别大，如果按统一规则压，要么把这一小撮压坏，要么为了迁就它们把整体的格点分辨率拉低，两边都亏。所以常见的做法是对离群通道做特殊照顾：有的保留高精度、有的做逐通道缩放。这正是各家方案拉开差距的第二处，也是精度差异的主战场。
为什么常见停在 4 位
再往下压到 3 位、2 位，缩放本身的误差开始盖过省下的空间收益，质量下滑往往不是线性的，而是断崖式的。所以 4 位附近成了工程上的常见落点——不是理论最优，是性价比拐点。真到更低档位，那基本是拿质量赌能不能跑，只适合容错极高的场景。
GGUF 和 AWQ 是两套不同的问题解法
把 GGUF 和 AWQ 放一起比精度数字，是最容易跑偏的比法。它们压根不在同一个层次上：一个更像文件格式加分档体系，一个更像一类权重量化算法。先搞清层次，再谈选型。
- GGUF
- 一套文件格式加分档体系：同一份权重能打出多种档位，配合 CPU/GPU 混合推理，面向「把模型塞进单机」这个目标
- AWQ
- 一类权重量化算法：按激活分布挑出重要通道，做逐通道缩放保护，通常面向 GPU 上跑满吞吐
| 对比维度 | GGUF 路线 | AWQ 路线 |
|---|---|---|
| 本质是什么 | 文件格式 + 多档位打包体系 | 权重量化算法 |
| 典型运行栈 | 常配合 llama.cpp 系的推理器 | 常配合 GPU 推理框架 |
| 硬件倾向 | CPU/GPU 混合，单机可跑 | GPU 为主，追求吞吐 |
| 主要目标 | 能不能塞进这台机器 | 能不能跑得更快 |
| 选型先问 | 你的机器是单卡还是混合 | 你的框架支不支持这套算法 |
选哪个，先问三件事：你的硬件是单卡还是 CPU/GPU 混合、你的推理框架支不支持、你要的是能跑还是跑得快。这三个问题答完，路线基本就定了。具体到各家框架的适配情况，到站内工具目录页面核对当时的口径。
4-bit 的精度损失在哪些任务上会显形
「量化到底掉多少」这个问题没有统一答案，因为损失不是均匀分布的。有些任务压完几乎无感，有些任务压完直接不可用。判断标准是任务的容错空间有多大。
- 长链条逻辑与精确算术：中间步骤一错，后面全歪，这类任务对累积误差最敏感
- 结构化输出：要严格 JSON、要严格括号配对的任务，容错空间本来就小，量化更容易把格式打崩
- 长上下文：同一份量化权重，短问答看不出差别，长文总结开始漏点，因为注意力被稀释后更依赖权重的精细度
- 高容错任务相反：创意生成、风格改写这类活，差一点措辞你根本感知不到，量化在这里往往划算
怎么自己验一遍，而不是听别人说
别人说「某一档够用」，那是别人的任务。你要的是自己那份用例上的结论。验证的成本不高，但方法要对，否则容易把偶发错误当成系统性退化，或者反过来。
- 准备固定用例覆盖三类：算术题、要求严格格式的输出、长文摘要。每类准备几条，固定不变，这是你的标尺。
- 横向比档位同一模型的不同量化档位之间对比，比「量化 vs 原版」更有参考价值，因为能看出趋势拐点。哪一档开始明显变差，那个拐点才是你该停下的位置。
- 多跑几次同一输入重复跑，把偶发错误和每次都错区分开。偶发错可能只是采样随机性，每次都错才是量化导致的退化。
- 按错误类型记录不要只记「像不像」，要记具体错法：是偶尔算错一位，还是格式再也对不上。前者可能还能接受，后者通常直接淘汰这一档。
什么时候不该用量化
量化不是默认必做项。下面几种情况，压了反而是给自己找麻烦。
- 显存本来就够：多出来的那点吞吐换不回潜在的质量折损，尤其是精度敏感的任务，别为了省而省
- 要交付给外部：出错成本高又没有兜底校验的链路，别拿最激进的档位去赌，宁可多占点显存
- 模型本身已经很小：小模型对量化的耐受度往往更差，压完可能直接不可用，这一点和大模型的经验不能直接套
- 用别人的 API：这条路根本轮不到你选档位，量化是平台侧的事，你只能看它暴露的口径。想横向比各家口径，到站内 API 价格页面核对当时的信息
反过来说，如果你的场景是本地单机跑、任务容错高、卡又确实装不下原版，那量化就是合理选择，不必因为「损失了一点精度」而纠结。
一条能落地的判断顺序
把前面几节收成一条可执行的顺序。照着走，不用每次重新想。
- 定约束卡是什么、显存多少、延迟要求多少，先写下来。约束不清，后面全是拍脑袋。
- 挑路线单机混合推理看格式体系，GPU 纯推理看算法方案。别混着比精度数字。
- 定档位从保守档位往下试，不要一上来就顶到最低位宽。先确认能跑，再逐步压。
- 做验证用你自己的固定用例跑对照，记录错误类型而不是只看「像不像」。拐点在哪，档位就停在哪。
- 留退路把原版权重和不量化的配置留着。出问题能退回去，比事后到处找原因划算得多。
量化解决的是「装不装得下」，不是「跑得好不好」——先把预期摆正，再谈选哪一档。下一步想看你手上这台设备适合哪条路线、各家推理框架的适配口径，以及不同量化思路下官方资料的横向对照，去站内工具目录和模型资料库页面核对当时的数字。→
常见问题
量化后的模型和原模型差别到底有多大？
没有统一答案，取决于档位、模型规模和你的任务类型。经验规律是：模型越大对量化越耐受，任务越结构化、越依赖精确计算就越容易露馅。想知道你自己的场景差多少，只能拿一组固定用例跨档位实测，别信单一跑分数字。
GGUF 和 AWQ 我该选哪个？
先看你的运行环境。单机、CPU 和 GPU 混着跑、想用同一份文件覆盖多种硬件，走 GGUF 这条路；整块 GPU 专门做推理、追求吞吐和并发，看 AWQ 这类算法方案。两者不是精度高低之争，是运行栈之争，框架不支持再好也白搭。
4-bit 是不是就一定比 8-bit 差？
大多数情况下是，但不是绝对。低档位用更聪明的分组和离群值处理，有时能在某些指标上追平简单的 8-bit 实现。所以别按位宽数字排序，按实测结果排序，同时留意吞吐和显存占用这两项实际收益。
量化能省下多少显存？
粗略地看，位宽减半大致能让权重占用减半，但整机占用还包括 KV 缓存、激活和框架开销，所以总显存不会等比例下降，长上下文场景尤其明显。具体数字按你的模型和上下文长度算一遍更靠谱，可以到站内部署测算页核对估算口径。
为什么同一个量化模型，短问题答得很好，长文档就开始出错？
短问答对权重的依赖集中在少数高频路径上，量化误差容易被掩盖；长上下文要做大量的注意力加权和跨段信息拼接，误差会累积放大。这不是模型「变笨」了，是误差在长链条上被放大了。
