作者 | 付秋伟

引言：大模型推理落地的“三角困境”

当大模型从技术探索走向产业落地，推理环节的“成本、吞吐、长上下文”三大难题逐渐成为行业规模化应用的核心阻碍。企业既希望降低每兆 Token 的推理成本，又要保证高并发场景下的吞吐效率，还需满足 VibeCoding、多轮对话等场景的长文本处理需求。这三者之间的矛盾如同“三角困局”，难以兼顾。

在此背景下，开源项目 Mooncake以“计算存储解耦”为核心思路，通过 PD 分离（Prefill-Decode 分离）、KVCache 池化等技术，为大模型推理提供了重要的底层基础设施支撑。「AI 进化论：智算时代 OS 的破局之路」第五期直播，聚焦「Mooncake 如何破解大模型推理成本、吞吐与上下文困局」，邀请清华大学章明星教授（Mooncake 联合发起人）与阿里云高级技术专家马腾博士（Mooncake 核心贡献者），从学术研发与产业落地双视角，拆解 Mooncake 的技术逻辑、开源价值与企业实践，并为智算时代 OS 的演进提供参考。

以下为经编辑整理的访谈内容精要。

1行业痛点与 Mooncake 项目背景

Q1：当前大模型推理落地加速，行业普遍面临成本、吞吐、长上下文难题，两位在各自领域感受到的最突出的挑战是什么？

@章明星（清华大学）

总体而言，还是一个成本和用户体验之间的权衡。我们做系统常讲，永远没有完美的方案，在某一场景下表现优异，在另一场景可能就会有所折损。Mooncake 架构最初就是为了保障用户体验而提出的。大模型推理包含两个阶段：一是 Prefill，主要负责处理用户的长段输入；二是 Decode，即逐词输出结果。像 Kimi 这类面向 ToC 的应用，输出流畅度至关重要。如果 Prefill 和 Decode 混合部署在同一 GPU 上，会产生干扰，导致输出时断时续，影响体验。因此，我们采用了分离式结构，并为了支持多轮对话和共享提示词，构建了大的 KVCache 缓存池，这是 Mooncake 架构的起点。

今年以来，随着 DeepSeek、Kimi K2 等参数量巨大（如 600B、1TB 以上）的模型出现，我们需要为 Prefill 和 Decode 设计不同的并行策略，以提升吞吐、降低成本。同时，VibeCoding 等业务上线后，对话上下文长度从原来的 1K、2K 显著增长至几十 K。在这种长文本场景下，分离架构已成为必须，但还需结合 SpecDecoding 等新技术来保证输出速度并控制成本。

@马腾（阿里云）

我从另一个角度谈谈。成本、吞吐和上下文长度，这三者像一个“三角关系”。若要支持很长上下文，可能需要独占大量显存；若追求高吞吐，则需进行批量处理（batching）来打满计算单元，但这又会限制并发处理的上下文长度。在此基础上，还要考虑成本因素——使用高端 GPU 成本高昂。Mooncake 的 PD 分离、分层存储等技术，正是在这三者间寻找平衡点。并且，PD 分离并非万能，例如在离线推理场景，更关注吞吐和成本，对实时性要求不高，就需要不同的推理策略。多轮对话、CloudCode 等场景，也需基于 Mooncake 这一底层基础设施进行针对性调优。

Q2：现在产学研协同做技术突破很常见，Mooncake 作为其中代表，最初发起的核心诉求是什么？开源模式对项目推进有哪些帮助？

@马腾（阿里云）

最初是去年六、七月份，我们看到了 Kimi 和清华联合发布的 Mooncake 技术报告，其核心是 KVCache 池化，很感兴趣。我与章老师认识已久，便一起探讨——最初 Mooncake 主要在 Kimi 内部使用，开源内容有限。我们就在想，如何将其做成业界能复用的开源项目，于是筹备了三个月推出第一版代码，去年 11 月正式开源后，逐步调整方向与上层推理框架对接，到今年五、六月份才基本完成。

开源的内在逻辑是构建生态循环。在 AI 时代，技术竞争激烈，闭门造车难以持续领先。通过开源贡献想法，吸引大家共同开发，不仅能自身受益，也能推动整个产业进步，避免重复建设。现在蚂蚁、摩尔线程等企业也参与进来，Mooncake 能覆盖更多场景。

@章明星（清华大学）

