直接用AutoGPTQForCausalLM加载预量化GPTQ权重最省事，需满足transformers≥4.40、auto-gptq==0.10.0，并指定device_map="auto"，否则易报错；自量化时须调group_size=128、校准数据≥256个长句，且MLA结构需特殊适配。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
直接用 GPTQForCausalLM 加载已量化权重最省事
如果你拿到的是别人已经跑好、公开发布的 GPTQ 4bit 权重（比如 Hugging Face 上标着 gptq-4bit-128g 的 DeepSeek-R1-7B），不用自己量化，直接加载就能跑。关键就两步：transformers 版本得 ≥ 4.40，auto-gptq 得装对：
-
pip install auto-gptq==0.10.0 transformers>=4.40.0（别用最新版auto-gptq，0.11+ 对 DeepSeek-R1 的mla层支持不稳） - 加载时指定
device_map="auto"，否则可能卡在 CPU 上不动
典型报错如 AttributeError: 'NoneType' object has no attribute 'shape'，基本就是 auto-gptq 版本不兼容或没设 device_map。
自己跑 GPTQ 量化要注意 group_size 和校准数据
GPTQ 不是“一键量化”，它需要在校准数据上逐层优化，而 DeepSeek-R1 的 MLA（多头潜在注意力）结构会让默认配置崩掉。实测下来必须调整两个参数：
-
group_size=128：比默认的 128 更稳妥；设成 -1（全权重一组）会爆显存，设成 64 则精度掉得明显（MMLU -1.8%） - 校准数据不能只喂 128 个样本——DeepSeek-R1 对激活分布敏感，至少要 256 个长度 ≥ 512 的中文句子，推荐用
pile-uncopyrighted子集或自建的法律/技术语料
命令行工具 text-generation-inference 不支持 R1 的 MLA 结构，必须用 Python 脚本调 optimum.gptq，且得 patch 掉 MLAAttention.forward 里硬编码的 torch.bfloat16 类型检查。
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
AWQ 量化更吃硬件，但对 R1 的 MLA 兼容性更好
AWQ 需要实际跑一遍前向来统计激活值，所以你得有足够显存先 load 原始 FP16 模型。以 DeepSeek-R1-7B 为例，FP16 占约 14GB 显存，意味着 RTX 4090（24GB）刚好够，RTX 3090（24GB）也行，但 RTX 4080（16GB）会 OOM。这时别硬扛，换用 llm-awq 的 export 模式，在 CPU 上做激活分析（慢但稳）：
- 安装：
pip install llm-awq==0.2.6（0.2.7 有 kernel crash bug） - 关键参数：
q_group_size=128、zero_point=False（R1 的 KV 投影层用 zero-point 反而降精度） - 输出格式选
w4a16，别用w4a8——后者在 R1 的 MoE 门控层上会触发 nan 输出
AWQ 量化后模型不能直接用 transformers 加载，得走 AwqForCausalLM，且 trust_remote_code=True 必须加，否则找不到 R1 自定义的 MLABlock 类。
量化后推理别忽略 kv_cache_dtype 这个隐藏坑
无论 GPTQ 还是 AWQ，量化只动了权重，KV cache 默认还是 FP16。DeepSeek-R1 的 MLA 机制本身就在压缩 KV，如果再把 cache 强制转成 INT8，会叠加误差导致长文本生成乱码（比如重复 token 或突然截断）。实测有效解法只有两个：
- 保持 KV cache 为
torch.float16，哪怕显存多占 1–2GB - 或者启用
flash-attn==2.6.3+--kv-cache-dtype fp8_e4m3（仅限 A100/H100，消费卡不支持）
很多教程跳过这点，结果跑着跑着输出变成“的的的的”或“```json{```”，其实是 KV cache 精度塌缩了，不是权重量化的问题。
