LoongServe论文解读：prefill/decode分离、弹性并行、零KV Cache迁移

最新推荐文章于 2025-05-08 16:00:00 发布
最新推荐文章于 2025-05-08 16:00:00 发布
阅读量1.1w 收藏 37
点赞数 52
分类专栏： LLM笔记 文章标签： transformer 人工智能 算法 深度学习
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_45817413/article/details/138584243
版权

LoongServe 论文解读：prefill/decode 分离、弹性并行、零 KV Cache 迁移

LoongServe: Efficiently Serving Long-context Large Language Models with Elastic Sequence Parallelism

论文提出了一种支持弹性分配的推理框架，通过引入弹性序列并行（Elastic Sequence Parallelism，简称 ESP）机制，动态地将 request 的 prefill 和 decode 阶段分配到 instance group 上。每个 group 可以根据负载的需求变化动态地 scale up 或者 scale down，并且没有 KV Cache 的迁移开销。

请添加图片描述

问题背景

Transformer LLM 推理过程分为两个阶段：prefill 和 decode。

  • prefill 阶段：将用户输入的 prompts 生成 q、k、v，存入 KV Cache（为 decode 阶段缓存）。这一步计算并行好，是计算密集型 compute bound
  • decode 阶段：由最新产生的 tokens 生成 q、k、v，计算它与之前所有 tokens 的 attention，这一步需要从 KV Cache 中读取前面所有 token 的 key、value，因此是内存密集型 memory bound。

请添加图片描述

在 long context 背景下，prefill 和 decode 阶段对计算和显存的需求非常不平衡，decode 阶段对 KV Cache 的容量需求是动态增长的、不能事先预测和分配（decode 阶段直到输出 end of sentence token 才停止）。如果把 prefill 和 decode 阶段混合部署，会造成 memory 等资源浪费，影响推理请求的吞吐量和延迟。因此，一种方法是将 prefill 和 decode 阶段分离，将 prefill 和 decode 部署在不同的 GPU 组。但是，prefill 和 decode 分离会带来新的问题：

  1. 如何细粒度地调度请求
  2. 请求从 prefill 到 decode 阶段可能需要迁移，迁移开销大
  3. GPU 组是静态划分的，无法跨组协同导致 memory 碎片（比如遇到 memory 需求很大的超长 request，哪怕所有 GPU 组的 memory 余量加起来可以满足，也无法服务）

相关工作

vLLM 提出了 Paged Attention 算法，将 attention 算法产生的连续的 key value 向量按照 block 进行组织和管理，以减少显存碎片。vLLM 还借鉴操作系统当中的虚拟内存和分页思想优化 Transformer 模型推理中产生的 KeyValue Cache，大大提高了显存当中 KV Cache 的利用效率。但 vLLM 是基于单机层面上设计，只能将 GPU 中的 block swap 到单机的内存当中。

SplitWise、DistServe 和 TetriInfer 将 prefill 和 decode 分离到不同的 GPU 组中以避免干扰，但它们的静态并行性和分区策略并不灵活，无法处理动态工作负载。

Infinite-LLM 针对 long context 场景提出分布式 DistAttention，将 KV Cache 分割成 rblock，一个 node 可以借用别的 node 上的空闲显存。但它没有做 prefill/decode 分离，并且仍然需要周期性的 KV Cache 迁移来维持局部性，并且没有考虑不同请求之间或不同阶段之间的弹性资源需求。

设计思路

论文提出一种新的并行策略：弹性序列并行（Elastic Sequence Parallelism, ESP），并构建了一个分布式的大型语言模型（LLM）服务系统——LoongServe，以充分释放 ESP 的潜力。

请添加图片描述

LoongServe 由一组弹性实例和一个 global manager 组成。这些弹性实例可以动态地将自己组织成一组不相交的 ESP（Elastic Sequence Parallelism）组，每个 ESP 组并行处理请求批次。它们还支持高效的 scale up 和 scale down，并且不需要 KV Cache 的迁移。这样，弹性实例的 GPU 内存实际上形成了一个统一的分布式 KV Cache 缓存池，可以灵活地以 token 为粒度存储请求的键值张量，减少 GPU 内存碎片。Global manager 以 iteration 为粒度动态地调度请求、调整 ESP 组和管理分布式 KV Cache 缓存池，

请添加图片描述

Sequence Parallelism

为了 ESP 组内并行地处理请求，LoongServe 采用 Sequence Parallelism。在 attention 阶段，将 tokens 分到不同的实例，每个实例：

  1. 计算自己分到的 tokens 的 q、k，计算 local attention。
  2. 将自己的 k、v 传给下一个邻居实例。
  3. 从上一个邻居实例接收到 k、v，更新 attention，将接收到的 k、v 传递给下一个邻居，直到接收到所有的 k。

