本文旨在对 transformers 支撑的各种量化计划及其优缺点作一个明晰的概述，以助于读者进行计划挑选。
现在，量化模型有两个首要的用途:
- 在较小的设备上进行大模型推理
- 对量化模型进行适配器微调
到现在为止，transformers 现已集成并 原生 支撑了 bitsandbytes 和 auto-gptq 这两个量化库。请留意， optimum 还支撑更多的量化计划，但本文不会触及这一块内容。
要具体了解每种计划的更多信息，可查看下文列出的相关资源，或者阅读相应的 transformers 文档。
另请留意，下文内容仅适用于 PyTorch 模型， Tensorflow 和 Flax/JAX 模型不在评论范围之内。
目录
资源
- GPTQ 博文 – 概述什么是 GPTQ 量化办法以及怎么运用它。
- bistandbytes 4 比特量化博文 – 本文介绍了 4 比特量化和 QLoRa，QLoRa 是一种高效的微调办法。
- bistandbytes 8 比特量化博文 – 本文解释了怎么与 bitsandbytes 合作运用 8 比特量化。
- 有关 GPTQ 根底用法的 Google Colab 笔记本 – 本笔记本展示了怎么运用 GPTQ 办法量化你自己的 transformer 模型，怎么用量化模型进行推理，以及怎么对量化模型进行微调。
- 有关 bitsandbytes 根底用法的 Google Colab 笔记本 – 该笔记本展示了怎么在推理中运用 4 比特模型及其一切变体，以及怎么在免费的 Google Colab 实例上运转 GPT-neo-X (20B 模型)。
- Merve 编撰的关于量化的博文 – 本文简要介绍了量化以及 transformers 中原生支撑的量化办法。
bitsandbytes 与 auto-gptq 之比较
本节咱们将评论 bitsandbytes 和 gptq 量化各自的优缺点。请留意，这些比较首要依据社区的反应，它们具有必定的时效性，会随着时刻的推移而改变，比如说其间一些功能缺失已被纳入相应库的路线图中了。
bitsandbytes 有什么好处？
简略: bitsandbytes 依旧是量化任何模型的最简略办法，因为它不需求量化校准数据及校准过程 (即零样本量化)。任何模型只需含有 torch.nn.Linear 模块，就能够对其进行开箱即用的量化。每当在 transformers 中添加新架构时，只需其能够用 accelerate 库的 device_map="auto" 加载，用户就能够直接受益于开箱即用的 bitsandbytes 量化，同时该办法对功能的影响也是最小的。量化是在模型加载时执行的，无需运转任何后处理或准备步骤。
跨模态互操作性: 因为量化模型的唯一条件是包括 torch.nn.Linear 层，因而量化关于任何模态都能够实现开箱即用。用户能够开箱即用地加载比如 Whisper、ViT、Blip2 之类的 8 比特或 4 比特模型。
兼并适配器 (adapter) 时功能下降为 0: (假如你对此不熟悉，请参阅 此文 以获得有关适配器和 PEFT 的更多信息)。假如你在量化根底模型之上练习适配器，则能够将适配器兼并在根底模型之上进行布置，而不会降低推理功能。你乃至还能够在反量化模型之上 兼并 适配器！GPTQ 不支撑此功能。
autoGPTQ 有什么好处？
文本生成速度快: 对 文本生成 使命而言，GPTQ 量化模型的速度比 bitsandbytes 量化模型的速度更快，下文咱们会具体比较。
n 比特支撑: GPTQ 算法能够将模型量化至 2 比特！但这或许会导致严重的质量下降。咱们主张运用 4 比特，这个值对 GPTQ 而言是个很好的折衷。
易于序列化: GPTQ 模型支撑任意比特的序列化。只需安装了所需的软件包，就支撑开箱即用地从 TheBloke 空间 中加载后缀为 -GPTQ 的模型。 bitsandbytes 支撑 8 比特序列化，但尚不支撑 4 比特序列化。
AMD 支撑: 开箱即用支撑 AMD GPU！
bitsandbytes 还有哪些潜在的改善空间？
文本生成速度比 GPTQ 慢: 运用 generate 接口时，bitsandbytes 4 比特模型比 GPTQ 慢。
4 比特权重不行序列化: 现在，4 比特模型无法序列化。社区用户经常提出这样的恳求，咱们相信 bitsandbytes 维护者应该很快就能解决这个问题，因为这现已在其路线图中了！
autoGPTQ 还有哪些潜在的改善空间？
校准数据集: 对校准数据集的需求或许会让一些用户难以用上 GPTQ。此外，模型量化或许需求几个小时 (例如，依据 该论文第 2 节，175B 的模型需求 4 个 GPU 时)。
现在仅可用于语言模型: 到现在，用 autoGPTQ 对模型进行量化的 API 仅支撑语言模型。运用 GPTQ 算法量化非文本 (或多模态) 模型应该是可行的，但原始论文或 auto-gptq 代码库中尚未对此有具体说明。假如社区对这方面很有爱好，将来或许会考虑这一点。
深入研究速度基准
咱们决议在不同硬件上运用 bitsandbytes 和 auto-gptq 在推理和适配器微调这两大场景上进行一系列广泛的基准测验。推理基准测验应该让用户了解不同推理办法之间或许存在的速度差异，而适配器微调基准测验应该让用户在需求决议挑选 bitsandbytes 还是 GPTQ 根底模型进行适配器微调时有一个明晰的判断。
根本设置如下:
- bitsandbytes: 运用
bnb_4bit_compute_dtype=torch.float16进行 4 比特量化。保证运用bitsandbytes>=0.41.1，以用上 4 比特加快核函数。 - auto-gptq: 保证
auto-gptq>=0.4.0以用上exllama加快核函数进行 4 比特量化。
推理速度 (仅前向)
该基准测验仅丈量预填充 (prefill) 步骤，该步骤对应于练习期间的前向传递。测验依据单张英伟达 A100-SXM4-80GB GPU，提示长度为 512，模型为 meta-llama/Llama-2-13b-hf 。
batch size = 1 时:
| 量化办法 | act_order | 比特数 | group_size | 加快核 | 加载时刻 (秒) | 每词元延迟 (毫秒) | 吞吐 (词元/秒) | 峰值显存 (MB) |
|---|---|---|---|---|---|---|---|---|
| fp16 | None | None | None | None | 26.0 | 36.958 | 27.058 | 29152.98 |
| gptq | False | 4 | 128 | exllama | 36.2 | 33.711 | 29.663 | 10484.34 |
| bitsandbytes | None | 4 | None | None | 37.64 | 52.00 | 19.23 | 11018.36 |
batch size = 16 时:
| 量化办法 | act_order | 比特数 | group_size | 加快核 | 加载时刻 (秒) | 每词元延迟 (毫秒) | 吞吐 (词元/秒) | 峰值显存 (MB) |
|---|---|---|---|---|---|---|---|---|
| fp16 | None | None | None | None | 26.0 | 69.94 | 228.76 | 53986.51 |
| gptq | False | 4 | 128 | exllama | 36.2 | 95.41 | 167.68 | 34777.04 |
| bitsandbytes | None | 4 | None | None | 37.64 | 113.98 | 140.38 | 35532.37 |
咱们能够看到，bitsandbyes 和 GPTQ 的预填充速度适当，batch size 比较大时 GPTQ 稍快一些。欲了解有关该基准测验的更多具体信息，请参阅此 链接。
生成速度
下面测验推理过程中模型的生成速度，你能够在 此处 找到基准测验脚本，用于重现咱们的成果。
use_cache
咱们先测验 use_cache 参数的影响，以更好地了解在生成过程中键值缓存对速度的影响。
该基准测验在 A100 上运转，提示长度为 30，生成词元数也为 30，模型为 meta-llama/Llama-2-7b-hf 。
use_cache=True 时:
use_cache=False 时:
经过这两个基准测验，能够得出定论，运用留意力缓存时，生成速度会更快，该定论契合预期。此外，一般来说，GPTQ 比 bitsandbytes 更快。例如， batch_size=4 且 use_cache=True 时，GPTQ 速度快了一倍！因而，咱们下一个基准测验中会直接运用 use_cache=True 。请留意， use_cache=True 会耗费更多显存。
硬件
下面，咱们看看量化模型在不同的硬件上的体现。咱们运用的提示长度为 30，生成 30 个词元，运用的模型是 meta-llama/Llama-2-7b-hf 。
单张 A100:
单张 T4:
单张 Titan RTX:
从上面的基准测验中，咱们能够得出定论，关于这三款 GPU，GPTQ 都比 bitsandbytes 更快。
生成长度
在下面的基准测验中，咱们将测验不同的生成长度，看看它们对量化模型速度的影响。实验依据 A100，咱们运用的提示长度为 30，并改变生成词元的长度。运用的模型是 meta-llama/Llama-2-7b-hf 。
生成 30 个词元:
生成 512 个词元:
从以上基准测验中，咱们能够得出定论，无论生成长度怎么，GPTQ 都比 bitsandbytes 更快。
适配器微调 (前向 + 后向)
对量化模型进行全模型微调是不行能的。但是，你能够运用参数高效微调 (PEFT) 来微调量化模型，在其之上练习新的适配器。咱们运用一种名为“低秩适配器 (LoRA)”的微调办法: 无需微调整个模型，仅需微调这些适配器并将它们正确加载到模型中。咱们来比照一下微调速度吧！
该基准测验依据英伟达 A100 GPU，咱们运用 Hub 中的 meta-llama/Llama-2-7b-hf 模型。请留意，关于 GPTQ 模型，咱们有必要禁用 exllama 加快核，因为它不支撑微调。
从成果中，咱们能够得出定论，bitsandbytes 的微调速度比 GPTQ 更快。
功能退化
量化关于减少内存耗费十分有用。但是，它也会带来功能退化。咱们运用 Open-LLM 排行榜 来比较功能！
关于 7B 模型:
| 模型 | 均值 | ARC | Hellaswag | MMLU | TruthfulQA |
|---|---|---|---|---|---|
| meta-llama/llama-2-7b-hf | 54.32 | 53.07 | 78.59 | 46.87 | 38.76 |
| meta-llama/llama-2-7b-hf-bnb-4bit | 53.4 | 53.07 | 77.74 | 43.8 | 38.98 |
| TheBloke/Llama-2-7B-GPTQ | 53.23 | 52.05 | 77.59 | 43.99 | 39.32 |
关于 13B 模型:
| 模型 | 均值 | ARC | Hellaswag | MMLU | TruthfulQA |
|---|---|---|---|---|---|
| meta-llama/llama-2-13b-hf | 58.66 | 59.39 | 82.13 | 55.74 | 37.38 |
| TheBloke/Llama-2-13B-GPTQ (revision = ‘gptq-4bit-128g-actorder_True’) | 58.03 | 59.13 | 81.48 | 54.45 | 37.07 |
| TheBloke/Llama-2-13B-GPTQ | 57.56 | 57.25 | 81.66 | 54.81 | 36.56 |
| meta-llama/llama-2-13b-hf-bnb-4bit | 56.9 | 58.11 | 80.97 | 54.34 | 34.17 |
从上面的成果中，咱们能够得出定论，模型越大，退化越少。更有意思的是，一切的退化都很小！
总结与最终的话
经过本文，咱们比较了多种设置下的 bitsandbytes 和 GPTQ 量化。咱们发现，bitsandbytes 更适合微调，而 GPTQ 更适合生成。依据这一观察，获得最佳兼并模型的一种办法是:
- (1) 运用 bitsandbytes 量化根底模型 (零样本量化)
- (2) 添加并微调适配器
- (3) 将练习后的适配器兼并到根底模型或 反量化模型 之中！
- (4) 运用 GPTQ 量化兼并后的模型并将其用于布置
咱们期望这个概述让每个人都能更轻松地将 LLM 使用至各自的使用场景中，咱们等待看到大家用它构建自己的风趣使用！
致谢
咱们要感谢 Ilyas、Clmentine 和 Felix 在基准测验上的帮助。
咱们还要感谢 Pedro Cuenca 对本文编撰的帮助。
英文原文: hf.co/blog/overvi…
原文作者: Younes Belkada，Marc Sun，Ilyas Moutawwakil，Clmentine Fourrier，Flix Marty
译者: Matrix Yao (姚伟峰)，英特尔深度学习工程师，工作方向为 transformer-family 模型在各模态数据上的使用及大规模模型的练习推理
审校/排版: zhongdongy (阿东)
