SGLang 0.5.22 新增延後配置 KV 快取選項，改善特定長短提示混合負載

SGLang 於 10 月 19 日發布 0.5.22，納入一項針對 prefill／decode 分離部署的記憶體排程選項：延後保留每筆請求在 decode 節點上的 KV 快取空間。新版也將 Python 最低需求提高至 3.11，升級前須檢查執行環境。正式發布說明

既有預設策略會在 prefill 尚未完成時，先替請求保留 decode 端空間。當長提示仍在計算，這些位置可能暫時無法供已準備生成的請求使用。新策略 prefill_complete 改為收到最終 prefill 結果就緒訊號後，才配置目的端位置並啟動傳輸握手；它調整的是保留時機，全域 KV 池大小不變。官方技術文件

合併提案提供的歷史測試使用 GLM-5.2-NVFP4、12 張 Rubin GPU，並刻意限制 decode KV 容量。在長短提示混合負載中，兩輪測試的平均系統輸出吞吐量增加 26.81%，p95 首 token 等待時間下降 48.87%；代價是 p99 token 間延遲增加 92.77%。另一組 Qwen3-8B 比較沒有明確收益。這些數據早於後續 rebase，也不是對最終發布版本的獨立驗證。測試設定與結果

啟用時須在兩端設定 --disaggregation-decode-allocation-policy prefill_complete。初版要求 Mooncake 傳輸與 Python bootstrap registry，attention TP、CP 及 pipeline 大小須為一；decode radix cache、HiSparse 等組合仍不支援。文件要求先讓所有 worker 在預設 early 策略下完成升級，再同步切換。部署限制

工程上的觀察重點是容量利用率與串流穩定性的交換：延後配置會讓來源端保留 KV 更久，也失去分塊 prefill 與傳輸重疊的機會。對長上下文檢索或代理服務，應以實際提示長度分布，同時比較吞吐量、首 token 等待與 token 間延遲，才能判斷是否值得啟用。