Transformers 量化方法选型指南推理、微调与研究场景下的最优取舍【免费下载链接】transformers Transformers: the model-definition framework for state-of-the-art machine learning models in text, vision, audio, and multimodal models, for both inference and training.项目地址: https://gitcode.com/GitHub_Trending/tra/transformersTransformers 生态中集成了十余种量化方法从即插即用的在线量化bitsandbytes、HQQ、SINQ、torchao到需要校准数据的高精度 4-bit 方案GPTQ、AWQ再到服务于 2-bit 极限压缩的研究型方法AQLM、VPTQ、SpQR、HIGGS选择空间庞大却容易让人无从下手。本文以 docs/source/en/quantization/selecting.md 为主线按推理 / 微调 / 研究三大应用场景逐一拆解各方法的适用条件、优劣势与配置要点并深入 src/transformers/quantizers/ 源码解释其统一调度机制与基准结论帮助你为具体硬件与任务挑选最合适的量化路径。为什么需要一个选型指南量化的本质是用更低位宽的数据类型int8、int4、fp8 乃至 1-bit替代高精度权重以内存换精度的方式换取更低的显存占用与更快的推理。不同方法在是否需要校准数据、支持的硬件、可达到的位宽、是否兼容 PEFT 微调以及量化耗时上差异巨大——没有任何一种方法在所有场景下都是最优解。从源码结构看Transformers 将所有方法统一到了同一套抽象接口之下HfQuantizer 抽象基类 负责量化流程的调度而各个方法的具体实现如Bnb4BitHfQuantizer、HqqHfQuantizer、GptqHfQuantizer等分别位于 src/transformers/quantizers/ 目录下对应的quantizer_*.py文件中并通过 quantizers/auto.py 中注册的*Config如BitsAndBytesConfig、HqqConfig、GPTQConfig、AwqConfig、TorchAoConfig、SinqConfig自动路由到正确的实现。这套统一 API 意味着无论最终选择哪种方法你的接入方式都是几乎一样的——构造对应的量化 Config 对象并传给AutoModelForCausalLM.from_pretrained(..., quantization_config...)。真正的差异体现在方法本身的原理、校准需求与硬件适配这正是本文要帮你决策的部分。关于全部方法特性的横向对比表是否支持在线量化、CPU/CUDA/ROCm/Metal/Intel GPU 支持情况、位宽范围、PEFT 兼容性、序列化支持等请查阅量化概览文档如果你对量化概念仿射量化、对称/非对称、权重打包、FP8、per-tensor 与 per-channel 粒度、PTQ/QAT 等还不熟悉建议先阅读量化概念指南。第一步根据使用场景圈定候选方法选型的第一步不是比较细节而是先明确你的目标场景。下表是 selecting.md 给出的推理场景速查结论量化方法适用场景bitsandbytes使用便捷支持 NVIDIA / Intel GPU 上的 QLoRA 微调compressed-tensors加载特定的预量化格式如 FP8GPTQModel / AWQ需要先校准换取 4-bit 下的高精度HQQ无需校准的快速在线量化SINQ无需校准的超快、高质量在线量化torchao灵活配置量化方案配合torch.compile实现快速推理对于微调场景官方建议优先考虑 bitsandbytesQLoRA 的标准路径对于研究与极限压缩sub-4-bit则应转向 AQLM、SpQR、VPTQ、HIGGS 等以论文为驱动的算法。以下各节分别展开。推理场景一无需校准数据的在线量化这类方法不需要单独的校准数据集或校准步骤加载模型即完成量化on-the-fly quantization上手成本最低适合快速验证与部署。bitsandbytes简单与普及度之选bitsandbytes 通过轻量级 Python 封装直接调用硬件加速函数为 Transformers 提供 LLM.int8()8-bit与 QLoRANF4/FP4 4-bit两条主线能力。其优缺点如下优点缺点使用非常简单推理时无需校准数据集主要为 NVIDIA GPUCUDA优化社区支持好、被广泛采用不保证推理加速收益主要在显存而非速度一个典型的 4-bit 加载示例完整示例与 QLoRA 用法见 bitsandbytes 文档from transformers import AutoModelForCausalLM, BitsAndBytesConfig quantization_config BitsAndBytesConfig(load_in_4bitTrue) model_4bit AutoModelForCausalLM.from_pretrained( bigscience/bloom-1b7, device_mapauto, quantization_configquantization_config, )大模型建议设置device_mapauto让权重自动分发到多张 GPU。核心要点还包括bitsandbytes 支持 CUDA 11.8–13.0 的 NVIDIA GPU、Intel XPU、Intel GaudiHPU与 CPU其中 LLM.int8() 推理要求 NVIDIA TuringRTX 20X0/T4及以上硬件而 NF4/FP4 量化仅要求 Pascal 及以上。非量化模块如 LayerNorm默认使用 fp16/fp32可通过dtypeauto让其遵循模型config.json中声明的数据类型。配套的 8-bit 优化器与量化算子能显著压低训练时的优化器状态占用这是其在 QLoRA 微调中被广泛选用的底层原因。HQQ免校准、宽位宽的多模态通用方案Half-Quadratic QuantizationHQQ把权重量化建模为半二次优化问题可快速在 8、4、3、2 甚至 1-bit 位宽下对任何模态模型LLM、视觉等做免校准量化并与torch.compile与 PEFT 完全兼容。其官方文档见 HQQ 文档。优点缺点量化过程快无需校准数据位宽低于 4-bit 时精度可能明显下降支持多个后端可实现快速推理除非使用torch.compile或专用后端否则推理速度未必占优兼容torch.compile支持宽范围位宽8/4/3/2/1-bitHQQ 的一个特色是支持按层差异化配置——这对 MoE混合专家模型特别有价值因为专家层对更激进的低比特量化不那么敏感。可以对注意力层用 4-bit、对 MLP 层用 3-bitimport torch from transformers import AutoModelForCausalLM, AutoTokenizer, HqqConfig q4_config {nbits: 4, group_size: 64} q3_config {nbits: 3, group_size: 32} quant_config HqqConfig(dynamic_config{ self_attn.q_proj: q4_config, self_attn.k_proj: q4_config, self_attn.v_proj: q4_config, self_attn.o_proj: q4_config, mlp.gate_proj: q3_config, mlp.up_proj: q3_config, mlp.down_proj: q3_config, }) model AutoModelForCausalLM.from_pretrained( meta-llama/Llama-3.1-8B, dtypetorch.float16, device_mapauto, quantization_configquant_config, )推理速度方面模型量化完成后可切换到专用推理后端以获取更高吞吐例如通过 HQQ 库的prepare_for_inference(model, backendtorchao_int4)启用 4-bit 融合内核torchao / Marlin 后端。SINQSinkhorn 归一化的新一代免校准方案SINQSinkhorn-Normalized Quantization是华为 CSL 提出的快速、即插即用、模型无关的量化技术定位上可以视为对 HQQ 的加速与精度升级无需校准即可在 8、4、3、2-bit 位宽下量化支持对称与非对称量化且支持 NF4 格式。官方集成文档见 SINQ 文档。优点缺点量化过程超快且质量高无需校准数据位宽 ≤2-bit 时精度可能明显下降GemLite 后端提供更快推理3-bit 模型推理较慢缺少 gemlite 内核支持宽范围位宽8/4/3/2-bit安装sinq包后可通过 Transformers 的SinqConfig完成量化import torch from transformers import AutoTokenizer, AutoModelForCausalLM, SinqConfig model_name Qwen/Qwen3-1.7B cfg SinqConfig( nbits4, # 2/3/4/5/6/8默认 4 group_size64, # 每组权重数量可选 64/128 tiling_mode1D, # 权重矩阵分块策略可选 1D/2D methodsinq, # sinq / asinqA-SINQ 暂不支持于 HF modules_to_not_convert[lm_head], # 不量化的模块列表 ) tok AutoTokenizer.from_pretrained(model_name) qmodel AutoModelForCausalLM.from_pretrained( model_name, quantization_configcfg, dtypetorch.bfloat16, )注意两个限制其一A-SINQ带校准的变体对标 AWQ目前未在 Transformers 中开放其二SINQ 量化与推理暂不支持多 GPU多卡环境下需通过CUDA_VISIBLE_DEVICES明确指定使用哪一块卡。当模型以 4-bit 量化且环境中装有gemlite库时推理会自动切换到 gemlite 快速内核。被保留为全精度的lm_head是有意为之——从 quantizers/base.py 的get_keys_to_not_convert可以看到框架会自动剔除 tied weights、输出嵌入层等对数值稳定性敏感的模块使其免于量化。torchao与torch.compile深度耦合的灵活方案torchao 是 PyTorch 官方的架构优化库除量化外还提供稀疏化、QAT、FP8 训练、KV Cache 量化等能力。它最大的特点是量化配置的组合自由度与对原生 PyTorch 特性的无缝集成。官方文档见 torchao 文档。优点缺点与torch.compile集成强潜在加速明显库较新生态仍在演进提供不错的 CPU 量化支持性能表现依赖torch.compile是否正常生效量化方案灵活int8/int4/fp84-bitint4wo精度可能不及 GPTQ/AWQtorchao 支持的方案包括 A16W8/W8A8 动态量化、int8/int4 仅权重量化weight-only、int4 2:4 稀疏组合等。接入方式如下需torchao 0.15.0使用AOBaseConfig对象而非被移除的字符串 APIfrom transformers import TorchAoConfig, AutoModelForCausalLM quantization_config TorchAoConfig(int4_weight_only, group_size128) model AutoModelForCausalLM.from_pretrained( meta-llama/Llama-3.1-8B, quantization_configquantization_config, cache_implementationstatic, # 首次推理时自动 torch.compile 前向 )⚠️cache_implementationstatic会让模型在首次推理时自动编译且每当 batch size 或max_new_tokens变化都会触发重编译。若只想量化、不编译请在generate()中传入disable_compileTrue。它还支持通过模块全限定名 → 量化配置的字典做模块级精细控制例如跳过某些层或对不同层使用不同量化方案。硬件支持方面需确认 CUDAcu118/cu126/cu128或 XPUpytorch 2.8版本匹配CPU 场景则把device_map设为cpu即可。推理场景二基于校准的高精度量化当任务对精度敏感、且你有能力先跑一遍校准流程时校准类方法通常在同等位宽下获得更高精度。它们的代价是需要一个前置的校准步骤准备一段有代表性的文本数据通过最小化量化误差寻找最优权重。如果你量化 8B 级别的模型一次校准的典型耗时量级为GPTQ 约 20 分钟、AWQ 约 10 分钟单张 A100。GPTQ / GPTQModelGPTQ 是逐行独立优化权重的后训练量化算法权重量化为 int4推理时在融合内核中动态反量化为 fp16而非先展开到显存因此既省 4x 显存又因更低带宽需求而更快。当前 AutoGPTQ 已不在 Transformers 中维护请使用GPT-QModelPython 包gptqmodel。优点缺点通常能取得较高精度需要校准数据集与独立的校准步骤可能带来推理加速存在在校准数据上过拟合的风险Hugging Face Hub 上有大量预量化 GPTQ 模型可直接使用校准需要数据集 tokenizer二者同时配置在GPTQConfig中。建议使用 GPTQ 论文所用的c4数据集也可传入自定义字符串列表from transformers import AutoModelForCausalLM, AutoTokenizer, GPTQConfig tokenizer AutoTokenizer.from_pretrained(facebook/opt-125m) # 方式一使用 c4 数据集 gptq_config GPTQConfig(bits4, datasetc4, tokenizertokenizer) # 方式二自定义数据集 dataset [gptqmodel is an easy-to-use model quantization library with user-friendly apis, based on the GPTQ algorithm.] gptq_config GPTQConfig(bits4, datasetdataset, tokenizertokenizer) quantized_model AutoModelForCausalLM.from_pretrained( facebook/opt-125m, device_mapauto, quantization_configgptq_config, )实操注意点详细见 GPTQ 文档数据集过大导致 OOM 时磁盘 offload 不受支持可用max_memory显式分配 GPU/CPU 内存预算例如max_memory{0: 30GiB, 1: 46GiB, cpu: 30GiB}。从零量化耗时与模型规模强相关opt-350m 在免费 Colab GPU 上约 5 分钟而 175B 模型在 A100 上可能要数小时。动手前建议先在 Hub 搜索是否已有现成的 GPTQ 版本。Marlin 内核一个专为 NVIDIA A100Ampere优化的 4-bit CUDA GPTQ 内核仅支持量化后推理、不支持量化本身。通过GPTQConfig(bits4, backendmarlin)启用可获得显著推理提升。GPT-QModel 相比旧 AutoGPTQ 提供非对称量化可进一步降低量化误差但不兼容旧 AutoGPTQ checkpoint且并非所有内核如 Marlin都支持非对称量化。AWQ激活感知的 4-bit 量化AWQActivation-aware Weight Quantization在压缩到 4-bit 时依据激活分布识别并保留一小部分对模型性能关键的权重仅约 1%从而以最小性能损失完成压缩。Transformers 支持加载 llm-awq 与 autoawq 量化过的模型。优点缺点4-bit 下常能达到较高精度部分任务上有时超过 GPTQ自行量化时仍需校准可能带来推理加速校准时间比 GPTQ 更短Hugging Face Hub 上有大量预量化 AWQ 模型加载预量化 AWQ 模型时无需校准直接传入模型名框架会读取模型config.json中的quantization_config.quant_method: awq自动识别并将其他权重按dtype参数处理from transformers import AutoModelForCausalLM, AutoTokenizer from accelerate import Accelerator model AutoModelForCausalLM.from_pretrained( TheBloke/zephyr-7B-alpha-AWQ, dtypetorch.float32, device_mapAccelerator().device, )AWQ 还支持融合模块fused modules优化对 Llama 与 Mistral 架构开箱即用通过AwqConfig(bits4, fuse_max_seq_len512, do_fuseTrue)启用fuse_max_seq_len需覆盖上下文长度加生成长度。融合后解码速度、显存占用均显著改善但注意融合模块不能与 FlashAttention2 等其它优化叠加。更完整的对比与配置可参考 AWQ 文档。加载特定预量化格式compressed-tensors 与 FP8如果你的目标不是现场量化而是加载社区或自家流水线已经产出的特殊格式 checkpoint那么方法选择的关键就变成该格式的支持方。compressed-tensors 正是这类加载特定格式场景的代表。优点缺点支持灵活的格式如 FP8主要面向加载预量化模型在 NVIDIASM89与 Intel XPU 上提供 FP8 内核加速它的意义在于FP8 等新型数据类型的收益E4M3/E5M2 两种变体的精度/动态范围权衡详见量化概念指南高度依赖厂商内核支持而 compressed-tensors 作为中间层把这些内核能力统一暴露给 Transformers。若你更关心 FP8 计算本身还可关注仓库中的 fbgemm_fp8 与 finegrained_fp8 两条内建路径。具体接入方式见 compressed-tensors 文档。微调场景以 bitsandbytes 为基准的 QLoRA 路径微调大模型时量化主要用来压缩前向与反向传播中的内存峰值优化器状态 激活 权重让消费级显卡也能训练数十亿参数模型。针对微调场景selecting.md 给出的建议非常明确描述通过 PEFT 做 QLoRA 微调的标准方法就是 bitsandbytes。优点能在消费级 GPU 上微调大模型在 PEFT 中被广泛支持且有完善的文档。缺点主要面向 NVIDIA GPU。尽管 HQQ、SINQ 等其它方法也提供 PEFT 兼容性但 bitsandbytes 仍然是 QLoRA 最成熟、文档最全的路径。其 4-bit NF4/FP4 存储 16-bit 计算bnb_4bit_compute_dtype的设计使训练态内存大幅下降配合低秩适配器LoRA只更新少量可训练参数即可在单卡上完成对大模型的指令微调。QLoRA 的完整接入流程包括 PEFT 侧的配置组合请参见 bitsandbytes 文档 与 overview 中的示例。研究场景sub-4-bit 与前沿压缩方法若你的目标不是立即上线而是探索压缩极限或复现前沿论文结论则可关注 AQLM、SpQR、VPTQ、HIGGS 等以研究为导向的方法它们分别对应 aqlm.md、spqr.md、vptq.md、higgs.md 的集成文档。官方认为当以下任一条件成立时应考虑它们你需要极端压缩sub-4-bit如 1–2-bit你正进行学术研究或需要复现对应论文的 SOTA 结果你拥有充足的计算资源能承受可能非常复杂的量化流程例如 AQLM、VPTQ 的量化时间可能极长。把这类方法投入生产前务必先精读各方法文档与配套论文评估其精度-耗时-稳定性是否符合你的约束。基准对比8-bit / 4-bit / sub-4-bit 的关键结论为了给出量化的横向证据官方在 Llama 3.1 8B 与 70B 上对多种流行方法做了基准评测指标包括精度越高越好、推理吞吐token/s越高越好、峰值显存GB越低越好与量化时间。测量环境与口径为Llama 3.1 70Bbfloat16使用 2 张 NVIDIA A100 80GBFP8 方法使用 1 张 NVIDIA H100 80GB其余方法使用 1 张 NVIDIA A100 80GB吞吐测量固定 batch size 1、生成 64 tokens在支持处纳入torch.compile与 Marlin 内核的结果。完整的逐项对比数据以交互表格形式维护在基准数据集对应 selecting.md 中的 iframe 表格中此处直接给出官方提炼的三档结论量化方法与位宽相对 bf16 的显存节省精度表现补充说明8-bitbnb-int8、HQQ、Quanto、torchao、fp8约 2x非常接近 bf16 基线模型4-bitAWQ、GPTQ、HQQ、bnb-nf4、SINQ约 4x精度相对较高AWQ/GPTQ 精度常领先但需校准HQQ/bnb-nf4/SINQ 属于易用的免校准方案Sub-4-bitVPTQ、AQLM、2-bit GPTQ极致4x精度下降明显2-bit 尤甚量化时间可能非常长AQLM、VPTQ不同方法表现差异大这份对照表的三档结论印证了前文的方法论8-bit 是无痛降载4-bit 是精度-成本甜点区用免校准便捷性或校准时间换取精度sub-4-bit 则是留给研究场景的极致压缩地带。收敛成一条决策路径综合全文一个可落地的选型流程如下明确场景纯推理、微调还是研究/极限压缩审视约束目标位宽8/4/sub-4、硬件NVIDIA/AMD/Intel/Apple/CPU、能否接受校准步骤、是否依赖torch.compile或特定内核Marlin/GemLite/torchao。套用推理速查表免校准优先考虑 bitsandbytes求稳、HQQ/SINQ求快求小、torchao要配合 compile 提速要极致 4-bit 精度则选 GPTQ 或 AWQ加载 FP8 预量化模型则用 compressed-tensors。微调默认 bitsandbytes QLoRA/PEFT。上线前务必自测选择文档的最终建议是——始终在你自己的任务与硬件上对量化模型做精度与速度基准确认其满足要求后再部署。各方法的详细使用说明请回到对应的独立文档页bitsandbytes、HQQ、SINQ、torchao、GPTQ、AWQ、compressed-tensors以及用于横向取舍的 overview.md。【免费下载链接】transformers Transformers: the model-definition framework for state-of-the-art machine learning models in text, vision, audio, and multimodal models, for both inference and training.项目地址: https://gitcode.com/GitHub_Trending/tra/transformers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考