Mooncake把KV Cache当成中央调度器，让预填充节点和推理节点彻底分家，再把CPU、内存、SSD和网卡全部拉进一个分布式缓存池。这套架构让Kimi每天处理超过1000亿token，在A800集群上多扛115%的请求，在H800集群上多扛107%的请求。
华尔街空头误读了Kimi的底牌
金融圈最近突然看空KV Cache卸载，理由是Kimi K3的KDA（Delta Attention）让缓存状态不再随上下文长度线性膨胀。空头们算了一笔账：如果缓存不膨胀，那专门搞一套分布式缓存池就亏了。
这套逻辑漏了一个关键事实。KDA确实把缓存压小了，但Kimi的对话场景里，前缀复用率才是吞吐量的心脏。用户每次追问都带一大段历史上下文，这些前缀的KV Cache如果能被全局共享，预填充阶段就能跳过大量重复计算。Mooncake的论文用真实流量证明，本地DRAM只能支撑理论缓存命中率的50%，剩下50%必须靠全局缓存池才能吃到。
换句话说，KDA解决的是"每个token占多少内存"的问题，Mooncake解决的是"这些内存能不能被成千上万个请求共享"的问题。两者压根不在一个维度。空头把技术栈的层次搞混了，就像因为硬盘容量变大了就断言云存储没用一样。
预填充和推理分家才是正经事
大模型推理其实分两个阶段。第一阶段叫预填充（Prefill），把所有输入token并行处理，算出第一个输出token，同时生成KV Cache。这个阶段算力密集，像工厂流水线。第二阶段叫解码（Decoding），用KV Cache自回归地一个token一个token往外蹦，这个阶段内存密集，像仓库发货。
传统做法把两个阶段塞在同一台GPU上，结果两头不讨好。预填充时GPU算力拉满，解码时GPU内存拉满，但两者不会同时拉满，资源总有一半在摸鱼。Mooncake的做法简单粗暴：预填充节点专门负责算，解码节点专门负责存和生成，中间用高速RDMA网络把KV Cache搬过去。
这套分离架构（Disaggregated Architecture）在学术圈吵了很久，有人质疑网络带宽撑不住。
Mooncake的回应是：A800集群里单张GPU配100Gbps网卡，H800集群里配200到400Gbps网卡，这个带宽已经跟内存带宽同一个量级。
Mooncake论文里算了一笔账，LLaMA3-70B在8卡A800上跑，前缀长度8192时，只要6GB/s的加载带宽就能让KV Cache复用比重新计算更划算。100Gbps网卡换算下来约12.5GB/s，绰绰有余。
Mooncake Store把闲置资源变成缓存池
分离架构只是第一步，Mooncake的真正狠活是Mooncake Store。这个东西把集群里所有闲置的CPU、DRAM、SSD和RDMA网卡拢在一起，做成一个分布式KV Cache缓存池。
缓存池里的KV Cache按页块（Paged Block）存储，每块16到512个token，带哈希键去重。同一个哈希键可以在多个节点上存副本，避免热点读卡脖子。缓存满了用LRU（Least Recently Used，最近最少使用）策略淘汰冷数据，除非这块数据正在被某个请求占用。
论文对比了全局缓存和本地缓存的命中率。全局缓存设计的命中率是本地缓存的2.36倍，直接省下48%的预填充计算时间。这意味着同样数量的GPU，Mooncake能喂饱更多请求。
传输引擎（Transfer Engine）是Mooncake Store的油门。传统方案用NCCL（NVIDIA Collective Communications Library，NVIDIA集合通信库）做RDMA通信，但NCCL不支持动态拓扑变更，也不支持DRAM到DRAM的直接路径。
Mooncake自己写了一套传输引擎，能感知服务器拓扑，自动选最优网卡路径，还能把单个大请求切成多个切片并行传输。实测比现有方案快2.4到4.6倍。
Conductor调度器在过载边缘走钢丝
分布式缓存池有了，怎么调度请求才是灵魂。
Mooncake的中心调度器叫Conductor，它给每个请求选一对预填充节点和解码节点，然后启动四步流程：先尽量复用前缀缓存，再做增量预填充，同时异步把KV Cache流式传到解码节点，最后解码节点把请求加入连续批处理。
这四步听着简单，实际全是坑。预填充阶段要最大化缓存复用，但等远程缓存可能拖慢TTFT（Time To First Token，首token延迟）。解码阶段要最大化批处理大小，但KV Cache总量不能超过GPU显存，否则TBT（Time Between Tokens，token间隔延迟）会暴雷。
Conductor的解法是给热点缓存块自动做多副本，给冷数据 swap 到SSD，同时预测未来负载。预测对了就能提前拒绝那些注定跑不完的请求，避免浪费预填充算力。但提前拒绝本身也有坑：如果拒绝策略太粗暴，负载会像过山车一样波动。Mooncake用短期负载预测平滑了这个波动。
这套调度在真实流量上跑出了59%到498%的有效请求容量提升。在A800集群上，Kimi比旧系统多扛115%的请求；在H800集群上，多扛107%。论文拿了FAST 2025的最佳论文奖，这是存储系统顶会，说明评审团认可这套架构的存储层创新。
长上下文是Mooncake的主场
Mooncake在长上下文场景里特别能打。传统序列并行（Sequence Parallelism）把长请求切到多个节点，但节点间通信开销大，还要频繁弹性扩缩容。Mooncake发明了CPP（Chunked Pipeline Parallelism，分块流水线并行），把长请求的预填充切成多个块，在多个节点上流水线执行，同时层间流式传输KV Cache。
跟传统SP比，CPP减少了网络消耗，也降低了对弹性扩缩容的依赖。论文里的实验显示，在真实对话负载和不同TBT SLO约束下，Mooncake的请求容量曲线比vLLM、vLLM Prefix Caching、vLLM Chunked Prefill都陡峭得多。在Threshold I（100ms TBT）处，Mooncake比vLLM多498%的容量；在Threshold II（200ms）处，多157%；在Threshold III（300ms）处，多59%。
这组数据说明，SLO越严格（TBT要求越低），Mooncake的优势越夸张。因为SLO严格时，解码节点必须保持小批量低延迟，预填充节点的效率就成了瓶颈。Mooncake通过全局缓存复用，把预填充时间压到最低，从而让更多请求挤进同一个解码批次。
产业链影响：内存、光模块和光纤的蛋糕怎么分
Mooncake的架构对硬件产业链有实打实的拉动。首先是内存。分布式缓存池把DRAM从GPU的附属品变成了独立资源池，集群里的CPU内存不再只是陪跑，而是成了KV Cache的主战场。这意味着AI服务器里的DRAM配比会上升，尤其是高带宽、低延迟的DDR5。
其次是光模块和光纤。Mooncake的RDMA网络跑在RoCEv2上，A800配100/200Gbps NIC，H800配200/400Gbps NIC。这些网卡需要对应速率的光模块和光纤来撑。论文里提到网络带宽最高可达8×400Gbps，这已经跟DRAM带宽一个量级。
分布式缓存意味着节点间的KV Cache流量是常态，不是偶尔同步一下。预填充节点和解码节点之间的数据搬运、缓存副本的同步、热点迁移，全部走网络。这推高了东西向流量（East-West Traffic，数据中心内部横向流量），对光互联的密度和带宽提出了更高要求。
最后是SSD。Mooncake把SSD也纳入缓存池，作为DRAM的溢出层。冷数据swap到SSD，虽然延迟比DRAM高，但容量大得多。这给了QLC SSD在AI推理场景里一个明确的位置——不是存模型权重，而是存KV Cache的冷数据。
开源生态正在跟进
Mooncake的代码已经开源，包括Transfer Engine和Mooncake Store。vLLM在2024年12月官方支持了Mooncake Transfer Engine，SGLang在2025年4月跟进，LMCache在2025年4月把Mooncake Store接进去当远程连接器。NVIDIA的NIXL也在2025年5月支持Mooncake Transfer Engine作为后端插件。
这意味着Mooncake的架构正在成为行业标准。不是Moonshot AI一家在玩，而是整个开源推理栈都在往"分离式架构+分布式KV Cache"的方向转。NVIDIA Dynamo、Red Hat的llm-d、阿里巴巴的RTP-LLM，都在走类似路线。
当整个行业都往一个方向拱的时候，单独看空某个技术点（比如KV Cache卸载）就没意义了。Mooncake证明的是：即使缓存大小被KDA压缩，全局共享和调度优化带来的吞吐量增益，仍然值得投入存储和网络资源。
总结
Mooncake用"以存储换计算"的思路，把AI推理集群的闲置资源全部盘活，让KV Cache成为全局调度中心。
这套架构让Kimi在A800和H800集群上分别多扛115%和107%的请求，长上下文场景下有效容量最高翻近五倍。产业链上，DRAM、光模块、光纤、SSD都因分布式缓存池而获得新增量。
华尔街空头看错了层次——KDA压缩的是单token缓存 footprint，Mooncake放大的是全局缓存的复用效率。两者叠加，才是Kimi的完整底牌。