请添加图片描述

下面看 LoongServe 是如何进行 ESP 组的 scale up 和 scale down 的。

Scale down

ESP 组内的计算需求下降时，可以进行 scale down，降低 DoP（degree of parallelism）。此时，需要将 KV Cache 集中到少数的实例。由于 sequence parallelism 机制，k、v 会在组间传递，实例只需要选择性地保存一部分 k、v，而不需要额外进行 KV Cache 迁移。

如下图所示，要将实例 1~3 组成的 ESP 缩成实例 1~2 时，若将 kv1~4 保存在实例 1，kv5~6 保存在实例 2，实例 1 只需要在组间传递 kv 的时候选择性地保存 kv2，实例 2 只需要选择性地保存 kv6。

请添加图片描述

Scale up

ESP 组内的计算或者显存需求上升时，可以进行 scale up，提高 DoP。此时，需要使新加入的实例可以参与并行计算。LoongServe 将 sequence parallelism 扩展到 decode 阶段，采用 multi-master distributed decoding 机制。

每一个 master 实例负责 batch 当中的某一个 request。对于一个 decode 阶段的请求来说，master 和组内其他的实例上都存储一部分 kv，master 将新 token 的 q 传给其他实例，其他实例在本地计算 attention，然后将结果汇总到 master。

除了 attention 层以外的层（例如 FFN）都在 master 本地计算，其他实例不参与。这样就达到了分布式 KV Cache 缓存池的效果，只要 master 上有空余的 memory 可以分配给自己负责的 request，就可以继续迭代。

请添加图片描述

调度算法

算法分为 dispatching, elastic instance allocation, batching 和 elastic scaling plan generation 四个部分。

  • dispatching：负责从待处理的 requests 中选择要处理的请求集合 Rp
  • elastic instance allocation：决定将 Rp 分配给哪些实例集合 Ep
  • batching：根据 Rp 和 Ep 确定每个请求的并行度（DoP）
  • elastic scaling plan generation：以 iteration 为粒度动态地规划 ESP 组的 scale up 和 scale down。

具体算法见论文第五章。

测试

请添加图片描述

