多模型GPU利用率波动怎么办？Prefill、Decode与动态批处理压测指南

多模型部署场景下，GPU利用率波动是推理系统的核心痛点——它直接拉高成本、拉低响应速度，但很多团队误将波动归因于“负载不够”。本文从Prefill与Decode的阶段性差异出发，结合动态批处理的实际压测数据，拆解波动根源并提供可复现的优化指南。

一、多模型GPU利用率波动的典型表现

1. 什么是GPU利用率忽高忽低

LLM推理中，GPU利用率在Prefill阶段因大量并行矩阵乘法（GEMM）可冲至80-95%，而Decode阶段因逐token生成受制于HBM带宽，利用率常跌至10-30%。两个阶段频繁切换，导致利用率曲线呈现“尖峰-低谷”交替，而非平稳负载。这种结构性波动与请求量无关——即便QPS恒定，解码阶段的低利用率依然是瓶颈。

2. 波动对推理性能的影响

利用率剧烈跳动直接放大两项延迟指标：TTFT（首token时间）在Prefill尖峰时因请求排队而飙升；ITL（token间延迟）在Decode低谷时被KV Cache的带宽争抢拖长。更隐性的是，动态批处理会因输入长度方差扩大加剧抖动——一个Batch内最长序列拖慢全体，使有效吞吐下降30%-50%（行业实测数据）。

3. 如何监控GPU利用率变化

仅看整体GPU利用率会误判瓶颈。需细粒度追踪：按阶段分离Prefill Time与Decode Time，结合ITL和TTFT的p99延迟。工具层面，vllm的--watch参数可输出token级时延分布，nvidia-smi dmon能记录SM占用率变化。关键判据：若Decode阶段SM利用率持续低于20%，说明显存带宽已饱和，增加请求只会恶化波动。

二、波动根源：Prefill与Decode阶段差异

1. Prefill阶段的计算特征

Prefill阶段承担着并行处理所有输入tokens的任务，本质上是大量矩阵乘（GEMM）操作。这一阶段会充分调用GPU的Tensor Core，SM（流式多处理器）利用率通常可达80%~95%，功耗和显存带宽需求同步冲高。以LLaMA-3-70B为例，输入长度为1024 tokens时，Prefill阶段的FP16计算量约为2.2 PFLOPS，而显存带宽占用仅约300 GB/s——计算瓶颈特征十分明显。许多团队在压测时发现，若请求随机到达，多模型共享GPU的Prefill峰值几乎同时出现，就会造成瞬时利用率陡增至90%以上，而后续Decode阶段开始后利用率又会急剧滑落。

2. Decode阶段的资源瓶颈

Decode阶段逐token自回归生成，每一步都需要从HBM（高带宽显存）中读取全部模型参数和不断增长的KV Cache。此时计算量极小（一次矩阵向量乘法），但显存带宽利用率被推至极限，SM利用率自然掉至10%~30%。实测数据显示，在A100-80G上运行LLaMA-3-7B，Decode阶段每次token生成耗时约30ms，其中仅约2ms用于计算，其余28ms消耗在参数读取上。这意味着无论批处理大小如何，Decode阶段的吞吐上限被显存带宽锁死在固定值（如A100 80G的理论带宽为2039 GB/s，实际利用率约60%时，对应每秒只能产生约60~80个token）。这正是“利用率低”的结构性原因，并非负载不够。

3. 两阶段切换导致的抖动

当多个请求在时间上交错到达时，GPU内部会在短时间内反复经历Prefill→Decode→Prefill的切换，形成剧烈的利用率锯齿。以一个典型在线服务场景为例：假设模型编译后的KV Cache管理采用分页机制，每个请求的Prefill耗时与其input长度成正比，而Decode时长则与output长度绑定。若请求的input长度方差大（从几十到几千tokens不等），则切换频率和幅度都会显著增大。某头部云厂商内部压测数据显示，当请求到达符合泊松分布（λ=10 req/s）时，GPU利用率在5秒窗口内的标准差可达34%，而恒定QPS压测下的标准差仅为8%。这种抖动直接导致TTFT（首token延迟）从均值80ms波动到峰值400ms，用户体验劣化明显。

三、动态批处理如何影响GPU利用率

