LLM 推論為何會變慢？Stanford 合作者的輸出長度排程研究

大型語言模型（LLM）回覆變慢，不一定是模型「算得不夠快」。在多人同時使用的服務裡，系統還得決定哪些請求先進入 GPU、每個請求要預留多少記憶體，以及遇到回覆比預期長時如何調整。輸出長度未知，正是推論調度的一個核心難題。

這篇文章更新自一篇有 Stanford 研究者共同作者的論文〈Adaptively Robust LLM Inference Optimization under Prediction Uncertainty〉。先釐清常見標題中的「慢五倍」：它不應被解讀為所有模型、硬體或服務都固定慢五倍。原始論文研究的是排程演算法，在理論分析與數值模擬中比較不同策略，並非一份宣告通用產品加速倍數的實測報告。

LLM 推論為什麼很難排程？

一次生成式請求通常可粗分為兩段：

Prefill：模型讀取已知的輸入提示，建立後續生成需要的狀態。
Decode：模型一個 token 接一個 token 產生答案，直到停止條件出現。

提示長度在請求抵達時就知道，答案會長到哪裡卻未必能準確預測。這會影響每個請求持續占用的 KV cache、可同時處理的批次大小與整體等待時間。若系統先替每個請求預留過多空間，GPU 可能塞不進足夠多的工作；預留太少，又可能在生成途中碰到記憶體壓力、需要中斷或重新安排工作。

保守預留與自適應調整的取捨

論文假設系統能得到輸出長度的區間預測，例如某個請求可能落在一個下限與上限之間。作者先分析一個保守策略 A_max：一律按預測上限安排資源。好處是較不容易超過記憶體限制；代價是當預測區間很寬或上限常被高估時，系統會過早縮小併發量，讓等待中的請求變多。

接著，論文提出 A_min。它先以預測下限來安排，再在生成過程中根據實際已產生的 token 動態更新估計。概念上，這不是「假裝長回答不存在」，而是把不確定性留在可觀察、可修正的線上排程裡。論文證明其競爭比性質，並在數值模擬中觀察到它常能接近事後已知道真實輸出長度的排程器。

研究結果能告訴我們什麼，不能告訴我們什麼？

這項研究的價值在於：它把輸出長度預測誤差視為一級的營運問題，而不是只追求更準的預測器。當上限很難準確預測時，一個能在執行期間逐步修正的排程策略，可能比一開始就做最壞情況預留更有效率。

但它不能直接回答「換成 A_min 就能讓我的服務快幾倍」。實際延遲還會受到模型大小、提示與上下文長度、GPU 記憶體與頻寬、批次策略、KV cache 實作、流量分布、輸出長度上限、併發數與中斷成本影響。論文本身以理論與數值模擬為主，正式導入前仍應在自己的工作負載上驗證。

KV cache 為什麼常成為瓶頸？

自回歸生成會重複利用先前 token 的注意力鍵值狀態，這些狀態累積在 KV cache。多請求併發時，快取記憶體會隨序列長度成長；如果管理不佳，碎片與重複保存會壓縮批次空間。vLLM 的 PagedAttention 研究就是從記憶體分頁與共享角度處理這個問題，顯示「怎麼管理快取」與「怎麼安排請求」是互補而非互斥的改善方向。

Stanford MAST Lab 的 LIMINAL 研究也提醒，解碼效能同時受運算、記憶體容量、記憶體頻寬與集體通訊限制。換句話說，排程可以減少不必要的保守預留，但不能取代硬體容量規劃、模型選擇或推論引擎優化。