PD分离这四个字最近在LLM推理圈里出现的频率有多高不用我多说。如果你同时跑过prefill和decode阶段的任务应该能明显感受到那种拧巴感prefill阶段GPU利用率能冲到90%以上一到decode阶段计算单元大量空转、显存带宽吃紧。vLLM从0.6.x开始把PD分离Prefill-Decode Disaggregation预填充与解码分离作为重点能力推进到了0.8.x之后已经可以直接在生产环境尝试。这篇文章就围绕PD分离聊聊它到底解决什么问题、怎么部署、有哪些需要注意的坑。本文主要面向有vLLM基础使用经验的工程师也适合正在调研大模型推理优化方案的朋友。1. 什么是PD分离先搞清楚它在解决什么难题1.1 Prefill与Decode的天然矛盾LLM推理的请求处理天然分成两个阶段prefill负责把用户输入的prompt并行算一遍生成第一批KV Cache和第一个tokendecode阶段则拿着KV Cache逐token生成后续内容。这两个阶段的计算特征、资源需求完全不是一回事直接对比一下维度Prefill阶段Decode阶段计算类型高度并行的矩阵乘适合GPU并行串行逐token生成访存受限关键瓶颈算力FLOPs显存带宽和KV Cache读取速度响应指标TTFT首token延迟TPOT每token生成时间KV Cache角色生产方按整个prompt长度一次性生成消费方每步追加一个token受并发影响并发越多算力竞争越激烈主要受KV Cache内存带宽影响这两者放在同一张GPU上就产生了调度上的天然矛盾。prefill喜欢一次吃下大量计算decode却希望GPU每个时刻都快速响应小批量访存。你让同一个工作进程在这两种状态之间来回切换性能不可能稳定。1.2 混合部署为什么在长上下文场景下失控很多人判断一个推理框架好不好用习惯性只用吞吐量说话。但在生产环境里长prompt请求把整个服务拖垮的问题远比单请求吞吐更棘手。我见过一个实际案例8卡A800跑一个72B模型在线服务给多个业务方共用。某业务方突然请求一个包含几十页文档的长上下文输入prefill计算量很大GPU在那一瞬间几乎全被这个请求占满。其他正在decode的请求立刻开始排队TTFT瞬间从几百毫秒飙到好几秒用户端直接感知到卡顿。这就是混合部署的典型失控场景长上下文请求的出现相当于在繁忙的decode流水线里突然插入一个重计算任务。GPU算力、显存带宽、KV Cache缓冲区全部被抢占导致所有请求的尾延迟暴涨。线上的SLA一旦被这类问题击穿再高的平均吞吐指标都没有意义。1.3 PD分离的拆分逻辑与三种实现路线PD分离的思路很简单既然prefill和decode的需求完全相反就别让它们互相迁就直接把两个阶段拆到不同的GPU实例上。prefill实例专心做prompt并行计算生成KV Cachedecode实例拿到KV Cache后只做逐token生成。这两个阶段之间传输的是计算产物而不是原始文本这个产物就是KV Cache。实际工程中PD分离有三种常见路线Chunked Prefill分块预填充不算严格意义的PD分离。它把长prompt切成多个chunk在decode调度的间隙插入计算。这种方案做到了时间上的分离但不是物理上的隔离只能缓解不能根治。同机组内多实例分离在同一个节点的多张GPU上一部分worker跑prefill一部分worker跑decode中间走NCCL做KV Cache传输。这是vLLM原生PD分离的常见形态适合单节点多卡环境。跨节点分离把prefill和decode分别放到不同机器或者干脆做成prefill集群和decode集群。这种形态最彻底也是DeepSeek等大厂线上推理架构的核心方向。vLLM在0.8.x之后把后两种路线通过一套参数统一了起来。下面重点讲落地时最常用的同机多卡方案因为大多数团队手头的资源规模优先验证这一步是最划算的。2. 动手之前硬件、网络与vLLM版本怎么选2.1 硬件规划先算显存再买卡PD分离之后prefill和decode节点都需要加载一份完整的模型权重这一点和单纯张量并行完全不同。所以硬件规划的第一步是确认显存够不够放两份权重 两份KV Cache。举个例子部署Qwen2.5-14B-Instructbf16权重大约28GB。如果打算单节点两张80GB的A800/H800做PD分离每张卡放一份权重权重只占28GB留约52GB给KV Cache和激活值空间比较从容。但如果是72B模型bf16权重约144GB单卡就要想办法做量化如AWQ 4bit约36GB或者用多卡张量并行跑单侧实例。这个显存预算在启动前必须算清楚否则PD分离跑起来之后请求稍微一多就会OOM。2.2 网络与通信依赖NCCL是不能忽略的环节PD分离之后KV Cache的传输链路就是新的瓶颈。prefill实例算完KV Cache要通过NCCL发给decode实例。每个token的KV Cache大小大约是 2 × 层数 × 注意力头数 × 头维度 × 字节数。以Qwen2.5-14B为例每个token约0.2MB左右。如果请求的prompt是2万token一次KV Cache传输就是4GB级别。这个体量走普通千兆以太网不现实单机多卡走NVLink内部互联还好跨节点就必须上InfiniBand或至少25GbE以上的RDMA网络。所以部署PD分离前需要确认同机组内GPU之间是否走NVLink跨节点方案是否有RoCE/IB链路NCCL版本是否和CUDA匹配。我实际遇到过NCCL版本不匹配导致KV传输hang住的情况后面会单独说排查过程。2.3 vLLM版本选择与基础环境验证PD分离在不同vLLM版本里的成熟度差异巨大。0.6.x还是实验性功能很多参数需要自己摸索0.7.x开始逐渐完善0.8.x之后尤其是v1引擎下功能才真正可评估。我自己在0.8.5和0.9.x上都跑过不稳定版本最终稳定生产用的是较新的稳定发行版。选好版本后先把最基础的链路跑通能不能正常启动模型、能不能正常夸卡张量并行。这一步不要跳过很多PD分离跑不起来的案例根源其实是基础环境问题被误判成PD分离的bug。先单独跑一次普通的多卡vLLM服务确认CUDA、NCCL、GPU间通信都正常再上PD分离。3. vLLM PD分离落地实操命令、参数与验证3.1 一个可直接参考的启动配置以单节点2卡A800、部署Qwen2.5-14B-Instruct为例vLLM 0.8.x/0.9.x版本下的启动命令大致如下# prefill decode 分离模式2卡各自承担一个角色 vllm serve Qwen/Qwen2.5-14B-Instruct \ --tensor-parallel-size 1 \ --pipeline-parallel-size 1 \ --enforce-eager \ --enable-pd-disaggregation \ --pd-disaggregation-config {num_prefill_workers: 1, num_decode_workers: 1} \ --kv-transfer-config {kv_connector: NCCL, kv_buffer_size_in_bytes: 1073741824}注意不同版本的参数名可能有差异实际以你安装版本的vllm serve --help输出为准。这里我把核心参数拆开说明--enable-pd-disaggregation总开关开启PD分离模式。--pd-disaggregation-configJSON格式配置。num_prefill_workers和num_decode_workers分别指定prefill和decode的worker数量。这里设为1:1即一张卡跑prefill一张卡跑decode。--kv-transfer-configKV Cache传输配置。kv_connector: NCCL表示用NCCL把KV Cache从prefill端送到decode端kv_buffer_size_in_bytes是KV传输缓冲区的显存大小这里给了1GB。--tensor-parallel-size 1单一worker不开启张量并行。如果显存不够可以在prefill和decode内部各自再开TP但那样传输逻辑会更复杂起步阶段不推荐。启动后会看到vLLM把不同rank分配成不同角色日志里类似rank 0 assigned as prefill worker、rank 1 assigned as decode worker的输出。看到这个说明PD分离的角色划分已经生效。3.2 KV Cache传输链路和显存Buffer怎么配KV Cache传输是PD分离里最容易出问题的环节没有之一。你在decode worker的显存里必须预留一部分空间作为接收KV Cache的buffer。这个buffer不够请求就会卡在prefill和decode的交接点上表现为TTFT异常高、甚至连接超时。kv_buffer_size_in_bytes给多少取决于你的单请求KV Cache体积上限。刚才算过Qwen2.5-14B的每token KV Cache约0.2MB。如果线上最大prompt是8K token单请求峰值KV Cache约1.6GB。再把并发算进去decode端buffer建议至少能容纳最极端的2~3个并发请求的KV Cache也就是4~5GB。我上面给的1GB只是demo级别真要上生产要按这个公式重新算。还有一点容易被忽略prefill端生成完KV Cache后原始prompt对应的KV Cache在prefill端占用的显存传输完成后要及时释放。vLLM内部有缓冲管理策略但如果你看到prefill端显存持续上涨不回弹要检查是不是同一批传输buffer没有被循环复用。3.3 怎么确认PD分离真正生效启动起来并不代表PD分离真正生效。我建议至少从三个维度验证日志确认角色分配启动日志里会不会明确区分prefill worker与decode worker。如果所有worker角色都一样或只有一个角色说明配置没加载进去。网络传输观察在decode worker的卡上用nvidia-smi dmon观察NVLink或网卡的传输流量。请求到位时如果能看到明显的NVLink传输峰值同机多卡场景说明KV Cache确实在跨卡流动。完全没有流量大概率是走了错误的路径。指标验证压测时对比PD分离前后的TTFT和TPOT。PD分离开启后正常情况下纯decode阶段的TPOT会明显更稳定不再因为并发prefill请求而剧烈波动。这三点都验证通过才算真正把PD分离跑通。3.4 结合Embedding模型启动的小补充热词里有提到带着BGE-M3这类embedding模型启动的场景。vLLM的OpenAI兼容接口目前对embedding模型和普通chat模型在PD分离框架下的处理并不同步。我自己在早期版本里试过一边起chat模型一边拉embedding模型结果是PD分离只对chat推理链路生效embedding请求并不走KV Cache逻辑倒也不冲突。如果你是混合服务场景建议用两个独立的vLLM实例分别承载chat和embedding不要指望PD分离能给你的embedding请求加速。4. 做一轮压测bench serve怎么用、指标怎么读4.1 bench serve基础用法PD分离调完之后压测是必做的一步。vLLM官方自带bench serve工具可以直接用它来评估。基本用法是vllm bench serve \ --model Qwen/Qwen2.5-14B-Instruct \ --dataset /path/to/sharegpt_dataset.json \ --num-prompts 200 \ --request-rate 10 \ --max-concurrency 16--dataset可以换成ShareGPT或者自定义的jsonl数据里面是真实请求格式。--num-prompts控制总请求数--request-rate控制请求速率设为0时是无限并发发送。如果你想把PD分离带来的效果压出来建议准备两组数据一组是短prompt短输出典型聊天场景一组是长prompt短输出比如文档问答、RAG场景。因为PD分离的收益在长prompt场景下才是最大的。4.2 关键指标怎么读bench serve输出里通常直接给出TTFT、TPOT、端到端延迟和吞吐量。我最关注的其实是两个指标的组合长prompt请求存在时短请求的TTFT中位数和p99有没有被带崩。如果PD分离生效无论长prompt再怎么涌入decode节点的TPOT应该维持在一个稳定区间内。这才是PD分离最核心的价值比单纯看吞吐提升几个点更有意义。压测要特别注意一点不要只看平均值。PD分离的优势恰恰在尾延迟控制上。要统计p95、p99这些分位数。线上用户感受到的卡顿基本都是p99级别的延迟波动造成的。4.3 和Chunked Prefill等组合调优PD分离并不排斥Chunked Prefill。实际上开启PD分离之后prefill节点依然可以配置chunked prefill让它把大prompt切成更细的chunk进行并行调度。这样prefill节点的利用率能进一步拉高多个prefill请求之间的互相抢占也会减少。在vLLM里可以通过--max-num-batched-tokens和--max-num-seqs来控制prefill的批处理规模。给一个调优顺序参考先不开PD分离压测拿到基线数据。开启PD分离保持其他参数不变对比TTFT和TPOT。在prefill侧单独调chunked prefill的参数目标是提高prefill吞吐。观察decode侧显存buffer是否够用不够就加大kv_buffer_size_in_bytes。这套流程走下来优于一上来就抄别人的参数配置。5. 常见问题与排查实录5.1 问题速查表PD分离涉及多实例、多角色、多通信链路问题表象千奇百怪。我把实际踩过和同行交流过的典型问题整理成一个速查表现象可能原因排查与解决启动后所有rank角色都是decodeprefill缺失PD分离配置未加载或版本对参数不识别检查启动参数的JSON格式确认--enable-pd-disaggregation存在打印--help核对参数名请求卡在TTFT阶段迟迟不出tokenKV Cache传输失败或buffer不足查看decode worker日志是否有NCCL超时适当调大kv_buffer_size_in_bytesNCCL初始化报版本不匹配错误vLLM内置NCCL版本和系统CUDA环境不匹配检查日志中的NCCL版本号统一CUDA与NCCL主版本热词里的pynccl.py日志就是指这类输出开启PD分离后吞吐反而下降传输链路成为瓶颈或模型太小收益不明显大多数小模型如7B以下在PD分离下的收益有限确认请求是否以长prompt为主prefill端显存不断上涨传输buffer未释放或请求队头阻塞限制并发请求数检查KV Cache的内存池复用策略decode端偶发OOM接收KV Cache的buffer加上本地KV Cache超过显存降低max num seqs或扩大显存预算5.2 几条独家排查心得第一条排查PD分离问题时先关掉PD分离复现一遍。很多PD分离独有问题实际上只是普通多卡部署就有的环境问题。关掉开关跑一下普通模式如果问题还在就不要在PD分离的代码路径里找原因了。这是我在一次线上故障里用过的排查方式很稳也很省时间。第二条网络传输不见得每次都走NVLink。同机多卡vLLM的NCCL通信可能走PCIe也可能走NVLink取决于拓扑和NCCL的检测。如果发现KV传输延迟高先看nvidia-smi topo -m确认卡间是不是P2P直连。跨节点部署时则要做RDMA连通性测试直接用nccl-tests测一下实际带宽再上生产。第三条版本更新后配置参数名很可能会变。我遇到过从0.8.x升到0.9.x原来的--pd-disaggregation-config结构变了服务能启动但角色分配不对请求全堆在decode端的情况。社区版本迭代快踩坑不可怕启动前养成vllm serve --help查参数的习惯能省很多时间。6. 一些实操体会与后续扩展PD分离这套架构本质上是一种用硬件资源换服务稳定性的方案。它不会让单次推理的理论速度变快但它能让延迟分布更可控、让长上下文请求不再随意破坏其他请求的SLA。我个人的体会是如果你的业务里长prompt请求比例不高或者模型本身很小PD分离可能并不划算毕竟多一份权重就要多占一份显存。但如果是长文档问答、代码分析、智能体记忆注入这些场景PD分离几乎是线上稳定性的刚需。如果你想往更深一层走下一步可以关注两个方向一是prefill和decode实例的比例动态调整根据线上流量特征让prefill实例多一些还是decode实例多一些这是由业务形态决定的需要自己积累数据二是跨节点KV Cache传输的优化比如压缩传输、异步预取等手段这些都是PD分离进入大规模生产之后才会遇到的深水区。先把单机PD分离吃透再往这些方向延伸思路就不会乱。
PD分离这四个字最近在LLM推理圈里出现的频率有多高不用我多说。如果你同时跑过prefill和decode阶段的任务应该能明显感受到那种拧巴感prefill阶段GPU利用率能冲到90%以上一到decode阶段计算单元大量空转、显存带宽吃紧。vLLM从0.6.x开始把PD分离Prefill-Decode Disaggregation预填充与解码分离作为重点能力推进到了0.8.x之后已经可以直接在生产环境尝试。这篇文章就围绕PD分离聊聊它到底解决什么问题、怎么部署、有哪些需要注意的坑。本文主要面向有vLLM基础使用经验的工程师也适合正在调研大模型推理优化方案的朋友。1. 什么是PD分离先搞清楚它在解决什么难题1.1 Prefill与Decode的天然矛盾LLM推理的请求处理天然分成两个阶段prefill负责把用户输入的prompt并行算一遍生成第一批KV Cache和第一个tokendecode阶段则拿着KV Cache逐token生成后续内容。这两个阶段的计算特征、资源需求完全不是一回事直接对比一下维度Prefill阶段Decode阶段计算类型高度并行的矩阵乘适合GPU并行串行逐token生成访存受限关键瓶颈算力FLOPs显存带宽和KV Cache读取速度响应指标TTFT首token延迟TPOT每token生成时间KV Cache角色生产方按整个prompt长度一次性生成消费方每步追加一个token受并发影响并发越多算力竞争越激烈主要受KV Cache内存带宽影响这两者放在同一张GPU上就产生了调度上的天然矛盾。prefill喜欢一次吃下大量计算decode却希望GPU每个时刻都快速响应小批量访存。你让同一个工作进程在这两种状态之间来回切换性能不可能稳定。1.2 混合部署为什么在长上下文场景下失控很多人判断一个推理框架好不好用习惯性只用吞吐量说话。但在生产环境里长prompt请求把整个服务拖垮的问题远比单请求吞吐更棘手。我见过一个实际案例8卡A800跑一个72B模型在线服务给多个业务方共用。某业务方突然请求一个包含几十页文档的长上下文输入prefill计算量很大GPU在那一瞬间几乎全被这个请求占满。其他正在decode的请求立刻开始排队TTFT瞬间从几百毫秒飙到好几秒用户端直接感知到卡顿。这就是混合部署的典型失控场景长上下文请求的出现相当于在繁忙的decode流水线里突然插入一个重计算任务。GPU算力、显存带宽、KV Cache缓冲区全部被抢占导致所有请求的尾延迟暴涨。线上的SLA一旦被这类问题击穿再高的平均吞吐指标都没有意义。1.3 PD分离的拆分逻辑与三种实现路线PD分离的思路很简单既然prefill和decode的需求完全相反就别让它们互相迁就直接把两个阶段拆到不同的GPU实例上。prefill实例专心做prompt并行计算生成KV Cachedecode实例拿到KV Cache后只做逐token生成。这两个阶段之间传输的是计算产物而不是原始文本这个产物就是KV Cache。实际工程中PD分离有三种常见路线Chunked Prefill分块预填充不算严格意义的PD分离。它把长prompt切成多个chunk在decode调度的间隙插入计算。这种方案做到了时间上的分离但不是物理上的隔离只能缓解不能根治。同机组内多实例分离在同一个节点的多张GPU上一部分worker跑prefill一部分worker跑decode中间走NCCL做KV Cache传输。这是vLLM原生PD分离的常见形态适合单节点多卡环境。跨节点分离把prefill和decode分别放到不同机器或者干脆做成prefill集群和decode集群。这种形态最彻底也是DeepSeek等大厂线上推理架构的核心方向。vLLM在0.8.x之后把后两种路线通过一套参数统一了起来。下面重点讲落地时最常用的同机多卡方案因为大多数团队手头的资源规模优先验证这一步是最划算的。2. 动手之前硬件、网络与vLLM版本怎么选2.1 硬件规划先算显存再买卡PD分离之后prefill和decode节点都需要加载一份完整的模型权重这一点和单纯张量并行完全不同。所以硬件规划的第一步是确认显存够不够放两份权重 两份KV Cache。举个例子部署Qwen2.5-14B-Instructbf16权重大约28GB。如果打算单节点两张80GB的A800/H800做PD分离每张卡放一份权重权重只占28GB留约52GB给KV Cache和激活值空间比较从容。但如果是72B模型bf16权重约144GB单卡就要想办法做量化如AWQ 4bit约36GB或者用多卡张量并行跑单侧实例。这个显存预算在启动前必须算清楚否则PD分离跑起来之后请求稍微一多就会OOM。2.2 网络与通信依赖NCCL是不能忽略的环节PD分离之后KV Cache的传输链路就是新的瓶颈。prefill实例算完KV Cache要通过NCCL发给decode实例。每个token的KV Cache大小大约是 2 × 层数 × 注意力头数 × 头维度 × 字节数。以Qwen2.5-14B为例每个token约0.2MB左右。如果请求的prompt是2万token一次KV Cache传输就是4GB级别。这个体量走普通千兆以太网不现实单机多卡走NVLink内部互联还好跨节点就必须上InfiniBand或至少25GbE以上的RDMA网络。所以部署PD分离前需要确认同机组内GPU之间是否走NVLink跨节点方案是否有RoCE/IB链路NCCL版本是否和CUDA匹配。我实际遇到过NCCL版本不匹配导致KV传输hang住的情况后面会单独说排查过程。2.3 vLLM版本选择与基础环境验证PD分离在不同vLLM版本里的成熟度差异巨大。0.6.x还是实验性功能很多参数需要自己摸索0.7.x开始逐渐完善0.8.x之后尤其是v1引擎下功能才真正可评估。我自己在0.8.5和0.9.x上都跑过不稳定版本最终稳定生产用的是较新的稳定发行版。选好版本后先把最基础的链路跑通能不能正常启动模型、能不能正常夸卡张量并行。这一步不要跳过很多PD分离跑不起来的案例根源其实是基础环境问题被误判成PD分离的bug。先单独跑一次普通的多卡vLLM服务确认CUDA、NCCL、GPU间通信都正常再上PD分离。3. vLLM PD分离落地实操命令、参数与验证3.1 一个可直接参考的启动配置以单节点2卡A800、部署Qwen2.5-14B-Instruct为例vLLM 0.8.x/0.9.x版本下的启动命令大致如下# prefill decode 分离模式2卡各自承担一个角色 vllm serve Qwen/Qwen2.5-14B-Instruct \ --tensor-parallel-size 1 \ --pipeline-parallel-size 1 \ --enforce-eager \ --enable-pd-disaggregation \ --pd-disaggregation-config {num_prefill_workers: 1, num_decode_workers: 1} \ --kv-transfer-config {kv_connector: NCCL, kv_buffer_size_in_bytes: 1073741824}注意不同版本的参数名可能有差异实际以你安装版本的vllm serve --help输出为准。这里我把核心参数拆开说明--enable-pd-disaggregation总开关开启PD分离模式。--pd-disaggregation-configJSON格式配置。num_prefill_workers和num_decode_workers分别指定prefill和decode的worker数量。这里设为1:1即一张卡跑prefill一张卡跑decode。--kv-transfer-configKV Cache传输配置。kv_connector: NCCL表示用NCCL把KV Cache从prefill端送到decode端kv_buffer_size_in_bytes是KV传输缓冲区的显存大小这里给了1GB。--tensor-parallel-size 1单一worker不开启张量并行。如果显存不够可以在prefill和decode内部各自再开TP但那样传输逻辑会更复杂起步阶段不推荐。启动后会看到vLLM把不同rank分配成不同角色日志里类似rank 0 assigned as prefill worker、rank 1 assigned as decode worker的输出。看到这个说明PD分离的角色划分已经生效。3.2 KV Cache传输链路和显存Buffer怎么配KV Cache传输是PD分离里最容易出问题的环节没有之一。你在decode worker的显存里必须预留一部分空间作为接收KV Cache的buffer。这个buffer不够请求就会卡在prefill和decode的交接点上表现为TTFT异常高、甚至连接超时。kv_buffer_size_in_bytes给多少取决于你的单请求KV Cache体积上限。刚才算过Qwen2.5-14B的每token KV Cache约0.2MB。如果线上最大prompt是8K token单请求峰值KV Cache约1.6GB。再把并发算进去decode端buffer建议至少能容纳最极端的2~3个并发请求的KV Cache也就是4~5GB。我上面给的1GB只是demo级别真要上生产要按这个公式重新算。还有一点容易被忽略prefill端生成完KV Cache后原始prompt对应的KV Cache在prefill端占用的显存传输完成后要及时释放。vLLM内部有缓冲管理策略但如果你看到prefill端显存持续上涨不回弹要检查是不是同一批传输buffer没有被循环复用。3.3 怎么确认PD分离真正生效启动起来并不代表PD分离真正生效。我建议至少从三个维度验证日志确认角色分配启动日志里会不会明确区分prefill worker与decode worker。如果所有worker角色都一样或只有一个角色说明配置没加载进去。网络传输观察在decode worker的卡上用nvidia-smi dmon观察NVLink或网卡的传输流量。请求到位时如果能看到明显的NVLink传输峰值同机多卡场景说明KV Cache确实在跨卡流动。完全没有流量大概率是走了错误的路径。指标验证压测时对比PD分离前后的TTFT和TPOT。PD分离开启后正常情况下纯decode阶段的TPOT会明显更稳定不再因为并发prefill请求而剧烈波动。这三点都验证通过才算真正把PD分离跑通。3.4 结合Embedding模型启动的小补充热词里有提到带着BGE-M3这类embedding模型启动的场景。vLLM的OpenAI兼容接口目前对embedding模型和普通chat模型在PD分离框架下的处理并不同步。我自己在早期版本里试过一边起chat模型一边拉embedding模型结果是PD分离只对chat推理链路生效embedding请求并不走KV Cache逻辑倒也不冲突。如果你是混合服务场景建议用两个独立的vLLM实例分别承载chat和embedding不要指望PD分离能给你的embedding请求加速。4. 做一轮压测bench serve怎么用、指标怎么读4.1 bench serve基础用法PD分离调完之后压测是必做的一步。vLLM官方自带bench serve工具可以直接用它来评估。基本用法是vllm bench serve \ --model Qwen/Qwen2.5-14B-Instruct \ --dataset /path/to/sharegpt_dataset.json \ --num-prompts 200 \ --request-rate 10 \ --max-concurrency 16--dataset可以换成ShareGPT或者自定义的jsonl数据里面是真实请求格式。--num-prompts控制总请求数--request-rate控制请求速率设为0时是无限并发发送。如果你想把PD分离带来的效果压出来建议准备两组数据一组是短prompt短输出典型聊天场景一组是长prompt短输出比如文档问答、RAG场景。因为PD分离的收益在长prompt场景下才是最大的。4.2 关键指标怎么读bench serve输出里通常直接给出TTFT、TPOT、端到端延迟和吞吐量。我最关注的其实是两个指标的组合长prompt请求存在时短请求的TTFT中位数和p99有没有被带崩。如果PD分离生效无论长prompt再怎么涌入decode节点的TPOT应该维持在一个稳定区间内。这才是PD分离最核心的价值比单纯看吞吐提升几个点更有意义。压测要特别注意一点不要只看平均值。PD分离的优势恰恰在尾延迟控制上。要统计p95、p99这些分位数。线上用户感受到的卡顿基本都是p99级别的延迟波动造成的。4.3 和Chunked Prefill等组合调优PD分离并不排斥Chunked Prefill。实际上开启PD分离之后prefill节点依然可以配置chunked prefill让它把大prompt切成更细的chunk进行并行调度。这样prefill节点的利用率能进一步拉高多个prefill请求之间的互相抢占也会减少。在vLLM里可以通过--max-num-batched-tokens和--max-num-seqs来控制prefill的批处理规模。给一个调优顺序参考先不开PD分离压测拿到基线数据。开启PD分离保持其他参数不变对比TTFT和TPOT。在prefill侧单独调chunked prefill的参数目标是提高prefill吞吐。观察decode侧显存buffer是否够用不够就加大kv_buffer_size_in_bytes。这套流程走下来优于一上来就抄别人的参数配置。5. 常见问题与排查实录5.1 问题速查表PD分离涉及多实例、多角色、多通信链路问题表象千奇百怪。我把实际踩过和同行交流过的典型问题整理成一个速查表现象可能原因排查与解决启动后所有rank角色都是decodeprefill缺失PD分离配置未加载或版本对参数不识别检查启动参数的JSON格式确认--enable-pd-disaggregation存在打印--help核对参数名请求卡在TTFT阶段迟迟不出tokenKV Cache传输失败或buffer不足查看decode worker日志是否有NCCL超时适当调大kv_buffer_size_in_bytesNCCL初始化报版本不匹配错误vLLM内置NCCL版本和系统CUDA环境不匹配检查日志中的NCCL版本号统一CUDA与NCCL主版本热词里的pynccl.py日志就是指这类输出开启PD分离后吞吐反而下降传输链路成为瓶颈或模型太小收益不明显大多数小模型如7B以下在PD分离下的收益有限确认请求是否以长prompt为主prefill端显存不断上涨传输buffer未释放或请求队头阻塞限制并发请求数检查KV Cache的内存池复用策略decode端偶发OOM接收KV Cache的buffer加上本地KV Cache超过显存降低max num seqs或扩大显存预算5.2 几条独家排查心得第一条排查PD分离问题时先关掉PD分离复现一遍。很多PD分离独有问题实际上只是普通多卡部署就有的环境问题。关掉开关跑一下普通模式如果问题还在就不要在PD分离的代码路径里找原因了。这是我在一次线上故障里用过的排查方式很稳也很省时间。第二条网络传输不见得每次都走NVLink。同机多卡vLLM的NCCL通信可能走PCIe也可能走NVLink取决于拓扑和NCCL的检测。如果发现KV传输延迟高先看nvidia-smi topo -m确认卡间是不是P2P直连。跨节点部署时则要做RDMA连通性测试直接用nccl-tests测一下实际带宽再上生产。第三条版本更新后配置参数名很可能会变。我遇到过从0.8.x升到0.9.x原来的--pd-disaggregation-config结构变了服务能启动但角色分配不对请求全堆在decode端的情况。社区版本迭代快踩坑不可怕启动前养成vllm serve --help查参数的习惯能省很多时间。6. 一些实操体会与后续扩展PD分离这套架构本质上是一种用硬件资源换服务稳定性的方案。它不会让单次推理的理论速度变快但它能让延迟分布更可控、让长上下文请求不再随意破坏其他请求的SLA。我个人的体会是如果你的业务里长prompt请求比例不高或者模型本身很小PD分离可能并不划算毕竟多一份权重就要多占一份显存。但如果是长文档问答、代码分析、智能体记忆注入这些场景PD分离几乎是线上稳定性的刚需。如果你想往更深一层走下一步可以关注两个方向一是prefill和decode实例的比例动态调整根据线上流量特征让prefill实例多一些还是decode实例多一些这是由业务形态决定的需要自己积累数据二是跨节点KV Cache传输的优化比如压缩传输、异步预取等手段这些都是PD分离进入大规模生产之后才会遇到的深水区。先把单机PD分离吃透再往这些方向延伸思路就不会乱。
