Mingxin FX and Mooncake: Open-Source KV Transport Layer Meets Storage Hardware
Mooncake is an open-source KVCache-centric disaggregated inference architecture (transfer engine + store interface); it defines how KV moves but still needs high-performance storage hardware to land on. Mingxin FX is the domestic option for that layer.
What Mooncake solves
Mooncake, open-sourced by Moonshot AI (Kimi), centers on a KVCache-centric PD-disaggregated architecture: the Transfer Engine moves KV at high speed across RDMA/NVMe media, and Mooncake Store provides a distributed KV storage interface, already integrating into the vLLM/SGLang ecosystems (public-source basis). It validates an industry judgment: KV cache deserves management as first-class cluster data.
Where Mingxin sits in this picture
Mooncake is the software orchestration and transport layer; KV data ultimately lands on physical media — the large warm/cold tier is exactly the FX array's role: a standard NVMe-oF block device that Mooncake/LMCache/NIXL sink paths can all attach to.
Honest measurement boundary: Mingxin's signed measurements (R1–R4) are on the vLLM+LMCache stack. A Mooncake-stack attachment is the same architecture class (identical NVMe-oF target side), but we have no measured numbers and will not pre-promise — G1–G4 gated joint tests welcome, numbers backfilled from reports.
Comparable anchors: the storage tier's own capabilities are framework-independent — parallel-read bandwidth 5.23 GB/s per GPU (R1), cross-instance sharing verified (R3), 480B cold-recovery TTFT p50 11.85 s (R2).
FAQ
With Mooncake, do I still need to buy an array?
Mooncake Store manages the logical KV layer; physical capacity still needs media. HBM/RAM take the hot tier; for the large warm/cold tier, an all-flash array wins on capacity cost (≈ ¥2,014/TB).
LMCache or Mooncake — which one?
For a single vLLM cluster starting out, LMCache is lighter; for large-scale PD disaggregation and cross-engine scenarios, Mooncake's ecosystem is fuller. Neither conflicts with the FX hardware layer — choose by architecture stage.
Will Mingxin build Mooncake adaptation?
Source-level adaptation is a standard Mingxin capability (ROCm/LMCache precedents in R1/R8); scheduling follows customer joint-test demand, with numbers backfilled from reports.
Data sources (verifiable)
Related reading
- Mingxin FX and NVIDIA Dynamo: Complementary, Not Competing
- Prefill/Decode Disaggregation and the KV Cache Transport Layer
- Productionizing LMCache: From Open-Source Component to Signed Benchmarks
Joint test first, decisions second: gate-based acceptance with built-in stop-loss
The full costing model is provided as reproducible Python after NDA — customers can rerun it with their own parameters. Every key figure on this site carries a report ID and is open to third-party verification.
This site presents business-cooperation information and constitutes neither an investment offer nor any promise of returns. Measured data come from signed / official test reports (see the Evidence Library); vendor specs, public sources and estimates are labeled as such.