FluidPD：具備 SLO 感知能力的 LLM 預填與解碼分離彈性架構

解決 LLM 服務中的 SLO 違反問題

FluidPD 是由伊利諾伊大學厄巴納-香檳分校與 IBM 研究團隊共同開發的系統，要解決大型語言模型（LLM）服務中，預填（Prefill）與解碼（Decode）分離架構難以彈性調整的問題。現有系統通常採用固定的預填與解碼工作節點比例，並透過請求路由來分配負載。然而，真實世界的負載不只有短時間的請求波峰，還會出現持續性的需求比例變化。FluidPD 引入 SLO 感知的就地彈性機制，不需要額外的 GPU 資源，就能即時應對階段性的運算不平衡。

核心機制：FluidToken 與 FluidRole

FluidPD 提出兩種互補的機制，分別處理不同時間尺度的壓力。第一種是 FluidToken，用來處理瞬態不平衡。當解碼側有閒置容量時，FluidToken 會把預填計算中受限制的部分卸載到解碼工作節點。這是在請求層級做調整，不改變工作節點的角色，就能減少預填隊列的延遲。

第二種是 FluidRole，專門處理持續性的不平衡。當階段性壓力長期存在，FluidRole 會把正在運行的工作節點，就地在預填與解碼角色之間重新分配。這個過程不需要重新載入模型，也不用重啟引擎。這兩種機制都由輕量級的壓力指數引導，這些指數能在 SLO 違反發生前，先一步顯示預填與解碼側的資源壓力。

壓力感知指標與決策邏輯

FluidPD 依賴兩個預測性壓力信號來決定調整策略：預填壓力指數（PPI）與解碼壓力指數（DPI）。PPI 用來估算排隊中的預填請求能否滿足剩餘的首個 Token 延遲（TTFT）預算，藉此預測請求是否有違反 SLO 的風險。DPI 則反映解碼執行的壓力以及 KV 快取的可用空間，確保解碼側有足夠資源接收卸載的計算任務。

有些觀察指標要等延遲惡化後才會反映問題，PPI 和 DPI 不同，能在壓力浮現之前先發出預警。系統優先使用 FluidToken，因為它不必改變工作節點角色，就能緩解瞬態預填壓力。壓力持續存在時，才會啟用 FluidRole，這表示目前的預填與解碼配置已不適合負載需求。

效能評估與實證結果

研究團隊在生產環境的 Azure 追蹤資料上評估 FluidPD，涵蓋 Llama-3.1-8B、Qwen3-14B 與 Qwen3-30B-A3B 等模型。實驗結果顯示，FluidPD 的整體 SLO 達成率明顯優於靜態配置的 SGLang，提升幅度最高達 94.6 個百分點。這證明 SLO 感知的就地預填與解碼彈性，能在不增加工作節點的情況下，有效提升服務品質。

此外，FluidPD 的表現也超越 Dynamo 自動擴展機制。在使用較少 GPU 的情況下，FluidPD 的 SLO 達成率比 Dynamo 最多高出 88.3 個百分點。自動擴展機制雖然能增加總體容量，但檢測與執行的延遲較長，也需要閒置的 GPU，面對短時間波峰或階段性不平衡，反應較慢。FluidPD 則利用現有部署中的容量，不需要等待額外的工作節點。

技術實現與架構優勢

FluidPD 建立在標準的預填與解碼分離結構上，包含獨立的預填與解碼工作節點池，以及負責分配請求的路由器。FluidToken 透過非同步的 KV 傳輸路徑，把部分預填請求的後綴卸載到配對的解碼工作節點。這種做法在數學上等同於未分割的預填，但能利用解碼側的閒置容量加速處理。

FluidRole 則用狀態機管理工作節點的角色切換，包含活躍、排空與切換三個狀態。切換時，工作節點會排空進行中的工作，並保留模型權重與平行配置，因此不會造成服務中斷。有了這種就地角色切換機制，系統不必停止服務，就能動態調整預填與解碼的工作節點比例，配合持續變化的負載需求。