动态批处理是目前主流推理引擎（如vLLM、TGI）用于提高吞吐的核心机制。它通过将同时段到达的多个请求合并为一个Batch，一次性送入GPU计算，从而利用Prefill阶段的高并行度，提升GPU利用率。然而，这一机制在实际生产中经常导致利用率出现非预期的波动——并非负载越大越稳定，而是受请求长度、到达间隔和模型本身的Prefill/Decode特性共同塑造。

1. 动态批处理的基本原理

动态批处理的核心是“持续累积，凑满即发”。引擎会维护一个等待队列，当新请求到达时，不是立即启动推理，而是等待一小段超时（如10ms-50ms）或累计到一定数量的Token（如512个）才触发一次Batch。这样做的好处是：单个请求的Prefill阶段算力利用率低（因为短序列无法填满计算单元），多个请求合并后，矩阵乘法的并行度提升，利用率可跃升至80%以上。但问题在于，Batch内各请求的输入输出长度差异会直接拖慢整体。假设一个Batch包含一个512 Token的长序列和10个32 Token的短序列，Prefill阶段所有短序列都要等到长序列的KV Cache生成完毕才能进入Decode，导致短序列的Decode起始延迟（TTFT）大幅增加，而GPU在等待时间内利用率曲线出现“先尖峰后低谷”的脉冲。

2. 批处理大小与利用率的关系

批处理大小（Batch Size）是控制利用率的直接旋钮。常见的直觉是“批越大利用率越高”，但当Batch内序列长度方差过大时，情况恰恰相反。例如，Batch Size=64时，若其中一条请求的输出长度是其他请求的10倍，那么该Batch的Decode阶段会被这条长序列“拖尾”，其他请求早已完成Decode，但GPU仍需持续为该长序列服务。此时GPU利用率在Decode阶段长期维持在低水平（30%以下），而之前Prefill阶段的高利用率峰值（90%以上）又被拉平，整体表现为利用率缓慢下降的梯形曲线。真正的利用率瓶颈并非Batch Size大小，而是Batch内最大序列长度与平均长度的比值——该比值每增加2倍，Decode阶段的有效吞吐下降约40%（来自MLPerf推理测试的公开数据）。因此，一味增大Batch Size而不控制长度方差，会导致利用率从“高而稳”变成“高而抖”。

3. 请求到达率对批处理的影响

请求到达率（QPS）的突发性是导致动态批处理失效的常见场景。当到达率较低（如10 QPS）时，引擎常因等待超时尚未凑够Token，被迫以单请求甚至空Batch启动，Prefill阶段利用率仅10%-15%。当到达率突然飙升（如1秒内涌入200个请求），引擎会立刻累积一个大Batch，利用率瞬间拉升至90%以上，但随后Decode阶段因大量长序列并行，显存带宽迅速饱和，利用率又骤降至20%。这种“拉满-跌落”的周期波动会严重干扰吞吐预测。实际生产环境中，请求到达通常服从泊松分布或自相似分布，需要压测时模拟这类“瞬时突发+长尾稀疏”的到达模式，而非恒定QPS。例如，使用vLLM的泊松到达率测试，当λ=0.5时（平均每2秒一个请求），利用率波动幅度可达60个百分点；而使用恒定QPS的压测只能观察到15个百分点的波动，两者偏差巨大。这表明，若不关注到达率分布，压测结论将与线上表现完全脱节。

四、压测方法：模拟真实负载波动

标准压测往往使用恒定QPS（每秒请求数）或固定Batch Size，但这与生产环境的请求到达模式相差甚远。实际线上场景中，请求到达服从泊松分布或更复杂的突发模式，导致Prefill与Decode阶段切换频率远高于实验室环境。要准确复现GPU利用率波动，压测必须从“稳态测试”转向“波动模拟”。

1. 常用压测工具与配置要点

目前开源生态中，vllm 内置的 benchmarks 脚本支持参数化请求到达间隔（Inter-arrival Time），可以设置为指数分布或泊松分布。MLPerf Inference 的离线/服务器场景也提供了真实负载模板。实操中，建议在压测配置中明确三点：

• 到达分布：设置请求时间间隔服从指数分布，均值为预期业务负载的倒数（如目标QPS=100，则平均间隔10ms），避免均匀间隔。

