模型量化实战指南：原理、档位选择与本地部署避坑

1. 为什么模型量化是本地部署的第一课

1.1 显存与带宽才是真正的瓶颈

最近一段时间，身边聊大模型部署的朋友，几乎没有一个绕得开“模型量化”四个字。不管你是想在单张消费级显卡上跑开源模型，还是想把视觉模型塞进边缘设备，或者干脆只是想在公司内网搭一个私有推理服务，第一步要面对的都是同一个问题：模型太大，硬件不够。

这里先算一笔最简单的账。一个7B参数的模型，如果用FP16（半精度）存储，光权重文件就要14GB左右显存。到了30B、70B这个量级，单卡24GB的RTX 3090/4090就只能干瞪眼。而量化的思路很简单——把模型参数从16bit压到8bit、4bit甚至更低。同样是7B模型，INT8大约7GB，INT4大约3.5GB，一下子就能塞进消费级显卡。

但很多人容易忽略另一件事：推理速度的真正瓶颈往往不是算力，而是显存带宽。GPU每生成一个token，都要把全部权重从显存搬到计算单元，这个搬运过程极其吃带宽。权重变小了，搬运量线性下降，吞吐自然上去了。所以量化不只是“塞得下”的问题，它还直接决定你每秒能跑几个token。

1.2 量化的本质是一次精度换资源交换

把量化想得太玄学也没必要。我自己的理解是：模型权重里有很多“不敏感的冗余信息”，量化做的就是把这些信息用更少的bit存下来。打个比方，一张高分辨率照片压成高质量JPEG，肉眼看几乎没区别，但文件体积小了好几倍；量化干的事类似，只是压缩对象是神经网络的参数和中间计算值。

具体到实现，量化通常分对称量化和非对称量化。对称量化把数值范围映射到[-127, 127]，非对称量化则额外引入一个zero-point偏移，能更好地适配分布不对称的权重。还有per-tensor、per-channel、per-group几种粒度，粒度越细精度损失越小，但计算复杂度越高。当前开源模型里最流行的做法，是per-group量化，比如以128个权重为一组单独计算缩放因子，在精度和效率之间取一个平衡点。

也就是说，选模型量化策略，本质上是做一道资源交换题：你要用多少精度损失，去换显存、速度和部署成本。搞懂这个前提，后面所有的方法选型和档位对比才谈得上有方向。

2. 量化方法的流派与核心选择逻辑

2.1 PTQ 与 QAT：先分清训练时量化和训练后量化

量化方法先得分两大类：训练后量化（PTQ）和量化感知训练（QAT）。PTQ是模型训练完了之后，直接拿权重做转换，不需要重新训练，速度快、成本低，现在开源社区里能下载到的量化模型绝大多数都是PTQ产物。但PTQ也不是无脑压，它需要一个“校准”过程——用一小批有代表性的样本跑一遍，统计激活值的分布范围，从而确定量化缩放参数。

QAT则是在训练过程中就模拟低精度误差，让模型自己去适应“被压扁”的数值范围。效果通常比PTQ好，尤其是低比特场景，但它要重训模型，成本高得普通团队根本玩不动。所以我的原则是：95%的场景用PTQ，只有当模型被压到3bit以下、并且任务又是数学代码这种高精度场景时，才认真考虑QAT。

2.2 GPTQ、AWQ、GGUF：都叫量化，生态完全不同

很多人第一次接触量化，会被GPTQ、AWQ、GGUF这几个名字搞得一头雾水。它们其实不是同一层的东西：GPTQ和AWQ是具体的量化算法/工具，GGUF是llama.cpp生态里的模型封装格式，附带了一整套K-quant量化方案。

先说GPTQ。它基于二阶信息做逐层量化，通俗讲就是量化完一层后，会根据误差去微调剩余权重，尽量把精度损失摊薄。AutoGPTQ是这个路线的代表实现，GPU推理效果好，过去两年一直是4bit量化的主流方案。AWQ则换了个思路：不去硬刚权重误差，而是观察激活值，找出那些“哪怕只差一点也会严重影响输出”的权重通道，给它们更高精度保护。AutoAWQ量化速度比GPTQ快很多，而且4bit下实测质量往往更稳。现在新出的模型，如果服务端要上批量推理，我基本优先焊死AWQ。

GGUF又是另一套玩法，它来自llama.cpp生态，主打CPU、GPU混合推理，Ollama后端默认就是它。GGUF文件里的Q4_K_M、Q5_K_M这些怪异名字，指的是不同的量化策略细节，我后面专门用一节来说。简单可以先记住：要跟Ollama/llama.cpp打交道，选GGUF；要在vLLM/TGI这类服务框架里跑高吞吐，选AWQ/GPTQ；在Apple Silicon上优先考虑MLX格式。

2.3 三元量化模型：1.58bit的特殊物种

热词里“三元量化模型”值得单独拎出来聊聊，因为它跟常规量化不在一个维度上。普通量化是把FP16小数映射成一堆整数，三元量化更极端，直接把权重限制成三个值：-1、0、1。因为每个权重理论上只需要log2(3)≈1.58bit，所以叫1.58bit量化，代表工作就是BitNet b1.58这条技术路线。

