共享 AI 算力時，誰的請求可以等待？

2026年10月20日，llm-d 發布1.0版本，強調多租戶營運。同日，Red Hat 介紹了 Red Hat AI 3.5的優先級感知服務。這些消息帶出一個超越基礎設施的問題：多個產品共用推理算力時，誰的工作可以等待，平台又向其他人承諾了什麼？

以下是針對這個產品設計問題的獨立分析，並非對專案效能宣傳的獨立驗證，也不是部署指南。共享資源需要分配稀缺的時間。佇列可以執行分配，但標籤代表什麼，仍須由營運服務的組織決定。

等待造成的損失並不相同

設想一家企業同時執行三類任務：協助員工準備即將開始的會議的助理、為明天的搜尋更新文件索引的作業，以及在背景產生可選建議的智慧代理。這是說明機制的假設案例，不是已報導的客戶部署。它說明，把工作簡單分成「互動式」和「批次處理」，仍留下一個關鍵問題。

會議助理只有在答案還能影響討論時才有價值。索引任務現在可以延後，但隨著明天的營業時間臨近，其重要性會上升。可選建議即使產生得很快，也可能完全可以放棄。速度要求、業務重要性，以及最晚仍有用的完成時間，是不同屬性。Google 的 SRE 過載處理資料也區分請求的重要程度與延遲要求。這是背景工程經驗，不證明某個推理產品已經實作截止時間策略。

我們建議從「延遲損失」著手：請求多等一段時間，什麼會變差，由誰承擔損失，結果何時不再有用？使用者已經離開頁面，助理就不該僅憑最初來自互動介面而繼續保有緊急身分。反過來，夜間任務也不該在承諾的交付窗口即將關閉時，仍永久處於最低順位。

接受請求，究竟意味著什麼

在這個假設裡，會議助理需要在三十秒內給出答案。這是示意性的產品要求，不是實測效能。如果大部分時間耗在排隊，臨近截止時才開始生成，系統可能得到一次技術上成功、卻錯過決策時點的回應。單純統計完成的請求數，會把這種失敗藏起來。

有用的服務約定應區分「已經收到」「接受執行」和「在仍然有用時完成」，並說明過期工作是否取消、部分輸出能否使用，以及呼叫端能否改選延後交付。這些含義應當先於優先級層級的數量確定。否則平台與應用程式可能對一次緩慢成功是否兌現承諾，得出相反判斷。

單靠優先順序無法解決這些問題。Red Hat 明確提示，持續的高優先級流量及已放行的長輸出會帶來限制。業務截止時間還包含推理佇列之外的時間：尋找文件、等待工具結果，以及把答案交還使用者。給模型呼叫貼上最高等級，並沒有替其他環節預留時間。可信的完成承諾需要端到端時間預算，也需要實際工作負載的證據。

誰有權宣布緊急

優先級還帶來誘因問題。如果申請更高等級沒有組織成本，每個團隊都有理由爭取最高級。標籤最終描述的可能是談判力度，而非延遲後果。排程器即使技術上完全正確，也可能忠實執行一套無助於業務的政策。

一種可行的治理方式，是讓服務負責人承擔分類責任，為例外保留理由，並複核長期占據緊急通道的流量。在假設企業裡，會議助理可以獲得有邊界的緊急額度，索引負責人則能在臨近交付期限時申請限時提升。這是本文提出的設計思路，不是對本次發布既有功能的描述。目的在於讓優先級成為有人負責授予、範圍有限的承諾。

智慧代理流程使邊界更重要。假設一次使用者請求衍生出幾個可選分支，若每個分支自動獲得同等緊急身分，一個互動就可能占用原本留給多個互動的份額。應用程式應說明哪些分支不可或缺、哪些可以取消，以及整個任務最多可以產生多少並行工作。只按單個請求衡量公平，會忽略父任務與後續分支之間的關係。

保留部分獨立算力也有合理性。隔離可以使範圍狹窄但重要的服務更容易判斷和管理，代價是降低共享池的調配彈性。選擇取決於正在出售、或被業務依賴的服務承諾。是否合併應圍繞承諾論證，而不宜把所有工作負載都合併視為當然目標。

測試承諾，也測試那些被要求等待的人

有意義的評估應重現假設企業的常規流量，再把需求高峰維持足夠長的時間，觀察被延後的工作。短暫突發可能證明緊急回答仍然迅速，卻掩蓋索引作業永遠追不上的問題。評估應關注各類工作是否在各自有效窗口內完成，而不只是整體回應時間有沒有下降。

還應區分有意延後與事實上被放棄。多少工作被接受後又取消？最老的待處理任務等了多久？可選智慧代理分支是否擠占獨立使用者的份額？錯過期限究竟發生在推理之前、之中，還是之後？這些是本文建議追問的營運問題，不是廠商已經公布的測試結果。

不確定性不會消失。未來請求的長度、需求高峰是否重合、部分答案是否仍有價值，都無法提前完全掌握。平台可以收窄承諾，明確持續爭用時如何處理，並給應用程式一條明確途徑，處理無法及時完成的工作。優先級感知服務的實際意義，在於讓分配規則可以設定；這種分配能否形成可信的服務，則取決於一項更難自動化的判斷：每個正在等待的使用者究竟有權期待什麼，以及這一期待有沒有經過檢驗。