SGLang
為什麼重要
深度解析
若要理解 SGLang，得先了解每個推論引擎都面臨的問題。自迴歸解碼一次生成一個 token，而每個 token 都必須讀取模型的所有權重，以及到目前為止生成內容的 KV Cache（KV 快取），因此限制解碼速度的是記憶體頻寬，而不是運算能力。真正關鍵的因素並非原始 FLOPs，而是能將多少請求合併批次處理，以及能避免多少重複工作。SGLang 從兩方面著手：它和其他現代引擎一樣高效地批次處理與排程請求，還進一步辨識正式環境流量中的共用結構——相同的系統提示詞、相同的少樣本範例、相同的對話紀錄——而單純的引擎會為每項請求從頭重新運算這些內容。
RadixAttention 與前綴重複使用
RadixAttention 是 SGLang 最具代表性的貢獻。引擎將 KV 快取儲存在一棵以 token 序列為鍵的基數樹（radix tree）中；當新請求的提示詞與近期算過的內容共用前綴——例如系統提示詞、文件或先前一輪對話——引擎便重複使用現有的快取項目，不再重新運算。SGLang 還搭配快取感知排程，優先將前綴重疊的請求安排至同一個副本執行，以提高快取命中率。對於共用長提示詞或多輪對話流量龐大的工作負載，相較於無狀態服務，這可顯著降低延遲並提高吞吐量。這個概念與 API 供應商販售的提示快取有關，但它會在引擎內部自動運作；包括 vLLM 在內的其他引擎此後也採用了各自的前綴重複使用機制。
高速結構化輸出
SGLang 的另一項招牌功能，是高速的Structured Output（結構化輸出）。受限解碼會在每一步遮蔽不合法的 token，迫使模型遵循文法或 JSON schema，而單純的實作方式會為每個 token 增加可觀的額外負擔。SGLang 以壓縮的有限狀態機表示文法，並運用一項技術跳過輸出中固定不變的區段——固定鍵名、括號與空白——一次送出多個 token，而非逐一生成，藉此將流程最佳化。這比想像中更加重要：代理管線、Function Calling和資料擷取工作會生成大量 JSON，若這部分的解碼加快 2—5 倍，就能直接造就成本更低、反應更快的代理。
SGLang 與 vLLM 的比較
最明顯的比較對象是 vLLM，也就是另一個主流開放原始碼Model Serving引擎。兩者都以 Python 為基礎，都具備連續批次處理、跨 GPU 張量平行處理、量化與推測解碼，也都提供與 OpenAI 相容的 API。vLLM 是歷史較久、生態系較大的專案，核心是 PagedAttention，也就是以區塊為基礎的 KV 快取記憶體管理方法；SGLang 則憑藉 RadixAttention 與受限解碼堆疊，往往在大量共用前綴的流量和結構化輸出上勝出。兩者的基準測試結果會隨每次發布、每個模型家族及每代硬體而變動，因此實務上的答案雖然無趣，卻很實在：將兩者都列入候選，並以自己的工作負載實測。許多推論平台正因如此，同時支援這兩種後端。
更快並不意味著更聰明
常見的誤解，是更換服務引擎會改變模型的能力。事實並非如此。SGLang 是服務層，不是模型，也不是訓練框架——相同權重無論透過 SGLang、vLLM 或其他引擎提供服務，產生的答案基本上一樣。有人聲稱更換引擎後模型變「好」或變「差」，真正原因通常是採用了不同的量化設定、截短了上下文視窗，或變更了溫度等取樣預設值。優良引擎帶來的是效率：每張 GPU 可處理更多請求、第一個 token 的等待時間更短、每秒 token 數更高。這關乎成本和產品延遲，而非能力——因此，引擎選擇是基礎設施決策，不是模型品質決策。
DeepSeek 效應
隨著超大型專家混合模型問世，尤其是 DeepSeek 的 V3 和 R1，SGLang 的知名度大幅提升。這類模型極難提供服務：總參數達數千億、專家平行處理橫跨多張 GPU，注意力設計也打破了舊有服務堆疊的既定假設。SGLang 很早就大力投入這些模型的支援，因此成為開放原始碼社群和推論供應商部署 DeepSeek 規模模型時的首選引擎之一。這項口碑延續至今：每逢大型開放權重新模型發布，實務工作者如今都會主動查看 SGLang 是否能在首日提供支援，就像他們關注 vLLM 的支援一樣。這個專案源自 LMSYS 生態系——也就是 Chatbot Arena 背後的社群——也讓它從一開始就取得研究社群的信任。