高效請求排隊以優化 LLM 效能

為多位使用者同時服務大型語言模型（LLM）具有挑戰性，因為請求會爭奪有限的 GPU 資源。為了維持一致的使用者體驗，組織必須實施精密的排隊與排程策略，防止單一高流量使用者壟斷推論引擎。

問題：高使用者造成的資源阻塞

在標準的推論引擎（例如 vLLM 或 HuggingFace TGI）中，請求通常由工作者、佇列與排程器處理。由於 GPU 計算在批次執行時效率更高，後端佇列允許排程器將多個請求合併成單一批次。

然而，當「高使用者」送出大量請求時，可能會填滿後端佇列。這會產生阻塞效應，使得其他使用者的後續請求必須等到所有高使用者的請求全部處理完畢，無論新請求的緊急程度或數量如何。

為了防止資源阻塞，TNG 實作了一個「LLM-Server」（API 伺服器），位於使用者與推論後端之間。LLM-Server 不直接將請求送至後端，而是為每個使用者與模型管理獨立的佇列。

LLM-Server 採用迴圈式排程器，而非先進先出（FIFO）方式。這確保不同使用者的請求都能獲得優先權，即使某位使用者的佇列中有多筆請求，單一請求的使用者仍能更快得到服務。

除了簡單的請求計數外，排程還可以根據多種指標進一步細緻化：

Processing Time：優先處理較短的請求以縮短整體等待時間，儘管預測產生長度相當困難。
Cache Optimization：依相似度排列請求，以最大化 KV‑cache 命中，這是 NVIDIA Dynamo 與 AIBrix 等框架使用的技巧。
Business Cost：依操作的財務成本決定優先順序。
Priority Tiers：為不同使用情境建立不同佇列。例如，互動式聊天介面需要高優先權以維持即時 UI；而批次 API 工作（如程式碼審查或基準測試）則可設定低優先權。

如果 LLM-Server 在公平排程後仍將所有優先請求立即送至後端，這些請求會在後端的 FIFO 佇列中堆積，重新產生阻塞問題，因而失去效用。

因部分後端（如 vLLM）不支援限制後端佇列的最大元素數，LLM-Server 必須動態調整轉發請求的速率。TNG 透過從 vLLM 的 /metrics 端點抓取 Prometheus 指標來實現此功能。

透過監控 backend queue length metric，LLM-Server 僅在佇列長度低於特定門檻（例如 3）時才轉發新請求。此舉在降低新使用者延遲的同時，兼顧低延遲與 GPU 利用率之間的平衡。

此回饋迴路允許根據即時效能進一步優化：

Token Speed Thresholds：若 time‑per‑output‑token metric 超過某個上限（例如 150 ms），伺服器可停止排程新請求，以維持最低產生速度（例如 >7 token/s）。
Priority‑Specific Thresholds：低優先權的批次請求僅在後端佇列完全為空時才排程，確保它們不會增加高優先權使用者的延遲。

近期的 vLLM 版本已加入基於優先權的排程，允許請求標記優先等級。高優先權請求可以「跳過」佇列，甚至直接進入已處理的批次，可能會將低優先權請求驅回等待佇列。

雖然後端側的優先排程簡化了部分邏輯，但仍需在上游保留 LLM-Server，原因包括：