Transformers quantization picker 怎样按硬件选择量化方式

我在给同一个模型安排本地推理和适配器微调时，最容易踩的坑不是把权重从 FP16 换成 4-bit，而是把“能压缩”误当成“当前硬件上适合”。Transformers 的 quantization picker 更适合做第一轮筛选：先输入模型和硬件，再按在线加载、PEFT、torch.compile()、保存量化结果等目标过滤，最后把 KV cache 也算进能否装下的判断。

官方地址：https://huggingface.co/docs/transformers/quantization/overview

先把硬件和目标说清楚

选择器的第一步不是选方法，而是确认运行后端。NVIDIA 卡填 CUDA GPU，AMD 卡填 ROCm GPU，Apple Silicon 填 Metal，纯处理器环境填 CPU；Intel GPU 也要单独选择。然后明确你要做的是“加载时临时量化”、PEFT 微调、torch.compile()，还是把量化后的结果保存下来。这个目标会改变可选集合。

例如，做一次本地推理可以优先看 on-the-fly quantization；要做 QLoRA，则把 PEFT 兼容性放在前面；要编译，则不能只看 bits 数，还要看 torch.compile() 那一列。picker 的 Compare 视图适合在同一硬件和目标下横向比较，而不是拿一行结论套到所有设备。

按硬件筛选时，先看兼容性再看位宽

在 CUDA GPU 上，bitsandbytes 是容易落地的起点：Transformers 文档给出了 8-bit 和 4-bit 的加载方式，4-bit 也常用于 QLoRA。若仓库已经提供经过校准的 AWQ 或 GPTQModel 权重，则可以把它们作为推理候选，但要确认对应后端、加载器和模型格式。

ROCm、Metal 和 CPU 的判断更应该依赖矩阵，而不是“某个方法在别人机器上跑过”的经验。Quanto 的定位是设备无关的权重量化路线，支持 CPU、CUDA 和 MPS 等设备；但是否是当前模型的最佳选择，仍取决于模型结构、算子覆盖和你的目标。选择器显示不支持时，优先换方法或换运行后端，不要只改成更低位宽硬试。

把 KV cache 纳入“装得下”的判断

量化后权重变小，并不代表长上下文一定安全。生成式模型运行时还会为每个请求维护 KV cache；上下文长度、批量大小和并发数上升时，缓存会继续占用显存。因此 picker 给出的 fit 结果只能作为候选门槛：如果结果已经贴着容量边缘，生产配置还要下调上下文或并发，或者换更宽裕的硬件。

可以把验证拆成三层：先用选择器排除硬件不兼容，再用最小加载代码确认依赖和权重格式，最后用目标上下文长度做一次真实推理。不要把“模型成功加载”写成“服务可以稳定承载”，两者之间还隔着 KV cache 和吞吐。

用最小代码验证首选方案

下面示例只验证“在线 4-bit 加载”这条路径。它不代表所有模型都能用同一配置；模型仓库的架构支持、CUDA/ROCm/MPS 后端以及 transformers、accelerate、bitsandbytes 版本仍要与 picker 结果一致。

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig

model_id = "your-org/your-model"

# 4-bit 仅作为候选验证；compute dtype 要和当前 GPU 的能力匹配。
quant_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
)

# device_map 交给 Accelerate 分配；加载失败时先回到 picker 检查后端和格式。
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    quantization_config=quant_config,
    device_map="auto",
    torch_dtype=torch.bfloat16,
)

print(model.get_memory_footprint())  # 只记录权重加载后的占用，不能替代 KV cache 压测。

如果目标是 CPU、Metal 或其他后端，不要机械复制这段 bitsandbytes 配置；回到选择器按后端重新筛选，并改用返回结果对应的量化配置。最后记录三项结果：能否加载、目标上下文下的峰值内存、实际生成速度。这样“按硬件选择”才真正落到可复查的工程决策。

常见问题

4-bit 一定比 8-bit 更适合显存紧张的机器吗？

不一定。4-bit 通常更省权重空间，但可能带来兼容、精度或吞吐代价；应先看 picker 的目标能力和实机结果，再决定是否接受这笔交换。

为什么模型能加载，长文本却仍然显存不足？

加载阶段主要验证权重，长文本生成还会扩大 KV cache。降低上下文或并发、换更宽裕的设备，通常比继续盲目降位宽更容易定位问题。

已有 AWQ 或 GPTQModel 权重还需要自己量化吗？

通常先按仓库提供的格式直接加载，并确认硬件和后端兼容；只有没有合适预量化权重，或需要自定义校准数据时，才进入自己的量化流程。