GitHub Repo
SGLang 0.5.22、遅延 KV キャッシュ割り当てオプションを追加し、特定の長短プロンプト混在ワークロードを改善
SGLang は 10 月 19 日に 0.5.22 をリリースしました。分離デプロイ構成の decode ノードで、prefill の完了後にリクエスト用の 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 容量を意図的に制限していました。長短プロンプトの混在ワークロードでは、2 回のテストで平均システム出力スループットが 26.81% 増加し、p95 の初回トークン待ち時間が 48.87% 短縮しました。一方、p99 のトークン間レイテンシは 92.77% 増加しました。別の Qwen3-8B との比較では、明確な効果は確認されませんでした。これらの数値は後続の rebase より前のものであり、最終リリース版を独立に検証した結果ではありません。テスト条件と結果
有効にするには、両端で --disaggregation-decode-allocation-policy prefill_complete を設定します。初期版では Mooncake transport と Python bootstrap registry が必要で、attention TP、CP、pipeline の各サイズは 1 でなければなりません。decode radix cache や HiSparse などとの組み合わせは、引き続きサポートされていません。ドキュメントでは、すべての worker をデフォルトの early ポリシーでアップグレードしてから、全体で一斉に切り替えるよう求めています。デプロイ時の制約
運用上は、容量利用率とストリーミングの安定性のトレードオフに注目してください。割り当てを遅らせると、ソース側で KV をより長く保持することになり、分割 prefill と転送を重ねて実行する機会も失われます。長文コンテキスト検索やエージェントサービスで有効にするか判断するには、実際のプロンプト長の分布を使い、スループット、初回トークン待ち時間、トークン間レイテンシを併せて比較する必要があります。