三元量化最大的优势在于，矩阵乘法大幅度退化。乘一个权重只需要做加减法，遇到0直接跳过，理论上推理能效极高，内存占用也压到了极致。但问题在于，当前主流GPU和推理框架并没有为这种极端低比特做优化，标准内核跑起来反而可能比4bit还慢。所以如果你看到“三元量化模型”下载，先别急着上生产，更多适合端侧芯片、FPGA这类从底层就为它设计的硬件去跑。我的态度是：值得持续关注，生态成熟后再上车。

3. 开源模型量化档位怎么排

3.1 先看跑分再看任务，别被单一指标带偏

“开源模型量化档排名”这个热词，说明了大家买量化模型前最想干的事是：知道哪个档位性价比最高。社区里经常能看到各种跑分图，拿MMLU、HumanEval这些指标横向对比不同量化位宽。这些分数可以参考，但我建议别只看一个数字。

原因有两点。第一，perplexity（困惑度）这类指标衡量的是模型“整体发疯程度”，它降一点可能感知不明显，但下游任务表现可能已经崩了不少。第二，不同任务对量化敏感度差异很大。闲聊、摘要这类生成式任务容忍度很高，4bit都能用；代码生成、数学推理这种要求精确逻辑的任务，3bit基本就废了。所以正确姿势是：先确定你的核心业务类型，再去看公开跑分里对应的子项。

3.2 各档位经验数据

我按照自己这几年的实测感受和社区公认结论，整理了一张表。以7B模型为例，显存是粗估的，实际会因量化组大小和tokenizer略有出入：

这张表里我想特别强调Q5_K_M。从社区大量反馈和我自己的体感来看，Q5_K_M是质量与体积的黄金平衡点。它比Q4_K_M只多占1GB左右显存，但复杂任务上的语义完整性和稳定性都明显更好。如果你的显卡放得下，优先选Q5_K_M。

3.3 不同模型对量化的敏感度差异

即便位宽相同，不同模型家族量化后的表现也千差万别。一个比较普遍的经验是：参数量越大，量化鲁棒性越强；小模型（3B以下）压到4bit之后，常会出现事实性错误增多的现象。另外，代码模型和数学推理模型对量化更敏感，我自己实测同样的4bit位宽，通用对话任务可能只掉几个点，代码生成却能肉眼可见地变笨。

这几年新出的模型还有个趋势：因为预训练数据更充分、训练方法更稳，量化鲁棒性整体变高了。所以如果你看到某篇2023年的文章说“4bit必崩”，放到现在的模型上不一定成立，还是要具体模型具体测。这也是为什么我一直建议，在确定量化档位前，把自己业务里的典型任务做成一个小评测集，逐个档位跑一遍，比任何公开排名都可信。

4. 实战：35B Compact量化模型怎么下载、怎么跑

4.1 先搞清楚什么被量化了：MoE模型的总参数与活跃参数

热词里有个很长一串的名字“qwen3.6-35b-a3b-apex-mtp-i-compact量化模型”，看着像某个社区推送的新模型。这里我拿它当案例，讲讲这类大模型量化到底要关注什么。名字里的“35b”指总参数量35B，“a3b”通常指激活参数只有3B，也就是说这是一个MoE（混合专家）架构模型——每个token只会激活一小部分专家网络。

很多人觉得MoE模型激活参数少，所以量化需求低，这是个误解。35B总参数的模型，即使一次只激活3B专家，权重文件依然是按35B来算的。你要把整个模型加载到显存里，照样需要70GB的FP16空间。那怎么办？把35B总参数量化到4bit，大约17.5GB，这样24GB的显卡才勉强能跑。所以MoE模型量化的重点，其实应该放在那些“每个token都会用到”的共享层上：embedding、attention、router、MTP（多token预测头）。专家层按需加载，在显存里的压力没那么大。

4.2 下载量化版的时候要看的几个东西

现在开源社区下载量化模型，主要去Hugging Face和ModelScope这类平台。搜“35b-a3b gguf”或者“35b compact quantized”就能找到对应仓库。但下载前有几个关键点必须核对。

第一，看量化格式。同一个模型往往同时放出GGUF、AWQ、GPTQ几种文件，选错格式你的推理框架根本加载不了。第二，看文件名里的档位标签，Q4_K_M、Q5_K_M、Q6_K这些不是乱码，具体含义前面表格已经解释过了。第三，看发布分支。有些仓库默认分支只放原版权重，GGUF文件放在“quantized”或“gguf”分支下，不切换分支下载会扑空。第四，务必核对SHA256。社区模型文件被恶意替换的事情不是没发生过，下载后先跑一下校验，再进推理流程。

根据我的经验，本地个人电脑上跑这类35B量化模型，最简单的方式就是在Ollama里操作：把GGUF文件按要求目录放好，写一个Modelfile指定路径，然后ollama create就能生成一个可用标签。如果用llama.cpp直接跑，命令大致是./llama-cli -m model.gguf -ngl 99，其中-ngl控制将多少层放到GPU。

