简介：面向大模型压缩与高效推理场景，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 光权重就要 14G，int8 也要约 7G，再加上激活值、KV cache 等开销直接爆显存。换大卡不现实，重训练又没那个算力，剩下最现实的一条路就是训练后量化，而 GPTQ 正是这条路上投入产出比最高的一种方案：不需要反向传播，不更新参数，只用一个小校准集走一遍前向，就能把权重压到 4bit 甚至更低。7B 模型量化后在 6G 显存上能跑，推理速度往往还比 fp16 更快。

这篇笔记写给想把开源模型部署到本地或低配服务器的人。我先讲清楚 GPTQ 在做什么、什么时候不该用，再给一个可照着跑的最小量化脚本，接着讲加载验证和部署，最后把血泪经验里的坑一条条列出来。新手可以按步骤照做，熟手可以重点看 3.3 的参数边界和第五章的排查记录。

2. 从原理和选型出发：为什么量化绕不开 GPTQ，什么时候不该用

2.1 从 OBQ 到 GPTQ：Hessian 矩阵与逐层误差补偿

量化本质上就是把连续的浮点权重映射到离散的整数点。最直接的做法是四舍五入，问题是这种误差在深层网络里会被一层层放大，尤其大模型动辄几十上百层，最后输出的 token 可能整个跑偏。GPTQ 的思路不是把每个权重孤立地取整，而是量化一部分权重后，用剩下的权重去补偿已经产生的量化误差。

这个思路最早来自 OBQ（One-Bit Quantization）方法。OBQ 在每一列里挑“当前量化误差影响最小”的那个权重先量化，量化之后再用 Hessian 矩阵更新其他权重，把误差摊薄。原理很漂亮，但计算量太大：每量化一个权重都要重新算一次补偿，在大模型上行不通。GPTQ 做的事情是把 OBQ 从“逐个挑最优顺序”改成“固定顺序、按列批量处理”，并利用数值线性代数的技巧大幅降低更新成本。

具体到实现，GPTQ 需要先准备一个校准数据集，把几百条文本喂给模型走一遍前向，在每一层记录输入的激活值，用激活值外积的累计来近似 Hessian 矩阵 H ≈ X Xᵀ。拿着这个 H，量化某一列权重时，对角项用于归一化补偿量，非对角项告诉你怎么把误差分摊到前面还没量化的权重上。校准集通常只要一百多条文本，整个前向过程在单卡上几分钟就能结束。

这里有个容易误解的点：GPTQ 全程不做梯度回传，也不更新原始权重，它只做“近似替换”。所以量化后的模型不需要重训练，校准集只是用来估计激活分布，不是用来微调的。这也是它和量化感知训练（QAT）最大的区别——QAT 要在训练过程中模拟量化误差，成本高得多；GPTQ 是纯训练后量化，适合没有大规模算力、想让现有模型尽快跑起来的场景。

2.2 GPTQ、AWQ 与 int8 动态量化：怎么选

量化方案不止 GPTQ 一种，选型时先想清楚你的部署场景是 GPU 显存受限、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 python=3.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( bits=4, group_size=128, desc_act=False, damp_percent=0.01, dataset=calib_file, ) model = AutoModelForCausalLM.from_pretrained( model_dir, quantization_config=quant_config, device_map="auto", torch_dtype=torch.float16, ) model.save_pretrained("./your-model-gptq-4bit") tokenizer.save_pretrained("./your-model-gptq-4bit")

逻辑说明：from_pretrained在加载权重的过程中按层完成量化，不是先加载 fp16 再额外转换，所以这个脚本不会出现“内存峰值 = 原模型 + 量化模型”的两倍占用。dataset参数接收校准集路径，库内部会逐条读取并对模型做前向，估算每层激活分布。保存时会把 quantize_config 一并写进新目录，之后加载时需要这个配置文件才能正确反量化。

参数说明：bits=4是位宽，一般用 4，显存极度紧张才考虑 3；group_size=128表示每 128 个权重共享一组量化参数，数值越小精度越好，但占用略高；desc_act=False关闭按激活顺序排序量化，速度更快，精度略降；damp_percent=0.01是 Hessian 矩阵对角线的阻尼系数，防止某些元素过小导致除零。

校准集不要直接从网上随便拉一篇长文丢进去。我习惯从自己的文本库里随机抽 128 条，每条截断到 1024 token 以内，混合不同风格和语言。校准集的质量直接影响量化后模型的生成质量，这个在 5.1 里会重点展开。

3.3 三个必调参数及其调整边界