最初的核心诉求，是希望将单一公司的推理引擎，转变为业界通用的基础设施。早期我们与月之暗面共同梳理了技术报告，后来为了推广，决定开源。开源最大的价值是降低协作成本，汇聚产业力量——若仅由清华或 Kimi 主导，力量有限，外界也可能担心其专属性。借助龙蜥社区这类开源运营团队，大家有了互信基础。目前 AI 领域从学术到产业的转化周期极短，开源能加速这一过程，使 Mooncake 从“实验室技术”快速转化为“产业级方案”。

Q3：阿里云在基础软件国产化方面的积累，对 Mooncake 项目的技术方向有哪些影响？

@马腾（阿里云）

初期适配存在挑战，例如如何高效利用阿里云的自研网络（如 eRDMA）和硬件（如 PPU）。比如 eRDMA 网络，端到端打通后，性能调优花了我们一、两个月；还有硬件拓扑感知，云上服务器卡数与网卡配置与传统环境不同，需要专门处理。我们的核心开发者任峰扩展了底层传输引擎的思路，目前这套拓扑感知方案也能被其他企业复用。

此外，我们通过龙蜥社区的 AI SIG、智算基础设施联盟，汇聚了国产生态伙伴，将阿里自身技术融入，降低了适配成本。Mooncake 对底层硬件性能压榨很极致，需要操作系统、驱动协同优化，开源社区能有效促进硬件厂商、软件团队协作，快速适配各类新型硬件和协议。

2Mooncake 的核心技术与设计逻辑

Q4：针对推理痛点，Mooncake 的核心解决思路和行业传统方案比，最大差异在哪？对底层操作系统又提出了哪些新要求？

@章明星（清华大学）

最大差异在于“分离式架构”——将传统数据中心的解耦思想，应用于 AI 数据中心。传统方案多是“同构 SILO”，一台机器承载所有功能；Mooncake 则以 KVCache 为中心实现分离：Prefill 生成 KVCache，KVCache Pool 负责缓存，Decode 消费 KVCache。这不仅实现了 PD 分离，还使 KVCache 独立管理。同期北大、微软也有类似 PD 分离思路，但 Mooncake 是较早成熟并大规模应用的，并拓展了分离边界，例如将 Decode 中的 Act-Offload 和 Attention 拆分到不同设备。

这对底层操作系统的核心要求是“极致的硬件性能压榨”。当前 GPU 速度极快，其他设备必须跟上。网络带宽发展快于本地内存，分离架构带来的通信成本在可接受范围，甚至更优；需要操作系统支持更多的异步操作、零拷贝数据传输，并能感知复杂硬件拓扑（如 NVLink、PCIe、外部网络），同时具备更好的故障容错能力。这些都要求 OS 提供更细粒度的硬件抽象和信息暴露。

@马腾（阿里云）

从操作系统角度看，现有通用 OS 内核与“解耦”概念存在差距。未来大规模推理可能趋向“Multikernel”（多核内核）架构——集群对外呈现为一个统一操作系统。现阶段，OS 需要成为硬件与 Mooncake 之间的桥梁，协助完成驱动层适配，抽象硬件能力。例如阿里云的智算镜像，就将 Mooncake 及其依赖打包，用户无需关心底层适配，实现开箱即用。

Q5：KVCache 池化和高效传输是 Mooncake 的关键技术，从技术落地看，最难突破的环节是什么？

@马腾（阿里云）

我博士期间就研究内存池化，但传统场景缺乏杀手级应用。直到 KVCache 场景出现，TB 级内存池化才真正发挥价值。

最难的是“标准化”和“规模化”。早期内存池化缺乏统一 API，Mooncake 需要定义一套能对接各类推理框架的标准接口。规模化后，多租户管理、云原生集成、兼容 CXL、RDMA 等新协议都是挑战。Mooncake 的传输引擎（Transport Engine）是关键，它适配了 eRDMA、GPU Direct 等技术，实现低延迟传输，是架构简洁性的基础。

@章明星（清华大学）

核心难点是“跟上硬件发展速度”。硬件速率快速提升，对代码效率要求极高，微秒、纳秒级的操作不能有任何瓶颈。同时需协调众多异构设备，优化数据路径。KVCache 池化的效益提升存在“边际递增”现象，例如命中率从 90% 提升到 95%，看似仅 5%，但重算量从 10% 降为 5%，相当于计算量减半。因此需不断优化分层设计和数据局部性，扩大池化容量而不牺牲性能。

Q6：从科研到工程落地，技术方案往往需要调整，Mooncake 是如何适配企业级需求的？

@章明星（清华大学）

早期 Mooncake 以“快速上线”为首要目标，对企业级需求的考量相对不足。随着用户增多，可靠性、稳定性、兼容性成为必须解决的问题。这是一个需要细致打磨的过程：例如提升可用性，实现动态弹性伸缩；增强兼容性，支持 eRDMA、CXL 等新协议，每个协议的适配都需要反复调试。

