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

月之暗面研发工程师开发者关系负责人 目录 01长文本推理的瓶颈 02长文本推理的优化 04上下文缓存的应用 03 Mooncake的实践 长文本推理的瓶颈 RAG ○无需额外训练○速度快○成本低○工程方案成熟○可设计多级检索方案 ○Embedding召回效果直接影响模型回答效果○无法处理复杂逻辑○对多模态支持不足 Long-Context ○无需额外训练○上下文兼顾更全面○可处理复杂逻辑和依赖 ○贵且慢○长度有限 Long-Context ○无需额外训练○上下文兼顾更全面○可处理复杂逻辑和依赖 ○贵且慢○长度有限 长文本：有点贵 Long-Context性能瓶颈 •并发性能随着上下文长度的增加而反比下降。•预填充延迟随上下文长度的增长而呈平方级别的增长。•解码延迟和上下文切换开销随上下文长度的增加而线性增加。 Long-Context性能瓶颈 •并发性能随着上下文长度的增加而反比下降。•预填充延迟随上下文长度的增长而呈平方级别的增长。•解码延迟和上下文切换开销随上下文长度的增加而线性增加。 长文本推理的优化 Long-Context推理优化 •硬件○A100 Memory Hierarchy•机器学习工程○FlashAttention○vLLM•模型架构○MoE○Speculative Decoding Long-Context推理优化 ○Confident Adaptive Language Modeling, 2022○CoLT5: Faster Long-Range Transformers with ConditionalComputation, 2023○LayerSkip: Enabling Early Exit Inference and Self-SpeculativeDecoding, 2024○You Only Cache Once: Decoder-Decoder Architectures forLanguage Models, 2024 •Head○GQA: Training Generalized Multi-Query Transformer Modelsfrom Multi-Head Checkpoints, 2023 Long-Context推理优化 ○Retrieval Head Mechanistically Explains Long-ContextFactuality, 2024○DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model, 2024 ○KIVI: A Tuning-Free Asymmetric 2bit Quantization for KVCache, 2024○WKVQuant: Quantizing Weight and Key/Value Cache forLarge Language Models Gains More, 2024 Long-Context推理优化 ○H2O: Heavy-Hitter Oracle for Efficient Generative Inference ofLarge Language Models, 2023○Model Tells You What to Discard: Adaptive KV CacheCompression for LLMs, 2023○Dynamic Memory Compression: Retrofitting LLMs forAccelerated Inference, 2024○SnapKV: LLM Knows What You are Looking for BeforeGeneration, 2024○TriForce: Lossless Acceleration of Long Sequence Generationwith Hierarchical Speculative Decoding, 2024 Mooncake的实践 一些基本概念 •Prefill：在预填充阶段。每个新Token都取决于之前的所有的Token，但由于输入的全部内容都是已知的（Prompt），因此此阶段是一个高度并行化的矩阵操作，它能有效饱和GPU利用率。此阶段影响TTFT（time to first token）。 •Decode：在解码阶段，LLM每次自动生成一个输出标记，直到满足停止条件为止。每个顺序输出令牌都需要知道之前迭代的所有输出状态（键和值）。这就像矩阵向量运算，与预填充阶段相比，无法充分利用GPU的计算能力。数据（权重、键、值、激活状态）从内存传输到GPU的速度决定了延迟时间，而不是计算实际发生的速度。换句话说，这是一种受内存限制的操作。此阶段影响TPOT（time per output token） Mooncake: A KVCache-centric DisaggregatedArchitecture for LLM Serving 动机 •现有的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集群的资源打散并重新组织成三个可以独立弹性伸缩的资源池——Prefill Pool、Decode Pool、KVCache Pool。 Mooncake: A KVCache-centric DisaggregatedArchitecture for LLM Serving 上下文缓存的应用 ●每次请求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的场合，每天能节省四分之三的费用消耗。 Context Caching适用场景 特别适合用于频繁请求，重复引用大量初始上下文的场景可以显著提高效率并降低费用 Context Caching适用场景 特别适合用于频繁请求，重复引用大量初始上下文的场景可以显著提高效率并降低费用 Under real workloads,Mooncake’s innovative architecture enablesKimito handle75%more requests 参考资料 •Mooncake: A KVCache-centric Disaggregated Architecture for LLMServing•Data Engineering for Scaling Language Models to 128K Context•Large Language Model Based Long Context Modeling Papers andBlogs•Full Stack Transformer Inference Optimization Season 2: DeployingLong-Context Models 想要了解更多？欢迎加入我们的开发者社群。