vLLM 對決 SGLang 2026：我們在 H100 上進行了基準測試

vLLM 對決 SGLang 2026：我們在 H100 上進行了基準測試

Hugging Face 於 2025 年 12 月將 TGI 置於維護模式，並開始引導團隊在新部署中轉向 vLLM 或 SGLang。如果您今天正在建置推論堆疊，真正的問題不是「我是否應該放棄 TGI？」，而是這兩種引擎中哪一種真正符合您的工作負載需求。

快速總結

選擇 vLLM，如果您希望獲得最廣泛的硬體支援、最大的社群規模，以及在 AWS、GCP 和 Azure 上經過實戰驗證的生產環境路徑。

選擇 SGLang，如果您的工作負載 heavily 依賴多輪對話、結構化輸出，或是像 RAG 這樣前綴較重的管線，並且您能適應較小的生態系統。

現在讓我們深入探討每個引擎實際勝出的領域。

我們是如何走到這一步的？TGI 的退場

Text Generation Inference (TGI) 多年來支撐著 Hugging Face 生態系統，但截至 2025 年 12 月，它僅接受錯誤修復，不再新增功能。Hugging Face 自家的 Inference Endpoints 現在預設使用 vLLM，並將 SGLang 作為替代方案。

這留下了兩個真正的競爭者來進行自託管 LLM 服務。兩者皆為開源，都支援 OpenAI API，並且都能在 NVIDIA GPU 上運行。差異會在負載下顯現出來。

結論：vLLM 和 SGLang 都是生產就緒的 TGI 替代品。 如果您正在遷移，兩者都是安全的選擇，本指南的其餘部分將幫助您決定選擇哪一個。

吞吐量與延遲基準測試

基準測試結果會因模型、GPU 和併發性而異，以下是相同硬體上獨立測試的數據。以下數據來自 Spheron 使用 FP8 格式的 Llama 3.3 70B Instruct 進行的 H100 基準測試，以及 PremAI 使用 Llama 3.1 8B 進行的測試。

H100 上的 Llama 3.3 70B (FP8)

H100 上的 Llama 3.1 8B

在較小的模型上，差距會擴大。PremAI 測量發現 SGLang 約為 16,200 tok/s，而 vLLM 為 12,500 tok/s，SGLang 擁有 29% 的吞吐量優勢。LMDeploy 在此表現與 SGLang 相當，但那是另一個話題。

數字代表的意義

在 70B 規模下，差異不大（3-5%）。但在 8B 規模下則相當顯著。這種模式合乎邏輯：當預填（prefill）佔總成本的比例較大時（這通常發生在較小模型和較短輸出中），SGLang 的 RadixAttention 優勢更為明顯。

尾部延遲也講述了類似的故事。在所有測試的併發層級中，SGLang 的 TTFT p95 始終比 vLLM 低 5-8%。如果您正在建構即時聊天介面，其中每 50 毫秒都至關重要，那麼這個差距會在用戶間累積放大。

結論：SGLang 在原始吞吐量上獲勝，尤其是對於較小的模型。 vLLM 在 70B+ 規模下表現接近。對於大多數生產工作負載而言，差異僅為個位數百分比，在大規模下有意義，但無論選擇哪一方都不是決定性的障礙。

前綴快取：RadixAttention 對比自動前綴快取

兩種引擎都會為重複的前綴快取 KV 計算，但其機制在某些工作負載下有著重要的差異。如果您已經熟悉 API 層級的提示詞快取，可以將此視為伺服器端的版本。

vLLM 使用區塊層級雜湊。它將 KV 快取分割成固定大小的區塊，對其進行雜湊處理，並在新請求中查找匹配項。這種方式可預測、高效且易於理解，但您需要一致的區塊邊界才能實現快取命中。

SGLang 使用在 token 層級索引的基數樹（radix tree）。它無需手動設定即可自動發現請求之間的共享前綴。如果 50 位用戶在同一對話執行緒中發送訊息，SGLang 會自動找到並重用共同前綴。

