公開動態與原創分析 · 消息日期: · 消息來源
10月20日，開源推理專案 llm-d 發布 1.0。它在 Kubernetes 環境中運作，為 vLLM、SGLang 等推理引擎提供分散式排程。這次版本的一個重點，是讓不同部門、不同緊急程度的請求共用模型服務時，不至於被一陣突發任務擠到佇列末端。
這項變化對應企業自建模型後的一個具體問題。假設營運人員一次提交了整批商品說明改寫，客服又正在等待一句回覆建議：兩類請求都呼叫同一個模型，卻有完全不同的等待代價。前者晚些完成可能仍趕得上排程，後者遲遲不傳回，就會拖住正在進行的對話。只看整台機器每秒生成多少文字，未必能發現後者的處境。
優先順序需要企業自己定義
llm-d 的發布說明介紹了按優先順序和租戶公平性進行流量控制的能力。同一優先等級內的多個租戶輪流獲得處理機會；壅塞時，請求可以先留在路由層等待，避免繼續送入已經繁忙的後端佇列。不過，預設行為仍接近先到先處理，企業需要主動設定相應策略。安裝新版本並不會自動知道哪一項業務更緊急。
因此，前面的客服請求和商品文案任務，應在進入推理服務前就帶上可以識別的業務類別。任務發起方可以提供類別，但不能人人都自行宣稱最高優先等級；否則，佇列很快又變回誰提交得多誰占得多。優先順序需要由業務負責人和維運人員共同確定，並與入口的身分識別對應起來。
這裡還有一個容易被「即時優先」掩蓋的問題：批次任務也有交付時間。如果客服流量全天不斷，商品文案一直沒有機會執行，營運排程仍會落空。合適的策略應為線上回應留出餘裕，也為批次工作保留可預期的進度；當總需求超過容量時，則要讓發起人知道任務正在排隊，或暫時無法受理。
吞吐量之外，要看到誰在排隊
檢查這種安排是否有效，可以在同一段繁忙時段分別觀察兩類任務：客服人員實際等了多久，批次文案在約定時間前完成了多少。平均回應時間可能掩蓋少數很慢的請求，記錄較慢請求的等待情況，才更接近使用者感受到的服務。還應區分佇列等待與模型生成時間，避免把排程壅塞誤判成模型能力不足。
對已經出現混合負載的團隊，llm-d 提供了更明確的排程手段。對呼叫量尚小、託管模型已經夠用的團隊，這則新聞並不構成立刻自建叢集的理由。先看清等待發生在什麼地方，再決定是否需要增加這一層設施，通常比先追求更高的總吞吐量更有幫助。
消息來源
墨客雲編輯部 · neo@mokyun.com
