Mooncake

从现有证据看，Mooncake 更适合判断为“值得基础设施团队重点跟踪并试点”的系统级项目，而不是已经被普通开发者广泛即插即用采用的推理框架。热度证明主要来自“它是 Kimi 的服务平台”这一官方仓库表述，以及多篇知乎解读和社区转发；但好用证明更多来自 vLLM、SGLang 集成文章、传输引擎拆解和 RDMA 实测，这些内容能支持它确实在分布式 KV Cache、长上下文和跨节点复用上有明确工程价值。它不是通用聊天应用、也不是单机推理 SDK，更准确的类比是“面向 LLM 服务端的 KV Cache 数据平面 + 解耦推理基础设施”。

实际作用上，证据集中指向两件事：一是把 KV Cache 当成独立核心资源，通过全局共享、远端拉取和传输引擎降低重复 prefill；二是在 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 集成，说明它更像需要 GPU 集群、高速网络和系统调优能力的工程方案，而不是买来就用的托管 API。关于带宽数据，如 87 GB/s、190 GB/s 等，来自社区实测/技术文章，只能说明在特定网络配置下 RDMA 可能显著优于 TCP，不能外推为默认效果。若团队没有长上下文高并发压力、没有跨节点 KV 复用需求，或缺少 RDMA/推理系统经验，接入和运维复杂度可能高于收益。

适合谁方面，最匹配的是做 LLM 推理平台、Agent 服务、长会话应用和大规模 GPU 调度的基础设施团队，尤其是已经在用 vLLM 或 SGLang 并遇到 TTFT、TBT、cache miss、PD 解耦瓶颈的人。不太适合个人开发者、只跑单机模型的人，或只想找“OpenAI 兼容推理接口”的团队。