FluidPD：原地弹性调度破解LLM推理的P/D资源失衡难题

大语言模型（LLM）服务的推理架构正在经历一场精细化变革。Prefill-Decode（预填充-解码）分离架构因其能够独立处理两个执行模式迥异的阶段而逐渐成为主流。但这套架构有一个长期未解的痛点：当真实工作负载的需求比例剧烈波动时，固定的资源配置会迅速失配，导致延迟SLO（服务等级目标）被打破。arXiv上一篇名为《FluidPD》的新论文，正是针对这一问题提出了一套"原地弹性"方案。

P/D分离架构的结构性困境

理解FluidPD的价值，需要先理解Prefill和Decode两个阶段的本质差异。Prefill阶段负责处理用户输入的提示词（prompt），属于计算密集型任务，一次性吞吐大量token；Decode阶段则逐token生成输出，属于访存密集型任务，对延迟更为敏感。正因为两者的执行特性和SLO目标截然不同，将它们拆分到不同的worker上分别优化，成为提升整体服务质量的合理选择。

问题出在"固定配比"上。现有系统通常采用固定的prefill/decode worker比例，再配合请求路由来分配负载。但论文指出，真实世界的工作负载既有短时突发（short bursts），也有持续性的需求比例漂移（sustained shifts）。这意味着某一时刻配置得当的资源分配，下一刻就可能严重失衡——即便系统其他地方还有空闲算力，延迟SLO依然会被违反。

FluidPD论文

KV Cache（键值缓存）是理解P/D分离架构的另一个关键背景。Prefill阶段计算完成后，会生成一组中间状态矩阵（即Attention机制中的Key和Value张量），这些矩阵需要在整个Decode阶段持续读取。在分离架构中，这意味着KV Cache要在prefill worker和decode worker之间传输，这本身就带来了显著的网络带宽开销。当worker角色发生动态调整时，如何高效管理和迁移KV Cache，也是FluidPD等系统必须面对的工程挑战之一。正是这种"计算在prefill、读取在decode"的不对称性，进一步放大了两个阶段在资源特征上的差异，使得固定配比的问题更加突出。

为什么传统自动扩缩容不够用

面对失衡，最直觉的方案是自动扩缩容（autoscaling）。但论文明确指出了这条路的三个短板：反应慢、需要预留空闲GPU、无法直接应对短时间尺度的阶段失衡。

扩缩容的本质是"增加容量"，它需要调度新的GPU、加载模型、启动推理引擎，整个过程动辄数秒到数十秒。对于秒级甚至亚秒级的突发需求波动，这种响应速度远远跟不上。更关键的是，扩缩容依赖于手头有空闲的GPU资源可供调配，而在资源紧张的生产环境中，这个前提往往并不成立。换句话说，传统扩缩容解决的是"总量不足"，而P/D架构真正的痛点是"结构失配"——总量可能足够，但分配错了方向。

FluidPD的两大核心机制

FluidPD的思路不是增加资源，而是让现有资源"流动"起来，实现SLO感知的原地弹性（in-place elasticity）。它引入了两个互补的机制，分别应对不同时间尺度的失衡。

FluidToken：应对瞬时失衡

FluidToken针对的是短时突发。当decode侧存在空闲余量时，它会将有限比例的prefill计算卸载到decode worker上执行。这里的关键词是"有限"（bounded）——卸载量受到约束，避免因为过度借用而拖累decode本身的延迟表现。这相当于在不改变worker角色的前提下，临时借用对方的闲置算力填补瞬时缺口。

FluidRole：应对持续失衡

当失衡不再是短暂突发，而是持续性的需求漂移时，FluidToken的临时借用就不够了。FluidRole的做法是原地重分配worker角色——将正在运行的worker在prefill和decode两种角色之间切换。最精妙之处在于，这一切换"原地"完成，避免了模型重新加载和引擎重启。这恰好绕开了传统扩缩容最耗时的环节，让角色调整的开销降到最低。

压力指数：在SLO违反前主动干预

两个机制的调度都由"轻量级压力指数"（pressure indices）来引导。这是FluidPD设计上的一个重要理念转变：不是等到SLO已经被违反才被动响应，而是通过暴露prefill侧和decode侧的资源压力，在延迟问题真正显现之前就提前干预。

这种前瞻式调度让系统能够在失衡的苗头阶段就做出反应，而不是在灾难发生后亡羊补牢。轻量级的设计也保证了压力监测本身不会成为新的性能负担。

SLO（服务等级目标）在LLM推理场景中通常有两类核心指标：TTFT（Time To First Token，首token延迟）和TBT/TPOT（Token Between Tokens / Time Per Output Token，逐token生成延迟）。TTFT主要受Prefill阶段影响，反映用户发出请求后多久开始看到响应；TBT则主要受Decode阶段影响，决定整体的生成流畅度。P/D分离架构的一个核心动机，正是这两个指标的优化目标相互冲突——激进地批量化prefill可以提升吞吐但会拖高TTFT，而保证TTFT又会压缩prefill批次。FluidPD的压力指数需要同时感知两侧的SLO压力，因此其设计必须能区分这两类延迟目标，才能做出正确的资源调度方向判断。

实验效果与意义

论文在生产级的Azure trace工作负载上进行了评测。结果显示，相较于静态配置的SGLang，FluidPD将整体SLO达成率最高提升了94.6个百分点。这是一个相当可观的数字，它证明了SLO感知的原地P/D弹性能够在不额外增配worker的情况下显著改善服务质量。

从行业角度看，FluidPD的意义不仅在于一个具体的性能数字，更在于它提供了一种不同于"堆资源"的思路。随着LLM推理成本成为企业落地的核心考量，如何在有限GPU资源下压榨出更高的服务质量，正成为系统工程的主战场。FluidPD展示的"让资源流动而非增加资源"的理念，为P/D分离架构的工程优化提供了一个值得关注的方向。

需要说明的是，这是一篇刚发布的arXiv预印本，上述结论尚待更广泛的同行评审和实际部署验证。但其提出的两级弹性机制和前瞻式压力调度，确实触及了当前LLM服务架构的真实痛点。