长文本大模型推理实践——以KVCache为中心的分离式推理架构

长文本大模型推理实践——以KVCache为中心的分离式推理架构 演讲人：唐飞虎 月之暗面研发工程师开发者关系负责人 目录 01 长文本推理的瓶颈 02 长文本推理的优化 03 Mooncake的实践 04 上下文缓存的应用 长文本推理的瓶颈 RAG •Pros. ○无需额外训练 ○速度快 ○成本低 ○工程方案成熟 ○可设计多级检索方案 •Cros. ○Embedding召回效果直接影响模型回答效果 ○无法处理复杂逻辑 ○对多模态支持不足 Long-Context •Pros. ○无需额外训练 ○上下文兼顾更全面 ○可处理复杂逻辑和依赖 •Cros. ○贵且慢 ○长度有限 Long-Context •Pros. ○无需额外训练 ○上下文兼顾更全面 ○可处理复杂逻辑和依赖 •Cros. ○贵且慢 ○长度有限 长文本：有点贵 长文本：有点慢 Long-Context性能瓶颈 •并发性能随着上下文长度的增加而反比下降。 •预填充延迟随上下文长度的增长而呈平方级别的增长。 •解码延迟和上下文切换开销随上下文长度的增加而线性增加。 Long-Context性能瓶颈 •并发性能随着上下文长度的增加而反比下降。 •预填充延迟随上下文长度的增长而呈平方级别的增长。 •解码延迟和上下文切换开销随上下文长度的增加而线性增加。 长文本推理的优化 Long-Context推理优化 •硬件 ○A100MemoryHierarchy •机器学习工程 ○FlashAttention ○vLLM •模型架构 ○MoE ○SpeculativeDecoding Long-Context推理优化 •Layer ○ConfidentAdaptiveLanguageModeling,2022 ○CoLT5:FasterLong-RangeTransformerswithConditionalComputation,2023 ○LayerSkip:EnablingEarlyExitInferenceandSelf-SpeculativeDecoding,2024 ○YouOnlyCacheOnce:Decoder-DecoderArchitecturesforLanguageModels,2024 •Head ○GQA:TrainingGeneralizedMulti-QueryTransformerModelsfromMulti-HeadCheckpoints,2023 Long-Context推理优化 •Head ○RetrievalHeadMechanisticallyExplainsLong-ContextFactuality,2024 ○DeepSeek-V2:AStrong,Economical,andEfficientMixture-of-ExpertsLanguageModel,2024 •Hiden ○KIVI:ATuning-FreeAsymmetric2bitQuantizationforKVCache,2024 ○WKVQuant:QuantizingWeightandKey/ValueCacheforLargeLanguageModelsGainsMore,2024 Long-Context推理优化 •Token ○H2O:Heavy-HitterOracleforEfficientGenerativeInferenceofLargeLanguageModels,2023 ○ModelTellsYouWhattoDiscard:AdaptiveKVCacheCompressionforLLMs,2023 ○DynamicMemoryCompression:RetrofittingLLMsforAcceleratedInference,2024 ○SnapKV:LLMKnowsWhatYouareLookingforBeforeGeneration,2024 ○TriForce:LosslessAccelerationofLongSequenceGenerationwithHierarchicalSpeculativeDecoding,2024 Mooncake的实践 一些基本概念 •Prefill：在预填充阶段。每个新Token都取决于之前的所有的Token，但由于输入的全部内容都是已知的（Prompt），因此此阶段是一个高度并行化的矩阵操作，它能有效饱和GPU利用率。此阶段影响TTFT（timetofirsttoken）。 •Decode：在解码阶段，LLM每次自动生成一个输出标记，直到满足停止条件为止。每个顺序输出令牌都需要知道之前迭代的所有输出状态（键和值）。这就像矩阵向量运算，与预填充阶段相比，无法充分利用GPU的计算能力。数据（权重、键、值、激活状态）从内存传输到GPU的速度决定了延迟时间，而不是计算实际发生的速度。换句话说，这是一种受内存限制的操作。此阶段影响TPOT（timeperoutputtoken） Mooncake:AKVCache-centricDisaggregatedArchitectureforLLMServing 动机 •现有的LLM服务系统(e.g.vLLM)通常将Prefill和Decode阶段放在同一个 GPU上进行处理。这种做法会导致以下问题： ○TTFT和TPOT优化不可兼得：prefill通常比decode耗时更长。当在某个时刻需要做出决策到底先执行哪个阶段的时候，vLLM之前的做法是decode阶段暂停一个step，让prefill阶段先forward，这造成的问题是：TPOT增加了，反过来，即使让decode先进行，TTFT也会增加。 ○GPU资源竞争：即使prefill和decode两个阶段是被单独调度的，它们仍会竞争GPU资源，导致等待时间增加。例如，前面讲的TTFT和TPOT优化不可兼得就是这个原因优先级调度问题，到底优先调度谁？ 动机（Cont.) •现有的LLM服务系统(e.g.vLLM)通常将Prefill和Decode阶段放在同一个 GPU上进行处理。这种做法会导致以下问题： ○Prefill和Decode的瓶颈不同：前者吃算力，后者吃内存和带宽，但是目前没有算力和带宽都很牛逼的芯片，所以，用不同特点的GPU来做Prefill和Decode或许更有利于资源的利用和成本的节约。 •因为存在着GPU资源竞争、TTFT和TPOT不可兼得的问题，以及Prefill和Decode阶段瓶颈不同的现象。我们将Mooncake的设计架构是典型的分离式架构，将单个同构GPU集群的资源打散并重新组织成三个可以独立弹性伸缩的资源池——PrefillPool、DecodePool、KVCachePool。 Mooncake:AKVCache-centricDisaggregatedArchitectureforLLMServing 上下文缓存的应用 ContextCaching基本原理 公共前缀只付一次费用 成本低！响应速度快！ 公共上下文 增量输入 输出 增量输入 输出 增量输入 输出 ... ... ContextCaching使用流程 TTL CreateCache Completion 长文本大家在怎么用：角色定义/领域知识 客服 跑团游戏 字幕翻译 基础角色 Kimi客服 DM 翻译组 领域知识 培训材料+SOP文档 规则说明书 剧情说明&名词定义 用户query 用户问题 用户行为 当前字幕文本 ContextCaching收费模式* 类目 收费模式 单价 创建Cache token 24元/Mtoken 存储Cache 时长xtoken 10元/Mtoken/分钟 调用Completion 增量token调用次数 按模型原价收费0.02元/次 *：内测期间，收费细则可能会发生调整 ContextCaching收费模式* 类目 收费模式 单价 创建Cache token 24元/Mtoken 存储Cache 时长xtoken 5元/Mtoken/分钟 调用Completion 增量token调用次数 按模型原价收费0.02元/次 *：内测期间，收费细则可能会发生调整 ●每次请求Tokens：35,000； ●每次请求价格：2.1元； ●存储时长：上午9点至夜间24点，共15小时； ●存储消耗：10×(35,000÷1,000,000)×60×15＋24× (35,000÷1,000,000)＝315.84元； ●总调用次数：639次； ●调用消耗：0.02×639=12.78元； ●不使用Cache时的请求消耗：639×2.1＝1,341.9元； 最终的降本幅度为(1,341.9-(315.84+12.78))÷1,341.9＝ 75.51%，也就是说，在合理使用Cache的场合，每天能节省四分之三的费用消耗。 ●每次请求Tokens：35,000； ●每次请求价格：2.1元； ●存储时长：上午9点至夜间24点，共15小时； ●存储消耗：10×(35,000÷1,000,000)×60×15＋24× (35,000÷1,000,000)＝315.84元； ●总调用次数：639次； ●调用消耗：0.02×639=12.78元； ●不使用Cache时的请求消耗：639×2.1＝1,341.9元； 最终的降本幅度为(1,341.9-(315.84+12.78))÷1,341.9＝ 75.51%，也就是说，在合理使用Cache的场合，每天能节省四分之三的费用消耗。 ContextCaching适用场景 特别适合用于频繁请求，重复引用大量初始上下文的场景可以显著提高效率并降低费用 ContextCaching适用场景 特别适合用于频繁请求，重复引用大量初始上下文的场景可以显著提高效率并降低费用 Underrealworkloads,Mooncake’sinnovativearchitectureenablesKimitohandle75%morerequests 参考资料 •Mooncake:AKVCache-centricDisaggregatedArchitectureforLLMServing •DataEngineeringforScalingLanguageModelsto128KContext •LargeLanguageModelBasedLongContextModelingPapersandBlogs •FullStackTransformerInferenceOptimizationSeason2:DeployingLong-ContextModels 想要了解更多？欢迎加入我们的开发者社群。