Mooncake は KV Cache を転送資源として扱うLLMサービング基盤
Mooncake は、Moonshot AI が提供する主要な LLM サービスである Kim のサービス プラットフォームです。
ひと目でわかる
- これは何？
- Prefill と Decode の分離を軸に、GPU間・ノード間のKV Cache転送と共有を組み立てる kvcache-ai の基盤を読む。
- 誰に向いている？
- LLM推論でPrefillとDecodeを分け、KV Cacheの転送をボトルネックとして設計したい基盤チームに向きます。README の性能値は実ワークロードに基づく説明ですが、利用環境で同じ結果が出る保証ではありません。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に C++ です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
中心にあるのはKV Cacheの分離
Mooncake は KVCache-centric Disaggregated Architecture for LLM Serving として公開されています。LLM のリクエスト処理を計算だけで見るのではなく、再利用できる KV Cache を保存・転送する資源として切り出す点が中心です。README は Kimi の serving platform であり、実ワークロードで SLO を守りながら75%多くのリクエストを処理できると述べていますが、これはプロジェクト側の説明です。一般のGPU構成へそのまま外挿できません。
Transfer Engineは複数ランタイムの接続点
公開されている構成には Mooncake Transfer Engine と Mooncake Store があり、GPUやホストをまたぐデータ移送を担います。素材には vLLM v1 の MooncakeConnector、TensorRT-LLM の cache_transmission/mooncake_utils、SGLang の HiCache や EPD disaggregation との統合が記載されています。接続先の API はランタイムの版で変わるため、Mooncake 単体の版だけ固定しても構成は再現できません。各統合先の公式ドキュメントで設定名と対応版を照合します。
RDMAと異種ハードウェアの前提を確認する
更新履歴には、RDMA engine による大きなマルチモーダル埋め込みの zero-copy transfer、GPU・NPU・ROCm・MUSA・EFA向けの transfer-engine パッケージが示されています。PyPI には mooncake-transfer-engine、cuda13、non-cuda、npu、musa、efa、rocm の派生パッケージがあります。これは全環境を同じ手順で動かせるという意味ではありません。NIC、ドライバ、CUDA ABI、RDMA権限、パッケージのビルド対象をインベントリ化してから導入します。
Storeは階層化キャッシュの設計に関わる
Mooncake Store は vLLM Ascend の分散KV cache pool backend、SGLang の hierarchical KV caching storage backend として更新履歴に登場します。デバイス、ホスト、リモートの各層で KV を再利用する構成を検討できます。FlexKV との distributed KVCache reuse、グローバルなマルチモーダル embedding cache への統合も案内されています。キャッシュ命中率、追い出し、障害時の再生成について README が一律の既定値を示しているわけではないため、アプリケーションの長いプロンプトと短いプロンプトを分けて観測します。
評価資料は性能主張と切り分ける
README には USENIX FAST25 の論文とスライド、FAST25-release/traces、公式ドキュメント、ブログ、Slack へのリンクがあります。まず論文の測定環境、モデル、リクエスト分布、SLO定義を読み、自社の測定と同じ単位に揃えるべきです。75%という数値だけをベンチマーク結果として転載するのは危険です。更新履歴は2026年8月の Miles 統合まで記録されており、開発の動きを見る材料になります。
採用時は依存関係とライセンスを記録する
Mooncake の配布物には Docker Hub イメージと複数の PyPI パッケージがあります。コンテナを使うかソースからビルドするかで、CUDAや通信ライブラリの再現条件が変わります。公式ドキュメントと GitHub の main の説明だけで本番設計を確定せず、利用する release、転送エンジンのパッケージ、ランタイム側の connector を同じ記録に残します。素材のライセンスは Apache-2.0 です。評価環境では、まず利用するtransfer-engineパッケージの派生版、CUDAまたはNPUの版、NICとRDMAの接続状態を固定します。PrefillノードとDecodeノードを分け、同一プロンプトの再利用あり・なしでKV転送時間、GPU使用率、ネットワーク帯域、生成開始までの待ち時間を採取します。Mooncake Storeを使う場合はdevice、host、remoteの各層で命中と追い出しを区別し、再起動後にキャッシュを再生成できるかを確認します。vLLM、SGLang、TensorRT-LLMのconnector設定をそれぞれ別ファイルとして保存し、ランタイム更新による失敗を切り分けます。FAST25のtraceは自社のリクエスト分布と同じ条件に変換して比較し、Kimiでの75%というREADMEの自報値を自社SLOの保証として使いません。Apache-2.0、Dockerイメージ、PyPI配布物、依存する通信ライブラリのライセンスも棚卸しします。Mooncakeの検証では、KV Cacheを保存する層と転送する経路を混ぜて測らないことが大切です。PrefillとDecodeを同じノードで処理した場合、分離した場合、キャッシュを再利用した場合を別シナリオにします。Transfer Engineの転送開始、受信完了、最初のトークン、全生成完了を記録し、RDMAの帯域とCPU処理を区別します。GPU、NPU、ROCm、MUSA、EFA用パッケージは名前が似ていても依存するドライバや通信経路が違うため、環境ごとにインストールログを保存します。Mooncake Storeのdevice、host、remoteの各層では、命中率だけでなく、追い出し後の再計算時間と障害時の再構築を測ります。vLLM v1、SGLang、TensorRT-LLMの接続設定を同じものとして扱わず、接続先のreleaseとcommitを固定します。FAST25の論文とtraceは測定条件を読んでから比較し、Kimiでの結果を一般的な保証に変換しません。Apache-2.0とPyPI、Docker、依存ライブラリの条件を確認し、運用開始後の性能劣化を検知できる指標を決めます。実施記録には対象版と入力条件を残し、成功した結果だけでなく失敗した場合の出力も保存します。設定を変更した前後で同じ確認を繰り返せるようにし、READMEに書かれた機能と自分の環境で確認できた事実を分けます。採用判断では、導入できたかだけでなく、更新、障害、切り戻し、権限、ライセンスを同じ担当者が追跡できるかを確かめます。
編集部の結論
LLM推論でPrefillとDecodeを分け、KV Cacheの転送をボトルネックとして設計したい基盤チームに向きます。README の性能値は実ワークロードに基づく説明ですが、利用環境で同じ結果が出る保証ではありません。採用前に対象GPU、RDMAやネットワーク、vLLMまたはSGLangの接続方式を揃え、Transfer Engine のサンプルと FAST25 の trace で転送量、待ち時間、SLO違反を測定してください。
コミュニティノート