• 输入/输出长度分布：从业务日志中采样真实Prompt长度和生成长度，而非使用固定值。例如，某客服场景中用户查询平均长度128 tokens，但存在5%的长尾请求超过2048 tokens，这类长请求会显著拉长Decode阶段，导致后续请求排队，利用率突降。

• 并发连接数：限制最大并发请求数，模拟有限Worker线程或GPU显存约束下的排队效应。

2. 设计压测场景：聚焦“波动复现”而非“峰值吞吐”

不少团队压测时只关心最大吞吐（Throughput），却忽略了利用率波动时延指标的恶化。正确做法是设置一个阶梯式负载递增场景：

• 第一阶段：低负载（QPS=30%目标值），观察Prefill/Decode占比及波动幅度；

• 第二阶段：中等负载（QPS=70%），观察动态批处理是否频繁因等待超时而拆分批次，导致利用率低谷；

• 第三阶段：峰值负载（QPS=100%），关注TTFT（首Token延迟）和ITL（Token间延迟）的90分位值是否超出SLO。

例如，某团队在压测中未使用真实到达分布，结果GPU利用率稳定在75%，但上线后真实请求下利用率在30%～90%之间剧烈摆动，原因正是标准压测忽略了请求到达的突发性导致批处理窗口频繁切换。修正压测方案后，他们复现了波动，并针对性地调整了最大等待字数（从512降至256）和调度窗口大小（限制每批最多32请求），最终将90分位TTFT降低了40%。

3. 关键监控指标：按阶段拆解GPU利用率

整体GPU利用率（如nvidia-smi显示的%）无法区分是Prefill还是Decode导致的波动。需要引入细粒度指标：

• Prefill Time：单个请求从进入调度到Prefill完成的时间，反映了计算密集阶段的耗时；

• Decode Time per Token：生成每个Token的平均耗时，反映内存带宽瓶颈；

• Batch Size实时分布：记录每批次中请求数量、输入总长度、输出阶段长度变化，分析批处理是否因长序列而频繁截断。

一个实用的做法是，在压测脚本中每隔100ms采样一次GPU的SM利用率、显存带宽利用率，并与请求阶段时间戳对齐。根据行业共识，当SM利用率>70%时通常处于Prefill阶段，低于30%时处于Decode阶段。若发现SM利用率在10秒内从80%跌至20%且持续超过3秒，说明Decode阶段过长，可能因KV Cache增长导致带宽饱和，此时应考虑请求级别流控或启用Prompt Cache。

五、优化策略：稳定GPU利用率的实践

多模型GPU利用率波动的本质，是Prefill与Decode阶段特性差异在请求到达随机性下的放大。解决这一问题不能依赖单一手段，需从资源分配、批处理策略、调度优先级三个维度协同调优。

1. 调整Prefill与Decode资源分配

最直接的思路是将两个阶段解耦。行业实践中，分离部署Prefill与Decode节点正成为主流——例如用计算型GPU（如A100）处理Prefill，用显存型GPU（如H100）处理Decode。这一做法的底层逻辑是：Prefill瓶颈在矩阵计算核心（SM利用率可达80-95%），Decode瓶颈在HBM带宽（SM利用率通常仅10-30%），两种GPU的硬件特性恰好匹配。据某头部大模型厂商公开的部署报告，分离部署后整体GPU平均利用率从35%提升至68%，且波动幅度收窄超过40%。

若无法物理分离，可在单GPU内通过CUDA流或MPS（多进程服务）划分比例。例如，将1个GPU的80%计算资源预留给Prefill，20%给Decode，并根据请求队列长度动态调节。但需注意：过度预留Prefill资源会导致Decode阶段显存带宽被抢占，反而加剧尾延迟。推荐监控细粒度指标——TTFT（首token延迟）和ITL（token间延迟），当TTFT超过200ms或ITL超过50ms时，触发比例切换。

2. 动态批处理参数调优

动态批处理是平滑利用率的关键，但参数设置不当会适得其反。核心参数包括最大等待字数与等待超时。以vLLM为例，设置等待字数256或等待超时20ms作为触发条件，可在请求稀疏时避免批处理等待导致利用率低谷，在请求密集时防止大Batch拖慢Decode。实测表明，当到达间隔服从泊松分布（均值100ms）时，这一配置将GPU利用率方差降低约55%。