大模型推理加速调研（框架、方法）
qq_33287871的博客
01-05 825
大模型推理加速的目标是高吞吐量、低延迟。吞吐量为一个系统可以并行处理的任务量。延时，指一个系统串行处理一个任务时所花费的时间。调研了一些大模型推理的框架。近年来，随着Transformer、MOE架构的提出，使得深度学习模型轻松突破上万亿规模参数，从而导致模型变得越来越大，因此，为了将大模型部署在端侧设备中，我们需要使用一些大模型压缩技术来降低模型部署的成本，并提升模型的推理性能。量化（Quantization）剪枝（Pruning）知识蒸馏（Knowledge Distillation）
VLLM专题（四十）—指标
探索人工智能革命，深入算法原理与创新应用，未来科技无限可能。
03-19 240
确保 v1 版本的 LLM 引擎暴露 v0 版本中所有可用的指标的超集。
第二章：推理加速核心：预填充（Prefill）与解码（Decode）的深度解析与实现
YPeng_Gao的博客
03-24 1641
动态 Batching 是一种提高 LLM 推理吞吐量的关键技术，尤其是在高并发的场景下。
GLM-4 (6) - KV Cache / Prefill & Decode
daihaoguang的博客
08-25 5339
KV Cache是一种为大模型量身定制的推理加速技术。为什么？因为大模型推理的逻辑是：根据当前轮输入tokens预测并输出下一个token，这两者拼接就得到了下一轮的输入，每一轮只比上一轮增加了一个token。这意味着当前轮包含了上一轮的部分计算。上一轮中每一层的key和value被当前轮复用，而不是重新计算，就能加速推理过程，这就是KV Cache的作用。随着KV Cache的广泛使用，大模型的推理被分为了Prefill和Decode两个阶段。简单来说，Prefill阶段将prompt。
为什么大语言模型推理要分成 Prefill 和 Decode？深入理解这两个阶段的真正意义
Harry的博客
04-05 1911
Prefill 阶段是语言模型推理中的第一个步骤，它负责处理你输入的所有上下文内容（prompt），为后续生成打下基础。“请解释一下 Transformer 的原理。这句话会被 tokenizer 编码为一串 token，比如["请", "解释", "一下", "Trans", "##former", "的", "原理", "。"]。然后这些 token 会进入 Transformer 模型进行前向传播。重点来了 👇。
大模型推理-基于prefill和decode阶段特性，PD分离，势在必行！
2401_84495872的博客
05-03 1013
• 服务级目标 service level objectives (SLO)：为提供一个满意的用户体验，大模型推理服务需要满足的一系列指标，一般包括首字延迟 (TTFT)，平均出词时间(TPOT)，端到端延迟(E2E)，指数移动平均(EMA)。• 首字延迟 time to first token latency (TTFT)：模型服务产生首字的延迟时间。• 平均出词时间 time per output token (TPOT)：模型服务生成单字的平均时间，生成token的总时间处于总token数量。
NLP高频面试题（十八）——什么是prefill和decoder分离架构
WeLearnNLP
03-26 2032
Prefill-Decoder 分离架构，简单来说就是将大模型推理流程中**“读取输入”和“生成输出”这两部分拆开**，各自优化、协同工作。对于模型服务厂商而言，这是在后GPT时代追求高效部署的一大创新趋势。从Moonshot Kimi的Mooncake架构可以看到，得益于这一思路，他们在实际业务中取得了显著的性能提升和成本节约。标准化与开源生态：随着Mooncake等项目开源，预填充-解码分离架构有望形成标准化方案。
打造高性能大模型推理平台之Prefill、Decode分离：微软新作SplitWise，通过将PD分离提高GPU的利用率
顺其自然~专栏
03-21 203
由上图可以看到Prefill和Decode时延都会随着token的数量增多而增多，而（c）更可以看出在E2E（end-to-end）的时延中，TTFT（Prefill阶段）时延仅占一小部分，尤其在Conversation中可以看到，只产生129个tokens所花的时间都比处理1020个Prefill的token时间多的多。可以看到这两个阶段的特征完全不同，即便使用很好的batching技术，也无法解决两个如此明显不同阶段所带来的问题，比如：由于硬件资源利用不足，使得为用户提供服务将产生更高的花费。
打造高性能大模型推理平台之Prefill、Decode分离系列（一）：微软新作SplitWise，通过将PD分离提高GPU的利用率哆啦不是梦
热门推荐
qq_32204441的博客
06-05 2万+
由上图可以看到Prefill和Decode时延都会随着token的数量增多而增多，而（c）更可以看出在E2E（end-to-end）的时延中，TTFT（Prefill阶段）时延仅占一小部分，尤其在Conversation中可以看到，只产生129个tokens所花的时间都比处理1020个Prefill的token时间多的多。可以看到这两个阶段的特征完全不同，即便使用很好的batching技术，也无法解决两个如此明显不同阶段所带来的问题，比如：由于硬件资源利用不足，使得为用户提供服务将产生更高的花费。
模型推理的Goodput指标、Prefilling和Decode阶段物理分离、DistServe
smartcat2010的博客
11-11 972
调整灵活：如果input prompt长，那就增加Prefilling的GPU数目；如果output sequence长，那就增加decoding的GPU数目；开销：KV-Cache在2个阶段的GPU之间传输。但，该开销
【论文解读】DistServe:Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Servi
coding乐园
04-30 2892
DistServe 通过分解预填充和解码计算来提高大型语言模型 (LLM) 服务的性能。现有的 LLM 服务系统将两个阶段colocate，并批量计算所有用户和请求的预填充和解码。我们发现这种策略不仅会导致强烈的预填充解码干扰，而且还会耦合两个阶段的资源分配和并行计划。LLM 应用程序通常强调每个阶段的单独延迟：预填充阶段的第一个token时间 (TTFT) 和解码阶段每个请求的每个输出token时间 (TPOT)。
deepseek大模型推理prefill/decode阶段研究分析
wangli的博客
03-18 1967
数据流向Prefill：所有输入token并行通过所有层Decode：一次只有一个新token通过所有层缓存使用Prefill：创建KV缓存Decode：利用已有KV缓存计算模式Prefill：批量处理Decode：自回归处理二、 Prefill阶段的目标与工作原理Prefill阶段的核心目标是将理解用户输入token的含义，生成输出第一个token，是后续decode阶段的首个输入。三、举例说明prefill、decode阶段在单台服务器上的物理推理模型。
高并发大模型推理服务内存优化实战：KV Cache 管理、显存调度与资源复用策略全解析
最新发布
努力分享一些人工智能相关的知识干货！
05-08 710
在大模型推理系统进入高并发部署阶段后，如何优化显存资源、提升 KV Cache 复用率、降低推理过程中长尾内存压力，成为影响系统稳定性和成本控制的关键因素。特别是在多实例、长上下文、Streaming 推理频繁的场景中，推理服务常面临 GPU 显存爆满、Cache page 溢出、OOM 崩溃等问题。本文结合 vLLM 架构与实际部署案例，深入剖析高并发推理系统中的核心内存管理策略，包括 KV Cache 分配与回收机制、Page 管理优化、批次拼接提升显存利用率，以及多模型共存下的显存隔离与负载均衡方法，
大模型分离架构学习记录
CSDN_WHB的博客
09-12 2735
GPU 网络的情况已经发生了很大变化。每个 GPU 都有自己的内部互联，例如 NVIDIA 的 A100 或 H800，它们内部的 NVLink 互联可以达到 600GB 甚至 900GB。这种内部互联与外部以太网网络集群设计之间存在耦合关系。GPU 是单机多网卡的，单机内的多张网卡之间有高速互联，单个服务器的带宽可以达到 3.2T，与通用 CPU 计算带宽相比至少有 6 到 8 倍的关系。GPU 需要使用 GPU Direct RDMA 来实现显存之间的数据迁移，并且需要超短的 RTT（往返时延）。
一起理解下LLM的推理流程
python12345_的博客
10-23 1266
本文来源自Pytorch Conference 2024的talking ——本文总结和整理下其描述的基于TRT-LLM的LLM推理流程。以下是简单的LLM推理流程（下图中输入 Write me a presentation…prefill推理阶段，一开始需要输入文本转换为token id，需要依赖Tokenization：但实际LLM模型中最终拿到的是embedding向量：分词过程，由于“smart”和“smarter”是不同的单词，分词器会为它们生成不同的token ID，即使它们看起来很相似。
LLM 推理框架之上：10 中常见 LLM 推理系统总结
python122_的博客
06-13 1832
在 [2302.11665] AlpaServe: Statistical Multiplexing with Model Parallelism for Deep Learning Serving 中，作者证明了当为多个模型提供服务时，即使单个模型可以放置在单个设备上，模型并行性也可以额外用于多个设备的统计多路复用。文中作者也探索了模型并行性引入的开销与利用统计多路复用来减少存在突发工作负载时的服务延迟之间的权衡。
理解 LLM 推理过程
MengyuyangEddy的博客
04-11 8566
参考重复这两个步骤直到生成 EOS token 或达到用户设定的停止条件（stop token 或最大 token 数）。让我们以 Llama2-7B（4096 序列长度，float16精度）为例，计算一下 batch_size = 1的理想推理速度。
【大模型】大模型相关技术研究，资料整理
yuuuuuuuk的博客
07-06 1411
大模型推理性能优化的一个常用技术是KV Cache，该技术可以在不影响任何计算精度的前提下，通过空间换时间思想，提高推理性能。 生成式generative模型的推理过程很有特点，我们给一个输入文本，模型会输出一个回答（长度为N），其实该过程中执行了N次推理过程。即GPT类模型一次推理只输出一个token，输出token会与输入tokens 拼接在一起，然后作为下一次推理的输入，这样不断反复直到遇到终止符。 其实，KV Cache 配置开启后，推理过程可以分为2个阶段： 1、预填充阶段：发生在计算第一个输出t
大模型 Prefill & Decode
03-13
### 大模型中的Prefill与Decode过程 #### Prefill 过程 在大模型处理输入序列时，Prefill 阶段负责初始化计算环境并执行初步的前向传播操作。此阶段的主要任务是对给定提示词（Prompt）进行编码，并生成初始隐藏状态表示。具体来说： - 对于每一个新请求，系统会先加载预训练好的权重参数。 - 接着将用户提供的文本转换成对应的token ID列表形式。 - 使用Transformer架构下的自注意力机制来捕捉上下文依赖关系[^1]。 ```python def prefill(prompt_tokens, model_weights): hidden_states = initialize_hidden_state(model_weights) attention_outputs = apply_self_attention(hidden_states, prompt_tokens) return attention_outputs ``` #### Decode 过程 当完成Prefill之后进入Decode环节，在这个过程中主要关注如何高效地逐个生成后续Token直到满足特定条件为止。为了加速解码速度通常采用如下策略： - 缓存已计算过的Key/Value矩阵以减少重复运算量。 - 利用Vulkan或CUDA等硬件特性来进行批量并行化处理。 - 实施Beam Search算法提高最终输出的质量而非单纯贪心选取最高概率项[^3]。 ```python def decode(current_token_id, cached_kv_matrices, beam_width=5): next_probabilities = compute_next_token_probs( current_token_id, cached_kv_matrices ) top_k_candidates = select_top_k(next_probabilities, k=beam_width) best_sequence = find_best_path(top_k_candidates) return best_sequence ``` 通过上述方法可以在保持较高精度的同时显著提升推理效率，使得大规模语言模型能够更加实时响应用户的查询需求[^2]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值