實際影響何在

RunPod 對多輪對話進行了基準測試，發現 SGLang 在高併發下始終提供約 30-31 tok/s，而隨著快取壓力增加，vLLM 從 22 tok/s 下降到 16 tok/s。對於聊天機器人和代理程式工作負載來說，這是一個有意義的差距。

對於模板化提示詞的批次推論，其中每個請求都使用相同的系統提示詞，vLLM 的方法運作良好。快取邊界自然與您的模板結構對齊。

結論：SGLang 在動態、多輪工作負載中獲勝。 vLLM 對於前綴可預測的批次推論和模板化提示詞來說完全足夠。

結構化輸出

如果您需要 JSON 結構強制執行或約束生成，這一節非常重要。兩種引擎都透過 XGrammar 和 LLGuidance 等語法後端支援 結構化輸出，但效能表現截然不同。

SqueezeBits 進行了詳細的基準測試，發現 vLLM 在啟用引導解碼（guided decoding）時顯示出 顯著的吞吐量下降，特別是在批次大小為 8 及以上時。相比之下，SGLang 將遮罩生成與 GPU 推論步驟重疊，使開銷降至最低。

重複性與動態結構

後端的選擇也很重要：

沒有結構化強制執行時，複雜結構的正確率降至約 61%。有了它，正確率提高了 20-25 個百分點。因此，對於生產環境的代理程式工作流程來說，這並非可選項目，而您選擇的引擎決定了您需要犧牲多少吞吐量。

結論：SGLang 在結構化輸出方面獲勝。 如果您的管線依賴 JSON 結構強制執行（大多數代理程式工作流程皆是如此），SGLang 的重疊方法意味著您無需支付吞吐量稅。

多 LoRA 與微調模型服務

兩種引擎都支援從單一基礎模型服務多個 LoRA 適配器，如果您為不同租戶或任務 微調模型，這至關重要。

SGLang 將多 LoRA 視為一等公民功能，具備原生批次處理能力，針對不同適配器的請求可以共享同一個批次。vLLM 也支援此功能，但 SGLang 的實作在最近幾個版本中稍微更加完善。

實際差異是什麼？如果您從一個 Llama 70B 基礎模型服務 5-10 個 LoRA 適配器，兩者皆可運作。如果您運行 50 個以上具有異質流量模式的適配器，SGLang 的原生批次處理能更優雅地處理排程。

結論：在大規模多 LoRA 場景中，SGLang 略有優勢。 對於少數幾個適配器，兩種引擎表現同樣出色。

推測式解碼 (Speculative Decoding)

兩種引擎都支援推測式解碼，這使用一個小型「草稿」模型來預測 token，然後由主模型平行驗證。結果是在記憶體受限的情境下，推論速度加快 2-3 倍。

vLLM 最近推出了統一平行草稿（Unified Parallel Drafting），推測式解碼現在可與結構化輸出同時運作。SGLang 的實作能力相似，在中等併發層級下表現稍佳。

真正的區別不在於引擎，而在於推測式解碼是否適合您的工作負載。它在大型模型的長輸出中最有幫助，因為瓶頸在於記憶體頻寬而非計算能力。

結論：平手。 兩種引擎提供相當的推測式解碼加速效果。

硬體支援與部署

這是 vLLM 顯著領先的地方。

vLLM

• NVIDIA GPU (A100, H100, H200, B200)
• AMD GPU (MI250, MI300X)
• Intel GPU (透過 vllm-xpu-kernels)
• AWS Trainium 和 Inferentia
• Google TPU
• 成熟的 Kubernetes 文件，包含 Helm charts、啟動/就緒/存活探針
• 開箱即用的 NVIDIA Container Toolkit 整合

SGLang

• NVIDIA GPU (A100, H100, H200, B200)
• AMD GPU (MI300X, 透過 ROCm)
• 以 Docker 為主的部署
• Kubernetes 可行但文件較少