蚂蚁集团的参与很有代表性——他们的多轮对话场景需要更大的 KVCache 容量和更快的换入换出速度，经共同优化后，其 TTFT（首词响应时间）显著降低。企业级场景还需考虑多租户、云原生集成，我们与阿里 ACK 团队合作，将 Mooncake 融入云原生生态，解决资源调度问题。

@马腾（阿里云）

工业界部署强调灵活性，不能期望一套方案解决所有问题。我们将 Mooncake 拆分为多个子项目（如传输引擎、Mooncake Store、Checkpoint Engine 等），不同场景可选用不同模块，便于维护。开源社区在此作用关键：企业需求多样，单靠一方难以满足。在社区中，硬件厂商可自行适配，我们再整合优化方案，避免生态碎片化。未来我们希望将 Mooncake 捐赠给基金会，使其发展更中立、可持续。

3Mooncake 的行业实践与效果验证

Q7：主流推理框架（vLLM/SGLang 等）各有特性，Mooncake 适配这些框架时，遇到的共性挑战是什么？

@马腾（阿里云）

共性挑战是“框架接口差异大”。我们先后对接 vLLM 和 SGLang，但两者模式不同：SGLang 倾向点对点传输，vLLM 则更适合使用 Mooncake Store 的 Put/Get 语义。如何在保持 Mooncake 核心架构不变的前提下，适配不同框架是一大挑战。

我们的策略是“复用组件 + 抽象中间层”。能复用的核心组件（如传输引擎）尽量复用，保持技术栈简洁；无法直接复用的，则通过 Mooncake Store 这类通用中间层进行适配。例如，蔡尚明老师在对接 vLLM 时，尝试了不同方案，最终通过 Mooncake Store 取得了良好效果。实际测试表明，在 SGLang 上使用 Mooncake 进行 PD 分离后，吞吐提升超过 30%，TTFT 降低 20%。

Q8：阿里云、蚂蚁已部署 Mooncake，这些企业级场景的需求，反过来对项目有哪些迭代推动？

@马腾（阿里云）

蚂蚁的多轮对话场景，直接推动了 KVCache 池的优化。在该场景下，不复用 KVCache 会导致延迟急剧上升。蚂蚁的同事提出利用 Mooncake Store 实现 KVCache 复用，我们共同对接了 SGLang 的 BlackCache，优化后 TTFT 提升显著。

在阿里云平台上，云环境的多租户需求推动了 Mooncake 的资源隔离能力建设。我们为 Mooncake Store 增加了隔离机制，并实现了 VRAM 池化，整合闲置的 GPU 显存资源提升利用率。同时，通过将不活跃的 KVCache 下沉至本地磁盘或 CFS 分布式存储，在性能影响较小（约 20%）的情况下，显著降低了成本。

@章明星（清华大学）

企业级场景让 Mooncake 变得更“实用”和“健壮”。例如，阿里云的 eRDMA 网络经过适配优化，带宽利用率得到提升；蚂蚁的长文本需求推动了 KVCache 分层存储的落地。此外，企业场景对易用性要求高，倒逼我们开发自动配置工具，利用传统统计模型结合业务 SLO（如 TTFT、吞吐要求），自动推荐最优资源配置，减少了人工调优成本。

Q9：0.2 美元 / 1M Token 的低成本是怎么实现的？行业有观点说“新模型推理成本仍高”，两位怎么看？

@章明星（清华大学）

0.2 美元 / 1M Token 的成本目标，在特定条件下是可以实现的，例如有足够高的并发量打满 GPU 算力，且对输出速度要求不高（如对话场景 15-20 Token/ 秒即可）。若需极高输出速度或边缘低并发场景，成本会上升。感觉新模型成本高，需区分看待：开源模型架构稳定后，推理成本实则在下降；而部分商业模型定价策略并非完全反映物理成本。此外，Token 用量的增长速度有时快于成本下降速度（例如 Agent 应用消耗巨大），导致总支出增加。

未来降本方向是“价值工程”，即整体优化，根据不同环节的需求混合使用不同规模的模型和策略。

@马腾（阿里云）

低成本的核心在于“资源利用率最大化”。云的本质是共享，Mooncake 通过 KVCache 池化、PD 分离等技术，显著提升了 GPU 算力和显存的利用率。新模型成本高也有硬件迭代的因素，但可通过技术优化对冲，例如存储下沉、VRAM 池化。未来多智能体场景可能无需全部使用大模型，通过优化协作流程也能实现降本增效。

