PD分离压测应覆盖哪些场景?

话题来源: 从训练转向推理:企业如何评估Prefill与Decode分离的AI算力架构?

PD 分离压测不能只验证“拆开后吞吐是否更高”,而应验证 Prefill 与 Decode 在不同负载结构下能否各自稳定工作。核心是观察:输入处理是否拖慢首个 Token,持续生成是否受到 KV Cache 和网络传输影响,以及路由、扩缩容和故障恢复是否引入新的尾延迟。

必测负载场景

短输入、短输出场景应作为基线。此时请求处理简单,单池部署可能已经足够,PD 分离反而可能增加状态传输和调度开销。对比非分离架构的 TTFT、TPOT、吞吐和单位 Token 成本,可以判断分离方案是否存在明显的额外成本。

长上下文场景重点压测 Prefill。逐步增加历史对话、检索内容和工具返回结果,观察 TTFT、Prefill 节点排队时间、显存占用以及 KV Cache 生成后的传输耗时。需要特别关注长请求是否挤压短请求,导致 P95、P99 延迟异常升高。

高并发持续生成场景重点压测 Decode。混合短输出和长输出请求,逐步提高并发生成数,观察 TPOT、动态批处理效果、显存带宽压力和 KV Cache 淘汰行为。不能只看平均速度,还要检查流式输出是否出现明显抖动。

输入与输出不均衡场景应覆盖“长输入短输出”和“短输入长输出”两类组合。前者检验 Prefill 资源池是否成为瓶颈,后者检验 Decode 节点能否持续承载生成任务。这类测试可以验证两阶段是否真正实现了资源解耦。

不应遗漏的系统压力

智能体任务需要加入检索、工具调用、多轮记忆和失败重试,模拟一次任务连续触发多次推理请求。压测时应记录每一轮请求的 TTFT、TPOT、排队时间和总完成时间,避免只测单轮模型调用。

还应单独制造 Prefill、Decode 节点负载峰值错开的情况,验证独立扩缩容是否有效;增加跨节点状态传输压力,观察网络等待是否抵消分离收益;模拟节点异常、路由重试、熔断和扩容过程,检查请求是否丢失以及尾延迟是否失控。

最终报告至少应同时呈现 P50、P95、P99 延迟、Token 吞吐、显存与 CPU 使用率、网络流量、缓存命中或淘汰情况,以及两类节点的利用率。只有在真实输入输出分布和智能体流程下,PD 分离仍能改善关键指标并控制额外成本,才具备生产部署价值。

发表回复

登录后才能评论