本文導(dǎo)論部署 LLaMa 系列模型常用的幾種方案，并作速度測試。包括 Huggingface 自帶的 LLM.int8()，AutoGPTQ, GPTQ-for-LLaMa, exllama, llama.cpp。

總結(jié)來看，對 7B 級別的 LLaMa 系列模型，經(jīng)過 GPTQ 量化后，在 4090 上可以達到 140+ tokens/s 的推理速度。在 3070 上可以達到 40 tokens/s 的推理速度。

LM.int8()

來自論文：LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale

LM.int8() 時 Hugingface 集成的量化策略。能夠通過在.from_pretrain()時候傳遞load_in_8bit來實現(xiàn)，針對幾乎所有的 HF Transformers 模型都有效。大致方法是，在矩陣點積計算過程中， 將其中的 outliers 參數(shù)找出來（以行或列為單位），然后用類似 absolute maximum (absmax) quantization 的方法，根據(jù)行/列對 Regular 參數(shù)做量化處理，outlier 參數(shù)仍然做 fp16 計算，最后相加。

根據(jù)huggingface 的博客， LLM.INT8() 能夠再模型性能不影響很多的前提下，讓我們能用更少的資源進行 LLM 推理。但 LLM.int8() 普遍的推理速度會比 fp16 慢。博客中指出，對于越小的模型， int8() 會導(dǎo)致更慢的速度。

結(jié)合論文中的實驗結(jié)果，模型越大，int8() 加速越明顯，個人猜測是由于非 outlier 數(shù)量變多了，更多的參數(shù)進行了 int8 計算，抵消了額外的量化轉(zhuǎn)化時間開銷？

GPTQ

GPTQ: ACCURATE POST-TRAINING QUANTIZATION FOR GENERATIVE PRE-TRAINED TRANSFORMERS

使用 GPTQ 量化的模型具有很大的速度優(yōu)勢，與 LLM.int8() 不同，GPTQ 要求對模型進行 post-training quantization，來得到量化權(quán)重。GPTQ 主要參考了 Optimal Brain Quanization (OBQ)，對OBQ 方法進行了提速改進。有網(wǎng)友在文章中對 GPTQ, OBQ, OBS 等量化策略進行了整理，這里就不多贅述了。

以下對幾個 GPTQ 倉庫進行介紹。以下所有測試均在 4090 上進行，模型推理速度采用oobabooga/text-generation-webui提供的 UI。

GPTQ-for-LLaMa

專門針對 LLaMa 提供 GPTQ 量化方案的倉庫，如果考慮 GPU 部署 LLaMa 模型的話，GPTQ-for-LLaMa 是十分指的參考的一個工具。像http://huggingface.co上的Thebloke很大部分模型都是采用 GPTQ-for-LLaMa 進行量化的。

Post Training Quantization：GPTQ-for-LLaMa 默認采用C4數(shù)據(jù)集進行量化訓(xùn)練（只采用了 C4 中英文數(shù)據(jù)的一部分進行量化，而非全部 9TB+的數(shù)據(jù)）：

CUDA_VISIBLE_DEVICES=0 python llama.py /models/vicuna-7b c4 
    --wbits 4 
--true-sequential
--groupsize128
--save_safetensorsvicuna7b-gptq-4bit-128g.safetensors

由于 GPTQ 是 Layer-Wise Quantization，因此進行量化時對內(nèi)存和顯存要求會少一點。在 4090 測試，最高峰顯存占用 7000MiB，整個 GPTQ 量化過程需要 10 分鐘。量化后進行 PPL 測試，7b 在沒有 arc_order 量化下，c4 的 ppl 大概會在 5-6 左右：

CUDA_VISIBLE_DEVICES=0 python llama.py /models/vicuna-7b c4 
    --wbits 4     
    --groupsize 128     
    --load vicuna7b-gptq-4bit-128g.safetensors     
    --benchmark 2048 --check

對量化模型在 MMLU 任務(wù)上測試，量化后 MMLU 為，于 fp16（46.1）稍微有點差距。

Huggingface 上的TheBloke發(fā)布的大部分 LLaMa GPTQ 模型，都是通過以上方式（C4 數(shù)據(jù)集 + wbit 4 + group 128 + no arc_order + true-sequential）量化的。若由于 GPTQ-for-LLaMa 及 transformers 倉庫不斷更新，Huggingface.co 上發(fā)布的模型可能存在無法加載或精度誤差等問題，可以考慮重新量化，并通過優(yōu)化量化數(shù)據(jù)集、添加 arc_order 等操作來提高量化精度。

GPTQ-for-LLaMa 的一些坑：