如果您部署在任何非 NVIDIA 或 AMD 的硬體上，vLLM 是您唯一的選擇。特別是在 AWS 上，Trainium 支援意味著您可以顯著降低推論成本，而 SGLang 無法支援該硬體。

對於在標準 NVIDIA GPU 上運行的團隊，部署情況類似。兩者都提供 Docker 映像和 OpenAI 相容端點。vLLM 只是擁有更多經過實戰驗證的生產指南和社群貢獻的 Helm charts。

如果您正在探索 在本地運行 LLM 的工具 或想更全面地了解 自託管推論，兩種引擎也都支援在消費級 GPU 上进行本地部署，儘管它們是為資料中心硬體設計的。

結論：vLLM 在硬體廣度和部署成熟度上獲勝。 如果您使用 NVIDIA 或 AMD，SGLang 沒問題。在其他任何地方，vLLM 是唯一選擇。

分離式服務 (Disaggregated Serving)

兩種引擎都支援將預填（計算密集型）與解碼（記憶體密集型）分離到不同的工作池。這讓您能夠獨立擴展每個階段，在提示詞密集的爆發期間增加更多預填工作節點，或在長生成期間增加更多解碼工作節點。

SGLang 支援 Mooncake 和 NIXL 作為分離式的傳輸後端，並發布結果顯示在 NVIDIA GB200 NVL72 集群上解碼吞吐量提高了 2.7 倍。vLLM 的分離式服務也可運作，尽管文件記載較少。

此功能在非常大規模（96+ GPU）時最為重要。如果您只運行少數幾個 GPU，可能還不需要它。

結論：SGLang 在分離式服務成熟度上略有優勢。 兩者都支援；SGLang 發布了更多真實世界結果。

何時使用哪一個：決策框架

許多團隊的誠實答案：兩者都試試看。它們都是開源的，都暴露相同的 OpenAI API，且在它們之間切換只是更換容器。將您的實際工作負載分別在兩者上運行一天，並比較對您重要的指標。

如果您要在多個推論後端之間路由流量，LLM 閘道器 可以位於任一引擎之前，處理故障轉移、速率限制和可觀測性。

Techsy 如何選擇推論伺服器

當我們協助團隊部署 LLM 驅動的功能時，推論引擎的選擇取決於三個問題：

1. 您被鎖定在哪種硬體上？ 如果是 Trainium 或 TPU，那就是 vLLM。其他情況，兩者皆可。
2. 您的工作負載形狀為何？ 多輪聊天和代理程式循環有利於 SGLang 的前綴快取。批次處理和簡單補全在任一引擎上都沒問題。
3. 您有多少維運容量？ vLLM 較大的社群意味著當凌晨 3 點發生問題時，有更多的 StackOverflow 答案和 Helm charts 可供參考。

我們在兩者上都運行過生產工作負載。它們確實非常接近。正確的答案取決於您的約束條件，而不是抽象地認為哪一個「更好」。

需要幫助選擇或部署推論伺服器嗎？聯繫我們，我們將評估您的工作負載並推薦合適的堆疊。

選擇工具只是簡單的一半。讓它在真實產品中可靠運行才是大多數團隊停滯不前的地方，而這正是我們的 AI 整合團隊 為客戶建構的內容，從 RAG 管線到自訂代理程式。

常見問題

SGLang 比 vLLM 快嗎？

在較小的模型（7B-8B）上，SGLang 在 H100 GPU 上顯示出約 29% 更高的吞吐量。在 70B+ 模型上，差距縮小到 3-5%。在所有測試的併發層級中，SGLang 也具有較低的尾部延遲（TTFT p95）。

我可以將 vLLM 和 SGLang 與 OpenAI API 格式一起使用嗎？

是的。兩者都開箱即用暴露 OpenAI 相容端點。您可以在不更改客戶端代碼的情況下將一個換成另一個。您的 /v1/chat/completions 呼叫在兩者上運作方式相同。

