LLM を本番運用していると、RAG やマルチターン会話のワークロードで「最初のトークンが返ってくるまでが遅い」「GPU コストが想定より膨らむ」という壁にぶつかります。原因の多くは、同じプロンプトの前半部分を毎回ゼロから計算し直す「プレフィル計算」の重複にあります。
vLLM には標準で prefix caching（プレフィックスキャッシュ）が備わっていますが、キャッシュは GPU メモリ内に限られるため容量が小さく、ヒット率が思うように伸びないという声は少なくありません。「外部にキャッシュを逃がして再利用できないか」「そのための OSS はどれを選べばいいのか」と調べ始めた方も多いはずです。
その有力な選択肢が、本記事で取り上げる LMCache です。LMCache は LLM 推論の KV キャッシュを GPU から CPU・ディスク・リモートストレージへ階層的にオフロードし、再利用可能にするキャッシュ管理レイヤーの OSS です。
本記事では、初めて LMCache を検討するエンジニアが「自分の推論基盤に採用すべきか」を判断できるよう、KV キャッシュの課題、LMCache の仕組み、vLLM との連携手順、Mooncake や vLLM 標準 prefix caching との違い、そして本番採用状況とメンテナンスの健全性までを解説します。なお本記事は公式 README・公式ドキュメント・公式サイト・関連論文をもとにしたドキュメントベースの解説であり、筆者による動作検証は行っていません。コマンドや数値はすべて出典を併記します。
LMCacheとは｜LLM推論のKVキャッシュを再利用するOSS
LMCache は、LLM 推論における KV キャッシュ管理レイヤー を提供するオープンソースソフトウェアです。リポジトリの説明文では「LMCache: Supercharge Your LLM with the Fastest KV Cache Layer（最速の KV キャッシュレイヤーで LLM を強化する）」と表現されています（LMCache/LMCache（GitHub））。
特定の推論エンジンに固定されないベンダー中立な設計が特徴で、KV キャッシュを「リクエストごとに使い捨てる一時的な状態」から「複数のリクエストやエンジンで使い回せる再利用可能な資産」へと位置づけ直します。これにより、同じプロンプト前半の再計算を減らし、TTFT の短縮とスループットの向上を狙います。
記事執筆時点（2026年6月）のリポジトリ基本情報は以下のとおりです（出典: LMCache/LMCache（GitHub）、gh api /repos/LMCache/LMCache 取得値）。
項目 | 値 |
|---|---|
リポジトリ | LMCache/LMCache |
主要言語 | Python |
ライセンス | Apache-2.0 |
スター数 | 9,358 |
フォーク数 | 1,349 |
オープン Issue 数 | 308 |
最終更新 | 2026年6月19日（調査当日に更新あり） |
トピック | amd, cuda, fast, inference, kv-cache, llm, pytorch, rocm, speed, vllm |
このリポジトリはアーカイブされておらず（archived=false）、他リポジトリからのフォークでもありません（fork=false）。本家として独立して開発が続いている現役のプロジェクトです。ライセンスは商用利用にも比較的扱いやすい Apache-2.0 が設定されています。
LMCache は単独で完結するアプリケーションというより、vLLM などの推論エンジンに組み込んで使うコンポーネントです。次の章では、なぜこうしたキャッシュレイヤーが必要になるのか、その前提となる KV キャッシュとプレフィル計算の話から整理します。
KVキャッシュとTTFTの課題｜なぜプレフィル計算が無駄になるのか
LMCache が解決する課題を理解するには、まず LLM 推論で何が起きているかを押さえる必要があります。
KVキャッシュとプレフィル計算の基礎
Transformer ベースの LLM は、入力されたプロンプトを処理する「プレフィル（prefill）」と、その後トークンを 1 つずつ生成する「デコード（decode）」の 2 段階で動きます。プレフィルでは、入力トークン全体に対して Attention の計算を行い、その中間結果である Key と Value のテンソルを保持します。これが KV キャッシュ です。
KV キャッシュをデコード段階で再利用することで、すでに処理したトークンを毎回計算し直さずに済みます。問題は、リクエストをまたいだ再利用です。たとえば次のようなワークロードでは、プロンプトの前半が何度も繰り返されます。
- RAG（検索拡張生成）: 検索でヒットした同じドキュメントを、複数のクエリで繰り返しコンテキストに入れる
- マルチターン会話: 会話が進むたびに、それまでの履歴全体を毎回プロンプト先頭に積み直す
- 長文処理: 同じ長大なシステムプロンプトや文書を、複数リクエストで共有する
これらでは、同じ前半部分のプレフィル計算が毎回発生します。プロンプトが長いほどこのプレフィルが重く、最初のトークンが返るまでの時間、すなわち TTFT（Time To First Token） が伸びます。
TTFT・スループットへの影響と標準prefix cachingの限界
vLLM には、この無駄を減らすための automatic prefix caching が標準搭載されています。同じプレフィックス（プロンプト先頭の一致部分）の KV キャッシュを GPU メモリ上に残し、次のリクエストで再利用する仕組みです。
ただし標準機能には次の限界があります。
- GPU メモリ内に限定される: キャッシュの保存先が高価で容量の小さい GPU メモリに限られるため、保持できるキャッシュ量が少なく、ヒット率が頭打ちになりやすい
- プレフィックス完全一致が前提: 先頭から連続して一致する部分しか再利用できず、文書の途中に共通チャンクがあっても活用できない
- 永続化されない: エンジンを再起動するとキャッシュは消え、複数の推論インスタンス間でも共有できない
つまり「キャッシュをもっと大きく、もっと柔軟に、もっと長く持ちたい」というニーズに、GPU メモリ内完結の標準機能だけでは応えきれません。ここを補うのが LMCache の役割です。
LMCacheの仕組み｜階層オフロードと非プレフィックス再利用
LMCache は、前章で挙げた標準 prefix caching の限界を、いくつかのコア機能で埋めます。仕組みを順に見ていきましょう（機能の出典: LMCache 公式サイト、LMCache 公式ドキュメント、LMCache/LMCache（GitHub））。
エンジン非依存デーモンと階層オフロード
LMCache は推論エンジンから独立したデーモンプロセスとして動作させることができます。エンジン本体とキャッシュ層のライフサイクルを分離することで、エンジンがクラッシュしてもキャッシュが道連れに消えてしまう「運命共有（fate-sharing）」を避けられます。
その上で LMCache は、KV キャッシュを以下のようなストレージ階層へオフロード・永続化します。
- GPU メモリ
- CPU の DRAM
- ローカルディスク（SSD）
- リモートストレージ
GPU メモリに収まらないキャッシュを下位の階層へ逃がすことで、GPU メモリ内完結よりはるかに多くのキャッシュを保持でき、結果としてキャッシュヒット率を引き上げます。エンジンを再起動してもディスクやリモートに残ったキャッシュを再利用でき、複数の推論インスタンスでキャッシュを共有することも可能になります。
CacheBlendによる非プレフィックス再利用とPDディスアグリゲーション
LMCache の固有機能として特に重要なのが CacheBlend です。標準の prefix caching がプレフィックス完全一致しか使えないのに対し、CacheBlend は任意の位置にあるキャッシュブロックを選択的に再計算しながら再利用します。これにより、文書の途中に登場する共通チャンク（プレフィックスではない部分）も使い回せます。RAG で複数の文書チャンクを組み合わせて投入するようなケースで、再計算を大幅に減らせるのが狙いです。
もう一つが PD（Prefill-Decode）ディスアグリゲーション への対応です。プレフィルを担うワーカーとデコードを担うワーカーを分離する構成で、両者の間で KV キャッシュを NVLink・RDMA・TCP 経由で転送します。プレフィルとデコードを別々のリソースで最適化する近年のサービング設計に組み込めるようになっています。
プラガブルなストレージバックエンドと可観測性
LMCache はストレージバックエンドをプラガブルに選べます。公式ドキュメントで挙げられている対応先には、CPU RAM、ローカルディスク（SSD）、Redis/Valkey、Mooncake、InfiniStore、S3 互換オブジェクトストレージ、NIXL、GDS などがあります（LMCache 公式ドキュメント）。自社のインフラ事情に合わせてキャッシュの保存先を選択できるわけです。
加えて、本番運用を意識した可観測性も備えています。リクエスト単位・トークン単位のメトリクス、ヘルスモニタリング、使用量トラッキングといった運用に必要な計測手段が用意されています。KV キャッシュの変換層（SERDE インターフェース）もプラガブルで、圧縮やトークンドロップ、カスタムシリアライズを差し込めます。
ここまでが LMCache の機能面の全体像です。次に、実際に vLLM と組み合わせる際の導入手順を、公式ドキュメントの記述に沿って確認します。
vLLMと連携する手順｜LMCacheの導入クイックスタート
ここでは公式ドキュメントのクイックスタートに記載されたコマンドを引用します。以下のコマンドはすべて公式ドキュメントからの抜粋であり、筆者環境での動作確認は行っていません。実行時は必ず最新の公式ドキュメントを参照してください。
最も手軽なインストールは pip です。
pip install lmcache
vLLM と連携させるクイックスタートでは、uv を使って vLLM と LMCache を同じ仮想環境に導入します。
uv venv --python 3.12
source .venv/bin/activate
uv pip install lmcache vllm
公式ドキュメントが推奨する MP（マルチプロセス）モードでは、まず LMCache サーバーを起動します。
lmcache server \
--l1-size-gb 20 --eviction-policy LRU --chunk-size 16
なお公式ドキュメントは、--chunk-size 16 はデモ用の説明値であり、本番ではデフォルトの 256 を使うよう注記しています。
別のターミナルで、LMCache の MP コネクタを指定して vLLM を起動します。
vllm serve Qwen/Qwen3-8B \
--port 8000 --kv-transfer-config \
'{"kv_connector":"LMCacheMPConnector", "kv_role":"kv_both"}'
サーバーを分けずにエンジンプロセス内で動かす In-Process モードも用意されています。環境変数で chunk size を指定する例は次のとおりです。
LMCACHE_CHUNK_SIZE=8 vllm serve Qwen/Qwen3-8B \
--port 8000 --kv-transfer-config \
'{"kv_connector":"LMCacheConnectorV1", "kv_role":"kv_both"}'
より簡易な In-Process 構成として、vLLM のオフロードバックエンドに LMCache を指定する書き方もあります。この場合 --disable-hybrid-kv-cache-manager の指定が必須です。
vllm serve <MODEL NAME> \
--kv-offloading-backend lmcache \
--kv-offloading-size <SIZE IN GB> \
--disable-hybrid-kv-cache-manager
導入のハードル自体は、すでに vLLM を運用している環境であれば「コネクタ設定の追加」と「キャッシュ保存先の指定」が中心で、極端に高いわけではありません。一方で、どのモードを選ぶか、どのストレージバックエンドを使うか、chunk size をどう設定するかといった本番向けのチューニングは、自基盤の特性に合わせた検証が前提になります。PoC で効果を測りながら詰めていくのが現実的です。
類似OSSとの違い｜Mooncake・vLLM標準prefix cachingとの比較
採用判断で最も悩ましいのが「他の選択肢とどう違うか」です。ここでは代表的な比較対象である Mooncake と vLLM 標準 prefix caching を取り上げます。
Mooncakeとの違いと協業関係
Mooncake（kvcache-ai/Mooncake）は、KVCache を中心に据えたディスアグリゲーテッドアーキテクチャです。プレフィルとデコードを分離し、グローバルスケジューラ（Conductor）を介して KVCache を転送する、分散ストレージと転送基盤・スケジューリングを含む「アーキテクチャ全体」の性格を持ちます（出典: Mooncake 論文（arXiv:2407.00079）、Mooncake 公式ドキュメント）。
これに対し LMCache は「エンジン非依存の KV キャッシュ管理レイヤー」です。両者はカバーする範囲が異なるため、正面から競合する関係ではありません。実際、Mooncake は KVCache の管理レイヤーとして LMCache を採用しており、2025年5月には両プロジェクトの連携が発表されています（出典: LMCache × Mooncake 連携発表（公式ブログ））。
役割を整理すると、Mooncake が「KVCache のストア・転送基盤・スケジューリング」を担い、LMCache が「キャッシュ制御・階層オフロード・CacheBlend による柔軟な再利用・可観測性」を担う、補完的な分担になります。「Mooncake か LMCache か」ではなく「Mooncake の中で LMCache を使う」という組み合わせが成立する点が重要です。
vLLM標準prefix cachingとの違い
vLLM 本体に組み込まれた automatic prefix caching との違いは、これまでの章で触れた内容に集約されます。整理すると以下のとおりです。
観点 | vLLM 標準 prefix caching | LMCache |
|---|---|---|
キャッシュ保存先 | GPU メモリ内に限定 | GPU → CPU → ディスク → リモートへ階層オフロード |
再利用範囲 | プレフィックス完全一致のみ | CacheBlend で非プレフィックス（中間チャンク）も再利用 |
永続化 | エンジン再起動で消失 | ディスク・リモートへ永続化可能 |
複数インスタンス間共有 | 不可 | 可能（共有ストレージ経由） |
本番可観測性 | 限定的 | リクエスト/トークン単位メトリクス・ヘルスモニタリング |
導入の手軽さ | 設定不要・標準有効化 | コネクタ・バックエンド設定が必要 |
小規模で短いプロンプトが中心、かつ GPU メモリに余裕があるワークロードなら、標準 prefix caching だけで十分なこともあります。一方、長コンテキストや RAG・マルチターンで「GPU メモリに乗り切らないキャッシュを使い回したい」「キャッシュを永続化・共有したい」という要件が出てきたときに、LMCache の追加価値が効いてきます。
なお、vLLM Production Stack（vllm-project/production-stack）のような Kubernetes 向けデプロイスタックは、LMCache を構成要素として内包する上位レイヤーです。これは比較対象というより、LMCache の採用事例として捉えるのが適切です。
性能と本番採用状況｜TTFT削減効果とエコシステム
最後に、定量的な効果とプロジェクトの健全性を確認します。採用可否の最終判断材料となる部分です。
TTFT削減・スループット向上のベンチマーク
LMCache の論文「LMCache: An Efficient KV Cache Layer for Enterprise-Scale LLM Inference」（arXiv:2510.09665）では、長コンテキストワークロードにおいて baseline の vLLM 比で TTFT を 1.9〜8.1 倍削減、スループットを 2.3〜14 倍向上させたと報告されています。また本番相当の RAG・マルチターン会話シナリオで約 50% のキャッシュヒット率が得られたとされています（出典: LMCache 論文（arXiv:2510.09665））。
一方、公式サイトでは「最大 8 倍高速・8 倍低コスト」「プロンプトキャッシングで応答 8〜10 倍高速」「RAG クエリで 4〜10 倍高速」と謳われています（出典: LMCache 公式サイト）。こちらは製品サイトのマーケティング表現であり、論文の計測レンジ（TTFT 1.9〜8.1 倍）とは性質が異なります。実際の効果はワークロードのキャッシュヒット率に大きく依存するため、数値は「ヒット率が高い条件での上限値」として読み、自基盤での PoC で確かめるのが安全です。
本番採用エコシステムとメンテナンス状況
LMCache は複数のメジャーなプロジェクトに採用されており、エコシステムの広がりがうかがえます。
- vLLM Production Stack: 2025年1月にリリースされた vLLM の Kubernetes 向けリファレンス実装で、KV キャッシュオフロードに LMCache を採用（出典: vLLM Production Stack 紹介（公式ブログ））
- NVIDIA Dynamo: LMCache をドロップイン置換として採用し、prefill/decode の完全ディスアグリゲーションを実現（出典: NVIDIA Dynamo ドキュメント）
- KServe: 0.15 リリースで LMCache サポートを追加し、長コンテキスト LLM ワークロードのスループット・レイテンシを改善（出典: KServe ドキュメント）
- Mooncake: KVCache 管理レイヤーとして LMCache を採用（前章参照）
メンテナンス状況も健全です。前掲のとおりスター数は 9,358、最終更新は調査当日（2026年6月19日）で、アクティブに開発が続いています。プロジェクトは PyTorch Foundation のエコシステムに参加しており、ハードウェア面でも NVIDIA・AMD MI300X・Arm・Ascend への対応が進んでいます。ライセンスは Apache-2.0 で、商用利用を含めて扱いやすい条件です。アーカイブ・フォークのいずれにも該当しない本家リポジトリである点も、長期的な採用を考える上で安心材料になります。
まとめ｜LMCacheの採用が向くケース
LMCache は、vLLM などの LLM 推論基盤に組み込み、KV キャッシュを GPU の外まで階層的にオフロード・再利用することで TTFT とコストを削減するキャッシュ管理レイヤーです。最後に、採用が向くケースと向かないケースを整理します。
LMCache の採用が向くケース
- RAG・マルチターン会話・長文処理など、同じプロンプト前半が繰り返されるワークロードが中心
- vLLM 標準の prefix caching では GPU メモリ容量が足りず、ヒット率が頭打ちになっている
- キャッシュを永続化したい、または複数の推論インスタンス間で共有したい
- prefill/decode 分離など、本番規模のサービング構成を組んでいる、または検討している
効果が限定的なケース
- 小規模・短プロンプト中心で、そもそもプレフィル計算の重複が少ない
- GPU メモリに十分な余裕があり、標準 prefix caching でヒット率が足りている
採用を検討する次のステップとしては、まず自社の代表的なワークロードでキャッシュヒット率を見積もり、LMCache 公式ドキュメント クイックスタートに沿って小規模な PoC を組むのが現実的です。Mooncake や vLLM Production Stack といった上位レイヤーと組み合わせる構成も視野に入れつつ、自基盤の要件に照らして判断してください。本記事はドキュメントベースの解説のため、最終的な数値や設定は必ず公式の最新情報で確認することをおすすめします。
