之前對LLM 推理和應用瞭解不多，因此抽時間梳理了一下，我們從模型量化，模型推理，以及開發平臺等三個層面來梳理分析。
模型量化
模型訓練時爲了進度，採用的32位浮點數，因此佔用的空間較大，一些大的模型需要很大的顯存才能加載，且計算推理過程較慢。爲了減少內存佔用，提升推理速度，可以將高精度的參數轉爲低精度的參數，例如從 32 位的浮點數轉換爲 8 位整數，這個技術就叫做模型量化。
模型量化是一種將浮點計算轉成低比特定點計算的技術，可以有效的降低模型計算強度、參數大小和內存消耗，但往往帶來巨大的精度損失。尤其是在極低比特(<4bit)、二值網絡(1bit)、甚至將梯度進行量化時，帶來的精度挑戰更大。
量化帶來的好處
- 保持精度：量化會損失精度，這相當於給網絡引入了噪聲，但是神經網絡一般對噪聲是不太敏 感的，只要控制好量化的程度，對高級任務精度影響可以做到很小。
- 加速計算：傳統的卷積操作都是使用FP32浮點，低比特的位數減少少計算性能也更高，INT8 相 對比 FP32 的加速比可達到3倍甚至更高
- 節省內存：與 FP32 類型相比，FP16、INT8、INT4 低精度類型所佔用空間更小，對應存儲空間 和傳輸時間都可以大幅下降。
- 節能和減少芯片面積：每個數使用了更少的位數，做運算時需要搬運的數據量少了，減少了訪 存開銷（節能），同時所需的乘法器數目也減少（減少芯片面積）
量化的方法與原理
主要有三種量化方法：
- 量化訓練 (Quant Aware Training, QAT)
- 量化訓練讓模型感知量化運算對模型精度帶來的影響，通過 finetune 訓練降低量化誤差。
- 動態離線量化 (Post Training Quantization Dynamic, PTQ Dynamic)
- 動態離線量化僅將模型中特定算子的權重從FP32類型映射成 INT8/16 類型。
- 靜態離線量化 (Post Training Quantization Static, PTQ Static)
- 靜態離線量化使用少量無標籤校準數據，採用 KL 散度等方法計算量化比例因子
模型量化的原理是，實現浮點數與定點數據轉換。
如上圖所示，將一個更大範圍的浮點數，轉換爲範圍更小的數。
FP16/INT8/INT4
在huggingface上去查看模型時，會看到一些帶有fp16、int8、int4 後綴的模型，比如Llama-2-7B-fp16、chatglm-6b-int8、chatglm2-6b-int4，其實這些模型就是量化後的模型，fp16表示模型的量化精度。
- FP32（單精度浮點數）：使用32位二進制表示，其中1位用於sign，8位用於exponent，23位用於fraction。其數值範圍大約是1.18e-38到3.40e38，精度大約是6到9位有效數字
- FP16（半精度浮點數）：使用16位二進制表示，其中1位用於sign，5位用於exponent，10位用於fraction。其數值範圍爲
[5.96×10^-8, 65504]，但實際能表示的最大正值爲65504，最小正值約爲0.0000000596（非規格表示下），符號位爲0時代表正數 - INT8，八位整型佔用1個字節，INT8是一種定點計算方式，代表整數運算，一般是由浮點運算量化而來。在二進制中一個“0”或者“1”爲一bit，INT8則意味着用8bit來表示一個數字
- int4佔用4個字節（32位）
量化精度從高到低排列順序是：fp16>int8>int4，量化的精度越低，模型的大小和推理所需的顯存就越小，但模型的能力也會越差。
業界有一些開源的量化模型格式，下面來介紹。
GGML
https://github.com/ggerganov/ggml
GGML全稱是Georgi Gerganov Machine Learning，是由Georgi Gerganov開發的一個張量庫（tensor library），Georgi Gerganov開源項目llama.cpp的創始人。
GGML是一個C寫的庫，可以將LLM轉爲爲GGML格式，通過量化等技術讓LLM方便進行加載和推理
- 採用量化技術，將原有大模型預訓練結果量化（即將原有大模型FP16精度壓縮成INT8、INT6精度
- 二進制文件編碼，將量化後的預訓練結果通過一種指定的格式變成一個二進制文件
特性：
- 用 C 語言編寫
- 支持 16 位浮點數
- 支持整數量化（4 位、5 位、8 位等）
- 自動微分
- ADAM 和 L-BFGS 優化器
- 針對 Apple 芯片進行了優化
- 在 x86 架構上利用 AVX/AVX2 內在函數
- 在 ppc64 架構上利用 VSX 內在函數
- 無第三方依賴項
- 運行時不進行內存分配
在 HuggingFace 上，如果看到模型名稱帶有GGML字樣的，比如Llama-2-13B-chat-GGML，說明這些模型是經過 GGML 量化的。有些 GGML 模型的名字除了帶有GGML字樣外，還帶有q4、q4_0、q5等，比如Chinese-Llama-2-7b-ggml-q4，這裏面的q4其實指的是 GGML 的量化方法，從q4_0開始往後擴展，有q4_0、q4_1、q5_0、q5_1和q8_0，在這裏可以看到各種方法量化後的數據。
GGUF
GGML是基礎的文件格式，沒有版本控制或數據對齊，適用於不需要考慮文件版本兼容性或內存對齊優化的場景。2023年8月份，Georgi Gerganov創建一個新的大模型文件格式GGUF，全稱GPT-Generated Unified Format，用以取代GGML格式。GGUF 與 GGML 相比，GGUF 可以在模型中添加額外的信息，而原來的 GGML 模型是不可以的，同時 GGUF 被設計成可擴展，這樣以後有新功能就可以添加到模型中，而不會破壞與舊模型的兼容性。
但這個功能是Breaking Change，也就是說 GGML 新版本以後量化出來的模型都是 GGUF 格式的，這意味着舊的 GGML 格式以後會慢慢被 GGUF 格式取代，而且也不能將老的 GGML 格式直接轉成 GGUF 格式。
GPTQ
GPTQ 是一種模型量化的方法，可以將語言模型量化成 INT8、INT4、INT3 甚至 INT2 的精度而不會出現較大的性能損失，在 HuggingFace 上如果看到模型名稱帶有GPTQ字樣的，比如Llama-2-13B-chat-GPTQ，說明這些模型是經過 GPTQ 量化的。以Llama-2-13B-chat爲例，該模型全精度版本的大小爲 26G，使用 GPTQ 進行量化成 INT4 精度後的模型大小爲 7.26G。
現在更流行的一個 GPTQ 量化工具是AutoGPTQ，它可以量化任何 Transformer 模型而不僅僅是Llama，現在 Huggingface 已經將 AutoGPTQ 集成到了 Transformers 中。
GPTQ vs GGML
GPTQ 和 GGML 是現在模型量化的兩種主要方式，在實際運用中如何選擇呢？
兩者有以下幾點異同：
- GPTQ 在 GPU 上運行較快，而 GGML 在 CPU 上運行較快
- 同等精度的量化模型，GGML 的模型要比 GPTQ 的稍微大一些，但是兩者的推理性能基本一致
- 兩者都可以量化 HuggingFace 上的 Transformer 模型
因此，如果目標模型是在 GPU 上運行，那麼優先使用GPTQ 進行量化，如果你的模型是在 CPU 上運行，那麼建議使用 GGML 進行量化
模型推理框架
llama.cpp
llama.cpp 是GGML作者創始開發的一款純C/C++的模型推理引擎，支持量化推理，支持多種設備、操作系統，最早是爲了支持llama的推理，現在已經支持主流的開源模型。
llama.cpp 的一個顯著特點是其對硬件的高效利用。無論是Windows/Linux用戶還是macOS用戶，都可以通過編譯優化來提高模型推理的速度。對於Windows/Linux用戶，推薦與BLAS（或cuBLAS如果有GPU）一起編譯，可以顯著提升prompt處理速度。而macOS用戶則無需額外操作，因爲llama.cpp 已對ARM NEON做優化，並且已自動啓用BLAS。M系列芯片推薦使用Metal啓用GPU推理，以顯著提升速度。
llama.cpp 支持在本地CPU上部署量化後的模型，也就是結合上面提到的GGML，這樣在超低配的硬件也能運行LLM。
chatglm_cpp
https://github.com/li-plus/chatglm.cpp
國產的chatglm模型開源後，有作者參考llama.cpp，開發了支持chatglm推理的chatglm_cpp，底層依然是基於GGML，當前支持ChatGLM-6B, ChatGLM2-6B, ChatGLM3-6B, CodeGeeX2, Baichuan-13B, Baichuan-7B, Baichuan-13B, Baichuan2, InternLM 這些國產開源模型。
vLLM
https://github.com/vllm-project/vllm
vLLM 是來自加州大學伯克利分校的，面向GPU的大模型推理框架。
vLLm 運行大模型非常快主要使用以下方法實現的：
- 通過PageAttention 對attention key & value 內存進行有效的管理
- 連續批處理
- 優化的CUDA kernels
當前支持NVIDIA GPUs 和 AMD GPUs，量化方面支持GPTQ, AWQ, SqueezeLLM, FP8 KV Cache
MLC LLM
https://github.com/mlc-ai/mlc-llm
Machine Learning Compilation for Large Language Models (MLC LLM) 是一個高性能的通用部署解決方案，支持任何大語言模型的原生部署。 MLC LLM支持以下平臺和硬件： AMD GPU、 NVIDIA GPU、 Apple GPU、 Intel GPU、 Linux / Win、 macOS、 Web 瀏覽器、 iOS / iPadOS、 Android。
這個框架是陳天奇(tvm發起者)團隊開發的，最大的特性是可以部署到iOS 和 Android 設備上，還能在瀏覽器上運行SD模型和LLM模型。
DeepSpeed
微軟出品的高性能推理框架，DeepSpeed-FastGen 利用分塊 KV 緩存和動態分割融合連續批處理，提供了比vLLM更好的吞吐。
DeepSpeed-FastGen 支持的模型：
DeepSpeed 沿用了業界主流的 分塊 KV 緩存， 連續批處理技術，同時引入了 動態 SplitFuse 技術，這是一種新穎的提示和生成組合策略，利用動態提示和生成分解, 統一來進一步改善連續批處理和系統吞吐量。詳情可參見 https://github.com/microsoft/DeepSpeed/blob/master/blogs/deepspeed-fastgen/chinese/README.md
推理框架小結
- 如果CPU推理，llama.cpp 結合模型int4量化，最佳的選擇
- GPU推理，微軟的
DeepSpeed-FastGen是一個好的選擇 - 手機終端推理，MLC LLM可以作爲候選
大模型應用開發平臺
之所以稱之爲開發平臺，是這些工具除了支持基本的模型推理，還有標準化的api，以及配套管理工具，可以方便去開發和管理AI應用。
Xorbits Inference
https://github.com/xorbitsai/inference/blob/main/README_zh_CN.md
Xorbits Inference（Xinference）是一個性能強大且功能全面的分佈式推理框架。可用於大語言模型（LLM），語音識別模型，多模態模型等各種模型的推理。通過 Xorbits Inference，你可以輕鬆地一鍵部署你自己的模型或內置的前沿開源模型。無論你是研究者，開發者，或是數據科學家，都可以通過 Xorbits Inference 與最前沿的 AI 模型，發掘更多可能。
官方介紹的主要功能：
🌟 模型推理，輕而易舉：大語言模型，語音識別模型，多模態模型的部署流程被大大簡化。一個命令即可完成模型的部署工作。
⚡️ 前沿模型，應有盡有：框架內置衆多中英文的前沿大語言模型，包括 baichuan，chatglm2 等，一鍵即可體驗！內置模型列表還在快速更新中！
🖥 異構硬件，快如閃電：通過 ggml，同時使用你的 GPU 與 CPU 進行推理，降低延遲，提高吞吐！
⚙️ 接口調用，靈活多樣：提供多種使用模型的接口，包括 OpenAI 兼容的 RESTful API（包括 Function Calling），RPC，命令行，web UI 等等。方便模型的管理與交互。
🌐 集羣計算，分佈協同: 支持分佈式部署，通過內置的資源調度器，讓不同大小的模型按需調度到不同機器，充分使用集羣資源。
🔌 開放生態，無縫對接: 與流行的三方庫無縫對接，包括 LangChain，LlamaIndex，Dify，以及 Chatbox。
dify
https://github.com/langgenius/dify
Dify.AI是一款開源的 LLM （大語言模型）應用開發平臺，它融合了 BaaS（後端即服務）和 LLMOps的理念，涵蓋了構建生成式 AI 原生應用所需的核心技術棧，包括一個內置 RAG 引擎。使用 Dify，可以基於一些開源模型自部署類似 Assistants API 和 GPTs 的能力。
dify的特點：
1. LLM支持：與 OpenAI 的 GPT 系列模型集成,或者與開源的 Llama2 系列模型集成。事實上，Dify支持主流的商業模型和開源模型(本地部署或基於 MaaS)。
2. Prompt IDE：和團隊一起在 Dify 協作，通過可視化的 Prompt 和應用編排工具開發 AI 應用。 支持無縫切換多種大型語言模型。
3. RAG引擎：包括各種基於全文索引或向量數據庫嵌入的 RAG 能力，允許直接上傳 PDF、TXT 等各種文本格式。
4. AI Agent：基於 Function Calling 和 ReAct 的 Agent 推理框架，允許用戶自定義工具，所見即所得。Dify 提供了十多種內置工具調用能力，如谷歌搜索、DELL·E、Stable Diffusion、WolframAlpha 等。
5. 持續運營：監控和分析應用日誌和性能，使用生產數據持續改進 Prompt、數據集或模型。
