网站实现语言转换技术上该怎么做,网络工程师35岁以后出路,广告买卖网,佛山新网站建设渠道最近Kimi公布了一篇Mooncake: Kimis KVCache-centric Architecture for LLM Serving的文章#xff0c;详细介绍了Kimi背后的推理架构#xff0c;因此笔者想到用Kimi解读Kimi#xff0c;梳理相关技术要点如下#xff0c;供大家参考#xff1a; 文章 Mooncake: A KVCa…最近Kimi公布了一篇Mooncake: Kimis KVCache-centric Architecture for LLM Serving的文章详细介绍了Kimi背后的推理架构因此笔者想到用Kimi解读Kimi梳理相关技术要点如下供大家参考 文章 Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving 介绍了 Mooncake 这一为大型语言模型(LLM)服务而设计的服务平台。以下是从文章中提取的技术要点、解决的问题以及提升效果的总结
解决的问题
高负载挑战Mooncake 面临由于高度超载场景带来的挑战这与传统研究不同后者假设所有请求都会得到处理134。早期拒绝策略为了缓解高负载问题开发了基于预测的早期拒绝政策13。
Mooncake 架构的核心特点
KVCache-中心化架构采用了解耦的预填充prefill和解码decoding集群以KVCache为中心进行调度和优化。资源的充分利用利用GPU集群中未充分利用的CPU、DRAM和SSD资源通过分布式KVCache实现高效的缓存机制。KVCache中心化调度程序开发了一个调度程序用以平衡整体吞吐量的最大化和满足延迟相关的服务级别目标SLOs。
架构设计动机与目标
多样化工作负载应对LLM服务中的多样化工作负载包括不同的输入/输出长度、请求到达频率和分布。优化问题作为模型即服务MaaS提供商Kimi旨在在满足不同SLOs的约束下最大化整体有效吞吐量。
架构实施细节
预填充池的实现介绍了如何实现一个独立的预填充节点池并通过分块管道并行性Chunked Pipeline Parallelism, CPP机制来处理长上下文输入。KVCache中心化请求调度算法详细描述了如何进行基于KVCache的请求调度包括自动化热点迁移方案以在不精确预测未来KVCache使用情况下复制热门KVCache块。过载导向调度讨论了在过载情况下如何决定接受或拒绝传入请求的策略包括基于预测的早期拒绝政策。
实验结果
性能提升在长上下文场景中与基线方法相比Mooncake在某些模拟场景中实现了高达525%的吞吐量增长同时遵守SLOs。实际工作负载下的表现在真实工作负载下Mooncake的架构使Kimi能够处理多75%的请求。
未来工作方向 从目前的趋势来看未来 LLM Serving 的负载会愈发的复杂和多元化。原本同等地位的请求会在厂商和用户的驱动下基于多种多样的诉求进一步分化。比如有些批处理请求可以完全不考虑 TTFT/TBT 仅仅需要保障 Job Completion Time (JCT) SLO有些高级/付费用户无疑需要保证更加可靠和更高的 SLO。另外外部基于 Agent 的任务也不仅仅看单个 request而是看整个 Workflow 的综合 SLO加上 Code Executor 等外部环境的交互后也会进一步复杂化整个系统。
异构加速器的潜力探索使用异构加速器以及新技术如存内计算Process-in-Memory或混合键合Hybrid Bonding技术。KVCache压缩算法研究减少KVCache大小的算法以提高缓存效率和吞吐量。调度策略开发考虑不同请求优先级和SLOs的高级调度政策。
相关工作
文件还讨论了其他旨在提高LLM服务效率的技术包括FasterTransformer、TensorRT-LLM、DeepSpeed Inference等并提到了Mooncake如何借鉴和区别于这些现有技术。
以上是KIMI总结的技术要点下面就Mooncake进一步展开详细内容。
Mooncake架构概览
Mooncake的架构革新在于其KVCache中心化的设计理念。这种设计允许系统将预填充(prefill)和解码(decoding)任务分配到不同的集群从而实现资源的最优分配和任务的高效处理。预填充集群负责生成模型的初始状态而解码集群则利用这些状态来处理具体的请求。
架构图示
实验表明Mooncake 在长上下文场景中表现出色。与基线方法相比Mooncake 在某些模拟场景中可以实现高达 525% 的吞吐量提升同时遵守 SLO。在实际工作负载下Mooncake 的创新架构使Kimi能够处理 75% 以上的请求。
从结构上看Mooncake由全局调度器Conductor、Prefill节点集群、Decoding节点集群和分布式KVCache池几部分组成另外还有RDMA通信组件Messenger。
其中全局调度器是用户请求到达系统后的第一站它负责接收请求并根据KV缓存分布和负载情况将请求调度到Prefill和Decoding节点。
调度器在调度时需要综合考虑KV缓存的复用长度、负载均衡等因素实现KV缓存复用的最大化。
具体到Mooncake它采用了一种启发式的自动热点迁移策略可以在不需要精确预测未来访问的情况下自动复制热点KV缓存块。
同时这种动态复制热点KV缓存块的方式也是实现均衡负载的一种重要途径。
实验结果表明与随机调度和负载均衡调度相比Mooncake的调度策略可以显著降低TTFTTime To First Token首个Token延迟提高系统性能。
Mooncake的另一个创新之处在于对GPU集群中未充分利用的资源的再利用。通过智能地分配任务到CPU、DRAM和SSDMooncake承载了 Kimi 线上80% 以上的流量不仅提升了硬件的使用效率还增强了系统的处理能力。
Mooncake的调度程序是整个架构的核心。它负责在保证服务级别目标(SLOs)的同时最大化整体有效吞吐量。调度程序采用了先进的算法来预测请求的负载并动态调整资源分配。
高负载挑战与解决方案
Mooncake 采用的解决方案就是同时综合 Prefill 和 Decode 两个集群的情况然后以两者中更高负载更危险的那个集群为去判定是否可以接受服务。由于会因为在 Prefill 集群有空闲的情况下由于未来 Decode 集群的负载问题提前拒绝一些服务这样的策略被我们称之为 Early Reject。
看起来很直接但实际部署之后我们观测到集群负载出现了奇怪的颠簸现象。可以看到 Prefill 和 Decode 集群的负载就和跷跷板一样一边上去一边下来然后交替。
在高负载情况下传统的服务架构往往会遇到性能瓶颈。Mooncake通过实时监测系统负载并评估当前的资源使用情况来识别潜在的高负载场景。
为了应对高负载带来的挑战Mooncake开发了一种基于预测的早期拒绝策略。这种策略通过预测模型来评估即将到来的请求并在系统达到临界负载之前拒绝一些请求从而避免系统过载。
性能提升的实证分析
Mooncake的性能提升在模拟场景中得到了验证。通过在不同的负载条件下测试系统Mooncake显示出了其在处理大规模请求时的卓越能力。
吞吐量图表
在实际工作负载下通过优化资源分配和调度策略Mooncake使得Kimi能够处理更多的请求同时保持了服务的稳定性和响应速度。
请求处理能力 长上下文场景的优势
在人工智能领域尤其是自然语言处理NLP中长上下文处理能力是衡量一个语言模型性能的关键指标之一。长上下文意味着模型需要理解和记忆大量的信息以便生成准确和连贯的输出。这对于诸如文档摘要、机器翻译、问答系统等应用至关重要。
应用场景示例
文档摘要自动生成长篇文章或报告的摘要。机器翻译处理包含复杂句式和专业术语的长文本。问答系统在对话中理解并引用之前的交流内容。
Mooncake的架构特别适合处理长上下文场景这得益于其高效的资源管理和调度策略。通过分离预填充和解码任务Mooncake能够为每个请求分配足够的上下文信息同时保持高性能。
由于 Prefill 和 Decode 集群负载之间的时间差如果简单的参考当前 Decode 集群负载去拒绝请求的话会导致 Decode 集群负载被消化的时候 Prefill 没有及时跟上由此产生了跷跷板效应。进一步设计和上线了基于预测的调度策略。原理也很直观能够预测未来特别是新加入的请求完成 Prefill 阶段的时刻Decode 集群负载的话自然就可以打消时间差的问题平滑整个系统的负载。
具体来说对于未来的某个时刻 t首先我们将现有的 Prefill 集群中 t 时已完成的请求加入 Decode 集群这一点可以通过预测 Prefill 时间和排队时间来实现。然后我们假设每个请求的 decode 时间均为 t_d将 Decode 集群中 t 时已结束即decode 时间超过 t_d的请求移除。这一步我们也在尝试通过预测每个请求实际会输出的 token 数做一个更精确的预测。最后我们利用事先拟合的模型根据 Decode 集群中 t 时仍在处理的请求预测 TBT作为 Decode 集群的预测负载并根据这个数据决定是否需要 Early Reject。 技术实现细节
KVCache的实现机制
整个Mooncake系统设计的核心是围绕着KV缓存展开的。KV缓存用于存储键-值对Key-Value Pairs主要优势在于可以简单高效地访问和检索数据在大模型当中可以提高推理速度并减少计算资源消耗。之所以这样做是因为团队预计KV缓存的容量会长期保持高位因此围绕KV缓存进行优化十分必要。
KVCache是Mooncake架构中的一个关键组件它负责存储和管理请求的上下文信息。KVCache的设计允许快速读写操作这对于处理长上下文请求至关重要。
在 Prefill/Decode 之外我们还利用每台 HGX 机器上组成了一个 KVCache Pool 来进行全局的 Prefix Cache。相比 vLLM 当前单机的 Prefix Cache 通过全局的调度能够大幅度提升复用率从而提升总吞吐。由此带来了一系列如何调度分配复制 KVCache 的问题而且必须和 Prefill/Decode 的调度 co-design因此我们把 Mooncake 的架构称之为以 KVCache 为中心。
在此基础上接下来我们分别讨论 Prefill/KVCache/Decode Pool 的关键 design choice。
在这个架构中每个组件都有其特定的职责通过高度模块化的设计Mooncake能够灵活地扩展和维护。Mooncake 的核心是其以 KVCache 为中心的调度程序它在最大化整体有效吞吐量和满足与延迟相关的服务级别目标 (SLO) 要求之间取得平衡。与假设所有请求都会得到处理的传统研究不同Mooncake 面临着高度超载场景带来的挑战。为了缓解这些问题我们开发了一种基于预测的早期拒绝策略。
完成调度之后任务会分别交由Prefill和Decoding节点进行运算。Prefill节点接收到调度器转发过来的请求后会从KV缓存池中读取缓存执行预计算并生成新的KV缓存。对于长上下文请求Mooncake还会分块流水并行的方式使用多个节点并行处理来降低延迟。而Decoding节点除了接收调度器发来的请求外还会收到Prefill阶段生成的KV缓存节点会对这些缓存执行解码并生成最终结果。
大容量、高性能的KV缓存存储由缓存池提供RDMA通信组件则凭借其高带宽、低延迟的优势负责在不同节点之间的KV缓存传输。除了采取以KV缓存为中心的工作流程外Mooncake还有另一个重要特点——分离式的架构。采取分离式架构的重要因素之一是在于Prefill和Decoding两个阶段的计算特性差异很大。具体来说它们分别要对TTFT和TBTTime Between TokensToken间延迟负责。这就导致了两者在计算复杂度、内存访问方式、并行粒度和对延迟的敏感度上都存在差异所以月之暗面团队对GPU集群也进行了相应的拆分以便将它们分别部署在不同节点集群上实现资源隔离和专门优化。
另外Mooncake中的KV缓存池也是分布式的同时充分利用了GPU集群中空闲的CPU、DRAM和SSD资源实现了大容量、高带宽的KV缓存存储和传输同时也减少了闲置资源的浪费。
