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

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

LM.int8()

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

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

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

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

GPTQ

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

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

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

GPTQ-for-LLaMa

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

Post Training Quantization：GPTQ-for-LLaMa 默認(rèn)采用C4數(shù)據(jù)集進(jìn)行量化訓(xùn)練（只采用了 C4 中英文數(shù)據(jù)的一部分進(jìn)行量化，而非全部 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，因此進(jìn)行量化時(shí)對(duì)內(nèi)存和顯存要求會(huì)少一點(diǎn)。在 4090 測(cè)試，最高峰顯存占用 7000MiB，整個(gè) GPTQ 量化過程需要 10 分鐘。量化后進(jìn)行 PPL 測(cè)試，7b 在沒有 arc_order 量化下，c4 的 ppl 大概會(huì)在 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

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

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)過測(cè)試，問題存在于llama.py中的quant.make_quant_attn(model)。使用quant_attn能夠極大提升模型推理速度。參考這個(gè)歷史 ISSUE，估計(jì)是position_id的推理 cache 在 Attention layer 中的配置存在了問題。left-padding issue

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

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

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

AutoGPTQ

AutoGPTQ 使用起來相對(duì)容易，它提供了對(duì)大多數(shù) Huggingface LLM 模型的量化方案，如 LLaMa 架構(gòu)系列模型，bloom，moss，falcon，gpt_bigcode 等。（沒在支持表中看到 ChatGLM 系列模型）。具體可以參考 官方的快速上手和進(jìn)階使用來進(jìn)行量化模型訓(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 時(shí)候開啟 triton 更快
  max_memory = {0: "20GIB", "cpu": "20GIB"}  # )

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

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

exllama

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

gptq

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

GGML

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

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

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

此處采用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

參考官方文檔，進(jìn)行權(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 測(cè)試

./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ā)送請(qǐng)求測(cè)試：

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ù)解釋參考官方文檔。主要參數(shù)有：

• --ctx-size: 上下文長(zhǎng)度。

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

• --batch-size：處理 prompt 時(shí)候的 batch size。

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

推理部署

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

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

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

一些備注

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

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

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

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

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

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