1. 大模型量化到底在解决什么问题先把结论摆在前面大模型量化这件事本质上就是在用极小的精度损失换取数倍的显存节省和推理加速。如果你手头只有一张 24G 显存的消费级显卡却想跑一个 70B 参数的模型不量化基本没戏——FP16 精度下 70B 模型光权重就要占 140GB 左右而 INT4 量化后能压到 35GB 上下配合分层加载甚至能在更小的卡上跑起来。我最初接触量化是在部署一个 13B 模型的时候FP16 权重接近 26GB单卡根本放不下推理框架直接 OOM。当时第一反应是换更大的卡但成本摆在那里后来转向量化方案用 GPTQ 做了 INT4 量化模型体积降到 7GB 左右推理速度反而比 FP16 快了将近一倍。这个经历让我意识到量化不是降级妥协而是部署环节的刚需技术。量化要解决的核心矛盾其实就三个显存墙、带宽墙、成本墙。显存墙好理解模型权重加 KV Cache 加激活值三者叠加很容易撑爆显存。带宽墙指的是推理时数据在显存和计算单元之间搬运的速度量化后数据量变小搬运效率自然提升。成本墙则是前两者的商业投影——同样的硬件能跑更多并发单位推理成本就下来了。适合读这篇内容的人我大致分三类一是做模型部署的工程师需要在实际项目里选量化方案二是做推理优化的同学想搞清楚 GPTQ、AWQ 这些方法背后的原理差异三是刚入门大模型、想搞明白为什么量化后模型还能用的开发者。不管你是哪一类我都会尽量把原理讲透把实操细节补全。提示量化不是万能药。有些任务对数值精度极其敏感比如长链推理、精确数学计算量化后可能出现明显的质量下降。选方案前一定要在自己的任务上做评测别只看论文里的困惑度指标。2. 量化技术的整体分类与选型逻辑2.1 从量化时机看PTQ 与 QAT 的分野量化方法按介入时机分两大类训练后量化PTQ和量化感知训练QAT。这个区分非常关键因为它直接决定了你的工作量和最终效果。PTQ 是在模型训练完成之后再做量化不需要重新训练只需要一小批校准数据来统计数值分布。GPTQ、AWQ、GGUF 里的各种量化方案基本都属于这一类。优点是成本低、上手快缺点是精度损失相对大一些尤其是量化到 4bit 以下时。QAT 则是在训练过程中就模拟量化误差让模型提前适应低精度表示。效果通常更好但需要完整的训练流程和算力普通开发者很难负担。实际工程里除非你对精度有极致要求否则 PTQ 基本够用。我个人的经验是7B 到 70B 这个区间的模型PTQ 做 INT4 量化在大多数对话和生成任务上质量损失可以接受。真正需要 QAT 的场景往往是量化到 2bit 甚至 1bit 的极端压缩或者任务本身对精度极其敏感。2.2 从量化粒度看per-tensor、per-channel 与 per-group量化粒度决定了多少个参数共享一套量化参数。粒度越细精度越高但元数据开销也越大。粒度类型说明精度开销per-tensor整个张量共享一组 scale/zero-point最低最小per-channel每个通道一组参数中等中等per-group每 group如 128 个元素一组最高较大GPTQ 默认用的是 per-group 量化group size 通常设 128。这个数字不是随便定的——group 太小元数据占比上升压缩率打折扣group 太大精度又掉得厉害。128 是实践中比较平衡的选择。2.3 从数据类型看对称量化与非对称量化对称量化把浮点映射到以 0 为中心的整数区间比如 INT4 的 [-8, 7]。非对称量化则允许零点偏移映射到 [0, 15] 这样的区间。非对称量化对激活值分布偏移较大的场景更友好但计算稍复杂。权重量化通常用对称量化就够了因为权重分布大多接近零均值。激活值量化则更常用非对称因为激活值经过 ReLU 之类的非线性后往往全为正。3. GPTQ 与 AWQ 的核心原理拆解3.1 GPTQ基于二阶信息的逐层量化GPTQ 的核心思想可以用一句话概括在量化每一层时用校准数据的最小二乘误差来指导权重的舍入方向。传统 round-to-nearest 量化就是把每个权重独立地四舍五入到最近的量化格点但这样忽略了权重之间的相关性。GPTQ 的做法是把量化问题建模成一个逐列的优化问题量化第 i 列时用 Hessian 矩阵二阶导数信息来补偿已经量化列带来的误差让整体输出误差最小。具体来说GPTQ 的流程大致是用校准数据跑一遍前向收集每层的输入激活计算 Hessian 矩阵 H 2XX^T。对权重矩阵按列逐个量化每量化一列就用 H 的逆来更新剩余未量化的列补偿误差。加入阻尼项和块状更新保证数值稳定性。这里有个实操细节Hessian 的逆计算容易数值不稳定GPTQ 用了 Cholesky 分解和阻尼因子来缓解。阻尼因子通常设 0.01 左右太小不稳定太大补偿效果变差。GPTQ 的优点是精度高、压缩率好INT4 下困惑度损失通常很小。缺点是量化过程需要跑校准数据70B 模型量化可能要几个小时而且对校准数据的选择有一定敏感性。3.2 AWQ保护重要权重的激活感知量化AWQ 的出发点和 GPTQ 不同。它观察到权重的重要性不是均匀的少数显著权重对输出影响很大量化时应该保护它们。那怎么判断哪些权重重要AWQ 的思路是看激活值的幅度。如果某个通道的输入激活幅度很大那么对应的权重即使微小扰动也会被放大这些权重就重要。于是 AWQ 在量化前先对权重做一次逐通道的缩放重要通道乘以一个大于 1 的缩放因子量化后再除回来。这样重要权重的相对量化误差就变小了。AWQ 的关键公式是寻找最优缩放因子 s使得量化误差最小s* argmin_s || Q(W · diag(s)) · diag(s)^-1 · X - W · X ||实际实现里AWQ 通过网格搜索找每个通道的缩放因子搜索范围通常是 [0, 1] 的若干离散值。这个过程比 GPTQ 快很多而且不需要 Hessian 计算。AWQ 的优点是量化速度快、对校准数据不敏感、推理时可以用更高效的 kernel。缺点是精度在某些任务上略逊于 GPTQ尤其是极低比特场景。3.3 GPTQ 与 AWQ 的实测对比我在一个 13B 模型上做过对比测试校准数据用 128 条通用语料量化到 INT4评测集是自建的对话质量集和几个标准 benchmark。结果大致如下指标FP16 基线GPTQ INT4AWQ INT4显存占用26GB7.2GB7.0GB首 token 延迟320ms180ms165ms生成速度42 tok/s78 tok/s85 tok/s困惑度5.826.016.08对话质量主观分4.6/54.4/54.3/5可以看到两者在显存和速度上差距不大GPTQ 在困惑度和主观质量上略好AWQ 在速度上略优。如果你的场景对质量更敏感选 GPTQ如果追求吞吐和低延迟AWQ 更合适。注意这个对比是在特定模型和任务上做的不同模型、不同校准数据下结论可能反转。选型前务必自己跑一遍评测。4. 量化实操全流程与关键参数4.1 环境准备与依赖安装量化工具链目前比较成熟的是 AutoGPTQ 和 AutoAWQ 两个库。我一般用 conda 建独立环境避免依赖冲突。conda create -n quant python3.10 -y conda activate quant pip install torch2.1.0 --index-url https://download.pytorch.org/whl/cu118 pip install auto-gptq0.6.0 pip install autoawq0.1.8 pip install transformers4.36.0 accelerate0.25.0 datasets2.15.0版本这块要特别注意auto-gptq 和 transformers 的版本兼容性比较敏感版本对不上经常报一些莫名其妙的错。我踩过的坑是 transformers 升到 4.37 后 auto-gptq 加载模型时报 key 不匹配回退到 4.36 就好了。4.2 校准数据的准备与处理校准数据的质量和数量直接影响量化效果。我的经验是数量128 到 512 条足够再多收益递减。来源最好用和目标场景分布接近的语料。做对话模型就用对话数据做代码模型就用代码数据。长度每条 512 到 2048 token 比较合适太短覆盖不了长程依赖太长量化时间飙升。from datasets import load_dataset def build_calib_data(tokenizer, n_samples256, seq_len1024): dataset load_dataset(wikitext, wikitext-2-raw-v1, splittrain) calib [] for sample in dataset: text sample[text].strip() if len(text) 100: continue ids tokenizer(text, return_tensorspt, truncationTrue, max_lengthseq_len).input_ids if ids.shape[1] seq_len: continue calib.append(ids) if len(calib) n_samples: break return calib这里有个细节校准数据不要用训练集本身否则量化时会过拟合到训练分布泛化性变差。用同领域的其他数据更稳妥。4.3 GPTQ 量化的完整代码与参数说明from transformers import AutoTokenizer, AutoModelForCausalLM from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig model_path your-model-path output_path your-model-gptq-int4 tokenizer AutoTokenizer.from_pretrained(model_path, use_fastTrue) calib_data build_calib_data(tokenizer, n_samples256, seq_len1024) quantize_config BaseQuantizeConfig( bits4, group_size128, desc_actTrue, damp_percent0.01, symTrue, ) model AutoGPTQForCausalLM.from_pretrained( model_path, quantize_configquantize_config, trust_remote_codeTrue, ) model.quantize(calib_data, batch_size1, use_tritonFalse) model.save_quantized(output_path, use_safetensorsTrue) tokenizer.save_pretrained(output_path)几个关键参数我逐个解释bits4量化位宽。4bit 是精度和压缩率的平衡点3bit 以下质量下降明显。group_size128分组大小。128 是默认值显存紧张可以调到 64但元数据开销上升。desc_actTrue是否按激活幅度重排权重列。开启后精度更好但推理时会有额外的重排开销速度略降。damp_percent0.01Hessian 阻尼因子。数值不稳定时调大但别超过 0.1。symTrue对称量化。权重量化一般用对称激活量化用非对称。4.4 AWQ 量化的完整代码与参数说明from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path your-model-path output_path your-model-awq-int4 model AutoAWQForCausalLM.from_pretrained(model_path, trust_remote_codeTrue) tokenizer AutoTokenizer.from_pretrained(model_path, trust_remote_codeTrue) quant_config { zero_point: True, q_group_size: 128, w_bit: 4, version: GEMM, } model.quantize(tokenizer, quant_configquant_config, calib_datacalib_data) model.save_quantized(output_path) tokenizer.save_pretrained(output_path)AWQ 的参数更少主要就是w_bit和q_group_size。version 选 GEMM 还是 GEMV 取决于你的推理场景GEMM 适合 batch 推理GEMV 适合单条低延迟场景。4.5 量化后的推理与性能验证量化完必须做验证不能直接上线。我一般从三个维度检查加载测试确认模型能正常加载权重形状和量化配置匹配。质量评测跑标准 benchmark 加自建评测集对比 FP16 基线。性能测试测首 token 延迟、生成速度、显存占用、并发吞吐。from auto_gptq import AutoGPTQForCausalLM from transformers import AutoTokenizer import torch, time model AutoGPTQForCausalLM.from_quantized( output_path, devicecuda:0, use_safetensorsTrue, use_tritonFalse, trust_remote_codeTrue, ) tokenizer AutoTokenizer.from_pretrained(output_path) prompt 请解释一下什么是大模型量化。 inputs tokenizer(prompt, return_tensorspt).to(cuda:0) torch.cuda.synchronize() start time.time() with torch.no_grad(): out model.generate(**inputs, max_new_tokens256, do_sampleFalse) torch.cuda.synchronize() elapsed time.time() - start print(tokenizer.decode(out[0], skip_special_tokensTrue)) print(f生成耗时: {elapsed:.2f}s, 速度: {256/elapsed:.1f} tok/s) print(f显存占用: {torch.cuda.max_memory_allocated()/1024**3:.2f} GB)5. 量化部署中的常见问题与排查技巧5.1 量化后质量下降明显怎么办这是最常见的问题。排查思路按优先级来第一检查校准数据。如果校准数据和目标场景分布差异大量化误差会被放大。换成领域内数据重新量化往往能明显改善。第二调整 group_size。从 128 降到 64 或 32精度会提升代价是模型体积增大。我遇到过 group_size128 时某些层质量崩掉降到 64 就正常了。第三开启 desc_act。GPTQ 里这个选项对精度影响不小尤其是深层模型。开启后推理速度会降 5% 到 10%但质量提升值得。第四检查是否有异常层。有些模型的某些层对量化特别敏感可以对这些层保持 FP16其余层量化做混合精度。AutoGPTQ 支持通过modules_to_not_convert指定跳过的层。5.2 量化过程 OOM 或耗时过长70B 模型量化时显存不够是常态。解决方案降低 batch_size量化时的 batch_size 设 1别贪多。分层量化用low_cpu_mem_usageTrue配合 accelerate 的分层加载。分片保存max_shard_size设小一点比如 2GB避免单文件过大。用多卡AutoGPTQ 支持多卡量化但配置稍复杂需要 device_map 配合。耗时方面13B 模型单卡量化大概 30 到 60 分钟70B 可能要 4 到 8 小时。建议在晚上跑别占着开发机。5.3 推理速度没有预期提升量化后速度没提升甚至变慢通常是这几个原因现象可能原因解决方案速度几乎没变用了 FP16 kernel 跑量化权重确认加载了量化专用 kernel速度变慢desc_act 开启 小 batch关闭 desc_act 或增大 batch首 token 慢权重反量化开销大用 fused kernel如 exllama吞吐上不去batch 太小增大 batch用 GEMM 版本我实测下来exllama kernel 比原生 kernel 快 30% 以上但兼容性要求高模型结构太特殊可能不支持。Triton kernel 是折中方案兼容性好速度也不错。5.4 量化模型跨框架加载失败GPTQ 模型在不同框架间迁移经常出问题。核心原因是量化配置的元数据格式不统一。比如 AutoGPTQ 保存的 config 里 group_size、desc_act 这些字段vLLM 或 TensorRT-LLM 读取时可能解析方式不同。解决办法是保存时用 safetensors 格式config 里显式写全所有量化参数迁移前先用目标框架的加载脚本做一次 dry run。我踩过的坑是 desc_act 字段在某个版本里默认值变了导致加载后精度对不上排查了半天才发现是配置问题。提示量化模型上线前一定要在目标推理框架里做完整的回归测试别只在量化工具自己的加载器里验证。6. 量化方案的选型建议与经验总结6.1 不同场景下的方案推荐选量化方案没有银弹得看具体场景。我整理了一个决策表场景推荐方案理由消费级显卡部署 7B-13BGPTQ INT4精度好生态成熟高并发服务 70BAWQ INT4 GEMM吞吐高延迟低边缘设备 CPU 推理GGUF Q4_K_M格式通用llama.cpp 支持好极致压缩 2-3bitQAT 或 AWQ 特殊 kernelPTQ 在极低比特下质量崩对精度极敏感混合精度敏感层保 FP16平衡质量和体积6.2 我踩过的几个坑坑一校准数据用了英文部署场景是中文。量化后中文生成质量明显下降换成中文校准数据后恢复正常。校准数据的语言和领域一定要匹配。坑二group_size 设太小导致模型体积反而变大。group_size32 时每 32 个权重就要存一组 scale 和 zero-point元数据占比超过 10%压缩率打折扣。128 是甜点区。坑三量化后没做回归测试直接上线。结果某个特定类型的输入触发质量崩溃用户反馈才发现。量化后必须跑完整的回归测试集别偷懒。坑四不同框架的量化配置不兼容。在 AutoGPTQ 里量化好的模型拿到 vLLM 里加载报错。后来发现是 config 里的 version 字段没写对。跨框架迁移前先查目标框架的文档确认支持的量化格式和配置字段。6.3 量化技术的后续演进方向从最近的论文和开源项目看量化技术有几个明显的演进方向。一是更细粒度的混合精度不是整层统一比特而是根据权重重要性动态分配比特数。二是量化与推理框架的深度协同比如专门为量化权重设计的 kernel把反量化开销压到最低。三是校准数据的自动化选择用少量样本自动挑出最有代表性的校准集减少人工调参。这些方向目前还在演进中工程落地程度不一。我的建议是生产环境优先选成熟方案新方案先在小规模场景验证别拿核心业务当试验田。最后分享一个实用技巧量化模型的效果和原始模型的质量强相关。如果 FP16 模型本身质量就一般量化后只会更差。所以量化前先把原始模型调好别指望量化能救一个本身就不行的模型。这个顺序搞反了后面怎么调参都是白费劲。