大模型推理PD解耦实战：DistServe架构设计与首字延迟优化

1. 大模型推理的算力困局与PD解耦的破局思路做过大模型推理服务的人都有一个共同的痛你明明买了一批很贵的加速卡部署了一个看起来参数很漂亮的推理集群结果上线之后发现首字延迟忽高忽低吞吐量怎么调都上不去GPU利用率长期在40%到60%之间晃荡。更让人头疼的是你调了一个参数首字延迟好看了吞吐又掉下去了你把吞吐拉上来首字延迟又炸了。这种按下葫芦浮起瓢的困境根子不在你的调参水平而在于传统推理架构把两个本质冲突的计算阶段硬绑在了一起。这两个阶段就是Prefill预填充和Decode解码。Prefill阶段处理的是用户输入的完整prompt一次性对所有输入token做注意力计算这个阶段是计算密集型的矩阵乘法占绝对主导GPU的算力单元被拉满但显存带宽相对空闲。Decode阶段则是自回归地一个token一个token往外蹦每生成一个token都要重新做一次注意力计算这个阶段是访存密集型的算力单元大量闲置显存带宽成为瓶颈。把这两个性格完全相反的家伙塞进同一个GPU上跑就像让一个举重运动员和一个绣花匠共用一张工作台谁都不舒服。DistServe这个工作之所以值得单独拿出来聊就是因为它把这件事想透了既然Prefill和Decode的计算特征、资源需求、优化目标都不一样那为什么非要绑在一起拆开物理隔离各跑各的。这个思路听起来简单但真正落地需要解决一连串工程问题——拆开之后资源怎么分配、请求怎么调度、KV Cache怎么传输、延迟怎么保证。DistServe给出了一套完整的答案而且实测数据相当能打在同等延迟约束下吞吐提升数倍首字延迟降低80%这个量级。这篇文章我会从架构设计、核心机制、实操部署、调优经验几个维度把PD解耦这件事掰开揉碎讲清楚。不管你是正在做推理服务优化的工程师还是准备搭建自己的推理集群这套思路和落地方法都值得你花时间研究。下面我按自己的理解把DistServe的核心设计和实操要点完整梳理一遍。2. 传统推理架构为什么会被算力干扰拖垮2.1 Prefill和Decode的计算特征差异到底有多大要理解PD解耦的价值首先得把Prefill和Decode这两个阶段的差异量化清楚。我用一个具体的例子来说明假设你部署的是一个大语言模型输入prompt长度512个token输出长度也是512个tokenbatch size设为16。Prefill阶段16个请求的512个token一次性送进模型每一层都要做完整的注意力计算。这个过程中输入矩阵的维度是[16, 512, hidden_dim]注意力计算涉及大量的矩阵乘矩阵操作计算量正比于序列长度的平方。GPU的Tensor Core在这个阶段利用率可以跑到很高因为矩阵乘法的并行度足够大。但这个时候KV Cache的写入量相对有限显存带宽不是瓶颈。Decode阶段就完全反过来了。每生成一个token16个请求各生成1个token输入矩阵维度变成[16, 1, hidden_dim]。矩阵乘矩阵退化成矩阵乘向量Tensor Core的利用率急剧下降大量算力单元空转。但每一步都要读取之前所有token的KV Cache显存带宽被吃满。这就是为什么Decode阶段GPU利用率看起来很低但速度就是上不去——瓶颈根本不在算力在访存。我把这两个阶段的核心特征整理成一张表方便对照特征维度Prefill阶段Decode阶段计算模式矩阵乘矩阵并行度高矩阵乘向量并行度低瓶颈资源算力单元Tensor Core显存带宽GPU利用率高可达70%以上低常低于30%延迟特征一次性完成延迟可控逐token生成延迟累积对batch敏感度高batch越大越划算低batch增大收益递减KV Cache操作写入为主读取为主这张表里的每一行都在说明同一件事这两个阶段对硬件资源的需求是错位的。Prefill饿的是算力Decode饿的是带宽。你把它们放一起算力被Decode拖累带宽被Prefill挤占两头不讨好。2.2 混部带来的算力干扰是怎么发生的混部的问题不只是资源错位这么简单更严重的是干扰。我举个实际场景一个推理服务同时收到两类请求一类是长prompt短输出的比如文档摘要一类是短prompt长输出的比如对话生成。前者Prefill阶段很重后者Decode阶段很长。在混部架构下这两类请求被调度到同一批GPU上。当一个长prompt请求正在做Prefill时它占满了算力单元同批次里正在做Decode的请求只能排队等。反过来当大量Decode请求在逐token生成时它们持续占用显存带宽新来的Prefill请求即使算力空闲也跑不快因为带宽被抢了。这种干扰在监控指标上表现为首字延迟TTFT的P99值远高于P50值而且波动极大。你去看GPU利用率曲线会发现它在一个不高不低的区间里反复震荡既没有跑满算力也没有跑满带宽。这就是典型的互相拖后腿。更麻烦的是这种干扰会随着负载变化而动态加剧。低负载时大家相安无事一旦并发上来Prefill和Decode开始抢资源延迟指标就崩了。你很难通过静态调参解决这个问题因为干扰程度本身是动态的。2.3 PD解耦的核心逻辑让专业的卡干专业的事DistServe的思路很直接既然干扰来自混部那就物理隔离。把集群里的GPU分成两组一组专门跑Prefill叫Prefill实例一组专门跑Decode叫Decode实例。请求进来先经过调度器Prefill实例处理完输入后把生成的KV Cache传给Decode实例Decode实例接着逐token生成输出。这样做的好处是立竿见影的。Prefill实例可以针对算力密集型任务做优化用更大的batch、更高的并行度、更激进的算子融合。Decode实例则针对访存密集型任务优化用更高效的KV Cache管理、更大的batch来摊薄访存开销、更精细的显存布局。而且两组实例的资源配比可以独立调整。如果你的业务以长输入为主就多配Prefill实例如果以长输出为主就多配Decode实例。这种灵活性在混部架构下是不敢想的。当然拆开也引入了新问题KV Cache怎么从Prefill实例传到Decode实例传输延迟会不会抵消掉解耦带来的收益资源配比怎么定才最优这些问题DistServe都给出了工程上可落地的方案我后面会逐一拆解。3. DistServe核心机制拆解与关键设计3.1 资源分配Prefill和Decode实例怎么配比资源配比是PD解耦第一个要回答的问题。配多了Prefill实例Decode那边排队配少了Prefill实例首字延迟上去了。DistServe的做法不是拍脑袋定一个固定比例而是根据延迟约束和负载特征来动态计算。具体来说它把优化目标拆成两个约束首字延迟TTFT必须低于某个阈值单token生成延迟TPOT必须低于某个阈值。在这两个约束下最大化整体吞吐。然后通过一个资源分配算法算出Prefill实例和Decode实例各自需要多少GPU。这个算法的核心逻辑是先估算单个Prefill实例在给定batch下的TTFT以及单个Decode实例在给定batch下的TPOT然后反推满足约束所需的最小实例数。实际部署时你可以先跑一轮基准测试拿到单实例的性能曲线再代入算法算配比。我自己的经验是对于输入输出长度比较均衡的场景比如输入输出各512 tokenPrefill和Decode的GPU配比大概在1:2到1:3之间比较常见。如果输入特别长比如4K以上Prefill那边要多配一些如果输出特别长比如2K以上Decode那边要多配。这个比例不是固定的一定要根据自己的实际流量分布来调。3.2 KV Cache传输解耦架构的最大工程挑战PD解耦之后Prefill实例算完的KV Cache必须传给Decode实例。这个传输过程如果做得不好延迟会直接吃掉解耦的收益。DistServe在这块做了几个关键设计。首先是传输时机。KV Cache不是等整个Prefill全部算完才传而是分层传输。Transformer每一层算完KV Cache就可以开始传这样传输和计算可以重叠隐藏掉大部分传输延迟。这个设计很关键如果等全部算完再传那传输延迟就是纯增加的。其次是传输通道。DistServe支持通过高速互联比如NVLink、InfiniBand传输也支持通过PCIe传输。如果Prefill和Decode实例在同一节点内走NVLink最快跨节点的话走RDMA网络。传输带宽直接决定了KV Cache传输能不能被计算掩盖住。第三是KV Cache的布局优化。传输前会对KV Cache做压缩和重排减少传输量。比如把多个请求的KV Cache打包成一个大块传输比逐个请求传效率高很多。注意KV Cache传输是PD解耦架构里最容易出问题的地方。如果你的集群网络带宽不够或者Prefill和Decode实例之间的拓扑距离太远传输延迟可能高达几十毫秒直接把首字延迟的优势抵消掉。部署前一定要实测传输带宽和延迟。3.3 请求调度怎么保证两组实例都不闲着拆成两组实例后调度器的工作变复杂了。它要同时考虑Prefill实例的负载和Decode实例的负载还要保证请求在两组之间的流转不出现瓶颈。DistServe的调度策略核心是解耦调度Prefill实例和Decode实例各自独立调度中间通过一个KV Cache队列衔接。请求先进入Prefill队列被Prefill实例处理后KV Cache进入传输队列然后进入Decode队列等待生成。这种设计的好处是两组实例可以各自做batch不用互相等待。Prefill实例可以攒一批请求一起做PrefillDecode实例也可以攒一批KV Cache一起做Decode。batch效率比混部架构高很多。但这里有个细节要注意Decode实例的batch不能无限攒因为每个请求的KV Cache大小不一样攒太多会爆显存。DistServe的做法是给Decode实例设一个显存水位线超过就停止接收新请求。这个水位线要根据模型大小和显存容量仔细调调低了浪费算力调高了容易OOM。3.4 延迟保证SLO约束下的吞吐最大化DistServe的最终目标是在满足延迟SLO的前提下最大化吞吐。这个目标听起来简单但实现起来需要一套精细的控制机制。它把延迟SLO拆成两个硬约束TTFT P99小于某个值TPOT P99小于某个值。然后在调度时对每个请求预估它的TTFT和TPOT如果预估会超就调整batch大小或者排队策略。具体做法是Prefill实例维护一个动态batchbatch大小根据当前队列长度和TTFT约束反推。队列长就减小batch保证延迟队列短就增大batch提升吞吐。Decode实例类似根据TPOT约束调整同时处理的请求数。这套机制的效果是在负载波动时延迟指标能稳定在SLO附近不会出现混部架构下那种延迟忽高忽低的情况。我实测下来DistServe在P99延迟上的稳定性确实比混部好很多这对线上服务来说太重要了。4. 实操部署从零搭建PD解耦推理服务4.1 环境准备与依赖检查动手之前先把环境理清楚。PD解耦架构对硬件和软件都有一些额外要求提前检查能省很多事。硬件方面你需要至少两组GPU实例。Prefill实例和Decode实例可以是同型号卡也可以是不同型号。如果预算允许Prefill实例用算力强的卡比如高算力型号Decode实例用显存带宽大的卡这样能各自发挥优势。两组实例之间要有高速网络连接同节点内最好跨节点的话RDMA网络是必须的。软件方面需要确认几件事推理框架是否支持PD分离部署DistServe本身是基于主流推理框架做的扩展KV Cache传输层是否就绪调度器是否支持解耦调度。这些组件缺一不可。我列一个部署前的检查清单GPU驱动和CUDA版本是否满足推理框架要求两组实例之间的网络带宽实测是否达标建议至少25Gbps以上推理框架是否编译了PD分离相关模块KV Cache传输服务是否已部署并连通调度器配置文件中Prefill和Decode实例的地址是否正确监控系统是否能采集两组实例的独立指标提示网络带宽这一项一定要实测不要看标称值。用实际大小的KV Cache做传输测试看P99传输延迟是多少。如果超过5ms就要考虑优化网络拓扑或者调整实例部署位置。4.2 实例配置与参数设置环境就绪后开始配置实例。Prefill实例和Decode实例的配置参数差异很大不能照搬。Prefill实例的关键参数# Prefill实例启动参数示例 --role prefill --max-batch-size 32 # Prefill batch可以设大算力密集 --max-seq-len 4096 # 根据实际prompt长度上限设 --kv-cache-dtype fp16 # KV Cache精度fp16平衡精度和传输量 --transfer-backend rdma # 传输后端同节点可用nvlink --transfer-chunk-size 64 # 传输分块大小单位MBDecode实例的关键参数# Decode实例启动参数示例 --role decode --max-batch-size 128 # Decode batch可以更大摊薄访存 --max-seq-len 4096 --kv-cache-dtype fp16 --memory-watermark 0.85 # 显存水位线超过停止接收新请求 --scheduling-policy fcfs # 调度策略fcfs或priority这里有几个参数需要重点解释。max-batch-size在Prefill和Decode上取值逻辑不同Prefill的batch受算力约束太大会导致TTFT超标Decode的batch受显存约束太大会OOM。我一般先设一个保守值压测后逐步往上调。kv-cache-dtype这个参数直接影响传输量。fp16比fp32传输量减半精度损失在大多数场景下可接受。如果对精度要求极高可以用bf16传输量和fp16一样但动态范围更大。memory-watermark是Decode实例的保命参数。设0.85意味着显存用到85%就停止接收新请求留15%缓冲防止突发。这个值设太低浪费显存设太高容易OOM建议从0.8开始调。4.3 启动流程与连通性验证配置写好后按顺序启动各个组件。顺序很重要先起传输层再起Decode实例最后起Prefill实例和调度器。第一步启动KV Cache传输服务。这个服务负责在Prefill和Decode实例之间搬运KV Cache。启动后检查监听端口是否正常。第二步启动Decode实例。Decode实例启动后会向传输服务注册自己等待接收KV Cache。启动后检查日志里有没有注册成功的记录。第三步启动Prefill实例。同样会向传输服务注册。这时候传输服务应该能看到两组实例都在线。第四步启动调度器。调度器需要配置Prefill和Decode实例的地址列表启动后检查它是否能正确发现两组实例。连通性验证我一般做三层第一层是网络层用ping和带宽测试工具确认两组实例之间网络通第二层是服务层用传输服务的健康检查接口确认服务正常第三层是端到端发一个测试请求看它能不能走完Prefill到Decode的完整流程。# 发送测试请求验证端到端连通 curl -X POST http://scheduler-address/generate \ -H Content-Type: application/json \ -d {prompt: 测试PD解耦链路, max_tokens: 32}如果返回正常结果说明链路通了。如果卡住或者报错按传输层、Decode实例、Prefill实例的顺序逐个排查。4.4 压测与性能基线建立链路通了之后别急着上生产先做压测建立性能基线。压测的目的是搞清楚在你的硬件配置下TTFT和TPOT随负载变化的曲线以及系统的吞吐上限。压测工具可以用常见的推理压测框架关键是控制好两个变量并发请求数和输入输出长度分布。我一般分几轮压测低并发看延迟下限中并发看延迟拐点高并发看吞吐上限和延迟崩溃点。压测时要同时采集两组实例的指标。Prefill实例重点看TTFT、batch利用率、算力利用率Decode实例重点看TPOT、显存占用、带宽利用率。传输层重点看传输延迟和传输量。拿到数据后画出TTFT和TPOT随并发变化的曲线。你会看到在某个并发点之前延迟基本平稳超过这个点之后延迟开始快速上升。这个拐点就是你的系统容量上限。生产部署时把负载控制在拐点的70%到80%留出突发余量。5. 调优实战把首字延迟压到极致5.1 首字延迟的构成与优化切入点首字延迟TTFT是PD解耦架构最核心的优化目标也是标题里骤降80%的来源。要优化它先得搞清楚它由哪几部分组成。TTFT 请求排队时间 Prefill计算时间 KV Cache传输时间 Decode首token生成时间这四项里排队时间和Prefill计算时间是大头传输时间和首token生成时间相对小。优化要抓大头。排队时间取决于Prefill实例的调度策略和batch大小。batch太大排队时间长batch太小算力浪费。DistServe的动态batch机制就是在这两者之间找平衡。Prefill计算时间取决于模型大小、序列长度和算力利用率。这部分优化空间在于算子融合、并行策略、精度选择。比如用FlashAttention替代标准注意力能显著降低Prefill时间。KV Cache传输时间取决于传输量和带宽。传输量跟序列长度和层数成正比带宽取决于网络。优化方向是压缩KV Cache和提升带宽利用率。Decode首token生成时间相对固定优化空间不大但可以通过预取和流水线隐藏掉一部分。5.2 动态batch调优找到延迟和吞吐的平衡点动态batch是DistServe最实用的调优手段。它的逻辑是根据当前队列长度动态调整Prefill的batch大小队列长就减小batch保证延迟队列短就增大batch提升吞吐。调这个参数需要理解一个权衡batch越大单个请求的Prefill计算时间越长因为要等batch里其他请求一起算但单位算力的吞吐越高。batch越小延迟越低但算力利用率下降。我一般这样调先设一个较大的max-batch-size然后观察TTFT P99。如果P99超过SLO就逐步减小batch直到P99达标。然后再看吞吐如果吞吐还有余量可以尝试微调batch往上走一点找到延迟刚好达标、吞吐最大的那个点。这里有个经验值可以参考对于7B到13B的模型Prefill batch在16到32之间通常能找到不错的平衡对于70B以上的大模型batch要小一些8到16比较常见。当然这跟硬件强相关一定要实测。5.3 KV Cache传输优化把传输延迟藏起来KV Cache传输是PD解耦特有的开销优化它的核心思路是让传输和计算重叠把传输延迟藏到计算后面。DistServe的分层传输机制就是干这个的。Transformer每一层算完KV Cache就立即开始传同时下一层的计算继续进行。只要传输速度跟得上计算速度传输延迟就被完全隐藏了。要做到这一点传输带宽必须足够。我算过一笔账假设模型有80层每层KV Cache大小是2MB总传输量160MB。如果Prefill计算时间是50ms那传输带宽至少要160MB/50ms 3.2GB/s才能完全隐藏。换算成网络带宽大概是25Gbps。所以前面说网络至少25Gbps起步就是这个原因。如果带宽不够传输藏不住就要考虑压缩KV Cache。常用的压缩方法有量化fp16转int8传输量减半和稀疏化丢弃不重要的KV对。量化实现简单精度损失可控我一般优先用量化。注意KV Cache量化会影响生成质量尤其是长文本生成。上线前一定要做质量评估对比量化前后的输出差异。如果质量下降明显宁可加带宽也不要硬压。5.4 资源配比动态调整跟着流量走生产环境的流量不是恒定的白天和晚上不一样工作日和周末不一样。固定的Prefill/Decode配比很难一直保持最优。DistServe支持资源配比的动态调整但实现方式不是实时切换GPU角色那太慢了而是通过调度器控制请求流向。当Prefill实例负载高时调度器把部分请求导向备用Prefill实例当Decode实例负载高时类似处理。更实用的做法是按时间段预设配比。比如根据历史流量白天配1:2晚上配1:3。通过配置管理工具定时切换。这种方式实现简单效果也不错。如果流量波动特别大可以考虑弹性伸缩监控两组实例的队列长度队列持续超过阈值就扩容持续低于阈值就缩容。扩容缩容的粒度可以是单实例也可以是实例组。这块需要跟容器编排系统配合实现起来复杂一些但长期看能省不少成本。6. 常见问题排查与避坑经验6.1 首字延迟不降反升的排查思路PD解耦理论上应该降低首字延迟但如果你部署完发现延迟反而高了别慌按下面的顺序排查。第一检查KV Cache传输延迟。这是最常见的原因。用传输层的监控看P99传输延迟如果超过10ms基本就是它的问题。解决办法是优化网络拓扑把Prefill和Decode实例部署得更近或者升级网络带宽。第二检查Prefill实例的batch设置。如果batch设得太大排队时间会吃掉解耦的收益。试着减小batch看TTFT是否改善。第三检查调度器配置。如果调度器把请求错误地路由到了负载高的实例延迟也会高。检查调度策略和实例权重配置。第四检查Decode实例的显存水位。如果水位设得太高Decode实例频繁触发停止接收KV Cache在传输队列里堆积间接影响TTFT。我整理了一个排查速查表现象可能原因排查方法解决方向TTFT P99高传输延迟大看传输层P99指标优化网络或压缩KV CacheTTFT波动大batch设置不当看batch大小和队列长度调小batch或启用动态batchTTFT逐渐升高Decode实例过载看Decode队列长度增加Decode实例或降低水位TTFT偶发尖刺调度不均看各实例负载分布调整调度策略6.2 Decode实例OOM的预防与处理Decode实例OOM是PD解耦部署里第二常见的问题。原因是Decode实例要同时持有多个请求的KV Cache请求一多显存就爆。预防措施有三个。第一设好memory-watermark留足缓冲。第二限制Decode实例的最大并发请求数超过就排队。第三监控显存增长趋势提前扩容。如果已经OOM了先看日志确认是哪个请求导致的。如果是单个超长请求可以考虑给它单独限流。如果是并发太高就降低最大并发数或者加实例。这里有个坑要注意OOM之后Decode实例可能不会自动恢复需要重启。所以生产环境一定要配健康检查和自动重启。另外OOM时正在处理的请求会丢失如果业务不能接受丢请求就要做请求重试或者持久化。6.3 传输层故障的应急方案传输层是PD解耦架构的单点它挂了整个链路就断了。应急方案要提前准备好。第一传输层要做高可用。至少部署两个传输服务实例用负载均衡分发。一个挂了另一个顶上。第二要有降级方案。传输层完全不可用时能不能临时切回混部模式这需要推理框架支持动态切换角色。如果支持配一个降级开关出问题时一键切换。第三监控要到位。传输层的队列长度、传输延迟、错误率都要监控设好告警阈值。我一般设传输延迟P99超过20ms就告警错误率超过1%就告警。第四定期演练。每季度做一次传输层故障演练验证降级方案是否有效。别等到真出问题了才发现降级开关是坏的。6.4 性能调优的独家经验最后分享几个我在实际调优中总结的经验都是文档里不会写的。经验一Prefill实例的算力利用率比batch大小更重要。很多人盯着batch调其实算力利用率才是关键。如果算力利用率上不去batch再大也没用。检查算子融合是否生效检查是否有不必要的同步操作。经验二Decode实例的瓶颈往往在显存带宽而不是容量。显存够用不代表性能好带宽才是Decode的命门。选卡时优先看带宽参数容量够用就行。经验三KV Cache传输的块大小要调。传输块太小传输次数多开销大块太大单次传输延迟高。我实测下来64MB到128MB的块大小比较平衡具体值要压测确定。经验四监控要分角色看。Prefill和Decode的指标要分开监控混在一起看会误导判断。比如GPU利用率Prefill高是好事Decode高反而可能说明batch太小。经验五压测要用真实流量分布。用固定长度的请求压测会得到过于乐观的结果。真实流量里输入输出长度是变化的这种变化会显著影响性能。压测时要用真实流量的长度分布。这套PD解耦架构我从测试到上线跑了几个月最大的体会是它不是一个开箱即用的方案需要根据你的硬件、模型、流量做不少调优。但一旦调好收益是实打实的。首字延迟降下来之后用户体验的提升非常明显尤其是对交互式应用来说首字延迟从几百毫秒降到几十毫秒感觉完全不一样。如果你也在为推理延迟发愁PD解耦这条路值得认真走一遍。