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聯絡我們的工程團隊。