簡介：速度陷阱
關於 AI 推論中的「快速」，問題在於每個人都想要，但沒有人同意它的含義。您想要降低單一使用者的延遲嗎？提高大量請求的吞吐量？更高的 tokens-per-dollar？或者只是減少超時，讓您的演示不會在 VP 面前崩潰？「SGL vs vLLM」就是其中一種在 Hacker News 上看起來很簡單，但當您嘗試交付人們實際使用的東西時，就會變成一團亂麻的比較。
我們一直被教導將 serving frameworks 視為衛生紙品牌：它們都可以吸掉溢出的液體，只需選擇「超強吸收」的即可。實際上，SGL 和 vLLM 是不同種類的拖把。它們用不同的物理原理解決類似的混亂問題——並且對於當您的 GPU 快要融化時，請求排程應該如何運作，有著奇怪的固執己見。
讓我們拋開炒作，戳破假設，並討論 SGL vs vLLM 實際上在哪裡不同——以及為什麼您仍然可能選擇「錯誤」的一個，並且過得很好。
SGL vs vLLM：真正的問題是什麼？
- 如果您的關鍵字是「SGL vs vLLM」，那麼您實際的問題可能是：哪個伺服器可以用更少的麻煩，從相同的 GPU 中獲得更多的 tokens？
- 或者：哪一個可以使我的模型對互動式應用程式做出反應，而不會將吞吐量變成一顆南瓜？
- 或者，更誠實地說：我可以在星期五部署哪一個，並且不會在星期一後悔？
這就是框架。細節很重要，但並非同等重要。
vLLM 優化了什麼（以及沒有優化什麼）
vLLM 的品牌是具有智慧的吞吐量。其明星功能是 PagedAttention，這是一種 VRAM 分頁方案，它將 KV 快取視為記憶體管理系統，而不是垃圾抽屜。您可以容納大量並發請求，而不會在填充和無效的上下文中浪費寶貴的 GPU 記憶體。排隊系統針對批次、並發生成進行了優化——可以想像許多使用者、許多聊天，或者一個 API 端點受到中小請求的轟炸。
用簡單的英語來說：vLLM 通過智慧地處理記憶體和排程，使您每個 GPU 可以進行更多同步生成。它以一種好的方式來說是無聊的——保守的預設值、穩定的性能，並且對於常見的形狀，往往可以正常工作。
它在哪裡會咬你：超低延遲的互動式 UX（單一使用者的緊密迴圈）、形狀怪異的提示（巨大的輸入 + 微小的輸出，或者相反），以及挑剔的擴展（自定義層、客製化的量化或最前沿的取樣技巧）有時會與 vLLM 的護欄產生摩擦。對於大多數團隊來說，這是一個可以交付的基準——直到您遇到邊緣情況，並發現基準存在的原因。
SGL 優化了什麼（以及為什麼這很有趣）
SGL 的宣傳更為極端：使用更智慧的排程來擠壓延遲和吞吐量——更動態的搶佔、更細粒度的共享，以及願意處理並發請求，以便在不讓任何一個請求餓死的情況下，使整個群體移動得更快。如果 vLLM 的記憶體模型是其名片，那麼 SGL 的名片就是其排程器。目標不僅僅是將更多東西塞入 VRAM，而且還要保持 GPU 的計算通道的供應，而不會讓長上下文像擱淺的鯨魚一樣坐在那裡，讓短請求等待。
在實踐中，這意味著當工作負載是零星的或混合的時，SGL 通常會發光——一些巨大的提示，一些簡短的回复，流量爆發，以及互動式會話，在這些會話中，延遲峰值是 UX 殺手。它是「擁擠的咖啡店」伺服器：許多小訂單，一個點了 14 種配料的客製化拿鐵的人，以及一個真正知道如何並行處理的咖啡師。
令人不安的事實：更智慧的排程也意味著更多的策略。更多的旋鈕。更多您可能犯錯的決策。如果您需要一個非常簡單的、商品化的部署，SGL 的靈活性可能會讓人感覺像是一個選擇你自己的冒險，其中幾個選擇以龍的結局告終。
核心權衡：延遲 vs 吞吐量 vs 可預測性
- 延遲：SGL 傾向於減少混合工作負載的尾部延遲，因為它在處理方面更積極。vLLM 是穩定的，但當隊列很深時，會優先考慮吞吐量。
- 吞吐量：vLLM 的 PagedAttention 在封裝並發請求以實現高 tokens-per-second-per-GPU 方面是一個怪物。在更智慧的搶佔可以防止計算泡沫的混合負載場景中，SGL 可以匹配或擊敗它。
- 可預測性：vLLM 在「無聊且穩定」方面勝出，SGL 在「我可以調整它以塑造我實際擁有的流量」方面勝出。可預測性不是一種道德美德；它是某些團隊的要求，而對另一些團隊來說是一種束縛。
批次處理和晚餐高峰問題
想像一家餐廳。vLLM 通過像俄羅斯方塊一樣排列桌子來快速安排每個人的座位，因此幾乎沒有空位。SGL 也管理著整個流程，但餐廳領班也在微觀管理廚房——調整上菜順序，以便一個六人桌不會擋住十幾個等待薯條的兩人桌。SGL vs vLLM 的重點不是「誰安排座位更快」，而是「當一個旅遊團出現，並且他們中有一半人對麩質過敏時，誰能保持餐廳的正常運轉」。
如果您的流量平穩且請求形狀一致，那麼 vLLM 的俄羅斯方塊獲勝。如果您的流量是零星的，並且提示長度分佈廣泛，並且您關心互動使用者的第 95 個百分位數延遲，那麼 SGL 的廚房編排會帶來回報。
KV 快取：一個並不奇怪的奇怪技巧
SGL 和 vLLM 都將注意力快取視為珍貴的金屬。vLLM 的分頁是典型的技巧：保持鍵/值緊湊、碎片整理，並且您避免在填充上浪費 VRAM。SGL 的方法更多是關於何時以及如何搶佔和交錯工作，以便快取不會變成垃圾填埋場。
如果您的模型幾乎無法容納多個並發會話，那麼 vLLM 的記憶體效率可能是「運行」和「OOM」之間的區別。如果您的模型可以舒適地容納，但您的使用者抱怨延遲峰值，那麼 SGL 的排程可能是「可用」和「令人愉快」之間的區別。
Token 預算和人類感知
使用者不會感知「每秒 tokens」。他們感知到的是：點擊…等待…回复開始…流動…完成。吞吐量是一個經濟指標；延遲是一個心理指標。SGL 偏向於心理——保持第一個 tokens 的流動，並防止尾部峰值。vLLM 偏向於經濟——最大化穩態生成。兩者都沒有錯。但您的產品可能更偏向於其中一種。
量化和紙牌屋
這裡是那些美好的故事崩潰的地方。一旦您加入 4 位元或 8 位元量化、自定義核心或非主流模型架構，那麼這個決定可能會由今天具有您所需核心支持的任何專案為您做出。SGL vs vLLM 變成了「在 40 分鐘後，什麼可以運行而不會出現神秘的準確性回歸或軟崩潰」。
您可以盡情地浪漫化排程；核心是重力。檢查矩陣以獲取您計劃交付的確切模型、dtype 和 GPU 型號。然後像您不信任任何人一樣進行測試——包括您自己。
串流 UX：第一個 Token 比最後一個更重要
vLLM 對於大多數應用程式來說，串流效果都很好。SGL 對於減少隊首阻塞的痴迷，使其在使用者體驗取決於第一個 token 時間時具有優勢——「這感覺是即時的」和「為什麼這個在旋轉？」之間的區別。如果您的應用程式是程式碼輔助、搜尋增強的聊天或任何人類參與其中的應用程式，那麼第一個 token 比原始的 tokens-per-second 更重要。
相反，如果您正在批量處理每週報告或在伺服器端呈現長篇輸出，那麼 vLLM 的穩態吞吐量可以為您節省 GPU 時間。如果整個過程都是在後台工作，那麼沒有人會關心第一個 token 是在 150 毫秒還是 450 毫秒到達。
運營現實：日誌、限制和「誰在值班？」測試
- vLLM：成熟的運營故事。更容易推理。容量規劃的指標更清晰，因為批次處理和分頁是可預測的。
- SGL：更多的旋鈕。可能更多的力量。當您了解您的流量模式並且您願意塑造它們時，效果更好。但是「凌晨 2 點值班」的故事只和您的運行手冊一樣好。
一個有用的啟發式方法：如果您的團隊無法解釋其自身的 p95/p99 目標以及它們如何映射到收入或 UX，則預設為 vLLM。如果您可以，並且您有理由在混合負載下追求低尾延遲，那麼 SGL 值得其複雜性。
RAG 和帶寬繁重的提示
檢索增強生成 (RAG) 在輸入端火上澆油。包含大量上下文區塊的巨大提示將延遲變成了 tokenization 和輸入傳遞成本的函數。vLLM 的記憶體封裝有助於並排放置更多這些怪物。SGL 的排程可以防止幾隻鯨魚凍結整個鯨群。如果您的 RAG 看起來像「巨大的提示 + 簡短的答案」，SGL 的搶佔可以使事情保持活力。如果它是「中等提示 + 中等答案」並且持續大量，那麼 vLLM 的封裝獲勝。
您可以實際解釋的成本模型
- 每個 GPU 小時的 Tokens：vLLM 傾向於在高負載穩態下獲勝。
- 每個互動會話的成本：當您無法在人類感知中丟幀時，SGL 傾向於獲勝。
- 工程時間：vLLM 通常更便宜，除非您已經深入 SGL 並獲得收益。切換成本是真實存在的。
這些都不是絕對的。但是如果您的 CFO 詢問，您現在擁有聽起來像英語的句子。
您應該忽略的基準（以及不應該忽略的基準）
忽略未披露請求形狀分佈、批次大小、最大並發數、模型 dtype 和 GPU 型號的單個數字圖表。它們是光線恰到好處的健身自拍照。有用的基準：
- 混合分佈負載測試：混合具有不同最大 tokens 的短、中、長提示。
- 突發下的尾部延遲：測量模擬流量高峰期間的 p95/p99 第一個 token 時間。
- 記憶體餘量：在目標並發數下，模型和 kv 快取的實際 OOM 邊距。
- 隨著時間的推移的穩定性：運行六個小時；注意緩慢的洩漏、吞吐量漂移或罕見的停頓。
如果對於其他人的流量在其他人的 GPU 上很快，「更快」就沒有意義。
開發人員人體工程學：您想要多少抽象？
vLLM 偏愛乾淨的 API、可預測的配置以及與流行的工具鏈的對齊。對於想要商品化服務層的團隊來說，這是一個安全的預設值。SGL 為您提供更多的策略介面：優先級、搶佔行為以及塑造計算形狀的空間。如果您需要它，那麼它是黃金——如果您不需要它，那麼它是開銷。
擴展故事也很相似。vLLM 傾向於更早地與流行的生態系統和託管平台集成。SGL 在排程功能和高級並發方面進展迅速。如果您知道為什麼需要 SGL，您可能確實需要它。如果您不知道，您可能還不需要——但很快就需要。
多模型動物園問題
服務於一個旗艦模型是很古怪的。大多數實際應用程式都會處理多個模型：指令調整的 LLM、重新排序器、嵌入，可能還有一個視覺語言模型。vLLM 的可預測性使其更容易在多個模型之間分配容量。SGL 的排程為您提供了避免長時間運行的資源佔用者削弱小型、高優先級呼叫的工具——但您需要設置規則。自動化有所幫助，但策略仍然需要大腦。
關於治理的一句話：SLA 還是感覺？
如果您欠客戶數字（SLA、SLO，選擇您的縮寫），那麼無聊是一個功能。vLLM 的一致性使其更容易承諾閾值並達到它們。如果您的產品完全是關於「感覺」，並且感覺是由即時反饋定義的（想想 IDE 協作程式），那麼 SGL 在壓力下捍衛使用者體驗的能力值得額外的思考。
當 GPU 是錯誤的答案時
最熱門的服務堆疊是使用較少 GPU 的堆疊。當您做成年人該做的事情時，SGL 和 vLLM 都會受益：良好的上下文窗口、智慧的截斷、更好的檢索、響應快取，以及不要求 LLM 為每個按鈕點擊編寫《戰爭與和平》。最便宜的延遲是您永遠不會生成的 token。
真實世界的模式（又名，人們實際上如何選擇）
- 新創公司下週交付 AI 應用程式：vLLM。快速掌握能力獲勝。
- 具有互動式 UX 和零星流量的產品：SGL，針對尾部延遲進行了調整。
- RAG 繁重的支持工具：如果您的提示很大，則平局打破者選擇 SGL；否則選擇 vLLM。
- 擁有一個喜歡排程器的、以性能為導向的領導者的團隊：SGL。負責任地享受。
SGL vs vLLM 用於程式碼輔助和 IDE
這是更清晰的案例之一。程式碼助手的生存取決於感知的響應能力。第一個 token 快速、串流穩定，避免當使用者連續三次敲擊快捷鍵時出現尾部峰值。SGL 以搶佔為中心的世界觀在這裡帶來了回報。vLLM 可以做到——特別是通過仔細的配置和餘量——但您通常會留下一些延遲。
大規模的聊天機器人的 SGL vs vLLM
反過來。對於大規模、穩定的聊天流量——支援機器人、內部助手、廣泛的問答——vLLM 的容量封裝是不斷給予的禮物。如果您的圖表大多是平坦的，並且商業模式獎勵 tokens-per-dollar，那麼這就是您想要的。
中間道路：您可以同時運行兩者
令人震驚的觀點：不同的工作負載，不同的伺服器。在您需要互動性和低尾部延遲的地方運行 SGL；對於批量，運行 vLLM。按端點、租戶甚至一天中的時間進行路由。運營開銷是真實存在的，但您可以免受錯誤的選擇。
Sider.AI 實際上可以工作——至少當您將其用於擅長的事情時，奇怪的是，這與行銷所說的並不完全相同。如果您因為需要一個實用的 AI 工作站和工作流程，並且不會在其自身的膠水程式碼下崩潰，而正在處理 SGL vs vLLM，那麼 Sider 的集成環境是沒有人預算的：一個無聊的介面，提示、文檔和實驗都存在於其中，而無需您重新發明一個草稿應用程式和一個自製的基準測試工具。它不會為您選擇 SGL vs vLLM——也不應該——但它會讓您的團隊在您測試兩者時，專注於結果。 如果您想要一顆銀彈，請去別處尋找。如果您想要減少「想法」、「提示」、「運行」和「交付」之間的尖銳邊緣，那麼 Sider.AI 就能物有所值。 常見的反對意見，不帶偏見的回答
- 「我們將失去 SGL 的吞吐量。」也許吧。在同質負載下，很可能。在混合的、零星的負載下，可能不會——尾部延遲的改進可以提高有效吞吐量。
- 「我們將失去 vLLM 的延遲。」也可能吧。在壓力下，vLLM 可以保持吞吐量，即使第一個 token 時間發生漂移。您可以使用餘量和合理的限制來緩解這種情況。
- 「我們可以調整 vLLM 以使其表現得像 SGL 嗎？」部分可以。您可以優先排序、修剪最大 tokens 並塑造隊列。但排程器的 DNA 是不同的。
- 「我們可以調整 SGL 以使其表現得像 vLLM 嗎？」也部分可以。但是，如果您花費數週時間將 SGL 變成 vLLM，那麼您就選錯了。
在您決定之前，請檢查實用清單
- 定義實際重要的指標：p95 第一個 token 時間、p99 端到端延遲、tokens-per-dollar 或突發下的崩潰率。選擇一個主要指標和一個護欄。
- 重現您真實的流量分佈。不是玩具。真實的提示/響應大小直方圖，真實的突發性。
- 在生產環境般的硬體上，在持續負載下至少測試一個小時。注意漂移、洩漏和罕見的停頓。
- 驗證您確切模型的核心和量化支援。然後在升級驅動程式後再次執行此操作。
如果您不這樣做，請選擇 vLLM 並接受預設值。如果您願意這樣做，SGL 可能會為您帶來更好的使用者體驗和更低的尾部延遲，而這正是樂趣所在。
關於遷移風險的簡短說明
在生產環境中切換服務框架是那種會毀掉週末的工作。如果您懷疑您會想嘗試兩者，請提前計劃：標準化請求/響應架構，保持 tokenizer 和取樣配置的可移植性，並將伺服器隱藏在一致的內部客戶端後面。解耦可以讓您選擇，這是一個用於表達「未來的您不會討厭過去的您」的奇特詞語。
您知道即將到來的辯證結尾
如果您來到這裡希望獲得騎士勳章——崛起吧，SGL 爵士；或者，vLLM 萬歲——您選錯了童話故事。正確的答案是根據工作負載決定的。vLLM 是一款可靠的皮卡車，可以拖運很多東西並且不會抱怨。SGL 是一款運動型旅行車，可以穿梭於交通中而不會灑出咖啡。您可以使用任何一種方式通勤；您會以不同的方式享受駕駛。
請記住：使用者感受到的是延遲，財務部門感受到的是吞吐量。你的工作是在不欺騙任何一方的情況下協調這兩者。SGL 與 vLLM 的比較不是一種感覺檢查，而是承認「快」有多個維度，並且服務框架（就像人一樣）會在壓力下展現其特性。
如果你幸運，你永遠不需要關心。如果你夠優秀，你就會知道何時需要關心。
H2: SGL vs vLLM 性能：尾部延遲 vs 吞吐量
- SGL 傾向於動態排程，以減少 p95/p99 尾部延遲，並在混合負載下改善首個 token 的輸出時間。
- vLLM 的 PagedAttention 將更多並發請求壓縮到相同的 VRAM 中，從而提高每 GPU 的 tokens-per-second。
- 對於互動式 UX 和突發流量，請選擇 SGL；對於穩定的高流量聊天或批次處理，請選擇 vLLM。
H2: 生產環境中 SGL vs vLLM 的部署選擇
- 將你的 SLA 對應到延遲（SGL 友好）或吞吐量（vLLM 友好）。
- 保持一個可移植的客戶端層，以便你可以通過端點將請求路由到 SGL 和 vLLM。
H2: 以正確的方式評測 SGL vs vLLM
- 在真實流量形狀下測量首個 token 的輸出時間和端到端延遲。
- 避免使用隱藏批次大小和請求分配的單一 tokens/sec 指標。
H3: 你真正關心的長尾關鍵字
結論：你可以使用的誠實答案
如果想要可靠的預設選項，並且你的指標是長期運行的每美元 tokens 數量，請選擇 vLLM。如果你的使用者是迴圈中的人類，並且產品的成敗取決於邊緣的感知速度，請選擇 SGL。如果你無法判斷自己屬於哪個陣營，那麼預設情況下你屬於 vLLM 陣營——這也沒關係。好消息是你可以同時運行兩者。更好的消息是你可以停止假裝有一個通用的冠軍。SGL 與 vLLM 是在兩種聰明、有主見的「快」之間做出選擇。剩下的就是你的工作負載、你的預算和你對旋鈕的偏好。
常見問題解答
Q1:哪個更快：SGL 還是 vLLM？
取決於你說的快是什麼意思。vLLM 在穩定的高併發吞吐量方面更快；SGL 在混合、突發負載下，首個 token 的輸出速度更快，並且在尾部延遲方面更一致。如果你的指標是每美元 tokens 數量，那麼選擇 vLLM；如果是感知延遲，則選擇 SGL。
Q2:對於 RAG 工作負載，SGL 是否比 vLLM 更好？
對於具有大量提示和簡短答案的 RAG，SGL 的排程可以防止首個 token 的輸出時間激增。對於大規模的中等提示，vLLM 的記憶體壓縮勝出。在投入大量資源之前，請評測你的實際提示大小。
Q3:我應該如何公平地評測 SGL 與 vLLM？
使用你的真實請求分配，而不是玩具範例。測量 p95/p99 首個 token 輸出時間、整體吞吐量和數小時內的穩定性。披露模型、dtype、GPU、批次大小和併發性——否則你只是在美化圖表。
Q4:我可以在同一個堆疊中部署 SGL 和 vLLM 嗎？
可以，如果你的工作負載不同，你可能應該這樣做。將互動式端點路由到 SGL，將批次或高流量聊天路由到 vLLM。保持一個可移植的客戶端層，以便交換不會毀了你的週末。
Q5:與 SGL 相比，vLLM 何時表現不佳？
在突發的混合工作負載下，首個 token 延遲很重要，並且長提示會阻止短提示。SGL 的搶佔和排程可以平滑這些尾部。如果你的流量是同質的，那麼 vLLM 的穩態通常會勝出。
