賈揚清點贊：3K star量的SGLang上新，加速Llama 405B推理秒殺vLLM、TensorRT-LLM

机器之心發表於2024-07-27

用來執行 Llama 3 405B 優勢明顯。


最近，Meta 開源了最新的 405B 模型（Llama 3.1 405B），把開源模型的效能拉到了新高度。由於模型引數量很大，很多開發者都關心一個問題：怎麼提高模型的推理速度？

時隔才兩天，LMSYS Org 團隊就出手了，推出了全新的 SGLang Runtime v0.2。這是一個用於 LLM 和 VLM 的通用服務引擎。在執行 Llama 3.1 405B 時，它的吞吐量和延遲表現都優於 vLLM 和 TensorRT-LLM。

在某些情況下（執行 Llama 系列模型），它的吞吐量甚至能達到 TensorRT-LLM 的 2.1 倍，vLLm 的 3.8 倍。
圖片
LMSYS Org 團隊是一個由加州大學伯克利分校、加州大學聖地亞哥分校以及卡內基梅隆大學的學生與教職員工共同組建的公開性質的研究團體。他們開發的大模型評測平臺 ——Chatbot Arena 已經成為檢驗大模型能力的重要平臺，也被認為是一種相對公平的評測方式。

SGLang 是該團隊開發的一個用於大型語言模型和視覺語言模型的快速服務框架，於今年 1 月份正式推出，在 GitHub 上已經收穫了超過 3k 的 star 量。

圖片

這次的更新效果驚豔，知名 AI 研究者、Lepton AI 聯合創始人兼 CEO 賈揚清評價說「我一直被我的博士母校加州大學伯克利分校驚豔，因為它不斷交付最先進的人工智慧和系統協同設計成果。去年我們看到了 SGLang 的使用，現在它變得更好了。迫不及待地想在產品中部署並嘗試新的 SGLang！」
圖片
為什麼 LMSYS Org 要開發並迭代 SGLang 呢？他們在部落格中提到，「我們已經執行 Chatbot Arena 平臺一年多，為數百萬使用者提供服務。我們深知高效服務對人工智慧產品和研究的重要性。透過運營經驗和深入研究，我們不斷增強底層服務系統，從高階多模型服務框架 FastChat 到高效服務引擎 SGLang Runtime (SRT)。」

「這篇文章的重點是 SGLang Runtime，它是一個用於 LLM 和 VLM 的通用服務引擎。雖然 TensorRT-LLM、vLLM、MLC-LLM 和 Hugging Face TGI 等現有選項各有優點，但我們發現它們有時難以使用、難以定製或效能不佳。這促使我們開發了 SGLang v0.2，旨在建立一個不僅使用者友好、易於修改，而且效能一流的服務引擎。」

與 TensorRT-LLM 和 vLLM 相比，SGLang Runtime 在處理從 Llama-8B 到 Llama-405B 的模型時，以及在 A100 和 H100 GPU 上使用 FP8 和 FP16 時，在線上和離線場景下都能持續提供卓越或有競爭力的效能。SGLang 的效能始終優於 vLLM，在 Llama-70B 上的吞吐量最高是前者的 3.8 倍。它還經常與 TensorRT-LLM 不相上下，甚至超過 TensorRT-LLM，在 Llama-405B 上的吞吐量最高是前者的 2.1 倍。更重要的是，SGLang 是完全開源的，由純 Python 編寫，核心排程器只用了不到 4K 行程式碼就實現了。

SGLang 是一個開源專案，採用 Apache 2.0 許可授權。它已被 LMSYS Chatbot Arena 用於支援部分模型、Databricks、幾家初創公司和研究機構，產生了數萬億 token，實現了更快的迭代。

以下是幾個框架的對比實驗設定和結果。

基準設定

研究者對離線和線上用例進行基準測試：

離線：他們一次傳送 2K 到 3K 個請求，測量輸出吞吐量（token / 秒），即輸出 token 數除以總持續時間。他們測試的合成資料集來自 ShareGPT 資料集。例如，I-512-O-1024 表示平均輸入 512 個 token、平均輸出 1024 個 token 的資料集。五個測試資料集分別為：

  • 資料集 1：I-243-O-770；
  • 資料集 2：I-295-O-770；
  • 資料集 3：I-243-O-386；
  • 資料集 4：I-295-O-386；
  • 資料集 5：I-221-O-201。

線上：他們以每秒 1 到 16 個請求 (RPS) 的速率傳送請求，測量端到端延遲的中位數。他們使用合成資料集 I-292-O-579。

他們使用 vLLM 0.5.2（帶預設引數）和 TensorRT-LLM（帶推薦引數和調整後的批大小）。所有引擎都關閉了字首快取。目的是在沒有任何附加功能（如推測解碼或快取）的情況下，對基本效能進行基準測試。他們使用與 OpenAI 相容的 API 對 SGLang 和 vLLM 進行基準測試，並使用 Triton 介面對 TensorRT-LLM 進行基準測試。

Llama-8B 在一個 A100 上執行（bf16）

研究者從小型模型 Llama-8B 開始測試。下圖顯示了每個引擎在五個不同資料集的離線設定下所能達到的最大輸出吞吐量。TensorRT-LLM 和 SGLang 都能達到每秒約 4000 個 token 的吞吐量，而 vLLM 則稍遜一籌。
圖片
下面的線上基準圖顯示了與離線情況類似的趨勢。TensorRT-LLM 和 SGLang 的效能相當，可以保持 RPS > 10，而 vLLM 的延遲在請求率較高時顯著增加。
圖片
Llama-70B 在 8 個 A100 上執行（bf16）

