LLM服務公平性
Cohere推出了一種新的推理請求調度解決方案，通過結合速率限制器、性能層級、赤字輪詢和優先級選擇器，確保多租户LLM平台中不同租户之間的公平性，防止“吵鬧鄰居”現象，保障每個租户獲得公平的計算資源份額。
將大型語言模型作為多租户SaaS平台運行面臨一個隱藏的難題：多個組織共享同一組GPU，它們的流量是突發且不均勻的。如果不加管理，一個客户的流量激增可能會變成其他客户的延遲問題。
在這篇博文中，我們將介紹Cohere用於跨租户公平調度推理請求的新解決方案，該方案結合了架構模式和經典調度算法。
問題：吵鬧鄰居
推理在請求被批量處理時效率最高。滿載批次的GPU運行高效且經濟，而一次只處理一個請求的GPU大部分時間處於空閒。因此，請求會短暫排隊，然後被打包成批次再送到硬件。
問題在於排序。想象一個簡單的隊列：一個單一的共享隊列，僅按優先級和截止日期排序。現在，考慮當一個組織突發發送10,000個請求，而另一個組織只發送5個時會發生什麼。使用單一的全局隊列，10,000個請求排在前面，而五個表現良好的請求則在後面等待。
這就是經典的“吵鬧鄰居”問題，多租户LLM平台與其他面臨此類流量模式的共享系統沒有什麼不同。
服務公平性的目標是隔離租户，使租户獲得的推理容量份額取決於公平調度，而不是取決於它如何激進地淹沒隊列。同時，它仍然保留每個租户內部的優先級和截止日期排序，同時保持批處理效率。
解決方案：分層容量管理方法
Cohere通過組合四種不同的機制來公平地管理跨租户的工作負載，每種機制解決問題的不同部分。它們按固定順序運行：速率限制器控制入口准入，然後三個選擇器——性能層級、赤字輪詢和優先級——選擇下一個出去的請求。
以下是架構和逐步流程：
- 速率限制器
在請求進入調度隊列之前，它需要通過准入控制。速率限制限制單個租户在給定時間範圍內（如每分鐘或每月）可以提交的推理請求的最大數量。
在Cohere，這些限制在端點級別配置，並根據每個模型消耗的資源量而有所不同。例如，重量級生成模型比輕量級嵌入模型具有更嚴格的限制。
還有一個實時節流檢查：如果隊列已經積壓太多，以至於新請求無法在其延遲目標內得到服務，則請求會提前被拒絕。這可以保護系統免受無法完成的工作的影響，並在負載下保持可預測的延遲。
請求被准入後，會進入下面的選擇器鏈。
- 性能層級（選擇器一）
第一個選擇決策是層級。計算資源根據服務級別協議（SLA）進行優先級排序：付費較高的層級獲得比低層級（或試用層級）更高的處理優先級和更快的隊列處理。反過來，後者的客户在容量允許的情況下得到服務。
關鍵的是，層級決定了誰先走；它本身並不能防止層級內單個大租户的支配。這是接下來兩層的目的。
- 赤字輪詢（選擇器二）
系統的核心是赤字輪詢（DRR）算法，它確保在同一層級內公平分配計算資源。
每個租户（“組織”）都有自己的隊列。調度器不是要清空最長的隊列，而是在租户之間輪流。每個租户獲得一個小的預算——一個量子——在輪到自己時可以做的工作。當租户使用其輪次時，其預算會根據剛發送的請求的成本進行扣減。預算用完的租户會被跳過，直到下一輪預算被補充。
DRR的優雅之處在於它既工作守恆又加權。便宜的請求讓租户更頻繁地出現在輪次中，昂貴的則較少，因此沒有租户能獨佔GPU，但也不浪費任何容量。回到之前的例子：即使組織A排了10,000個請求，而組織B只有5個，組織B仍然在每個週期獲得應得的輪次。組織A的突發不再轉化為組織B的延遲。
預算的衡量標準
該方案依賴於兩個關鍵變量：
- 量子：每輪授予租户的預算量
- 成本：每個請求消耗的預算量
關鍵的設計選擇在於這些變量以什麼單位表示。這決定了在不同推理上下文中如何概念化“公平性”。在Cohere，我們根據端點使用兩種成本模型：基於請求的預算和基於令牌的預算。
基於請求的預算
為了簡單起見，每個請求的成本設為1，量子是租户每輪可以發送的請求數。因此，公平性純粹以請求數量來衡量。
這對於生成端點（如聊天和補全）來説不是最優的，因為請求服務成本可能差異很大。一個具有100K令牌提示的請求可能比一個1K令牌提示的請求消耗多幾個數量級的資源。對於推理能力模型，總成本不僅取決於輸入大小，還取決於請求特定上下文所觸發的中間推理、規劃和輸出生成量。
理想情況下，DRR將使用基於請求令牌歸一化服務成本的指數移動平均（EMA）的反饋循環，使預算適應觀察到的資源消耗。當端點內的請求在大小和成本上大致相似時，靜態預算效果最好。
基於令牌的預算
這裏，請求的成本是其令牌數，量子是每輪的令牌預算。現在公平性以實際完成的工作來衡量。這是批量端點（如嵌入和排序器）的自然選擇，其中批次的令牌總和（而不是項目數量）驅動GPU成本。發送幾個非常大的文檔的租户會很快用完預算並更快地讓出位置；發送許多小請求的租户每個請求收費很少，更頻繁地出現。這樣，沒有租户能通過提交少量超大型請求來獨佔GPU。
每個模型對你的請求意味着什麼
| 特性 | 基於請求 | 基於令牌 | |------|----------|----------| | 每個請求的成本 | 始終為1，無論大小 | 與其令牌數成比例 | | 量子（每輪預算） | 請求數量 | 令牌配額 | | 大請求 | 與小請求計數相同 | 收費更高，消耗租户更多份額 | | 小請求的租户 | 獲得與其他租户相同的輪次數 | 獲得更多輪次（每個請求便宜） | | 最適合 | 生成/流式端點 | 嵌入/排序器（批量）端點 | | 公平性衡量 | 服務的請求 | 完成的工作（令牌） |
因此，在基於請求的預算下，你的請求最多等待每個競爭租户固定數量的請求，無論這些請求有多大。這個計數可能是可預測的，但鄰居的大請求在每個輪次中仍可能耗費你的GPU時間。
在基於令牌的預算下，大請求“更重”：它更快地消耗其租户的預算，因此該租户更快地讓出位置，小請求可以高效地通過。這種模型更忠實地反映了工作的真實成本，並且是對單個租户重流量造成的瓶頸的更強保證。
量子的大小也適應端點的批處理策略：流式端點大約每個租户旋轉一個請求以實現緊密交錯，而批量端點則授予接近完整批次的預算。因此，一個租户可以在調度器繼續之前貢獻有意義的部分——在不犧牲公平性下保持批處理效率。
- 優先級（選擇器三）
如果公平性是關於決定哪個租户先走，那麼優先級選擇器決定該租户的哪個請求先走。
一旦赤字輪詢選擇了某個租户的輪次，調度器就從該租户的隊列中取出一個請求——但不是盲目的。每個隊列都是按以下順序排列的系統化隊列：
- 優先級：顯式更高優先級的請求先被服務。
- 截止日期：在相同優先級中，截止日期最早的請求獲勝，因此時間敏感的工作不會過期。
- 到達時間：作為最終決勝條件，較早的請求先走，提供穩定的先進先出行為。
將這種排序保持在每個租户內部，而不是在全局隊列中，是讓公平性和緊迫性在平台上共存的關鍵。租户不會因為共享平台而失去其優先級和截止日期保證；它只是將這些保證應用於其自己的公平容量份額。
整合在一起
這四個階段組合成一個清晰的請求生命週期。速率限制器控制入口准入；層級、公平性和每個租户的緊迫性控制出口選擇，每個批次組裝時。
單獨來看，這些機制——速率限制、層級、輪詢調度和優先級隊列——對於MLOps和平台工程師來説都很熟悉。它們的新穎價值在於它們如何集成：
- 速率限制保護系統免受過載，並強制每個租户的配額。
- 層級履行商業承諾。
- 赤字輪詢保證在同等層級的准入流量中，每個租户獲得公平、抗突發的份額。
- 優先級在每個租户的公平份額內保持其自己的緊迫性和截止日期排序。
步驟2-4重複，直到批次滿，然後批次被髮送到GPU。結果是一個平台，你的體驗取決於你的層級和你的公平容量份額——而不是取決於你的鄰居那天有多吵。
今天享受更公平、無摩擦的推理
服務公平性現已面向所有通過Cohere SaaS API和第三方市場部署（包括AWS）使用任何Cohere模型的客户啓用。
我們以客户需求為中心開發了這一功能。如果您正在使用Cohere模型，並有反饋、觀察到的性能問題或改進建議，請通過我們的Discord聯繫我們的工程團隊。