对话清华章明星、月之暗面许欣然：Mooncake架构背后，如何用“炒菜”的思路实现推理的极致优化

硅星人首届AI创造者大会（ACC 2024），在「异构推理框架」议题下，硅星人创始人兼CEO骆轶航邀请到了清华大学助理教授、KVCache.AI团队负责人章明星，以及月之暗面Kimi工程副总裁许欣然，共同探讨AI推理架构的创新与开源对行业生态的深远影响。以下为对话实录整理。

骆轶航：刚才我和章明星还在聊，那篇论文意外地收获了积极的反馈。我的第一个反应是，月之暗面发布了论文，这篇论文让大家能够上手操作，确实为很多人带来了启发。Kimi之前遇到的问题，不排除在某些爆款AI应用中也可能会出现，这个事特别有价值。先做个调查，大家有谁碰到过“Kimi 有点累了，请稍等一下再问我”，有多少人经历过这种情况？

（台下零星举手）

章明星：这说明我们的优化做得很好。

骆轶航：确实，这个优化做得相当不错，让大家遇到这种情况的几率减少了许多，我明白这件事情，章教授你也参与了 Mooncake 这个项目，Mooncake 的开发仍是创业公司的运作方式。过去我们总说一块钱要掰成两半花，现在是一张卡要劈成更多份使用。我们一直在争取算力资源、服务器资源，整体资源都是相对紧张的状态。所以我们采用了这样的方法来应对。我很好奇的是，论文是在 7 月份发布的，而过去这两个月请求负载的情况显然变得越来越好。Kimi 我印象中流量比较高是在今年3月份，所以大家都在使用这个功能。Kimi智能助手的推出时间是去年11月。那到底你们是什么时候开始着手做这件事的呢？我的理解可能是去年11月之后，在3月份高峰期前后开始的，也许更早更晚。那么具体开始的时间是什么时候？

许欣然：我们在去年做内部能力验证后，发现了一个很严重的问题，模型的回答需要两个步骤，这个思考的过程很漫长。为了节省成本，不得不把一张卡分成多份使用，结果就是可能模型正在回答一个问题，突然有另一个请求插进来，这种体验非常不好。大概在去年11月发布之前，我们就意识到这种情况是用户无法接受的。试想，有人在跟你说话，突然让你等一下，两分钟之后接着说，谁都接受不了。所以早在九月份我们就开始解决这个问题了，当时还拉着章老师一起研究这件事。到年初的时候还没有完全解决，但这个想法其实很简单，后来我们加了多个“越墙度”，紧急把这个方案完成并上线了。是在后续发的论文，这个优化已经在做得相对完善，而且我们也认识到，这对很多友商，甚至对我们的供应商都有一些指导意义，因为未来的集群将会朝着这个方向发展，所以我们才决定发布这篇论文。

骆轶航：这个项目是从去年9月份开始的吗？章老师也在这个时间参与进来的吧？

章明星：其实我在月之暗面最初创立的时候就参与了，是一个自然而然的过程。他们的核心创始人是我高中同学，那时我已经回到学校当老师了，作为老师我们不能直接参与公司运营，但我觉得这是一个全新的方向值得关注。我和汤文超在同一个研究所，我们所里，包括我自己，之前主要从事超算和分布计算，以及大数据的相关工作，但那个领域当时已经有些退潮的趋势，新的应用方向必然是朝着AI发展的。正好有这样一个机会，就想着一起看看在国内是否可行，只需要两三个人就能把这个东西发展起来。我其实是带着学习的心态参与进来的，后来欣然也加入进来。最早是在训练间隙，当我们做长文本任务时，预想到推理的成本会非常高，因此在推理方面的投入比其他人要早，也更加激进，这大概就是我的参与历程。

骆轶航：章老师太谦虚了。我觉得这里有一个关键点，我们在设计助手产品、训练这个产品的过程中，就意识到单线程沟通和输入Prompt指令的过程可能会被其他指令打断，这样的体验很差，特别是在并发增加的情况下会成问题，这是一条主线。章老师刚才提到长文本，Kimi智能助手在超长文本的无损压缩和推理解释方面做得很好，这也是它从第一天起主打的特性，我们一开始就是为了两个目标：一方面是处理长文本，一方面是为长文本的推理成本降低做准备，因此采用了分离式架构，第二个是为高并发潜在的可能性做准备，这两个可能性，一开始哪个会更重一点？

章明星：我印象很深刻，当时我们定下的用户指标非常高，考虑到可能会有爆发情况，所以，从一开始我们就在为海量并发做准备。长文本也是相关的，文本越长，适应的场景越多。在算法层面，我们较早就坚定了信念，为长文本进行更好的优化，我们的架构分离其实不是全新的想法，很多人可能都会想到，但更早地大家都关注到这个问题，我们才做出这样的架构。