至於在 8 個 GPU 上進行張量並行的較大型 Llama-70B 模型，趨勢與 8B 相似。在下面的離線基準測試中，TensorRT-LLM 和 SGLang 都能達到很高的吞吐量。
圖片
在下圖的線上結果中，TensorRT-LLM 憑藉高效的核心實現和執行時間，顯示出較低的延遲。
圖片
Llama-70B 在 8 個 H100 上執行（fp8）

現在來測試 FP8 效能。vLLM 和 SGLang 都使用了 CUTLASS 的 FP8 核心。在離線設定中，SGLang 的批處理排程器非常高效，可以隨著批處理規模的增大而繼續擴充套件吞吐量，在這種情況下實現了最高吞吐量。其他系統則由於 OOM、缺少大量手動調整或存在其他開銷而無法擴充套件吞吐量或批大小。線上情況下也是如此，SGLang 和 TensorRT 的中位延遲相似。
圖片
圖片
Llama-405B 在 8 個 H100 上執行（fp8）

最後，研究者在最大的 405B 模型上對各種方法的效能進行了基準測試。由於模型較大，大部分時間都花在了 GPU 核心上。不同框架之間的差距縮小了。TensorRT-LLM 效能不佳的原因可能是 405B 模型剛剛問世，而圖中使用的版本尚未整合一些最新最佳化。在線上和離線情況下，SGLang 的效能都是最好的。
圖片
圖片
SGLang 概覽

SGLang 是大型語言模型和視覺語言模型的服務框架。它基於並增強了多個開源 LLM 服務引擎（包括 LightLLM、vLLM 和 Guidance）的許多優秀設計。它利用了來自 FlashInfer 的高效能注意力 CUDA 核心，並整合了受 gpt-fast 啟發的 torch.compile。

此外，研究者還引入了一些創新技術，如用於自動 KV 快取重用的 RadixAttention 和用於快速約束解碼的壓縮狀態機。SGLang 以其完全用 Python 實現的高效批處理排程器而聞名。為了進行公平比較，本部落格測試了這些服務引擎在關閉特定場景或工作負載最佳化（如字首快取和推測解碼）後的基本效能。SGLang 的提速是透過適當的工程設計實現的。SGLang 基於 Python 的高效批處理排程器具有良好的擴充套件性，通常可與使用 C++ 構建的閉源實現相媲美，甚至更勝一籌。

表 1 比較了 SGLang、TensorRT-LLM 和 vLLM 的各個方面。在效能方面，SGLang 和 TensorRT-LLM 都非常出色。在可用性和可定製性方面，SGLang 的輕量級和模組化核心使其易於定製，而 TensorRT-LLM 複雜的 C++ 技術棧和設定說明使其更難使用和修改。SGLang 的原始碼完全開源，而 TensorRT-LLM 僅部分開源。相比之下，vLLM 的 CPU 排程開銷較高。
圖片
研究者還表示，未來他們還將開發長上下文和 MoE 最佳化等新功能。

使用方法

你可以按照以下步驟輕鬆服務 Llama 模型：

1、使用 pip、原始碼或 Docker 安裝 SGLang：https://github.com/sgl-project/sglang/tree/main?tab=readme-ov-file#install

2、啟動伺服器：
# Llama 8B
python -m sglang.launch_server --model-path meta-llama/Meta-Llama-3.1-8B-Instruct

# Llama 405B
python -m sglang.launch_server --model-path meta-llama/Meta-Llama-3.1-405B-Instruct-FP8 --tp 8

3、使用 OpenAI 相容的 API 傳送請求：
curl http://localhost:30000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "default",
    "prompt": "Say this is a test",
    "max_tokens": 7,
    "temperature": 0
  }'

4、執行基準： 
python3 -m sglang.bench_serving --backend sglang --num-prompts 1000

附錄：詳細的基準設定

重現基準的說明位於 sglang/benchmark/blog_v0_2。

對於所有基準測試，研究者都設定了 ignore_eos 或 min_length/end_id 以確保每個引擎輸出相同數量的 token。他們曾嘗試使用 vLLM 0.5.3.post1，但它在高負載情況下經常崩潰，與部分基準測試中的 vLLM 0.5.2 相比，vLLM 0.5.3.post1 效能似乎差不多甚至更差。因此，他們報告的是 vLLM 0.5.2 的結果。雖然他們知道不同的伺服器配置會對服務效能產生重大影響，但他們主要使用每個引擎的預設引數來模擬普通使用者的情況。

對於 8B 和 70B 模型，他們使用 meta-llama/Meta-Llama-3-8B-Instruct 和 meta-llama/Meta-Llama-3-70B-Instruct bf16 檢查點，以及 neuralmagic/Meta-Llama-3-70B-Instruct-FP8 fp8 檢查點。對於 405B 模型，他們在所有基準測試中都使用了虛擬權重。由於 TensorRT-LLM 最新影像 r24.06 不支援官方 meta-llama/Meta-Llama-3.1-405B-FP8 檢查點中的 fbgemm_fp8 量化，他們在所有框架中都使用了每層 fp8 量化，並對除 lm_head 以外的所有層進行了量化。他們相信這樣可以對所有引擎進行公平的比較。A100 和 H100 GPU 為 80GB SXM 版本。

參考連結：https://lmsys.org/blog/2024-07-25-sglang-llama3/

相關文章