Mooncake破解大模型推理“三角困境”，开源共建智算基础设施
快速阅读: Mooncake项目通过计算存储解耦，解决大模型推理中的成本、吞吐量和长上下文处理难题，采用PD分离和KVCache池化技术，优化用户体验，提高资源利用率，支持多租户和云原生集成，推动AI基础设施发展。
引言:大模型推理落地的“三角困境” 当大模型从技术探索走向产业落地,推理环节的“成本、吞吐、长上下文”三大难题逐渐成为行业规模化应用的核心阻碍。企业既希望降低每兆 Token 的推理成本,又要保证高并发场景下的吞吐效率,还需满足 VibeCoding、多轮对话等场景的长文本处理需求。这三者之间的矛盾如同“三角困局”,难以兼顾。
在此背景下,开源项目 Mooncake 以“计算存储解耦”为核心思路,通过 PD 分离(Prefill-Decode 分离)、KVCache 池化等技术,为大模型推理提供了重要的底层基础设施支撑。「AI 进化论:智算时代 OS 的破局之路」第五期直播,聚焦「Mooncake 如何破解大模型推理成本、吞吐与上下文困局」,邀请清华大学章明星教授(Mooncake 联合发起人)与阿里云高级技术专家马腾博士(Mooncake 核心贡献者),从学术研发与产业落地双视角,拆解 Mooncake 的技术逻辑、开源价值与企业实践,并为智算时代 OS 的演进提供参考。
以下为经编辑整理的访谈内容精要。
行业痛点与 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 对底层硬件性能压榨很极致,需要操作系统、驱动协同优化,开源社区能有效促进硬件厂商、软件团队协作,快速适配各类新型硬件和协议。
Mooncake 的核心技术与设计逻辑 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 捐赠给基金会,使其发展更中立、可持续。
Mooncake 的行业实践与效果验证 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、吞吐要求），自动推荐最优资源配置，降低了人工调优的成本。
针对 0.2 美元/1M Token 的低成本实现问题，章明星认为，在特定条件下，如具有足够高的并发量以充分利用 GPU 算力，且对输出速度要求不高（如对话场景下的 15-20 Token/秒），这一成本目标是可以达成的。对于新模型成本较高的观点，他认为需要区别看待：开源模型架构稳定后，推理成本实际上在下降；而部分商业模型的定价策略并不完全反映实际物理成本。此外，Token 用量的增长速度有时超过成本下降的速度，如 Agent 应用消耗巨大，导致总体支出增加。未来的降本方向将是“价值工程”，即通过整体优化，根据不同环节的需求混合使用不同规模的模型和策略。
马腾（阿里云）指出，低成本的关键在于“资源利用率的最大化”。云服务的本质是资源共享，Mooncake 通过 KVCache 池化、PD 分离等技术，显著提升了 GPU 算力和显存的使用效率。虽然新模型成本高的问题部分源于硬件迭代，但可以通过技术优化来抵消，比如存储下沉、VRAM 池化。未来，在多智能体场景中，不一定需要全部使用大型模型，通过优化协作流程同样可以实现成本效益的提高。
关于大模型推理技术的发展方向，马腾认为将朝着“AI 感知操作系统”和“大规模协同”方向前进。操作系统需更深入地优化网络、存储、GPU 调度，并具备 AI 感知能力。Mooncake Store V2 的设计基于两个趋势：一是云环境中多租户共享的需求，允许多个用户安全共享通用提示词的 KVCache 以降低成本；二是 KVCache 容量需求持续增长，需要引入廉价存储（如磁盘）进行分层存储，以在成本与性能之间找到平衡。
章明星补充说，推理技术将更加灵活，以适应 Agent 时代多样化的需要。Mooncake 将支持动态调整配置，并注重局部性优化，减少跨节点的数据传输开销，支持 CXL 等新协议，以满足长文本、多轮对话场景对容量和性能的要求。
对于 Mooncake 生态的拓展，马腾强调将遵循“开放、公平”的原则，吸引更多企业和高校参与，避免单一主导。项目计划捐赠给基金会，确保其中立发展。他建议开发者可以从传统技术领域入手，如存储、网络知识在 Mooncake 中的应用。参与开源社区是快速了解行业需求、提升个人影响力的途径。
章明星则认为，生态拓展应侧重“标准化和自动化”。推动接口标准化，并开发智能调优工具以降低使用门槛。加强与大平台（如云原生调度平台）的合作。他建议团队和开发者寻找自身技术与 AI 基础设施的衔接点，开源社区提供了宝贵的学习和成长机会。
章明星还提到，Mooncake 的实践对大模型推理领域的技术范式、操作系统演进的主要启发是“分离式架构逐渐成为共识”。通过 PD 分离、KVCache 独立管理，可以在成本、吞吐量和长上下文之间取得更好的平衡，形成新的技术范式。同时，产学研协同的开源模式为国内 AI 基础设施项目提供了重要参考。对操作系统演进的启发在于“功能扩展”。操作系统需要提供更细粒度的硬件抽象和管理能力，以支持 AI 推理的特殊需求，如拓扑感知、高效数据搬运。未来，传输引擎等组件的部分功能可能会被整合到操作系统层面，成为其原生能力。
马腾补充道，对技术范式的启发在于“以存储换计算”。通过 KVCache 池化，用存储资源换取计算资源，提高效率。“被集成”的理念至关重要，Mooncake 致力于增强而非替代现有生态系统。对操作系统的启发在于“更贴近 AI 需求”。操作系统需要优化 GPU 利用率、支持异构设备协同工作、具备 AI 感知能力。例如，阿里云的智算镜像集成了 Mooncake 与操作系统，让用户能够开箱即用。未来，操作系统可能会更加轻量化、灵活，以快速适应新硬件和新协议。
总结而言，Mooncake 的价值不仅在于为解决大模型推理的“三角困境”提供了技术思路，更在于通过开源模式探索了产学研协同的新路径，将传统基础设施技术与 AI 需求相结合，形成了“技术创新 – 产业落地 – 需求反馈”的良性循环。随着大模型推理从“单点优化”向“系统协同”转变，需要更多像 Mooncake 这样的开源项目汇聚行业力量，推动技术标准化和成本优化。未来，随着分离式架构的深化和操作系统的 AI 化发展，大模型推理有望更好地支持各行业的智能化转型。
(以上内容均由Ai生成)