• 經(jīng)過測試，問題存在于llama.py中的quant.make_quant_attn(model)。使用quant_attn能夠極大提升模型推理速度。參考這個歷史 ISSUE，估計是position_id的推理 cache 在 Attention layer 中的配置存在了問題。left-padding issue

• 模型加載問題：使用 gptq-for-llama 時，因 transformer 版本不同，可能出現(xiàn)模型加載不上問題。如加載TheBloke/Wizard-Vicuna-30B-Uncensored-GPTQ時，用最新版的 GPTQ-for-LLaMa 就會出現(xiàn)權(quán)重于模型 registry 名稱不匹配的情況。

• left-padding 問題：目前 GPTQ-for-LLaMa 的所有分支（triton, old-cuda 或 fastest-inference-int4）都存在該問題。如果模型對存在 left-padding 的輸入進行預(yù)測時候，輸出結(jié)果是混亂的。這導(dǎo)致了 GPTQ-for-LLaMa 目前無法支持正確的 batch inference。

• GPTQ-for-LLaMa 版本變動大，如果其他倉庫有使用 GPTQ-for-LLaMa 依賴的話，需要認真檢查以下版本。如obbaboogafork 了一個單獨的GPTQ-for-LLaMa為oobabooga/text-generation-webui做支持。最新版的 GPTQ-for-LLaMa 在 text-generation-webui 中使用會有 BUG。

AutoGPTQ

AutoGPTQ 使用起來相對容易，它提供了對大多數(shù) Huggingface LLM 模型的量化方案，如 LLaMa 架構(gòu)系列模型，bloom，moss，falcon，gpt_bigcode 等。（沒在支持表中看到 ChatGLM 系列模型）。具體可以參考 官方的快速上手和進階使用來進行量化模型訓(xùn)練和部署。

AutoGPTQ 可以直接加載 GPTQ-for-LLaMa 的量化模型：