4Mooncake 的未来演进与行业启示

Q10：大模型推理技术会往哪些方向发展？Mooncake Store V2 的多实例共享、廉价存储下沉，是基于哪些趋势设计的？

@马腾（阿里云）

未来推理技术会向“AI Aware OS”（AI 感知操作系统）和“大规模协同”方向发展。操作系统需要更深入地优化网络、存储、GPU 调度，并具备 AI 感知能力。Mooncake Store V2 的设计基于两大趋势：一是云场景多租户共享需求，允许不同用户安全地共享通用提示词的 KVCache 以降低成本；二是 KVCache 容量需求持续增长，需要引入廉价存储（如磁盘）进行分层存储，在成本与性能间取得平衡。

@章明星（清华大学）

推理技术将更加“灵活”，以适配 Agent 时代多样化的需求。Mooncake 需要支持动态调整配置。Mooncake Store V2 还注重“局部性优化”，减少跨节点数据传输开销，并支持 CXL 等新协议，以应对长文本、多轮对话场景对容量和性能的要求。

Q11：未来 Mooncake 生态扩展会侧重什么？对想入局大模型推理基础设施的团队 / 开发者，有什么建议？

@马腾（阿里云）

生态扩展将侧重“开放、公平”。希望吸引更多企业、高校参与，避免单一主导。会加强硬件厂商合作，并计划将项目捐赠给基金会，确保其中立发展。建议开发者可以从“传统技术领域”切入，例如存储、网络知识在 Mooncake 中非常适用。参与开源社区是快速了解产业需求、提升个人影响力的有效途径。

@章明星（清华大学）生态扩展侧重“标准化和 自动化”。推动接口标准化，并开发智能调优工具降低使用门槛。加强与大平台（如云原生调度平台）的合作。建议团队和开发者寻找自身技术与 AI 基础设施的“衔接点”，开源社区提供了宝贵的实践和成长平台。

Q12：Mooncake 的实践，对大模型推理领域的技术范式、操作系统演进有哪些启发？

@章明星（清华大学）主要启发是“分离式架构正成为共识”。Mooncake 的实践表明，通过 PD 分离、KVCache 独立管理，能够在成本、吞吐和长上下文之间取得更好平衡，这正形成新的技术范式。同时，产学研协同的开源模式，也为国内 AI 基础设施项目提供了重要参考。

对操作系统演进的启发在于“功能扩展”。操作系统需要提供更细粒度的硬件抽象和管理能力，以支撑 AI 推理的特殊需求（如拓扑感知、高效数据搬运）。未来，传输引擎等组件中的部分功能，或许可能被吸收到操作系统层，成为原生能力。

@马腾（阿里云）

对技术范式的启发是“以存储换取计算”。通过 KVCache 池化，用存储资源换取计算资源，提升效率。“被集成”的思路很重要，Mooncake 旨在增强而非替代现有生态。

对操作系统的启发是“更贴近 AI 需求”。操作系统需要优化 GPU 利用率、支持异构设备协同、具备 AI 感知能力。例如阿里云的智算镜像就集成了 Mooncake 与 OS，使用户开箱即用。未来操作系统可能更轻量化、灵活，以快速适配新硬件和新协议。

5结语：共建智算时代的推理基础设施

实际上，Mooncake 的价值，并不仅仅在于为解决大模型推理的“三角困境”提供了技术思路，更在于以开源为纽带，探索了产学研协同的新模式，将传统基础设施技术与 AI 需求融合，形成了“技术创新 - 产业落地 - 需求反哺”的闭环。

随着大模型推理从“单点优化”走向“系统协同”，需要更多像 Mooncake 这样的开源项目凝聚产业力量，推动技术标准化与成本优化。未来，随着分离式架构的深化和操作系统的 AI 化演进，大模型推理有望更好地支撑各行各业的智能化转型。

Mooncake 项目开源地址（复制链接至浏览器打开）：https://github.com/kvcache-ai/mooncake

栏目介绍

在 AI 重塑产业格局与国产化替代加速推进的双重浪潮下，《AI 进化论：智算时代 OS 的破局之路》以云、AI、安全等技术与服务器操作系统如何融合演进为主线，聚焦服务器操作系统在智算时代的进化之路，特邀学术权威、行业专家、客户代表围绕原生智能、原生安全、软硬协同等热点议题展开深度对话，并以阿里云服务器操作系统为例，系统性解析其技术架构、演进之路及场景应用价值，以期给行业带来启示与借鉴。