Skip to content
AI-Daily-Builder

2026-06-07 — 回閲覧

vLLM 0.22 がマルチティア KV キャッシュのオフロードを追加：長コンテキストのローカル提供に向けて GPU から CPU、そしてディスクへ

vLLM 0.22.0（2026 年 5 月 29 日）は、キャッシュされたブロックを CPU DRAM の先からディスクへとカスケードする、マルチティア KV キャッシュのオフロードフレームワークを出荷し、Python ファイルシステム層と Mooncake ディスクバックエンドを備える。6 月 5 日のパッチでは、いくつかのモデルと AMD-CPU の修正が追加された。128K-token

出荷された内容

2026 年 5 月 29 日にタグ付けされた vLLM 0.22.0 は、ネイティブのマルチティア KV キャッシュのオフロードフレームワーク（PR #40020）を着地させた。これまで vLLM は key/value キャッシュを GPU メモリから CPU DRAM へ退避させ、また戻すことができたが、それが行き止まりだった。ホスト RAM がいっぱいになると、ブロックは追い出され、prefill は再計算しなければならなかった。新しいフレームワークは CPU DRAM を単一のプライマリ層として扱い、その後ろに 1 つ以上のセカンダリ層——ローカルファイルシステム、オブジェクトストレージ、key-value ストア、またはリモートノード——を置けるようにする。本リリースは、最初の具体的なバックエンドとして Python ファイルシステムのセカンダリ層（PR #41735）と Mooncake ディスクオフロード（PR #42689）を追加し、あわせて DeepSeek V4 サポート（PR #43142）も加えた。

2026 年 6 月 5 日のパッチ 0.22.1 はより小規模なフォローアップだ。JetBrains の Mellum v2 コード MoE を追加し、AMD Zen CPU 上で int8 と GPTQ の線形演算を zentorch kernels 経由でルーティングし、DeepSeek-V4 の CUTLASS 初期化の破損を修正する。単一筐体で長コンテキストを動かす人にとっての目玉機能は、0.22.0 にある。

ティアリングの仕組み

この設計（RFC #38260）は、スケジューラのプロセス内で動作する TieringManager と、各バックエンドが実装する SecondaryTierManager インターフェースを導入する。オーケストレーションのルールは「常にカスケード」だ。あるブロックが CPU DRAM 内で確認されると、マネージャーはそれを登録済みのすべてのセカンダリ層へ非同期に押し下げ、CPU テンソルへの zero-copy ビューを用いるため、スケジューラは I/O でブロックされることがない。あるリクエストが DRAM から老化して消えたブロックを必要とすると、マネージャーは新しい prefill をトリガーするのではなく、セカンダリ層からそれを上へと昇格させる。ブロックは正規の CPU レイアウト（TP rank 1 形式）で保存され、これこそが、ある tensor-parallel 度で書き込まれたキャッシュを別の度で再利用できるようにするものだ。

経済性は単純だ。GPU HBM は約 3.35 TB/s でデータを動かす。PCIe 4.0 の NVMe ドライブはおよそ 7 GB/s で、サブミリ秒のレイテンシを持つ。その差は残酷に見えるが、それは代替案と比べるまでの話だ。代替案は「HBM から読む」ことではなく「prefill 全体を再計算する」ことなのだ。プロンプトが長くなれば、ディスクから事前計算済みブロックをロードするほうが、再計算を楽々と上回る。

なぜローカルリグにとって重要なのか

2026 年の現実は、128K——さらには 1M-token のウィンドウですら通常のワークロードであり、カードを食い尽くすのは KV キャッシュだということだ。以下は、H100 クラスのカードで 70B モデルを 128K コンテキストで提供する独立したベンチマークから引いた、おおまかな単一筐体の見取り図である。

構成128K でのおおよその同時ユーザー数
GPU HBM のみ~1
FP8 KV + CPU swap + ディスクオフロード~8-10

同じ情報源は、prefill が再計算ではなくディスクからのキャッシュヒットとして提供される場合、128K のシステムプロンプトに対する time-to-first-token がおよそ 11 秒から約 1.5 秒へと下がると述べている。（これらの数字は、あるホスティングベンダーの 2026 年 4 月の記事によるもので、vLLM 自身の数値ではないため、その倍率は方向性を示すものとして扱うこと。）セルフホストの運用者にとっての実用的なアンロックは、固定のシステムプロンプトや長い検索済みドキュメントを、もはやリクエストごとに払う必要がなくなることだ——それは SSD 上に存在し、必要なときに昇格されて戻ってくる。

同じリリースは、そもそも GPU 上のフットプリントを小さくする量子化パスも引き締めた。batch-invariant Cutlass FP8 はエンドツーエンドで +28.9% を謳い（PR #40408）、padded NVFP4 量子化 kernel は +2.4 から 5.7% を加える（PR #42774）。より小さい KV ブロックに加えて、あふれた分を置く場所があること——この組み合わせこそが、単一のカードを引き伸ばすものだ。

実務者向けメモ

もしあなたが単一 GPU の筐体を使っていて、ボトルネックが純粋なトークンのスループットではなくコンテキスト長にあるなら、ここでのてこは、第 2 の GPU ではなく、高速なローカル NVMe に加えてファイルシステム層または Mooncake 層だ。キャッシュヒットの経路が実際に発火するよう、現実的な共有プレフィックス（システムプロンプトや固定の RAG ドキュメント）でベンチマークすること。冷えた、すべてがユニークなワークロードは、I/O コストだけを見せ、再計算の節約は何も見せてくれない。ディスク層を有効にする前に、妥当な CPU DRAM の予算を固定すること——プライマリ層は、依然としてすべてのブロックが通過するステージング領域だ。

あまり検討されていない観点：マルチティアのオフロードは、「ローカル」なデプロイの脅威と信頼性の面を静かに変える。KV ブロックは今やディスクに永続化される。つまり、あなたのプロンプトと検索済みコンテキストの内容が、リクエストの寿命を超えて SSD 上に存在するということだ——これは、キャッシュが GPU メモリとともに蒸発していたときには存在しなかった、プライバシーと保持に関する考慮事項である。そしてブロックは正規の TP-rank-1 レイアウトで保存されるため、今日構築したキャッシュは、tensor-parallel 度を変更したりサーバーを再起動したりした後でも再利用でき、KV ストアを、はかないスクラッチではなく、あなたが考え抜かねばならない永続的な状態（追い出しポリシー、ディスク圧、古いエントリ）へと変えてしまう。近い将来の興味深い問いは、永続的で再起動をまたぐ KV キャッシュが、ベクトルインデックスがすでにそうであるように、ソロのリグ上で管理対象の資産になるのかどうか、ということだ。

Sources

チップ