訓練大型語言模型以及微調的教程比比皆是，但關于在生產環境中部署它們并監控其活動的資料相對稀缺。上章節提到了未來云原生的AI是趨勢，然而涉及到云原生會比較偏技術。而在此之前為了解決大模型部署量產的問題，社區也一直在探索，目前已有不少工具可用于這個領域。

另一方面，選擇正確的推理后端為大型語言模型 （LLMs） 提供服務至關重要。不同的后端提供不同的服務LLMs方式，每種方式都有獨特的功能和優化技術。它不僅確保了最佳的用戶體驗和最快的生成速度，而且還通過高Token生成率和資源利用率提高了成本效益。

在介紹往vLLM和TGI之后，恰好BentoML工程團隊在BentoCloud上對Llama 3使用vLLM、LMDeploy、MLC-LLM、TensorRT-LLM和Hugging Face TGI的服務性能進行全面的基準測試。這里所有推理后端都遵循Apache 2.0 許可證。

1.實驗背景

BentoML 工程團隊在BentoCloud上對Llama 3使用vLLM、LMDeploy、MLC-LLM、TensorRT-LLM和Hugging Face TGI的服務性能進行全面的基準測試。這里使用兩個關鍵指標進行評估：

• TTFT：測量從發送請求到生成第一個令牌的時間，以毫秒為單位記錄。TTFT對于需要即時反饋的應用程序非常重要。更低的延遲可提高感知性能和用戶滿意度。<注意，這個過程為解碼過程！>
• TGR：評估模型在解碼過程中每秒生成的Token，以每秒令牌數為單位。Token生成率是模型處理高負載能力的指標。高的數值表明該模型可以有效地管理多個請求并快速生成響應，適用于高并發環境。

本次實驗是在BentoCloud上單個A100 80GB GPU實例上使用Llama 3 8B和70B的4位量化<??忘記量化的請查看鏈接！??>模型進行了基準測試，涉及三個級別的推理負載（10、50 和 100 個并發用戶）。

• vLLM: 0.4.2
• MLC-LLM: mlc-llm-nightly-cu121 0.1.dev1251 (No stable release yet)
• LMDeploy: 0.4.0
• TensorRT-LLM: 0.9.0 (with Triton v24.04)
• TGI: 2.0.4

2.指標解讀

解讀之前，小編溫馨提醒，實驗的結果僅供參考。畢竟這個實驗是在特定的場景下實驗。若配合其他的優化手段，結果可能大不一樣，但是還是可以管中窺豹。先來看看Llama-3-8B的情況：

上面的指標TTFT數值是越低越好，而下面的指標TGR數值是越高越好

LMDeploy：在Token生成率方面提供最佳解碼性能，100個用戶每秒最多可處理4000 個Token。在10個用戶中實現了一流的TTFT。盡管TTFT隨著用戶的增加而逐漸增加，但它的延時還是在可接受的范圍。

MLC-LLM：解碼性能略低，100個用戶每秒約3500個令牌。然而隨著時間的推進，TGR從運行基準測試5分鐘后降低到每秒3100個Token。

vLLM：一流的 TTFT。但與LMDeploy和MLC-LLM相比，解碼性能不太理想，每秒2300-2500個令牌類似于 TGI 和 TRT-LLM。

后面來看看Llama-3-70B 4位量化的情況：

LMDeploy：在為 100 個用戶提供服務時，提供高達 700 個Token的生成率，同時在所有級別的并發用戶中保持最低的TTFT。

TensorRT-LLM：在Token生成率方面表現出與LMDeploy相似的性能，并在低并發用戶數量下保持低 TTFT。但是當并發用戶數達到100 時，TTFT下滑厲害。

vLLM：始終表現出較低的TTFT，類似于在8B模型中觀測到的。與 LMDeploy和TensorRT-LLM相比，Token生成率較低。

3.對比表格

下面對比表格從量化、模型和支持的硬件將物種大模型的服務端（運行大模型，對外提供服務）進行對比，其實也給讀者提供決策的依據。在選擇部署大模型的時候，可以先針對量化情況，基座模型支持度以及手頭的硬件綜合選擇后端的服務，配合云原生進行產線部署。

當然除此之外還是要考慮這些服務是否有穩定版本，模型編譯情況還有就是文檔齊備性。

本文轉載自 ??魯班模錘??，作者： 龐德公