本文旨在對 transformers 支持的各種量化方案及其優缺點作一個清晰的概述，以助于讀者進行方案選擇。

目前，量化模型有兩個主要的用途:

• 在較小的設備上進行大模型推理
• 對量化模型進行適配器微調

到目前為止，transformers 已經集成并 原生 支持了 bitsandbytes 和 auto-gptq 這兩個量化庫。請注意，?? optimum 還支持更多的量化方案，但本文不會涉及這一塊內容。

要詳細了解每種方案的更多信息，可查看下文列出的相關資源，或者閱讀相應的 transformers 文檔。

另請注意，下文內容僅適用于 PyTorch 模型， Tensorflow 和 Flax/JAX 模型不在討論范圍之內。

目錄

• 資源
• bitsandbytes 與 auto-gptq 之比較
• 深入研究速度基準
• 總結與最后的話
• 致謝

資源

• 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

從上面的結果中，我們可以得出結論，模型越大，退化越少。更有意思的是，所有的退化都很?。?/p>

總結與最后的話

通過本文，我們比較了多種設置下的 bitsandbytes 和 GPTQ 量化。我們發現，bitsandbytes 更適合微調，而 GPTQ 更適合生成。根據這一觀察，獲得最佳合并模型的一種方法是:

• (1) 使用 bitsandbytes 量化基礎模型 (零樣本量化)
• (2) 添加并微調適配器
• (3) 將訓練后的適配器合并到基礎模型或 反量化模型 之中！
• (4) 使用 GPTQ 量化合并后的模型并將其用于部署

我們希望這個概述讓每個人都能更輕松地將 LLM 應用至各自的應用場景中，我們期待看到大家用它構建自己的有趣應用！

致謝

我們要感謝 Ilyas、Clémentine 和 Felix 在基準測試上的幫助。

我們還要感謝 Pedro Cuenca 對本文撰寫的幫助。

---

英文原文: https://hf.co/blog/overview-quantization-transformers

原文作者: Younes Belkada，Marc Sun，Ilyas Moutawwakil，Clémentine Fourrier，Félix Marty

譯者: Matrix Yao (姚偉峰)，英特爾深度學習工程師，工作方向為 transformer-family 模型在各模態數據上的應用及大規模模型的訓練推理

審校/排版: zhongdongy (阿東)

總結

以上是生活随笔為你收集整理的Transformers 中原生支持的量化方案概述的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。