kvcached: KV キャッシュを物理メモリから切り離し、GPU を複数モデルで共有する
Virtualized Elastic KV Cache for Dynamic GPU Sharing and Beyond
ひと目でわかる
- これは何？
- kvcached は LLM 推論エンジンの KV キャッシュに OS 流の仮想メモリを持ち込み、論理アドレスと物理 GPU メモリの対応を実行時に決め直すライブラリだ。SGLang と vLLM に組み込む前提の設計で、単一モデルを専有させる使い方には向かない。
- 誰に向いている？
- 複数の LLM を 1 枚の GPU に載せたい、あるいはアイドル時にモデルを退避させたいチームには検討の価値がある。逆に単一モデルを常時フル稼働させる構成では、仮想メモリ層の分だけ複雑さが増えて見返りが薄い。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
解こうとしている問題は「KV キャッシュが GPU メモリを占有し続ける」こと
LLM 推論エンジンは通常、起動時に KV キャッシュ用の GPU メモリをまとめて確保する。確保した領域は負荷が下がっても他のプロセスには渡らない。結果として、1 枚の GPU に 2 つ目のモデルを載せようとすると、物理メモリを静的に分割するしかなく、片方が暇でももう片方はその余裕を使えない。kvcached の README はこの状態を「今日使われている硬直したメモリ分割」と表現し、複数 LLM が 1 枚の GPU メモリを弾力的に共有する用途を第一に挙げている。対象読者は、推論エンジンをすでに運用していて、モデルを増やしたいが GPU を増やしたくない人だ。学習用途にも触れられているが、README で具体的な手順が示されているのは serving 側である。
仮想アドレスを先に予約し、物理メモリは使った分だけ後から貼る
仕組みの中心は、KV キャッシュの GPU 仮想アドレスと物理メモリの割り当てを分離する点にある。README によれば、エンジンはまず仮想メモリだけを予約し、キャッシュが実際に使われた時点で物理 GPU メモリを対応づける。この対応は実行時に張り替えられるため、割り当てと回収を負荷に追随させられる。OS の仮想メモリと同じ発想を GPU 側に持ち込んだ形だ。ここで重要なのは、これがアプリケーションから見た KV キャッシュの論理構造を変えるものではないという点である。エンジンは従来どおり KV ブロックを扱い、その裏側の物理配置だけが遅延して決まる。だからこそ SGLang や vLLM といった既存エンジンに組み込む形を取れる。リポジトリの構成や README から確認できるのはここまでで、ページテーブルの実装やフォールト時のレイテンシについては、この資料だけでは判断できない。
メモリ上限は CLI で締める。モデルの退避は sleep mode
README が挙げる機能のうち、運用に直接効くのはメモリ制御 CLI とフロントエンドルータだ。CLI ではメモリ上限を強制できるとされている。ルータ側の役割は 2 つあり、リクエストを対象モデルへ振り分けることと、アイドル状態のモデルを sleep させることである。複数モデルを 1 枚に載せる構成では、この 2 つが揃っていないと弾力的な共有は成立しない。物理メモリを返しても、次のリクエストをどのモデルに流すかと、使われていないモデルをどう休ませるかが決まらなければ、結局は全モデルが常駐することになる。README の例示では、マルチ LLM serving、サーバーレス、複合 AI システムの 3 つが用途として並んでいる。いずれも「常駐させたくない」という動機が共通している。
導入はエンジン側の差し替えが前提で、対応バージョンの幅が実務上の制約になる
README の対応表では、SGLang は v0.4.9 以上（v0.5.15 までテスト済み）、vLLM は v0.8.4 以上（v0.24.0 までテスト済み）とされている。注意機構は MHA / GQA / MLA / sliding window / hybrid に対応し、例示モデルには DeepSeek-V3、Qwen3-8B、GPT-OSS-20B などが並ぶ。バージョン範囲が広いように見えるが、上振れのテスト済みラインは固定されている。エンジンは更新が速いので、手元のバージョンがこの範囲の外にあるなら、まずそこを揃えるのが先になる。モデルごとの結果と KV レイアウトは issue #425 にまとめられていると README は案内している。ML モデルやパイプライン並列への対応は 2026-03 の更新で追加された経緯があり、対応は一度に広がったのではなく段階的に足されてきた。
prefix caching はメモリ境界を自分で決める必要がある
2026-04 の更新で prefix caching が入った。vLLM 側は automatic prefix caching（APC）、SGLang 側は RadixCache に対応し、リクエストをまたいだプレフィックスの再利用ができる。ただし README は「設定可能なメモリ上限つき」と書いている。つまりプレフィックスをどれだけ保持するかは自動では決まらず、運用者が境界を決めることになる。ここは設計上のトレードオフが露出している箇所だ。上限を大きく取ればヒット率は上がるが、その分だけ弾力的に動かせる余地が減る。上限を小さくすれば共有の利得は戻ってくるが、再利用の効果は薄くなる。具体的な設定キーと例は examples/09_prefix_caching に置かれていると README は示しているので、値を決める前にそこを読む必要がある。この資料には個別のキー名までは記載がない。
向かない場面: 単一モデルを専有させる構成
kvcached の利得は、メモリを巡って競合する相手がいるかどうかで決まる。1 つのモデルを 1 枚の GPU で常時動かし、負荷も安定しているなら、KV キャッシュを遅延確保する意味はほとんどない。仮想メモリの対応づけという層が増える分だけ、障害点とデバッグ対象が増える。同様に、レイテンシが最優先で、メモリ確保のタイミングを完全に制御したいワークロードにも向かない。README は動的で混在したワークロードでの GPU メモリ利用率の改善を目的として掲げており、静的なワークロードはそもそも想定外だ。もう一点、対応エンジンのバージョン範囲外を使っている場合も、この資料の範囲では動作を保証できない。
代替手段との違いは「分割」か「多重化」か
現実的な比較対象は、vLLM や SGLang が備える KV キャッシュのメモリ設定（gpu_memory_utilization のような比率指定）と、MPS や MIG による GPU の静的分割だ。前者は 1 プロセス内の KV キャッシュ量を比率で抑えるもので、複数モデルが 1 枚を分け合う状況は扱わない。後者はハードウェア的に区画を切り、区画をまたいだメモリの融通はできない。kvcached はこのどちらでもなく、物理メモリの対応づけ自体を実行時に動かす。だから区画の境界をまたいで余ったメモリを回せる。ただしその代わり、エンジン側に手を入れる必要があり、対応バージョンの追従コストを負う。静的分割で足りているなら、そちらのほうが壊れにくい。
ライセンスと保守コスト
ライセンスは Apache-2.0 で、リポジトリの LICENSE に置かれている。特許許諾条項を含む一般的な許諾型ライセンスであり、改変物の配布時に何を残す必要があるかは条項の確認が要る。ここで法的な判断は示さない。保守の面では、リリースは v0.1.3（2026-01）、v0.1.4（2026-03）、v0.1.5（2026-04）と 2 か月前後の間隔で続いており、メジャー番号はまだ 0 のままだ。API が固まっていない段階と見るのが自然で、エンジン側の更新に追随する作業が定期的に発生すると考えるべきである。README の対応表がテスト済みバージョンの上限を明記しているのは、この追随コストを利用者に自覚させる意味でも機能している。
編集部の結論
複数の LLM を 1 枚の GPU に載せたい、あるいはアイドル時にモデルを退避させたいチームには検討の価値がある。逆に単一モデルを常時フル稼働させる構成では、仮想メモリ層の分だけ複雑さが増えて見返りが薄い。導入前に確認すべきは、自分のエンジンバージョンが README の表の範囲に入っているか、対象モデルの注意機構（MLA や sliding window、hybrid）がサポート表に載っているか、そして prefix caching を使うなら examples/09_prefix_caching の設定が自分のワークロードに合うかの 3 点だ。
コミュニティノート