骆轶航：你们的分离架构是不一样的。今天的场合让我在上午主持时特别放松，因为面对的是企业家，而下午是技术人士，我的状态紧绷起来了，怕露怯。接下来我们探讨一下分离式架构的细节，我理解这个架构的核心有两个非常重要的模块，它们分别起什么作用？这是你们内部的分享图，能否具体解释一下分离式架构中的Prefill和Decode，分别比作“备菜”和“炒菜”阶段。分离后是如何解决高并发问题的？包括文本复杂度的问题，用这两张图说明一下，文本长度和并发处理的逻辑是否相似？

许欣然：我们确实考虑了很久，想用某种方式来解释这个图。通常情况下，一台机器上的GPU既用于“备菜”（预填充，即思考过程），也用于“炒菜”（解码，即逐字逐句输出），这两个阶段交替进行。假设今天只有一个请求，就是显卡可以顺利地进行“思考”和“输出”，过程相对简单。但是随着用户增多，传统想法是需要更多人使用同一张卡进行服务，因此当显卡在“炒菜”的过程中，如果有新请求进来，它就必须立即开始“备菜”。在Kimi的表现上可能是回答一半卡住，等一会儿再继续，这样的用户体验很差。

通过分离式架构，我们将“备菜”和“炒菜”阶段独立开来。这样每个阶段都有专人负责，如果“炒菜”的资源不足，就增加“炒菜”的资源，“备菜”资源不足就增加“备菜”的资源，每个任务完成后，转交至下一阶段。这样不管用户有多少，只要对话开始，就不会出现卡顿问题。我们可以放心地将压力加载，GPU始终保持满负荷运行。一方面降低了成本，另一方面也提升了用户体验，实现了双赢。

骆轶航：这种情况下应对的复杂度非常高，实际中可能有50万人同时在线，直接处理200万文档的请求。

许欣然：是的，当突然有大量文档涌入需要分析时，我们会立即增加负责“备菜”的资源和机器，灵活地进行调配。

骆轶航：这些场景的核心在于“机房”中的服务器和算力问题。先将“备菜”和“炒菜”分开，然后在遇到并发时，通过增加更多阶段的分叉和优化应对，可以这样理解吗？

许欣然：可以这样理解。

骆轶航：分离式架构的核心解决了高并发问题。我认为在缓存和DRM方面也存在类似的问题。这套架构的分离逻辑，如果用“炒菜”来比喻，是否仍然适用？

章明星：我们一直在用“炒菜”来比喻这个问题。关键在于，作为餐厅运营者，不可能每次都根据顾客的现场点单从头制作每道菜。相反，事先准备一些常见的菜色，尤其是受欢迎的“拿手菜”，复用率会较高。在这种情况下，并不需要每道菜从“洗菜”“切菜”开始，理解成预制菜模式比较合适，炒菜时间依然不可少，但备菜时间可以减少。在大模型场景中，很多请求的前缀是类似的，这意味着有些步骤可以直接跳过，前提是需要一个大的缓存池来保存这些共用的内容，这样我们才能进一步分离KVCache，池化利用资源达到目的。

骆轶航：通过缓存来简化流程，很多内容可以直接利用已有的积累进行处理，而DRM则可以减轻GPU的负担，因为GPU资源宝贵。这套架构解释得很有意思。我想知道，这个架构是否可以让“VIP用户”避免过载问题？这套系统在7月份时差不多就准备好了吧？

章明星：是的，但上线确实需要一个过程。

骆轶航：七八月份上线后，系统是否能彻底解决访问被中断或卡住的问题？自GPT-4在2024年3、4月推出以来，尤其是GPT-4o 推出后，我几乎没有遇到访问中断的情况，比如连续访问40次都不会中断，体验很流畅，我不清楚他们是如何解决这个问题的？那个时候Gemini的访问量也很大，而GPT-3.5的访问量也不小。你们了解GPT如何处理这些问题吗？尤其是GPT的流量比Kimi大很多倍，我们是否也能彻底解决这个问题？

许欣然：所有的基础设施（infra）工作都不是灵丹妙药，它只是提高了资源利用率。利用率低的话，可能只有20%或30%，无论我们怎么努力，基础设施的利用率是有上限的，超过百分之百电和功率不允许。基础设施的提升对模型执行过程本身没有影响，模型的结构没有改变，只是执行效率更高。以ChatGPT为例，我们可以把资源提升分为三个层次，第一层是算力的绝对值，算力增加以后自然可以服务更多用户；第二层是如何让基础设施更高效地发挥算力，把算力的成本优化，使得每个单位算力能够服务更多的用户；第三层是算法本身，在算法上如何用更好的模型，甚至更节省资源的模型来提供相同甚至更高质量的服务。

骆轶航：这就像我们上午在端侧讨论的，如何用更小尺寸的模型。

许欣然：是的，在云端也有类似的问题。

骆轶航：更高性能地处理某些问题。

许欣然：我们在这三层都投入了资源和努力，但模型和算力的具体投入我们不方便公开分享。不过在基础设施方面我们乐于与大家交流，一起探讨如何提高利用率，主动分享这些内容，让大家积极来讨论。