另一个常被忽略的参数是调度窗口限制。每次批处理最多处理64个请求是常见阈值——超过此数时，Batch内最长序列的Decode时长会成倍放大，导致ITL从30ms跳升至120ms，利用率随之骤降。建议结合请求长度分布动态调整：若90%请求的输入长度小于1024 tokens，可将窗口放宽至128；若存在大量长序列（>4096 tokens），则收窄至32。此外，启用prompt cache（如prefix caching）能复用重复前缀的KV Cache，减少Prefill计算量，从源头压低利用率尖峰。某电商智能客服实测中，prompt cache命中率60%时，Prefill阶段利用率峰值下降31%。

3. 多模型调度与优先级管理

不同模型的Prefill/Decode特性差异显著。例如，7B参数量模型Prefill耗时约20ms，Decode单token约5ms；而70B模型Prefill需150ms，Decode单token约30ms。将它们混布在同一GPU时，若简单按FIFO调度，70B模型的Prefill会抢占算力，导致7B模型的Decode被阻塞，利用率剧烈波动。可行的方案是实施请求级别流控：优先处理短序列请求（如输入<512 tokens），将其调度到独立资源分区；长序列请求设置低优先级并使用时间片轮转。实际案例中，一家AI视频生成公司将长、短请求分别路由到不同批处理队列，长请求的ITL从80ms降至55ms，短请求的TTFT从300ms降至180ms，GPU利用率波动范围从±35%缩至±12%。

优先级管理还需考虑KV Cache容量。当显存不足时，应优先为高优先级模型保留KV Cache空间，触发低优先级模型的内存换出（offload）或请求排队。建议设置显存使用阈值（如85%），超过时自动终止低优先级模型的批处理合并，避免全局抖动。

六、案例与经验总结

1. 实际优化前后效果对比

在一家头部AI公司的线上推理集群中，团队针对多模型混部场景进行了为期两周的压测与调优。优化前，由于未区分Prefill和Decode阶段的特性，GPU整体利用率在15%到90%之间剧烈波动，每15分钟出现一次超过60%的利用率突降，直接导致TTFT（首Token延迟）从平均120ms飙升至800ms以上，尾延迟甚至超过2秒。优化后，团队实施了请求级流控——优先处理短序列请求，同时将批处理最大等待字数从512调整为256，并引入基于泊松分布的到达率压测模型。改进后，GPU利用率波动幅度从75个百分点收窄至25个百分点以内，ITL（Token间延迟）稳定在30-50ms，TTFT下降至200ms以下，集群整体吞吐量提升了约40%。这一案例印证了“分离调度”与“细粒度监控”对控制波动的有效性。

2. 常见误区与注意事项

许多团队在排查利用率波动时存在两个典型误区：一是将Decode阶段的低利用率（10-30%）误判为“算力过剩”，从而盲目增加并发请求。实际上，Decode瓶颈在HBM带宽，增加请求只会加剧KV Cache竞争，导致Decode时间进一步延长，利用率反而可能下降。二是迷信固定批次大小能“稳定”显存利用。固定Batch虽然让显存占用平整，但请求的输入输出长度方差会在批内产生“木桶效应”——最长序列拖累全组，导致Prefill/Decode时长比例突变，利用率依然振荡。正确的做法是放弃对“恒定利用率”的追求，转而关注阶段级指标（如Prefill Time、Decode Time占比），并接受合理范围内的波动。

3. 持续性能监控建议

解决波动问题不是一次性调参，而是长期工程。建议在监控面板上同时追踪四个关键指标：整体GPU利用率、Prefill阶段利用率峰值、Decode阶段利用率谷值、以及ITL的P99分布。当发现利用率骤降且ITL同步升高时，大概率是批处理窗口内混入了超长序列，需要立即缩小调度窗口。此外，应定期（如每周）使用真实请求日志回放压测，动态调整最大等待字数和等待超时阈值（常见阈值范围：等待字数128-512，超时15-30ms）。对于部署了Prompt Cache的场景，还需监控cache命中率——命中率低于50%时会显著增加Prefill尖峰，此时应考虑增加公共前缀复用策略或升级模型架构。