简介面向大模型压缩与高效推理场景GPTQ是一种基于近似二阶信息的生成式预训练Transformer一次性权重量化方法。它能在约4个GPU小时内将1750亿参数模型的权重压缩至3或4比特精度损失几乎可忽略较此前一次性量化方法压缩比提升两倍以上并首次支持在单个GPU上运行175B模型进行生成式推理在2比特或三值等极端量化下也仍有合理精度。这份PDF收录了发表于ICLR 2023的原始论文系统阐述二次信息近似、动态量化与逐层精度调整原理并给出A100/A6000上的端到端推理加速实验和开源实现地址适合研究模型压缩、本地化部署或量化推理的开发者与算法工程师精读。资源为单个PDF文件大小510KB章节完整便于查阅。已有344人学习下载可作为理解GPTQ原理、复现实验及对比其他量化方法的直接参考资料。1. 大模型量化绕不开的一个名字是 GPTQ大模型量化绕不开的一个名字是 GPTQ。8G 显存的卡想跑 7B 模型fp16 光权重就要 14Gint8 也要约 7G再加上激活值、KV cache 等开销直接爆显存。换大卡不现实重训练又没那个算力剩下最现实的一条路就是训练后量化而 GPTQ 正是这条路上投入产出比最高的一种方案不需要反向传播不更新参数只用一个小校准集走一遍前向就能把权重压到 4bit 甚至更低。7B 模型量化后在 6G 显存上能跑推理速度往往还比 fp16 更快。这篇笔记写给想把开源模型部署到本地或低配服务器的人。我先讲清楚 GPTQ 在做什么、什么时候不该用再给一个可照着跑的最小量化脚本接着讲加载验证和部署最后把血泪经验里的坑一条条列出来。新手可以按步骤照做熟手可以重点看 3.3 的参数边界和第五章的排查记录。2. 从原理和选型出发为什么量化绕不开 GPTQ什么时候不该用2.1 从 OBQ 到 GPTQHessian 矩阵与逐层误差补偿量化本质上就是把连续的浮点权重映射到离散的整数点。最直接的做法是四舍五入问题是这种误差在深层网络里会被一层层放大尤其大模型动辄几十上百层最后输出的 token 可能整个跑偏。GPTQ 的思路不是把每个权重孤立地取整而是量化一部分权重后用剩下的权重去补偿已经产生的量化误差。这个思路最早来自 OBQOne-Bit Quantization方法。OBQ 在每一列里挑“当前量化误差影响最小”的那个权重先量化量化之后再用 Hessian 矩阵更新其他权重把误差摊薄。原理很漂亮但计算量太大每量化一个权重都要重新算一次补偿在大模型上行不通。GPTQ 做的事情是把 OBQ 从“逐个挑最优顺序”改成“固定顺序、按列批量处理”并利用数值线性代数的技巧大幅降低更新成本。具体到实现GPTQ 需要先准备一个校准数据集把几百条文本喂给模型走一遍前向在每一层记录输入的激活值用激活值外积的累计来近似 Hessian 矩阵 H ≈ X Xᵀ。拿着这个 H量化某一列权重时对角项用于归一化补偿量非对角项告诉你怎么把误差分摊到前面还没量化的权重上。校准集通常只要一百多条文本整个前向过程在单卡上几分钟就能结束。这里有个容易误解的点GPTQ 全程不做梯度回传也不更新原始权重它只做“近似替换”。所以量化后的模型不需要重训练校准集只是用来估计激活分布不是用来微调的。这也是它和量化感知训练QAT最大的区别——QAT 要在训练过程中模拟量化误差成本高得多GPTQ 是纯训练后量化适合没有大规模算力、想让现有模型尽快跑起来的场景。2.2 GPTQ、AWQ 与 int8 动态量化怎么选量化方案不止 GPTQ 一种选型时先想清楚你的部署场景是 GPU 显存受限、CPU 推理、还是边缘设备。常见的选择有这么几类。方案权重位宽需要校准集需要重训典型场景GPTQ4bit / 3bit是否GPU 显存受限服务端部署AWQ4bit是否激活值分布敏感的大模型动态 int8如 LLM.int8 风格8bit否否快速接入、显存余量尚可GGUF 系量化格式2bit~8bit 多档否否CPU / 边缘设备、跨平台GPTQ 的最大优势是生态成熟几乎所有主流推理框架都原生支持加载 GPTQ 格式的量化权重我在本地用现成接口就能直接跑通不需要写自定义内核。AWQ 的精度在某些模型上表现更好因为它会观察激活值的分布、把重要通道保留高精度但它的实现依赖更多有的环境装起来要折腾半天。如果你的部署目标主要是 CPU那 GGUF 更合适它对 CPU 推理做了专门优化而且位宽档位更灵活。我自己选型时一般先看两件事一是推理设备是不是 GPU二是模型有没有现成的量化校准脚本。GPU 上用 GPTQ 是默认项除非遇到明显的精度掉点才去试 AWQ。当然也有不该用 GPTQ 的时候。模型小于 1B 时量化省下的显存有限精度损失却相对明显不如直接 fp16。如果任务对单 token 的数值极其敏感比如长串数学计算4bit 的累积误差可能导致中间某一位算错这类场景建议保留高精度权重或只量化部分层。还有一种情况是模型很快要拿去接着做微调频繁在量化权重和浮点权重之间切换容易把自己绕晕不如先训完再一次性量化。3. 本地跑通 GPTQ 最小流程环境、量化脚本与 3 个必调参数3.1 环境准备conda 环境与依赖组合开始之前先把环境收拾干净。GPTQ 依赖 torch 和 auto-gptq 两个核心库这两个库之间的版本配合比较敏感装错组合经常在加载模型时才报算子缺失排错很浪费时间。我一般会新建一个干净的 conda 环境单独给量化用不跟日常实验环境混在一起。conda create -n gptq python3.10 -y conda activate gptq pip install torch --upgrade pip install auto-gptq pip install transformers逻辑说明python 3.10 是当前兼容性最好的版本3.11 及以上在个别旧版 auto-gptq 上会出编译问题。torch 先装最新稳定版再装 auto-gptq顺序不要反因为 auto-gptq 在安装时会检测 torch 版本决定编译开关。提示如果你的机器有 GPU建议先确认本机 CUDA 版本再按对应版本的官方 pip 源说明安装 torch。装错 CUDA 版本不会在 import 时报错但量化跑起来会很慢或者直接报“CUDA driver 版本不匹配”。装完后跑一下python -c import auto_gptq; print(auto_gptq.__version__)确认没有 import 报错。这一步能拦下八成环境问题。3.2 量化脚本最小可用代码环境就绪后下面这份脚本就是最常见的最小量化流程。它做的事情是加载一个本地因果语言模型配好 4bit GPTQ 参数用校准集走一遍前向量化最后把量化结果保存到新目录。import torch from transformers import AutoModelForCausalLM, AutoTokenizer, GPTQConfig model_dir ./your-model-dir # 本地模型目录需包含 config.json 和权重文件 calib_file ./calib.jsonl # 校准集每行一条文本建议 128~256 条 tokenizer AutoTokenizer.from_pretrained(model_dir) quant_config GPTQConfig( bits4, group_size128, desc_actFalse, damp_percent0.01, datasetcalib_file, ) model AutoModelForCausalLM.from_pretrained( model_dir, quantization_configquant_config, device_mapauto, torch_dtypetorch.float16, ) model.save_pretrained(./your-model-gptq-4bit) tokenizer.save_pretrained(./your-model-gptq-4bit)逻辑说明from_pretrained在加载权重的过程中按层完成量化不是先加载 fp16 再额外转换所以这个脚本不会出现“内存峰值 原模型 量化模型”的两倍占用。dataset参数接收校准集路径库内部会逐条读取并对模型做前向估算每层激活分布。保存时会把 quantize_config 一并写进新目录之后加载时需要这个配置文件才能正确反量化。参数说明bits4是位宽一般用 4显存极度紧张才考虑 3group_size128表示每 128 个权重共享一组量化参数数值越小精度越好但占用略高desc_actFalse关闭按激活顺序排序量化速度更快精度略降damp_percent0.01是 Hessian 矩阵对角线的阻尼系数防止某些元素过小导致除零。校准集不要直接从网上随便拉一篇长文丢进去。我习惯从自己的文本库里随机抽 128 条每条截断到 1024 token 以内混合不同风格和语言。校准集的质量直接影响量化后模型的生成质量这个在 5.1 里会重点展开。3.3 三个必调参数及其调整边界第一次跑通后你会想调参数看效果。这三个参数是 GPTQ 里最值得花时间摸清边界的。bits是显存和精度的第一杠杆。4bit 是大多数人的甜点位3bit 能把显存再压 25% 左右但模型容量下降明显逻辑推理类任务容易露出马脚。2bit 我基本不建议碰生成质量劣化到没法用。如果实在塞不进显存先砍上下文长度、换小批次都比降到 2bit 更划算。group_size128是经验值。改成 256 能再省一点显存但量化粒度变粗误差更容易累积改成 64 精度会更好显存占用也会增加。对 7B 模型来说128 和 64 的差别在普通任务上肉眼几乎看不出来但长文本生成时 64 会更稳。如果你在跑代码生成或数学题优先保 64。desc_act是个容易被忽略的开关。打开后模型会按激活值的方差给每一列排重要性优先量化不重要的列精度更好但推理时多一步 permutation速度会慢 10%~20%。显存很紧的时候我一般关掉它换速度对精度有硬性要求且显存有余量就打开。注意desc_actTrue时group_size必须是 128 的倍数这是底层实现的限制记不住也没关系报错时会提醒你。4. 加载与验证量化模型部署到低显存环境要做的三件事4.1 量化模型的加载与设备映射量化完成后加载到推理环境的方式和普通模型略有不同。你不再需要传quantization_config因为量化配置已经保存在模型目录里直接加载即可。import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_dir ./your-model-gptq-4bit tokenizer AutoTokenizer.from_pretrained(model_dir) model AutoModelForCausalLM.from_pretrained( model_dir, device_mapauto, torch_dtypetorch.float16, ) model.eval()逻辑说明device_mapauto会按照你的显存情况自动分配层显存不够时会把部分层放到 CPU虽然慢一点但能保证跑起来。如果你的卡显存足够放下一整个模型也可以指定device_map{: 0}强制全部放 GPU省去层间通信开销。加载后可以用model.hf_device_map查看每一层被分配到了哪里。我见过不止一次加载后模型全跑到 CPU 上、推理慢得离谱的情况基本都是 device_map 设置太保守导致的。注意加载时torch_dtype要和量化保存时保持一致统一用 float16。如果保存时是 float16、加载时却写了 float32有些版本会报 dtype 不匹配有些版本会静默地做一次额外转换导致显存直接翻倍。4.2 用困惑度与生成质量做双重验证量化完不能只看能不能加载还得验证质量。最常见的指标是困惑度perplexityPPL它衡量模型对文本的预测能力数值越低越好。写个简单脚本对比量化前后的 PPL 是最直接的做法。import torch from tqdm import tqdm def evaluate_ppl(model, tokenizer, texts, max_len512): model.eval() nlls [] for text in tqdm(texts): enc tokenizer(text, return_tensorspt, truncationTrue, max_lengthmax_len) input_ids enc.input_ids.to(model.device) with torch.no_grad(): out model(input_ids, labelsinput_ids) nlls.append(out.loss.detach()) avg_nll torch.stack(nlls).mean() return torch.exp(avg_nll).item() # 准备一批评测文本建议和校准集不同源 with open(./eval_texts.jsonl) as f: eval_texts [line.strip() for line in f if line.strip()] ppl_quantized evaluate_ppl(model, tokenizer, eval_texts) print(fQuantized PPL: {ppl_quantized:.2f})逻辑说明out.loss是当前批次所有 token 的平均交叉熵损失取指数后就是困惑度。这里直接拿整段文本的预测任务来测不需要额外构造标签因为 labels 就是输入本身。评测文本要和校准集分开不然会高估量化模型的表现。PPL 变化多少算可接受我的经验是4bit 量化后 PPL 上升 0.5~1.5 属于正常范围肉眼一般看不出来超过 2 就要检查校准集质量和参数配置。但 PPL 只是第一关它反映的是统计层面的预测能力不代表生成语义没崩。我会再跑几组固定 prompt 的生成结果把量化前后的输出并排对比看是否有复读、乱码、答非所问。这一步才真正决定这个量化模型能不能上线。4.3 低显存部署的实操经验真正部署到低显存环境时我踩过的几个规律可以共享。生成参数要克制。量化模型省下的显存很容易被max_new_tokens2048加num_beams4一口吃掉。推理时开着use_cacheTrue能省大量重复计算beam search 在低显存场景下能不开就不开用贪心解码配合top_p采样往往更稳。上下文长度是隐藏的显存杀手。KV cache 随序列长度线性增长同样的模型把上下文从 4096 砍到 2048省下的显存比把位宽从 4bit 降到 3bit 还多。显存不够时先砍上下文别急着降位宽。设备映射默认是“能放 GPU 就放 GPU”但在显存边缘徘徊的场景我反而建议手动分配。把前几层放 CPU、后面的大头放 GPU虽然跨设备传输有开销但至少不会在生成长文本时突然 OOM 崩溃。这种方案适合离线批量推理不适合在线实时服务。5. GPTQ 实操避坑五条翻车记录与现场排查5.1 校准集语言不匹配中文生成乱码现象用英文校准集量化一个中文模型量化后生成的句子出现大量乱码和重复个别 prompt 直接输出空内容。原因GPTQ 依赖校准集估计激活分布校准集全是英文模型对中文 token 的激活分布完全没有被覆盖量化误差集中在中文相关权重上生成时这些误差被放大。解决校准集里按比例混入中文语料我一般中英混合 7:3总量 128 条即可。如果量化的是垂直领域模型校准集最好也从同类语料里抽——用通用文本量化法律模型效果一样会翻车。5.2 target_modules 覆盖不全显存没降下来现象量化完成后加载模型显存占用只降了 30%和预期差很远。原因默认的量化目标没有覆盖全部线性层。常见的实现里 target_modules 只默认覆盖 attention 层的 q/k/v/o 投影MLP 里的 gate/up/down 层还是 fp16权重占了整个模型一大半。解决加载后打印model.config.quantization_config.target_modules确认覆盖范围。如果发现缺失在 GPTQConfig 里显式传入完整的 target_modules 列表把门控层、上下投影层全部加入。改完重新量化显存占用才会真正降下来。5.3 加载时 dtype 不匹配报错现象量化保存一切正常换一台机器加载时报 “dtype mismatch” 或者 key error有时干脆就是 shape 对不上。原因保存和加载时的torch_dtype设置不一致。保存用 float16加载侧写了 float32反量化时按错误的浮点精度读低比特块数值全部错位。解决统一用torch_dtypetorch.float16保存和加载。如果是从网上下载别人量化好的模型先看它的 config 里写了什么 dtype照着传。5.4 量化过程 OOM现象模型不大显卡也不差但跑量化脚本时中途爆显存。原因校准集里混入超长文本或者校准集 batch 默认不是 1。校准过程要完整走一遍前向长文本的中间激活值会临时占掉大量显存这比推理时的峰值高不少。解决校准集每条文本截断到 1024 token 以内在 GPTQConfig 里把校准 batch 设为 1。另外把device_mapauto加上让加载阶段就分摊显存压力。5.5 长序列生成的误差累积现象短 prompt 生成没问题一旦上下文变长量化模型就出现重复率飙升、甚至整段复读。原因量化误差在长序列里逐 token 累积。每一层虽小但几十层乘以几百个 token 后分布偏移越来越明显采样时更容易扎进重复区域。解决保留 embedding 层和 lm_head 为高精度只量化中间的线性层。如果已经量化完可以在生成时调高repetition_penalty到 1.1~1.2能压住一部分复读现象但根治还是要从量化范围下手。6. 进阶技巧位宽、校准集与精度恢复的平衡量化做到后面你会发现参数组合不是死的而是要跟模型规模和任务要求配着调。这里分享几个我摸出来的技巧。校准集的多样性比体量重要得多。128 条来源分散的文本效果往往好过 1024 条同一来源的文章。我习惯从不同业务线、不同文体里各抽几十条拼起来而不是拿一个长文档切块。换校准集后一定重跑一遍 4.2 的评测脚本量化这事有点玄学同一个模型换校准集 PPL 波动 1 个点是常事。精度恢复不一定要全局降位宽。更高效的做法是分层配置把靠近输出端的最后几层、以及容易受干扰的层设成 8bit其余层保持 4bit。这样显存增加很少但长文中后段的稳定性明显更好。实现上就是把 config 按层分开指定很多推理框架已经支持这种混合位宽。导出的文件一定要配套归档。我会把原版 fp16 权重保留量化后的模型连同 quantize_config 一起单独存好。之后再做一次量化先跑 PPL 对比确认变化在接受范围内再决定要不要替换线上版本。见过有人手滑删掉原版权重后面想重新调量化参数只能重新下载这就是没有后悔药了。另外一个值得养成的习惯是留一组固定的评测 prompt。不用多20 条覆盖常用场景就够每次量化完跑一遍记录生成结果。这样既能看到语义层面的变化也能对比生成速度。不要只盯 PPL——PPL 降了生成却崩掉的情况在低比特量化里真的发生过。最后补一句4bit GPTQ 不是万能药它是显存、速度、精度三者之间的一个平衡点。上手先跑通最小流程再根据你的模型和场景慢慢调位宽和校准集这两个变量足够你玩出很多组合。希望帮到你。本文还有配套的精品资源点击获取