第一次跑通后，你会想调参数看效果。这三个参数是 GPTQ 里最值得花时间摸清边界的。

bits是显存和精度的第一杠杆。4bit 是大多数人的甜点位，3bit 能把显存再压 25% 左右，但模型容量下降明显，逻辑推理类任务容易露出马脚。2bit 我基本不建议碰，生成质量劣化到没法用。如果实在塞不进显存，先砍上下文长度、换小批次，都比降到 2bit 更划算。

group_size=128是经验值。改成 256 能再省一点显存，但量化粒度变粗，误差更容易累积；改成 64 精度会更好，显存占用也会增加。对 7B 模型来说，128 和 64 的差别在普通任务上肉眼几乎看不出来，但长文本生成时 64 会更稳。如果你在跑代码生成或数学题，优先保 64。

desc_act是个容易被忽略的开关。打开后，模型会按激活值的方差给每一列排重要性，优先量化不重要的列，精度更好，但推理时多一步 permutation，速度会慢 10%~20%。显存很紧的时候我一般关掉它换速度；对精度有硬性要求且显存有余量，就打开。注意desc_act=True时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_map="auto", torch_dtype=torch.float16, ) model.eval()

逻辑说明：device_map="auto"会按照你的显存情况自动分配层，显存不够时会把部分层放到 CPU，虽然慢一点但能保证跑起来。如果你的卡显存足够放下一整个模型，也可以指定device_map={"": 0}强制全部放 GPU，省去层间通信开销。

加载后可以用model.hf_device_map查看每一层被分配到了哪里。我见过不止一次加载后模型全跑到 CPU 上、推理慢得离谱的情况，基本都是 device_map 设置太保守导致的。

注意：加载时torch_dtype要和量化保存时保持一致，统一用 float16。如果保存时是 float16、加载时却写了 float32，有些版本会报 dtype 不匹配，有些版本会静默地做一次额外转换，导致显存直接翻倍。

4.2 用困惑度与生成质量做双重验证

量化完不能只看能不能加载，还得验证质量。最常见的指标是困惑度（perplexity，PPL），它衡量模型对文本的预测能力，数值越低越好。写个简单脚本对比量化前后的 PPL 是最直接的做法。

import torch from tqdm import tqdm def evaluate_ppl(model, tokenizer, texts, max_len=512): model.eval() nlls = [] for text in tqdm(texts): enc = tokenizer(text, return_tensors="pt", truncation=True, max_length=max_len) input_ids = enc.input_ids.to(model.device) with torch.no_grad(): out = model(input_ids, labels=input_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(f"Quantized PPL: {ppl_quantized:.2f}")

逻辑说明：out.loss是当前批次所有 token 的平均交叉熵损失，取指数后就是困惑度。这里直接拿整段文本的预测任务来测，不需要额外构造标签，因为 labels 就是输入本身。评测文本要和校准集分开，不然会高估量化模型的表现。

PPL 变化多少算可接受？我的经验是：4bit 量化后 PPL 上升 0.5~1.5 属于正常范围，肉眼一般看不出来；超过 2 就要检查校准集质量和参数配置。但 PPL 只是第一关，它反映的是统计层面的预测能力，不代表生成语义没崩。我会再跑几组固定 prompt 的生成结果，把量化前后的输出并排对比，看是否有复读、乱码、答非所问。这一步才真正决定这个量化模型能不能上线。

4.3 低显存部署的实操经验

真正部署到低显存环境时，我踩过的几个规律可以共享。

生成参数要克制。量化模型省下的显存，很容易被max_new_tokens=2048加num_beams=4一口吃掉。推理时开着use_cache=True能省大量重复计算；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_dtype=torch.float16保存和加载。如果是从网上下载别人量化好的模型，先看它的 config 里写了什么 dtype，照着传。

5.4 量化过程 OOM

现象：模型不大，显卡也不差，但跑量化脚本时中途爆显存。

原因：校准集里混入超长文本，或者校准集 batch 默认不是 1。校准过程要完整走一遍前向，长文本的中间激活值会临时占掉大量显存，这比推理时的峰值高不少。

解决：校准集每条文本截断到 1024 token 以内，在 GPTQConfig 里把校准 batch 设为 1。另外把device_map="auto"加上，让加载阶段就分摊显存压力。

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 不是万能药，它是显存、速度、精度三者之间的一个平衡点。上手先跑通最小流程，再根据你的模型和场景慢慢调，位宽和校准集这两个变量足够你玩出很多组合。希望帮到你。

本文还有配套的精品资源，点击获取