為什麼 Hugging Face 棄用 TGI？

TGI 於 2025 年 12 月進入維護模式。Hugging Face 決定貢獻給 vLLM 和 SGLang，而不是維護單獨的推論引擎。TGI 仍適用於現有部署，但不會有新功能。

SGLang 支援 NVIDIA 和 AMD GPU 嗎？

SGLang 支援 NVIDIA GPU（A100, H100, H200, B200）和 AMD GPU（透過 ROCm 的 MI300X）。它不支援 Intel GPU、AWS Trainium、Inferentia 或 Google TPU。vLLM 擁有更廣泛的硬體覆蓋範圍。

什麼是 RadixAttention，為什麼它很重要？

RadixAttention 是 SGLang 的前綴快取機制。它將 KV 快取條目存儲在 token 層級索引的基數樹中，自動發現請求之間的共享前綴。這使得多輪對話和 RAG 管線顯著更快，因為重複的上下文無需重新計算。

哪種引擎更適合結構化 JSON 輸出？

SGLang。它將語法遮罩生成與 GPU 推論重疊，因此結構化輸出強制執行幾乎不影響吞吐量。當啟用引導解碼時，vLLM 在批次大小為 8 及以上時顯示出明顯的性能下降。

我可以從一個基礎模型服務多個 LoRA 適配器嗎？

兩種引擎都支援多 LoRA 服務。SGLang 將其視為原生功能，可在同一請求批次中跨不同適配器進行批次處理。vLLM 也支援，但 SGLang 的排程在高適配器數量下更有效率。

什麼是分離式預填/解碼服務？

這意味著在不同的 GPU 工作節點上運行預填階段（處理提示詞）和解碼階段（生成 token）。預填是計算綁定的；解碼是記憶體綁定的。將它們分離讓您能夠獨立擴展每個階段。兩種引擎都支援此功能，SGLang 擁有更多發布的生產結果。

如何從 TGI 遷移到 vLLM 或 SGLang？

由於三者都暴露 OpenAI 相容 API，遷移主要是更換容器。將您的 Docker Compose 或 Kubernetes 部署指向新映像，調整模型加載標誌，並更新健康檢查端點。客戶端代碼保持不變。

我應該為 RAG 管線使用 vLLM 還是 SGLang？

SGLang 是 RAG 的更強選擇。其 RadixAttention 自動快取並重用 RAG 管線反覆發送的長系統提示詞和文檔上下文。vLLM 的區塊層級快取也可運作，但當文檔塊在請求間略有變化時，您會在 SGLang 的 token 層級方法中看到更好的快取命中率。

最終結論

SGLang 贏得了更多類別，但 vLLM 的優勢——硬體廣度和生態系統成熟度——是那種在凌晨 3 點節點宕機時至關重要的事情。

如果您使用 NVIDIA 硬體，且工作負載涉及多輪對話、具有結構化輸出的代理程式，或具有共享前綴的 RAG 管線，請從 SGLang 開始。您將在關鍵領域獲得更好的吞吐量和更低的延遲。

如果您需要多雲靈活性、非 NVIDIA 硬體支援，或最大開源 LLM 服務社群帶來的安心感，請從 vLLM 開始。這是更安全的預設選項，能很好地服務大多數團隊。

無論如何，兩種引擎都非常優秀且快速改進。選擇一個，部署它，測量您的實際工作負載，如果數據告訴您該切換，那就切換。OpenAI 相容 API 使這種切換變得輕鬆無痛。

來源

• Spheron H100 基準測試：vLLM vs TensorRT-LLM vs SGLang
• PremAI：vLLM vs SGLang vs LMDeploy 基準測試
• SqueezeBits：vLLM 和 SGLang 上的引導解碼性能
• RunPod：SGLang vs vLLM KV 快取重用
• SGLang 官方文件
• vLLM 官方文件