from auto_gptq import AutoGPTQForCausalLMmodel = AutoGPTQForCausalLM.from_quantized(
  model_dir,   # 存放模型的文件路徑，里面包含 config.json, tokenizer.json 等模型配置文件
  model_basename="vicuna7b-gptq-4bit-128g.safetensors",
  use_safetensors=True,
  device="cuda:0",
  use_triton=True,  # Batch inference 時候開啟 triton 更快
  max_memory = {0: "20GIB", "cpu": "20GIB"}  # )

AutoGPTQ 提供了更多的量化加載選項，如是否采用fused_attention，配置CPU offload等。用 AutoGPTQ 加載權(quán)重會省去很多不必要的麻煩，如 AutoGPTQ 并沒有 GPTQ-for-LLaMa 類似的 left-padding bug，對 Huggingface 其他 LLM 模型的兼容性更好。因此如果做 GPTQ-INT4 batch inference 的話，AutoGPTQ 會是首選。

但對于 LLaMa 系列模型，AutoGPTQ 的速度會明顯慢于 GPTQ-for-LLaMa。在 4090 上測試，GPTQ-for-LLaMa 的推理速度會塊差不多 30%。

exllama

exllama為了讓 LLaMa 的 GPTQ 系列模型在 4090/3090 Ti 顯卡上跑更快，推理平均能達到 140+ tokens/s。當(dāng)然為了實現(xiàn)那么高的性能加速，exllama 中的模型移除了 HF transformers 模型的大部分依賴，這也導(dǎo)致如果在項目中使用 exllama 模型需要額外的適配工作。text-generation-webui 中對 exllama 進行了 HF 適配，使得我們能夠像使用 HF 模型一樣使用 exllama，代價是犧牲了一些性能，參考exllama_hf。

gptq

GPTQ 的官方倉庫。以上大部分倉庫都是基于官方倉庫開發(fā)的，感謝 GPTQ 的開源，讓單卡 24G 顯存也能跑上 33B 的大模型。

GGML

GGML是一個機械學(xué)習(xí)架構(gòu)，使用 C 編寫，支持 Integer quantization（4-bit, 5-bit, 8-bit） 以及 16-bit float。同時也對部分硬件架構(gòu)進行了加速優(yōu)化。本章中討論到的 LLaMa 量化加速方案來源于LLaMa.cpp。LLaMa.cpp 有很多周邊產(chǎn)品，如llama-cpp-python等，在下文中，我們以 GGML 稱呼這類模型量化方案。

llama.cpp 在一個月前支持了全面 GPU 加速（在推理的時候，可以把整個模型放在 GPU 上推理）。參考后文的測試，LLaMa.cpp 比 AutoGPTQ 有更快的推理速度，但是還是比 exllama 慢很多。

GGML 有不同的量化策略（具體量化類型參考），以下使用 Q4_0 對 LLaMa-2-13B-chat-hf 進行量化和測試。

此處采用docker with cuda部署，為方便自定義，先注釋掉.devops/full-cuda.Dockerfile中的EntryPoint。而后構(gòu)建鏡像：

docker build -t local/llama.cpp:full-cuda -f .devops/full-cuda.Dockerfile .

構(gòu)建成功后開啟容器（models 映射到模型文件路徑）：

docker run -it --name ggml --gpus all -p 8080:8080 -v /home/kevin/models:/models local/llama.cpp:full-cuda bash

參考官方文檔，進行權(quán)重轉(zhuǎn)換即量化：

# 轉(zhuǎn)換 ggml 權(quán)重python3 convert.py /models/Llama-2-13b-chat-hf/# 量化./quantize /models/Llama-2-13b-chat-hf/ggml-model-f16.bin /models/Llama-2-13b-chat-GGML_q4_0/ggml-model-q4_0.bin q4_0

完成后開啟server 測試

./server -m /models/Llama-2-13b-chat-GGML_q4_0/ggml-model-q4_0.bin --host 0.0.0.0 --ctx-size 2048 --n-gpu-layers 128

發(fā)送請求測試：

curl --request POST   --url http://localhost:8080/completion   --header "Content-Type: application/json"   --data '{"prompt": "Once a upon time,","n_predict": 200}'

使用 llama.cpp server 時，具體參數(shù)解釋參考官方文檔。主要參數(shù)有：

• --ctx-size: 上下文長度。

• --n-gpu-layers：在 GPU 上放多少模型 layer，我們選擇將整個模型放在 GPU 上。

• --batch-size：處理 prompt 時候的 batch size。

使用 llama.cpp 部署的請求，速度與 llama-cpp-python 差不多。對于上述例子中，發(fā)送Once a upon time,并返回 200 個字符，兩者完成時間都在 2400 ms 左右（約 80 tokens/秒）。

推理部署

記得在bert 時代，部署 Pytorch 模型時可能會考慮一些方面，比如動態(tài)圖轉(zhuǎn)靜態(tài)圖，將模型導(dǎo)出到 onnx，torch jit 等，混合精度推理，量化，剪枝，蒸餾等。對于這些推理加速方案，我們可能需要自己手動應(yīng)用到訓(xùn)練好的模型上。但在 LLaMa 時代，感受到最大的變化就是，一些開源的框架似乎為你做好了一切，只需要把你訓(xùn)練好的模型權(quán)重放上去就能實現(xiàn)比 HF 模型快 n 倍的推理速度。

以下對比這些推理加速方案：HF 官方 float16（基線）, vllm，llm.int8()，GPTQ-for-LLaMa，AUTOGPTQ，exllama, llama.cpp。

以上所有測試均在 4090 + Inter i9-13900K上進行，模型推理速度采用oobabooga/text-generation-webui提供的 UI（text-generation-webui 的推理速度會比實際 API 部署慢一點）。這邊只做速度測試，關(guān)于精度測試，可以查看GPT-for-LLaMa result和exllama results。

一些備注

1. 模型推理的速度受 GPU 即 CPU 的影響最大。有網(wǎng)友指出link，同樣對于 4090，在 CPU 不同的情況下，7B LLaMa fp16 快的時候有 50 tokens/s，慢的時候能達到 23 tokens/s。

2. 對于 stable diffusion，torch cuda118 能比 torch cuda 117 速度快上1倍。但對于 LLaMa 來說，cuda 117 和 118 差別不大。

3. 量化 batch inference 首選 AUTOGPTQ (TRITON)，盡管 AutoGPTQ 速度慢點，但目前版本的 GPTQ-for-LLaMa 存在 left-padding 問題，無法使用 batch inference；batch size = 1 時，首選 exllama 或者 GPTQ-for-LLaMa。

4. vllm 部署 fp16 的模型速度也不錯（80+ tokens/s），同時也做了內(nèi)存優(yōu)化；如果設(shè)備資源夠的話，可以考慮下 vllm，畢竟采用 GPTQ 還是有一點精度偏差的。

5. TheBloke 早期發(fā)布的一些模型可能無法加載到 exllama 當(dāng)中，可以使用最新版本的 GPTQ-for-LLaMa 訓(xùn)練一個新模型。

6. 當(dāng)顯卡容量無法加載整個模型時（比如在單卡 4090 上加載 llama-2-70B-chat），llama.cpp 比 GPTQ 速度更快（參考）。