骆轶航：在讨论的过程中，我们还想解决一个问题，我们采用了分布式架构，最初是为长文本和海量增长做准备。我们设定了一个前提，那就是并没有无限制地投入显卡和服务器资源，毕竟就算想买也不一定能买到足够的卡，服务器扩展也需要考虑成本。我理解Kimi这样的公司，资金虽然看似充裕，但实际利用在训练、推理、优秀人才招募和市场投放上的开销非常紧张。尤其是在算力这一块，假设不再扩容算力或服务器的情况下，后续是否有架构对多模态的高算力应用有效？特别是对于长文本和高并发的需求，我特别想了解，Kimi智能助手未来是否会支持多模态？如果是多模态模型，流程和逻辑上是否会有新的变化？

许欣然：事实上，部分用户可能已经注意到，Kimi具备一定的多模态能力。在Mooncake项目中，我们目前所使用的大模型具有很大的优势，它的结构非常统一。正如前面袁老师所提到的，不论是语言模型还是多模态模型，甚至其他类型的模型，整体架构是相似的。它们的输入输出格式可以抽象为“tokenin”和“tokenout”，这种架构越长的上下文越能够支持前缀越长的缓存，从而节省更多的处理时间。

骆轶航：这个架构背后是“tokenin、tokenout”的逻辑，这一逻辑在Transformer下模型的基本原理类似。最后一个问题，前面提到暂时不发论文，等技术成熟后再说，这本身是非常积极的事情。我们的分离式推理架构一经推出，引起广泛关注，大家对这篇论文的讨论非常热烈。近期对于中国厂商，尤其是优秀的AI公司，有两件特别有意义的事件引发了深入讨论，一个是我们七月份的这个论文，另一个是前两天的那件事，我认为大家对我们公开成果的兴奋有两个原因：一是大家意识到推理在未来的算力需求中占比越来越高，算力和计算资源越来越稀缺；二是这一技术确实对业界有实际帮助。请问，这个架构公开后，在社区中产生了哪些影响？虽然你们公布了方法，但没有公开源代码，接下来在开源方面会有什么计划？作为学校和企业合作的成果。

章明星：我一直在推动这件事，虽然算法方面大家可能会保留一些商业机密，但在基础设施方面，我们希望大家共同努力，降低硅基成本，在基础设施方面我们非常开放，愿意与大家合作和交流。发布后，反响比预期更热烈，尤其是很多基础设施厂商，认为这为他们指明了一个新方向。我们也乐于看到这样的结果，我们的初衷就是希望引领基础设施向这个方向发展，我们后续会在这方面做大量工作，包括和阿里、华为等基础设施厂商的合作。

骆轶航：比如华为和阿里非常愿意参与的。

章明星：他们提供标准化的基础服务，供上层应用进行推理，不论是开源模型还是其他场景，都可以通过相同的架构来降低成本。我们希望构建一个共享的生态，这是我们正在尝试的事情，第一期的开源工作已经在进行中，由于很多代码是紧耦合的状态，我们正在逐步分割，剥离一部分，开源一部分。

骆轶航：这个话题很吸引人。首先，一些云计算巨头对开源非常感兴趣，因为开源之后，能给到更多的下游公司使用。

许欣然：这类似于新时代的数据库服务，有可能发展成一种新的云服务产品，因此云厂商在这方面有非常强的动机和我们合作，也许大家可以把注意力集中在自己最擅长的部分，形成协同效应。

骆轶航：这个很有意思。月暗继续研发Kimi助手是合理的，但发布论文确实让我震惊，但效果也很好。在 infra 层面上，月暗确实为行业贡献了许多，你负责 infra 这一块，怎么看待这个问题？

许欣然：开源确实是奢侈的工作。通常那些拥有充足现金流的大公司会开源更多项目，我们开源的主要动力在于推动大家朝共同的目标前进，尤其是在大模型推理和长上下文的快速发展方向上，业界达成了一定共识。既然这个方向在加速发展，也需要大家共同合作，因此我们更愿意将一些细节贡献出来，避免重复造轮子。就像数据库领域，提到数据库就会想到MySQL，我们不希望未来出现100多种协议，各自为战且无法互通。

骆轶航：上午我们提到了AI通信协议这些问题。

许欣然：在这些层面上，我们非常乐意建立更多的合作，避免浪费时间和资源。在应用层或与应用紧密结合的 infra 层面，如何针对特定模型优化，我们可能不会开放太多，这是我们的开源策略。

骆轶航：我认为这是正确的，开源并不是将所有资源无条件提供，而是选择性地共享，留下一些独特的内容自我优化，这也是产业协同的信号。过去AI行业尤其是国内AI行业的协同还不够充分，科学家之间较劲现象比较普遍，如果有更多学者和企业联合起来共同推动这项技术，是非常好的事情。

章明星：确实需要建立标准化的生态体系，推动行业发展。公司之间虽然有利益分歧，但在某些方面达成一致对大家都有利。

骆轶航：不要等到行业成熟十多年后仍无法实现标准化，今天这个环节特别有意义。我们期待这样的技术加速开源，让更多人受益，希望未来用户使用Kimi时能享受到更长的文本支持、更高的响应效率和更智能的架构。感谢二位的分享！

点个“在看”，再走吧