Mooncake

現時点の証拠からみると、Mooncake は「基盤チームが本格的に追跡し、PoC すべきシステム寄りのプロジェクト」であり、一般開発者向けの即導入型推論フレームワークとは言いにくいです。注目度の証拠は、公式 GitHub にある Kimi のサービング基盤という説明や、複数の解説記事・転載投稿です。一方で、使い勝手や実力の証拠としては、vLLM や SGLang との統合記事、転送エンジンの分解解説、RDMA 実測のほうが重要です。これらは、分散 KV Cache 再利用や長文脈推論で実際の工学的価値があることをある程度支えています。これは汎用チャット製品でも単機推論 SDK でもなく、より近い比喩は「LLM バックエンド向けの KV Cache データプレーン＋解結合サービング基盤」です。

実際の役割は大きく 2 つです。1 つ目は KV Cache を独立した中核資源として扱い、グローバル共有、リモート取得、転送エンジンによって重複 prefill を減らすこと。2 つ目は Prefill/Decode 分離、ノードまたぎのルーティング、長い会話の再利用でもスループットやヒット率を維持することです。vLLM の記事では 95% 超のヒット率と 12 から 60 GPU へのほぼ線形な拡張が示され、SGLang/HiCache 統合記事では実運用シナリオで TTFT 84% 低下とされています。RDMA 解説は、その前提として高速なネットワークが重要だと示します。ただし、525% のスループット改善や 84% の TTFT 改善といった数字は、論文要約やコミュニティ記事、特定の統合条件に基づくものが多く、方向性の信頼材料にはなっても、どの環境でも再現される確約ではありません。

コストと導入ハードルについては、オープンソースのため公式価格情報は確認できません。ただし、導入コストが低いとは言えず、これはアーキテクチャ証拠に基づく保守的判断です。複数資料で RDMA、RoCE、GPUDirect RDMA、metadata server、分散 cache pool、vLLM/SGLang 統合が繰り返し出てくるため、これはマネージド API というより GPU クラスタ、高速ネットワーク、システムチューニングを前提にした方式です。87 GB/s や 190 GB/s のような帯域値はコミュニティ実測・技術記事由来であり、特定構成で RDMA が TCP より優れる可能性を示すにとどまります。長文脈の高同時実行負荷、ノード間 KV 再利用需要、RDMA や推論基盤の経験がないチームでは、統合運用の負担が効果を上回る可能性があります。