【原】不要再用Ollama，不要再用llama.cpp

大家好，我是 Ai 學習的老章

最近在測試 llama.cpp 這個推理引擎的表現，主要是啟動 GGUF 格式的量化大模型比較方便

# 內網部署 llama.cpp，運行量化大模型

# 純離線安裝大模型推理引擎，部署量化大模型

啟動確實方便，但是性能測試結果卻很不理想

單并發極快，速度飛起，并發數上來之后平均 TPS 斷崖式下降

我的啟動腳本中是設置了并發相關參數的

搜了一下了 Reddit 的 LocalLLaMA 社區，發現很多吐槽

llama.cpp 項目 issue 還有吐槽

看了一個博主的文章《# Stop Wasting Your Multi-GPU Setup With llama.cpp》^[1]

作者地下室里的常駐 AI 服務器——一臺配備 14 張 RTX 3090 GPU 和 336GB VRAM 的專用 AI 服務器，在此設備上做過大量測試。

省流： lama.cpp 并未針對張量并行（Tensor Parallelism）與批推理（Batch Inference）進行優化。只有在進行 LLM 的部分或全部 CPU 卸載時，你才應該使用 llama.cpp。但在多 GPU 配置下，需要經過優化的批推理與 Tensor Parallelism，此時 vLLM 或 ExLlamaV2 等才是正確選擇。也不要使用 Ollama，它只是 llama.cpp 的一個封裝，干的就是設置環境變量、蹩腳地計算顯存拆分和卸載。如果你只有一塊 GPU，只想跑點基礎模型做做聊天，那它還行；但凡超出這個范圍，就不值得用了。

llama.cpp^[2] 是一個支持多種模型架構和硬件平臺的推理引擎。然而，它不支持批處理推理，因此一次處理多個請求時并不理想。它主要與 GGUF 量化格式配合使用，在單次請求場景下性能尚可，但也就僅此而已。唯一真正推薦使用 llama.cpp 的情況是：當你的 GPU 顯存（VRAM）不足，需要將部分模型權重卸載到 CPU 內存（RAM）時。

它是目前最流行的推理引擎。圍繞它的開源社區非常活躍，通常能很快支持新模型和新架構，尤其因為它支持 CPU 卸載，對更廣泛的用戶群體而言也極易上手。遺憾的是，llama.cpp 并不支持、也大概率永遠不會支持張量并行（Tensor Parallelism）^[3] 因為大多數人不會像我一樣把幾千美元砸在快速貶值的資產上^[4] ??

作者的 AI 服務器配備了 512 GB 高性能 DDR4 3200 3DS RDIMM 內存，可提供 CPU 架構所支持的最大內存帶寬。配合 AMD Epyc Milan 7713 CPU，僅通過 CPU 卸載就能夠在 DeepSeek v2.5 236B BF16 模型上實現每秒約 1 個 token。

但是

利用 14x GPU AI 服務器中的 8 塊 GPU，僅通過 GPU 卸載，服務器在處理 Llama 3.1 70B BF16 時，通過 vLLM 使用張量并行的批量推理，可達到每秒約 800 個 token，同時處理 50 個異步請求。

這是為什么呢？

從宏觀上看，張量并行將模型每一層的計算分布到多塊 GPU 上。與其在單塊 GPU 上完成整個矩陣乘法，不如把運算切分，讓每塊 GPU 只處理一部分工作量，這樣每塊 GPU 就能同時運行不同層中的不同部分，使結果以指數級速度計算出來。

張量并行對多 GPU 配置至關重要——經驗法則是 TP 喜歡 2^n，因此下面運行模型時用了 8×GPU——而在對系統進行壓力測試時，并行也比串行更合適。當你試圖用 llama.cpp 讓 LLMs 彼此對話時，引擎會把這些 GPU 拖慢，讓它們一個接一個地排隊等待。

下圖作者運行的一個腳本：50 個異步請求，每個請求約 2k tokens，總共耗時 2 分 29 秒，使用的是 vLLM 運行 Llama 3.1 70B BF16。如果改用 INT8 量化或更低精度，速度會快得多；再加上投機解碼和/或嵌入模型，速度還會進一步提升。這一切都離不開 vLLM 利用張量并行實現的批推理。

作者還測試了 vLLM、Aphrodite、Sglang、TensorRT-LLM、ExLlamaV2 和 LMDeploy 等支持張量并行的推理引擎。其中 ExLlamaV2^[5] 它是一款僅 GPU 的推理引擎，ExLlamaV2 帶來了獨一無二的 EXL2 量化格式 ，如今已被多款推理引擎采納，因為它在顯存利用率上的優勢巨大。