本文作者kaiyuanPD分离弹性伸缩/角色切换的实践笔记想深耕AI Infra领域欢迎访问InfraTech库内容涵盖大模型基础、PyTorch/vLLM/SGLang框架入门、性能加速等核心方向配套50知识干货及适合初学者的notebook练习:https://github.com/CalvinXKY/InfraTechPDPrefill-Decode分离是推理侧提升性能的主流手段之一从2024年兴起、2025年逐步普及如今已成为常见部署选项与之相伴的EPDEncode-Prefill-Decode分离、AFDAttention-FFN Disaggregation[1]、Chunked Prefill、分布式KV cache等也把推理服务的工程复杂度整体抬高了一档。长期实践表明在大规模集群里单一PD分离并不总是全局最优很难用固定形态覆盖波动的流量与多变的需求。本文结合工程经验介绍两类用于弥补PD分离局限的手段弹性伸缩与角色切换。1 为什么需要PD分离在PD分离普及之前GPU上多为混合部署同一请求的Prefill与Decode在同一批GPU上完成。模型参数变大后矛盾会凸显例如算力给少了Prefill阶段时延拉长TTFT偏大算力给多了Decode阶段又容易出现算力闲置。PD分离依据Prefill偏算力密集与Decode偏访存密集的差异把资源更精细地切分到两阶段以提升整体利用率。vLLM的PD分离示意图PD分离自提出以来常被质疑认为其徒增系统复杂度、得不偿失但从vLLM/SGLang、DynamoNVIDIA等主流推理框架的演进看各方都在积极适配这一方向。2025年初笔者曾围绕该方向做过一些梳理如《vLLM PD分离方案浅析》、《vLLM PD分离KV cache传递机制详解与演进分析 》等虽以vLLM为主也顺带涉及其它框架目前各框架对PD分离的支持已趋于稳定业界仍不断出现新的工程解法。融入K8S生态的llm-d最新版本v0.5[2]v0.5 版本新增了可复现基准测试工作流、分层 KV 卸载、缓存感知 LoRA 路由、双活高可用架构、基于 UCCL 的传输容错以及缩容至零的自动扩缩容能力经验证单张 B200 推理 GPU宽模式专家并行解码吞吐约 3.1k token/s在 16×16 B200 预填充 / 推理拓扑下最高输出 50k token/s与轮询基线相比首词时延TTFT实现数量级降低。字节推出的aibrix已融入vllm生态[3]AIBrix 提供一套云原生解决方案专为企业需求定制针对大语言模型LLM推理的部署、管理与弹性扩缩进行了深度优化。Ray Serve LLMray原生解决方案[4]Ray Serve LLM提供一套高性能、可扩展的框架用于在生产环境中部署大语言模型LLM。它针对分布式大语言模型推理服务场景对Ray Serve基础组件做了专项优化兼具企业级特性与OpenAI API兼容能力。可结合vLLM框架实现PD分离功能。NVIDIA Dynamo[5]随着模型规模不断增大并越来越多地融入需要多个模型协同的 AI 工作流中在规模化部署时必须将这些模型分布到多台节点上并在 GPU 之间进行精细协调。随着采用诸如解耦式推理disaggregated serving等推理优化方法这种复杂性进一步提升——推理的不同阶段被拆分到不同 GPU 上执行响应在多块 GPU 间拆分与聚合给协同调度和数据传输都带来了更多挑战。概括而言PD分离的核心是在约束TTFT/TPOT/ITL与集群吞吐如QPS的前提下优化GPU资源的阶段化分配在许多场景下效果确实明显。但若只保留一种静态部署形态去应对所有负载有时不但省不下资源反而可能拉高总消耗。这也是下文要讨论弹性伸缩与角色切换的原因。Case1大参数量与稀疏结构下的波动当前主流LLM里MoE等稀疏结构很常见在PD分离形态下资源利用率往往波动更大。为拉高Decode吞吐常见做法是跨机EP等扩展方式但其隐含前提是基线流量足够。当流量回落时仍可能出现部分GPU利用率不足。此外单实例若固定占用多台机器规模一旦按参数敲定中途弹性扩缩容会变得困难与流量起伏的匹配度下降。Case2场景的快速变化智能体类客户增多后流量往往不再只是单一模型、单一曲线而是多模型、多形态叠加。这要求推理集群能适配多模型的波动对单模型的PD分离部署而言往往既需要实例级扩缩也需要实例内部如P/D子池或机器数的细粒度调整才能跟上场景变化。下文介绍我们团队在应对上述问题时探索过的两个方向。2 弹性伸缩对多数云厂商而言整条P/D实例的扩缩已是基线能力但粒度通常停在单个实例层面。要进一步提效需要更细的弹性。vLLM RoadMap 2025 Q3[6]中相关能力规划笔者团队当时在NPU硬件上基于KV pool展开实践。并据此提交过RFC[7]。在分离式P/DPrefill/Decode场景中支持P/D实例的弹性伸缩是大规模推理部署的关键需求正如vLLM 2025 年Q3 路线图“Autoscaling P D Replicas”中所提到的。这一功能不仅能提高资源利用率还能提供容错支持。尤其是在Ascend超节点上实例通常跨多个设备部署重建实例可能产生较大影响因此该能力尤为重要。借助Mooncake Store和Mem Cache等分布式KV Cache功能的支持我们可以以此为基础实现P/D实例的弹性伸缩。在伸缩实例时需要管理三种类型的连接a. P 与 D 之间的 D2D 链接由 connector 及其他组件建立b. P/D 与 KV Pool 之间的链接c. P/D 与 scheduler 之间的链接。这涉及实例注册、链接断开/建立、链接重建等流程。方案架构图实施计划阶段1 同构伸缩Homogeneous Scaling1.1 P-instance 伸缩的实现1.2 D-node 伸缩的实现阶段2 异构伸缩Heterogeneous Scaling2.1 异构 KV cache 传输的支持2.2 P/D 配置下异构传输的支持实践效果工程侧因前期已对KV Pool做了较完整适配传输建链、KV cache生命周期等重复建设相对较少难点在于异构伸缩下的并行策略与多模型配比往往需要实验得到先验。在部分场景下吞吐可提升约5%15%。部分实现已以PR形式贡献至vLLM社区5822[8]、5063[9]可供对照参考。3 角色切换角色切换指在不长时间停机的前提下快速改变实例承担的角色。实践中可归纳为几类能力P与D的角色热切换实例的动态热加载多模型间切换PD分离与混合部署之间的热切换。a P与D角色热切换一般在P、D硬件规格一致时更易落地。例如同一模型下P实例不足、D实例有余可将部分D实例切为P反之亦然。过程中需关注Prefix cache等一致性借助分布式KV cache可降低工程复杂度。b 实例动态热加载在不同模型间快速切换例如同一P实例从模型A切到模型B常见会结合休眠/睡眠类机制减少冷启动成本具体依框架与硬件而定。vLLM中通过睡眠模式sleep mode[10]目前设置了两个等级level 1操作卸载模型权重并清除KV cache。内存模型权重被移动到CPU内存KV cache被清除。level 2操作同时丢弃模型权重和KV缓存。内存模型权重和KV cache都被清除。应用中一般使用level2模式。调用示例# Sleep level 2# Put the engine to sleep (level2: discard both weights and KV cache)llm.sleep(level2)# Reallocate weights memory onlyllm.wake_up(tags[weights])# Load weights in-placellm.collective_rpc(reload_weights)# Reallocate KV cachellm.wake_up(tags[kv_cache])过程步骤示意如下在sleep和wake_up操作中会分别调用unmap_and_release(handle)与create_and_map(handle)函数这两个函数定义于vllm/csrc/cumem_allocator.cpp中。//代码节选 void create_and_map(unsignedlonglongdevice,ssize_t size,CUdeviceptr d_mem,#ifndef USE_ROCMCUmemGenericAllocationHandle*p_memHandle){#elseCUmemGenericAllocationHandle**p_memHandle,unsignedlonglong*chunk_sizes,size_t num_chunks){#endifensure_context(device);//Define memory allocation properties CUmemAllocationProp prop{};//Allocate memory using cuMemCreate CUDA_CHECK(cuMemCreate(p_memHandle,size,prop,0));if(error_code!0){return;}CUDA_CHECK(cuMemMap(d_mem,size,0,*p_memHandle,0));if(error_code!0){return;}CUDA_CHECK(cuMemSetAccess(d_mem,size,accessDesc,1));if(error_code!0){return;}在睡眠模式下使用VMM可以确保唤醒后CUDA Graph无需重新编译从而显著提升框架的启动速度。睡眠模式与冷启动的对比[11]SGLang的睡眠模式与vLLM的功能相似其主要目的同样是减少启动阶段的时间开销从而提升强化学习RL的整体迭代速度。在SGLang中该模式分为两个步骤释放显存Release Memory与恢复显存Resume Memory并通过标签tag控制权重与KV Cache的释放与恢复。c PD分离与混合部署热切换与动态热加载类似但切换前后仍为同一模型。例如在MoE、PD形态下流量不足时可收缩D侧实例并将P实例快速切到混合部署等形态以节省碎片资源。角色切换能丰富调度策略但收益因场景而异并非总是净正。在系统尚不够稳定时故障成本可能压过细粒度切换带来的收益此时粗粒度实例调度有时更稳妥。小结PD分离通过阶段化资源分配缓解Prefill与Decode的资源错配是推理工程的重要选项但单一静态形态难以应对MoE稀疏、多模型流量与实例粒度固定等现实约束。弹性伸缩把优化从整条P/D实例粒度推进到更细的容量与配比在KV pool等基础设施就绪时可在部分场景换取可观的吞吐增益。角色切换则在实例不退出的前提下扩展调度空间需与Prefix cache、分布式KV及稳定性权衡一并设计。总体思路是以PD分离为基座用弹性与切换补齐其在动态负载下的短板并按成熟度在细粒度策略与粗粒度调度之间取舍。参考:[1]https://zhuanlan.zhihu.com/p/1952393747112367273[2]https://llm-d.ai/docs/architecture[3]https://github.com/vllm-project/aibrix[4]https://docs.ray.io/en/latest/serve/llm/index.html[5]https://developer.nvidia.cn/dynamo[6]https://github.com/vllm-project/vllm/issues/20336[7]https://github.com/vllm-project/vllm-ascend/issues/3380[8]https://github.com/vllm-project/vllm-ascend/pull/5822[9]https://github.com/vllm-project/vllm-ascend/pull/5063[10]https://github.com/vllm-project/vllm/blob/main/docs/features/sleep_mode.md[11]https://blog.vllm.ai/2025/10/26/sleep-mode.htmlInfraTech申明未经允许不得转载
本文作者kaiyuanPD分离弹性伸缩/角色切换的实践笔记想深耕AI Infra领域欢迎访问InfraTech库内容涵盖大模型基础、PyTorch/vLLM/SGLang框架入门、性能加速等核心方向配套50知识干货及适合初学者的notebook练习:https://github.com/CalvinXKY/InfraTechPDPrefill-Decode分离是推理侧提升性能的主流手段之一从2024年兴起、2025年逐步普及如今已成为常见部署选项与之相伴的EPDEncode-Prefill-Decode分离、AFDAttention-FFN Disaggregation[1]、Chunked Prefill、分布式KV cache等也把推理服务的工程复杂度整体抬高了一档。长期实践表明在大规模集群里单一PD分离并不总是全局最优很难用固定形态覆盖波动的流量与多变的需求。本文结合工程经验介绍两类用于弥补PD分离局限的手段弹性伸缩与角色切换。1 为什么需要PD分离在PD分离普及之前GPU上多为混合部署同一请求的Prefill与Decode在同一批GPU上完成。模型参数变大后矛盾会凸显例如算力给少了Prefill阶段时延拉长TTFT偏大算力给多了Decode阶段又容易出现算力闲置。PD分离依据Prefill偏算力密集与Decode偏访存密集的差异把资源更精细地切分到两阶段以提升整体利用率。vLLM的PD分离示意图PD分离自提出以来常被质疑认为其徒增系统复杂度、得不偿失但从vLLM/SGLang、DynamoNVIDIA等主流推理框架的演进看各方都在积极适配这一方向。2025年初笔者曾围绕该方向做过一些梳理如《vLLM PD分离方案浅析》、《vLLM PD分离KV cache传递机制详解与演进分析 》等虽以vLLM为主也顺带涉及其它框架目前各框架对PD分离的支持已趋于稳定业界仍不断出现新的工程解法。融入K8S生态的llm-d最新版本v0.5[2]v0.5 版本新增了可复现基准测试工作流、分层 KV 卸载、缓存感知 LoRA 路由、双活高可用架构、基于 UCCL 的传输容错以及缩容至零的自动扩缩容能力经验证单张 B200 推理 GPU宽模式专家并行解码吞吐约 3.1k token/s在 16×16 B200 预填充 / 推理拓扑下最高输出 50k token/s与轮询基线相比首词时延TTFT实现数量级降低。字节推出的aibrix已融入vllm生态[3]AIBrix 提供一套云原生解决方案专为企业需求定制针对大语言模型LLM推理的部署、管理与弹性扩缩进行了深度优化。Ray Serve LLMray原生解决方案[4]Ray Serve LLM提供一套高性能、可扩展的框架用于在生产环境中部署大语言模型LLM。它针对分布式大语言模型推理服务场景对Ray Serve基础组件做了专项优化兼具企业级特性与OpenAI API兼容能力。可结合vLLM框架实现PD分离功能。NVIDIA Dynamo[5]随着模型规模不断增大并越来越多地融入需要多个模型协同的 AI 工作流中在规模化部署时必须将这些模型分布到多台节点上并在 GPU 之间进行精细协调。随着采用诸如解耦式推理disaggregated serving等推理优化方法这种复杂性进一步提升——推理的不同阶段被拆分到不同 GPU 上执行响应在多块 GPU 间拆分与聚合给协同调度和数据传输都带来了更多挑战。概括而言PD分离的核心是在约束TTFT/TPOT/ITL与集群吞吐如QPS的前提下优化GPU资源的阶段化分配在许多场景下效果确实明显。但若只保留一种静态部署形态去应对所有负载有时不但省不下资源反而可能拉高总消耗。这也是下文要讨论弹性伸缩与角色切换的原因。Case1大参数量与稀疏结构下的波动当前主流LLM里MoE等稀疏结构很常见在PD分离形态下资源利用率往往波动更大。为拉高Decode吞吐常见做法是跨机EP等扩展方式但其隐含前提是基线流量足够。当流量回落时仍可能出现部分GPU利用率不足。此外单实例若固定占用多台机器规模一旦按参数敲定中途弹性扩缩容会变得困难与流量起伏的匹配度下降。Case2场景的快速变化智能体类客户增多后流量往往不再只是单一模型、单一曲线而是多模型、多形态叠加。这要求推理集群能适配多模型的波动对单模型的PD分离部署而言往往既需要实例级扩缩也需要实例内部如P/D子池或机器数的细粒度调整才能跟上场景变化。下文介绍我们团队在应对上述问题时探索过的两个方向。2 弹性伸缩对多数云厂商而言整条P/D实例的扩缩已是基线能力但粒度通常停在单个实例层面。要进一步提效需要更细的弹性。vLLM RoadMap 2025 Q3[6]中相关能力规划笔者团队当时在NPU硬件上基于KV pool展开实践。并据此提交过RFC[7]。在分离式P/DPrefill/Decode场景中支持P/D实例的弹性伸缩是大规模推理部署的关键需求正如vLLM 2025 年Q3 路线图“Autoscaling P D Replicas”中所提到的。这一功能不仅能提高资源利用率还能提供容错支持。尤其是在Ascend超节点上实例通常跨多个设备部署重建实例可能产生较大影响因此该能力尤为重要。借助Mooncake Store和Mem Cache等分布式KV Cache功能的支持我们可以以此为基础实现P/D实例的弹性伸缩。在伸缩实例时需要管理三种类型的连接a. P 与 D 之间的 D2D 链接由 connector 及其他组件建立b. P/D 与 KV Pool 之间的链接c. P/D 与 scheduler 之间的链接。这涉及实例注册、链接断开/建立、链接重建等流程。方案架构图实施计划阶段1 同构伸缩Homogeneous Scaling1.1 P-instance 伸缩的实现1.2 D-node 伸缩的实现阶段2 异构伸缩Heterogeneous Scaling2.1 异构 KV cache 传输的支持2.2 P/D 配置下异构传输的支持实践效果工程侧因前期已对KV Pool做了较完整适配传输建链、KV cache生命周期等重复建设相对较少难点在于异构伸缩下的并行策略与多模型配比往往需要实验得到先验。在部分场景下吞吐可提升约5%15%。部分实现已以PR形式贡献至vLLM社区5822[8]、5063[9]可供对照参考。3 角色切换角色切换指在不长时间停机的前提下快速改变实例承担的角色。实践中可归纳为几类能力P与D的角色热切换实例的动态热加载多模型间切换PD分离与混合部署之间的热切换。a P与D角色热切换一般在P、D硬件规格一致时更易落地。例如同一模型下P实例不足、D实例有余可将部分D实例切为P反之亦然。过程中需关注Prefix cache等一致性借助分布式KV cache可降低工程复杂度。b 实例动态热加载在不同模型间快速切换例如同一P实例从模型A切到模型B常见会结合休眠/睡眠类机制减少冷启动成本具体依框架与硬件而定。vLLM中通过睡眠模式sleep mode[10]目前设置了两个等级level 1操作卸载模型权重并清除KV cache。内存模型权重被移动到CPU内存KV cache被清除。level 2操作同时丢弃模型权重和KV缓存。内存模型权重和KV cache都被清除。应用中一般使用level2模式。调用示例# Sleep level 2# Put the engine to sleep (level2: discard both weights and KV cache)llm.sleep(level2)# Reallocate weights memory onlyllm.wake_up(tags[weights])# Load weights in-placellm.collective_rpc(reload_weights)# Reallocate KV cachellm.wake_up(tags[kv_cache])过程步骤示意如下在sleep和wake_up操作中会分别调用unmap_and_release(handle)与create_and_map(handle)函数这两个函数定义于vllm/csrc/cumem_allocator.cpp中。//代码节选 void create_and_map(unsignedlonglongdevice,ssize_t size,CUdeviceptr d_mem,#ifndef USE_ROCMCUmemGenericAllocationHandle*p_memHandle){#elseCUmemGenericAllocationHandle**p_memHandle,unsignedlonglong*chunk_sizes,size_t num_chunks){#endifensure_context(device);//Define memory allocation properties CUmemAllocationProp prop{};//Allocate memory using cuMemCreate CUDA_CHECK(cuMemCreate(p_memHandle,size,prop,0));if(error_code!0){return;}CUDA_CHECK(cuMemMap(d_mem,size,0,*p_memHandle,0));if(error_code!0){return;}CUDA_CHECK(cuMemSetAccess(d_mem,size,accessDesc,1));if(error_code!0){return;}在睡眠模式下使用VMM可以确保唤醒后CUDA Graph无需重新编译从而显著提升框架的启动速度。睡眠模式与冷启动的对比[11]SGLang的睡眠模式与vLLM的功能相似其主要目的同样是减少启动阶段的时间开销从而提升强化学习RL的整体迭代速度。在SGLang中该模式分为两个步骤释放显存Release Memory与恢复显存Resume Memory并通过标签tag控制权重与KV Cache的释放与恢复。c PD分离与混合部署热切换与动态热加载类似但切换前后仍为同一模型。例如在MoE、PD形态下流量不足时可收缩D侧实例并将P实例快速切到混合部署等形态以节省碎片资源。角色切换能丰富调度策略但收益因场景而异并非总是净正。在系统尚不够稳定时故障成本可能压过细粒度切换带来的收益此时粗粒度实例调度有时更稳妥。小结PD分离通过阶段化资源分配缓解Prefill与Decode的资源错配是推理工程的重要选项但单一静态形态难以应对MoE稀疏、多模型流量与实例粒度固定等现实约束。弹性伸缩把优化从整条P/D实例粒度推进到更细的容量与配比在KV pool等基础设施就绪时可在部分场景换取可观的吞吐增益。角色切换则在实例不退出的前提下扩展调度空间需与Prefix cache、分布式KV及稳定性权衡一并设计。总体思路是以PD分离为基座用弹性与切换补齐其在动态负载下的短板并按成熟度在细粒度策略与粗粒度调度之间取舍。参考:[1]https://zhuanlan.zhihu.com/p/1952393747112367273[2]https://llm-d.ai/docs/architecture[3]https://github.com/vllm-project/aibrix[4]https://docs.ray.io/en/latest/serve/llm/index.html[5]https://developer.nvidia.cn/dynamo[6]https://github.com/vllm-project/vllm/issues/20336[7]https://github.com/vllm-project/vllm-ascend/issues/3380[8]https://github.com/vllm-project/vllm-ascend/pull/5822[9]https://github.com/vllm-project/vllm-ascend/pull/5063[10]https://github.com/vllm-project/vllm/blob/main/docs/features/sleep_mode.md[11]https://blog.vllm.ai/2025/10/26/sleep-mode.htmlInfraTech申明未经允许不得转载