4.3 显存到底够不够：先算KV Cache

很多朋友下载完模型，加载就报OOM，其实不是模型权重超了，而是没给KV Cache留位子。KV Cache是推理时缓存历史token注意力键值的地方，它的大小公式大致是：batch_size × 序列长度 × 层数 × 隐藏维度 × 2 × 字节数。单看公式有点吓人，但你只要记住：上下文越长、batch越大，KV Cache吃得显存就越多。

举例，17.5GB的4bit权重放到24GB显卡上，看着还剩6GB多，但你把上下文拉到32K，KV Cache可能就吃掉好几个GB，一并发请求多就爆。解决办法有几个：把上下文需求降到8K/16K、减小batch、使用量化后的KV Cache（部分框架已经支持），或者把权质量化档位降半档，比如从Q5_K_M换到Q4_K_M。我自己遇到显存吃紧时，第一反应是优先保上下文长度，因为业务上上下文长度不够往往比模型变笨更致命。

5. 视觉模型量化：以SAM2为例

5.1 SAM2各个模块的显存分配

热词里还有一个“sam2量化模型”，SAM2是Meta开源的第二代分割模型，支持图像和视频分割。它跟大语言模型不一样，不是一个纯粹的Transformer+MoE结构，而是由Image Encoder（图像编码器）、Memory Attention（记忆注意力）、Mask Decoder（掩码解码器）几个模块组成。这里面显存大头是Image Encoder，它负责把每一帧图像编码成特征，参数和计算量都相当可观；剩下的Memory和Decoder相对轻量。

所以视觉模型量化更要讲究“重点打击”。对SAM2来说，把Image Encoder量化到INT8或FP8，显存和延时都能降一大截，而Mask Decoder保持FP16精度，这样整体分割质量损失很小。如果你只是图省事把整个模型一刀切全部量化，反而可能在边缘、小目标这些细节上翻车。

5.2 视觉量化和大语言模型量化的差异

很多人把LLM量化那套经验直接搬到视觉模型上，这是个大坑。视觉分割任务属于密集预测，每个像素都要精确，模型对激活值量化远比语言模型敏感。语言模型量化里很流行的weight-only策略（只量化权重、不量化激活），到视觉模型这里，通常要谨慎处理激活量化。实际操作中，vison模型做INT8推理时，我基本都是权重和激活一起量化（W8A8），再用校准数据把激活范围对齐。

另外，视觉模型里的LayerNorm、Softmax这类层数值范围很窄，量化后误差容易爆炸。常规做法是这些层保持FP16/FP32。这跟你训练时的BatchNorm/LayerNorm计算精度密切相关，不要为了省那一点点计算强行量化。

5.3 量化SAM2的实操要点

如果要落地SAM2量化，我建议走ONNX Runtime或TensorRT这条链路。先用原始权重导出ONNX，再把模型做INT8量化。校准数据集可以从COCO或者SA-1B里抽几百张，覆盖不同光照、尺度，效果会比随机图片好很多。量化完成后，用mIoU之类的指标和原模型做对比，一般掉1到3个百分点属于正常范围，超过5个点就要检查是不是校准数据出了问题。

视频分割场景还有一个额外坑：长期依赖。因为SAM2会跨帧维护一个memory bank，量化误差会在长序列里累积，帧数一多，掩码质量可能肉眼可见地劣化。我的建议是每处理几百帧就用短期窗口重置一下memory，防止误差滚雪球。

6. 避坑实录：常见故障与排查思路

6.1 常见问题速查表

玩量化模型，总会遇到一些反复出现的坑。我把这些年遇到的高频问题整理成一张表，方便你照着排查：

6.2 三条最值得记住的实操经验

第一条，同一档位下，不同量化工具生成的模型质量可能差不少。AutoAWQ和AutoGPTQ虽然都是4bit，但对同一个模型的量化效果并不完全相同。我会固定一套评测集，切换工具后统一对比，不凭感觉下结论。

第二条，GGUF文件名里的K_S和K_M不能随便换。K_S是小尺寸变体，显存省一点，但有些任务效果会明显弱于K_M。如果显存紧张程度不是特别高，尽量选K_M这个主流档。

第三条，跑任何量化模型之前，先跑一遍perplexity测试，再跑业务测试。perplexity能快速暴露模型是不是已经“坏了”，避免你花半天调业务提示词，结果发现是量化文件本身的问题。

6.3 我建议的量化模型验收流程

说到底，模型量化策略没有一个万能答案。我自己的固定流程是这样的：先根据显卡显存和业务上下文长度，用表格里的估算公式圈出两三个候选档位；然后每个档位下载对应量化模型，跑一个包含10到20个问题的小评测集，覆盖你业务里最典型的场景；最后看两样东西——语义完整性和任务完成率，而不是只看跑分。这样选出来的量化版本，才真正服务于你的业务。

最后说一个我个人的体会：我见过太多人死磕最高量化档位，非要上Q3甚至Q2，结果业务效果崩了又怪模型不行。其实换个思路，把上下文缩短一点、batch调小一点，用Q5_K_M往往就全都解决了。量化是手段，跑得好才是目的。