深入解析大模型推理架构之 Prefill-Decode Disaggregation (PD分离)
文章目录
- 深入解析大模型推理架构之 Prefill-Decode Disaggregation (PD分离)
- 1 从统一到分离,推理架构为何演进?
- 2 什么是Prefill-Decode分离?
- 3 PD分离系统的工作流程
- 4 PD分离的优势
- 5 挑战与相应的解决方案
- 6 总结与展望
1 从统一到分离,推理架构为何演进?
在标准的大型语言模型推理流程中,整个生成任务,从处理用户输入(Prompt)到逐字生成回答,通常都在同一个GPU上完成。这种统一式架构(Unified Architecture)虽然简单,但随着模型规模和并发请求量的激增,其固有的低效率问题逐渐暴露。
问题的根源在于,LLM推理的两个核心阶段——Prefill和Decode——在计算特性上存在根本性的差异:
-
Prefill (预填充) 阶段:
- 任务: 并行处理输入的整个Prompt,为其所有Token计算Key和Value,并生成初始的KV Cache。
- 特性: 这是计算密集型 (Compute-Bound) 任务。计算量巨大,涉及大量的矩阵乘法,可以充分利用GPU强大的并行计算能力(高TFLOPS)。处理一个包含512个Token的Prompt,其计算量可能相当于生成512个Decode步骤的总和。
-
Decode (解码) 阶段:
- 任务: 逐个生成输出Token。每次只处理一个Token,但需要加载整个模型权重和不断增长的KV Cache。
- 特性: 这是内存带宽密集型 (Memory-Bandwidth-Bound) 任务。单步计算量小,但需要频繁、大量地从GPU显存中读写数据。其瓶颈在于显存的带宽,而非GPU的计算核心。
关于大模型推理中的Prefill、Decode与KV Cache等概念的介绍,请参考我的这篇文章:【大模型】大模型推理中的Prefill、Decode与KV Cache详解 。
在统一式架构中,昂贵且计算能力强大的GPU在执行Decode任务时,其计算单元大部分时间处于空闲状态,等待数据从显存中加载,造成了巨大的资源浪费。反之,当GPU忙于一个长Prompt的Prefill时,其他等待Decode的短任务则必须排队,导致系统整体响应变慢。
为了解决这种资源错配和效率瓶颈,**Prefill-Decode分离(PD分离)**的思想应运而生。其核心目标是:为不同计算特性的任务匹配最合适的硬件资源,实现系统整体性能的最大化。
2 什么是Prefill-Decode分离?
Prefill-Decode分离是一种先进的LLM服务架构,它将推理过程中的Prefill和Decode两个阶段,从物理上或逻辑上调度到不同的、专门优化的硬件集群(或资源池)中执行。
一个典型的PD分离系统架构如下:
- 路由/调度器 (Router/Scheduler): 系统的“大脑”,负责接收所有请求,并根据请求类型(是新的Prompt还是正在进行的生成任务)将其分发到合适的集群。
- Prefill集群: 由少量但计算能力极强的GPU(如NVIDIA H100/H200)组成,专门用于高效地处理新请求的Prefill阶段。
- Decode集群: 由大量GPU组成,这些GPU可能算力不是最顶尖,但拥有高内存带宽(如NVIDIA A100),性价比更高,专门用于处理Decode阶段。
- KV Cache传输层: 这是连接两个集群的桥梁,通常是基于高速网络(如RDMA、NVLink)的分布式内存系统或高速网络文件系统,用于在Prefill和Decode节点之间快速传递KV Cache。
3 PD分离系统的工作流程
一个用户请求在PD分离架构中的生命周期如下:
-
请求到达与Prefill调度: 用户的新请求(包含Prompt)到达系统。调度器识别出这是一个需要Prefill的任务,并将其分配给Prefill集群中的一个空闲节点。
-
Prefill执行: Prefill节点接收到Prompt后,利用其强大的并行计算能力,对Prompt中的所有Token进行一次批处理计算,生成初始的KV Cache和响应的第一个Token。
-
KV Cache迁移 (核心步骤): Prefill任务完成后,生成的KV Cache(可能高达数GB)以及相关的请求状态信息,被迅速打包并通过高速传输层从Prefill节点发送出去。
-
Decode调度与执行: 与此同时,调度器将这个“已预处理”的请求(现在携带了KV Cache的引用或实体)分配给Decode集群中的一个可用节点。Decode节点加载这个KV Cache,然后进入自回归生成循环。在每一步,它只为新的一个Token进行计算,从显存中读取模型权重和完整的KV Cache,然后将新生成的(K,V)对追加到Cache中,并将生成的Token流式传输给用户。
-
生成结束与资源释放: 当生成过程完成(例如,模型输出了结束符
[EOS]
),结果被完整地返回给用户。Decode节点上为该请求分配的资源,特别是宝贵的KV Cache显存,被立即释放,以便服务于下一个等待中的Decode任务。
4 PD分离的优势
-
极致的资源利用率与性价比: 可以为Prefill配置少量昂贵的顶级算力卡,为Decode配置大量性价比更高的带宽型卡。硬件成本可以得到显著优化,避免了让昂贵的计算单元在Decode阶段“无所事事”。
-
更高的系统吞吐量: 解耦了Prefill和Decode的执行过程。Prefill集群可以持续不断地处理新涌入的请求(提高系统接纳新用户的能力),而Decode集群则专注于为大量并发用户快速生成后续Token。两者互不阻塞,系统整体的并发处理能力(Throughput)大幅提升。
-
灵活的扩展性 (Scalability): 可以根据业务负载的实际情况独立扩展两个集群。如果业务场景多为长篇问答(长Prompt),可以增加Prefill集群的节点;如果多为简短的聊天(长对话历史),则可以增加Decode集群的节点。
-
优化的延迟表现:
- 降低首字延迟 (TTFT): 专用的Prefill集群可以通过更大的批处理(Batching)规模,更高效地处理Prompt,从而加快第一个Token的生成速度。
- 保障字间延迟: Decode集群的专用性确保了正在生成中的任务不会被耗时长的Prefill任务抢占,从而获得稳定、快速的后续Token生成体验。
5 挑战与相应的解决方案
PD分离架构虽好,但也带来了新的技术挑战:
-
挑战1: KV Cache传输开销
- 问题: KV Cache可能非常大,在不同物理节点间传输它会引入不可忽视的延迟,可能抵消掉分离带来的部分收益。
- 解决方案:
- 硬件层面: 采用支持RDMA(远程直接内存访问)的InfiniBand或RoCE等超低延迟网络。
- 软件层面: 使用KV Cache量化,例如将FP16的Cache压缩为INT8或INT4,显著减小其体积。
- 调度层面: 设计智能调度算法,尝试将同一个长对话的连续轮次的Prefill和Decode任务调度到物理位置相近的节点上。
-
挑战2: 复杂的调度系统
- 问题: 调度器需要管理两个异构资源池,并处理任务在它们之间的状态交接,其设计和实现复杂度远高于传统调度器。
- 解决方案: 需要构建一个全局的、状态感知的调度系统。该系统不仅要监控节点负载,还要能够预测任务时长,并对KV Cache的传输进行协同调度,以实现全局最优。
-
挑战3: 资源孤岛与负载均衡
- 问题: 如果流量模式剧烈变化,可能导致一个集群(如Prefill)过载,而另一个(Decode)处于空闲,形成暂时的资源孤岛。
- 解决方案: 引入动态资源分配机制,允许部分硬件根据需要灵活地在Prefill和Decode角色之间切换。或者,采用更精准的负载预测模型来提前调整资源池大小。
6 总结与展望
Prefill-Decode分离是LLM推理系统从“作坊式”走向“工业化”的重要一步。它体现了计算体系结构中的一个经典思想:用专门化的组件处理专门化的任务。通过将Prefill的计算密集型特性与Decode的访存密集型特性解耦,并为之匹配最优化的硬件,PD分离架构能够显著提升大型语言模型服务的吞吐量、降低成本,并优化延迟。
虽然实现上存在挑战,但随着Orca、Sarathi等研究系统的提出和业界实践的深入,PD分离正逐渐成为超大规模AI计算中心的主流架构范式。未来,它还将与投机性解码(Speculative Decoding)、模型混合(MoE)等更多先进技术融合,共同推动AI普惠化的进程。