【无标题】vLLM：推理吞吐与尾延迟的资源真相

Chunked Prefil 大小影响哪些 影响TPOT 和TTFT。 吞吐吗。 吞吐是怎么定义的 以及QPS怎么定义的以及并发树的关系https://support.huaweicloud.com/intl/en-us/bestpractice-modelarts/modelarts_llm_infer_5906026.htmlReduced latency: By balancing the computational utilization of prefill and decode, it reduces the P90_ttft (time to first token) and P90_tpot (time per output token) latencies, particularly in scenarios with short inputs, short outputs, and high concurrency. 为什么chunked prefillThe user is asking why chunked prefill reduces P90 TTFT and P90 TPOT latencies, particularly in scenarios with short inputs, short outputs, and high concurrency.Chunked Prefill 为什么能降低 P90 TTFT 和 P90 TPOT先理解不启用 Chunked Prefill 的问题问题1长 Prefill 阻塞 DecodeTPOT 抖动不启用 Chunked Prefill 时间轴 ┌─────────────────────────┐┌──┐┌──┐┌──┐ GPU计算 │ 长请求 Prefill(4096tok)││D1││D2││D3│ └─────────────────────────┘└──┘└──┘└──┘ ←────── 很长时间 ─────────→←─短─→ 正在decode的请求(req_old1, req_old2...) 必须等待长Prefill完成 才能做下一步decode ITL(req_old1) 正常decode时间 等待prefill的时间 本来10ms → 变成 200ms 这就是为什么 P90_TPOT 高 高并发下必然有请求撞上长prefill P90就被这些倒霉请求拉高了问题2Decode 阻塞新请求的 PrefillTTFT 抖动不启用 Chunked Prefill 场景高并发running里有100个decode请求 新请求 req_new 进来 等待队列: [req_new] 每轮迭代 running里100个decode请求先处理 剩余token预算 max_num_batched_tokens - 100 3996 req_new 输入 512 tokens 512 3996 ✅ 可以调度 但每轮只能调度1个新prefill 如果waiting里有很多请求排队 waiting: [req_new1, req_new2, req_new3...req_100] req_new1: 本轮调度 → TTFT 1轮等待 req_new2: 下轮调度 → TTFT 2轮等待 req_new3: 下轮调度 → TTFT 3轮等待 ... req_new100: TTFT 100轮等待 P90_TTFT 被排队靠后的请求拉高Chunked Prefill 如何解决核心思路把长 Prefill 切成小块 和 Decode 混合在同一个 batch 里处理 不再是 [────────长Prefill────────][D][D][D] 而是 [Prefill_chunk1][D][D][D][Prefill_chunk2][D][D][D] ←── 每块都很短 ──→ ←── 继续 ──→解决 TPOT 抖动启用 Chunked Prefill max_num_batched_tokens 2048 (每轮token上限) 长请求(4096 tokens)被切成2块 chunk1: 2048 tokens 第1轮处理 chunk2: 2048 tokens 第2轮处理 每轮迭代 decode请求: 100 tokens (100个请求各1token) prefill chunk: 1948 tokens (2048-100) 合计: 2048 tokens ✅ 时间轴 ┌──────────────────────┐ │ decode(100) │ 每轮耗时基本一致 │ prefill_chunk(1948) │ └──────────────────────┘ ┌──────────────────────┐ │ decode(100) │ │ prefill_chunk(1948) │ └──────────────────────┘ decode请求不再被长prefill阻塞 每轮都能推进decode TPOT 变得稳定P90_TPOT 下降解决 TTFT 抖动短输入场景启用 Chunked Prefill 场景短输入请求512 tokens高并发 max_num_batched_tokens 8192 每轮可以同时处理多个短输入的prefill decode请求: 100 tokens prefill req1: 512 tokens prefill req2: 512 tokens prefill req3: 512 tokens prefill req4: 512 tokens ...最多能塞 (8192-100)/512 ≈ 15 个短prefill 不启用时每轮只能处理1个 TTFT(req_15) 15轮等待 启用后每轮处理15个 TTFT(req_15) 1轮等待 P90_TTFT 大幅下降短输入短输出高并发场景的具体分析场景参数 输入长度: 512 tokens (短输入) 输出长度: 128 tokens (短输出) 并发请求: 1000 个 (高并发) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 不启用 Chunked Prefill 每轮只处理1个新prefill waiting里1000个请求 req_900 需要等待900轮才能开始prefill 每轮耗时假设 20ms req_900 的 TTFT 900 × 20ms 18秒 P90_TTFT 900个请求中90%点 ≈ 几秒级别 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 启用 Chunked Prefill max_num_batched_tokens 8192 短输入512tokens每轮可以处理 (8192 - decode消耗) / 512 ≈ 15个新prefill waiting里1000个请求 req_900 需要等待 900/15 60轮 每轮耗时 20ms req_900 的 TTFT 60 × 20ms 1.2秒 P90_TTFT 从18秒 → 1.2秒为什么短输出也是关键条件短输出 请求完成得快 running队列快速释放槽位 短输出场景128 tokens 请求从进入running到完成 128轮decode 128轮后槽位释放新请求进来 长输出场景2048 tokens 请求占用running槽位 2048轮 新请求等待时间更长 即使chunked prefill也难以缓解排队问题 所以 短输入 → 每轮能处理更多prefill → TTFT降低 短输出 → running槽位快速轮转 → 整体吞吐提升 高并发 → chunked prefill的批量 → 优势更明显 处理能力被充分利用本质原因总结┌──────────────────────────────────────────────────────────┐ │ Chunked Prefill 降低延迟的本质原因 │ ├──────────────────────┬───────────────────────────────────┤ │ 问题 │ Chunked Prefill 解法 │ ├──────────────────────┼───────────────────────────────────┤ │ 长Prefill阻塞Decode │ Prefill切块每块不超过token预算 │ │ → TPOT抖动 │ Decode每轮都能推进 │ │ │ → P90_TPOT 稳定下降 │ ├──────────────────────┼───────────────────────────────────┤ │ 每轮只能处理1个 │ 每轮可处理多个短输入prefill │ │ 新Prefill │ 减少waiting队列等待轮数 │ │ → TTFT排队过长 │ → P90_TTFT 大幅下降 │ ├──────────────────────┼───────────────────────────────────┤ │ GPU计算不均衡 │ 每轮token总量固定在 │ │ prefill轮算力爆满 │ max_num_batched_tokens附近 │ │ decode轮算力浪费 │ GPU利用率更稳定均衡 │ └──────────────────────┴───────────────────────────────────┘ 一句话 Chunked Prefill 把大块不均衡的计算 变成小块均衡的计算 让Prefill和Decode不再互相长时间阻塞 从而降低P90_TTFT和P90_TPOTChunked Prefil 大小影响哪些 影响TPOT 和TTFT。 吞吐吗。 吞吐是怎么定义的 以及QPS怎么定义的以及并发树的关系Chunked Prefill 对性能指标的影响对 TTFT 和 TPOT 的影响Chunked Prefill 大小主要通过max_num_batched_tokens参数控制对延迟指标有显著影响 1较小值如 2048获得更好的 ITLInter-Token Latency因为 prefill 对 decode 的干扰更少较大值获得更好的 TTFTTime to First Token因为可以在批处理中处理更多 prefill token推荐值 8192 以获得最佳吞吐量对吞吐量的影响吞吐量定义在 vLLM 中吞吐量有多个维度 2classBenchmarkMetrics:request_throughput:float# 请求吞吐量 (req/s)output_throughput:float# 输出 token 吞吐量 (tok/s)total_token_throughput:float# 总 token 吞吐量 (tok/s)Chunked Prefill 通过以下方式影响吞吐量提高 GPU 利用率混合计算密集型prefill和内存密集型decode操作减少阻塞分块处理避免长 prefill 阻塞 decode 请求优化批处理更灵活的 token 预算分配QPS 定义QPS (Queries Per Second)等同于request_throughput表示每秒完成的请求数 3request_throughputcompleted/dur_s,并发数关系并发数与吞吐量的关系并发数上限由max_num_seqs控制 4实际并发受 token 预算和 KV cache 限制吞吐量优化增加并发数通常提高吞吐量但可能增加延迟默认值设置系统根据硬件自动设置默认值 5# H100/MI300x 等高端 GPUdefault_max_num_batched_tokens{UsageContext.LLM_CLASS:16384,UsageContext.OPENAI_API_SERVER:8192,}性能调优建议目标Chunked Prefill 设置其他参数低延迟较小值 (2048-4096)减少max_num_seqs高吞吐较大值 (8192)增加max_num_seqs平衡中等值 (4096-8192)根据负载测试调整NotesChunked Prefill 是 vLLM V1 的默认行为显著改善了混合负载性能实际性能需要通过vllm bench serve工具测试验证QPS 和吞吐量指标可通过 Prometheus 端点监控并发数、延迟和吞吐量之间存在权衡关系Wiki pages you might want to explore:Configuration and Initialization (vllm-project/vllm)Metrics and Observability (vllm-project/vllm)Wiki pages you might want to explore:Model Correctness Validation (vllm-project/vllm)Configuration and Initialization (vllm-project/vllm)CitationsFile:docs/configuration/optimization.md (L54-59)You can tune the performance by adjusting max_num_batched_tokens: - Smaller values (e.g., 2048) achieve better inter-token latency (ITL) because there are fewer prefills slowing down decodes. - Higher values achieve better time to first token (TTFT) as you can process more prefill tokens in a batch. - For optimal throughput, we recommend setting max_num_batched_tokens 8192 especially for smaller models on large GPUs. - If max_num_batched_tokens is the same as max_model_len, thats almost the equivalent to the V0 default scheduling policy (except that it still prioritizes decodes).File:vllm/benchmarks/serve.py (L171-179)classBenchmarkMetrics:completed:intfailed:inttotal_input:inttotal_output:intrequest_throughput:floatrequest_goodput:floatoutput_throughput:floattotal_token_throughput:floatFile:vllm/benchmarks/serve.py (L567-568)request_throughputcompleted/dur_s,request_goodputgood_completed/dur_s,File:vllm/engine/arg_utils.py (L2048-2065)default_max_num_batched_tokens{UsageContext.LLM_CLASS:16384,UsageContext.OPENAI_API_SERVER:8192,}default_max_num_seqs{UsageContext.LLM_CLASS:1024,UsageContext.OPENAI_API_SERVER:1024,}else:# TODO(woosuk): Tune the default values for other hardware.default_max_num_batched_tokens{UsageContext.LLM_CLASS:8192,UsageContext.OPENAI_API_SERVER:2048,}default_max_num_seqs{UsageContext.LLM_CLASS:256,UsageContext.OPENAI_API_SERVER:256,}Chunked Prefill 的大小本质上由max_num_batched_tokens控制。它通过在 batch 中混合 prefill 和 decode 请求改变了 GPU 的计算模式从而在 TTFT、TPOT 和吞吐量之间引入了一种新的权衡关系。简单来说更大的 Chunk由更大的max_num_batched_tokens决定会提升吞吐量但可能稍微增加 TTFT而更小的 Chunk 则有助于稳定 TPOT 并降低尾延迟。1. Chunked Prefill 大小如何影响关键指标结合 vLLM 的调度逻辑和社区分析其影响机制如下指标影响机制对 Chunk 大小的选择吞吐量 (Throughput)Chunked Prefill 将长 prompt 切分并用 decode token 填充计算间隙使 GPU 保持高利用率。更大的 Chunk更大的max_num_batched_tokens意味着单次迭代处理更多 tokenGPU 算力更饱和从而提升吞吐量。追求高吞吐 →调大 ChunkTTFT (首 Token 延迟)TTFT 主要受 prefill 完成时间影响。较大的 Chunk 能更快地完成 prompt 的处理有助于降低 TTFT。但若 Chunk 过大可能会在调度时因等待资源而略有增加。追求低 TTFT →调大 Chunk(但需权衡)TPOT (每 Token 延迟)Chunked Prefill 的核心优势之一是稳定 TPOT。通过将 prefill 打散避免了大段 prefill 阻塞 decode 请求从而减少了 TPOT 的抖动。然而如果 Chunk 设置得过大它仍然会挤占 decode 的计算资源导致 TPOT 平均值略微上升。追求稳定 TPOT →启用功能追求最低 TPOT 平均值 →调小 ChunkvLLM 官方文档也指出Chunked Prefill 通过有效管理块大小提供了对 TPOT 更可靠的控制。而解耦预填充Disaggregated Prefill则是另一种更彻底但更复杂的优化方案专门用于在极大规模下控制尾延迟。2. 吞吐量 (Throughput)、QPS 与并发数的定义及关系在 vLLM 和在线推理系统中这三个概念需要被清晰地区分吞吐量 (Throughput)通常指系统在单位时间内生成的 Token 总数单位是tokens/s。它衡量的是 GPU 等硬件的计算效率。QPS (Queries Per Second)指系统每秒能够处理的请求数量单位是req/s。它衡量的是系统的业务处理能力。并发数 (Concurrency)指系统在同一时刻正在处理尚未完成的请求数量。这是 vLLM 调度器running队列中的请求数。它们之间最重要的关系是在固定的硬件和模型下吞吐量tokens/s ≈ QPSreq/s × 平均输出长度tokens/req。这意味着如果服务的平均输出长度较长即使 QPS 不高系统吞吐量tokens/s也会很高。此外QPS 和并发数通过Little‘s Law关联并发数 ≈ QPS × 平均响应时间。因此在目标 QPS 下平均响应时间TTFT TPOT × 输出长度越长系统需要维持的并发数就越高对显存KV Cache的压力也越大。3. 结合 vLLM 代码的深入分析vLLM 的基准测试工具清晰地区分了这三种指标吞吐量测试固定输入/输出长度让系统自动决定 batch 大小测量Throughput (tokens/s)。延时测试固定 batch size如 8测量端到端延迟Latency关注平均值和 P99。Serving 测试模拟真实请求流设置不同的目标QPS如 1, 4, 16测量在不同负载下的Throughput, TTFT, ITL。从代码调度逻辑看max_num_batched_tokens是连接吞吐和延时的关键。它决定了每一“步”StepGPU 前向计算处理的总 token 数。vLLM 通过连续批处理Continuous Batching在每个 Step 中动态决定 batch 大小和组成。当max_num_batched_tokens较大时每个 Step 可以处理更多 tokenGPU 利用率高吞吐量也随之提升。同时为了填满这个较大的 token budget调度器可能会让一些请求等待以组成一个更大的 batch。这个等待过程会增加TTFT并可能影响TPOT的稳定性。Chunked Prefill 正是利用了这个max_num_batched_tokens的预算将原本一个巨大的 prefill 请求“切碎”与其他 decode 请求混合从而在保持高吞吐的同时平衡了 TTFT 和 TPOT。总结Chunked Prefill 的大小由max_num_batched_tokens控制是平衡吞吐量、TTFT 和 TPOT 的核心旋钮。更大的 Chunk 倾向于提升吞吐并可能降低 TTFT但会对 TPOT 产生轻微压力。启用该功能本身就是为了通过混合 prefill 和 decode 来稳定 TPOT避免长请求带来的延迟抖动。吞吐tokens/s是硬件效率指标QPSreq/s是业务吞吐指标两者通过“平均输出长度”关联而并发数则是系统在时间窗口内处理请求的“库存”由 QPS 和响应时间共同决定。在生产环境中理解这三者的关系才能正确地配置 vLLM 参数在目标 QPS 下将 TTFT 和 TPOT特别是 P99 值控制在可接受的 SLO服务等级目标范围内。vLLM推理吞吐与尾延迟的资源真相混合长短请求但不做队列隔离或优先级典型表现短请求的 p99 被长请求拖到不可用用户感知为“突然卡住”。原因continuous batching 在追求整体吞吐时可能让短请求等待更久以换取更大的批次长请求又延长了序列驻留时间。 这里的短请求是指什么回复长度短还是prompt 短。整体吞吐时可能让短请求等待更久以换取更大的批次 是为什么 从代码角度讲vllm v1 对吗Reduced latency: By balancing the computational utilization of prefill and decode, it reduces the P90_ttft (time to first token) and P90_tpot (time per output token) latencies, particularly in scenarios with short inputs, short outputs, and high concurrency. 描述的对吗The user is asking about whether the description of vLLM v1’s latency reduction is correct, specifically about P90_TTFT and P90_TPOT.分析这个描述的准确性这个描述部分正确但有几处值得推敲✅ 正确的部分vLLM v1 确实引入了更好的prefill/decode 调度机制chunked prefill确实能降低某些场景下的延迟⚠️ 存疑/不准确的部分问题点说明P90_TPOTTPOT 主要受 decode 阶段影响prefill/decode 平衡对它的改善有限且间接短输入短输出场景Chunked prefill 的收益更多体现在长输入场景短输入场景 prefill 本身不是瓶颈高并发场景说法相对合理高并发时 prefill 抢占 decode 资源的问题更突出“balancing computational utilization”表述不够精确核心机制是chunked prefill将大 prefill 拆分避免阻塞 decode 更准确的描述应该是vLLM v1 通过chunked prefill机制将长 prefill 请求拆分为小块与 decode 交错执行主要改善了长输入、高并发场景下的TTFT避免 decode 被长 prefill 阻塞导致的 TPOT 抖动结论描述方向对但细节上对适用场景和指标的对应关系描述不够准确。https://git.modelhub.org.cn:9443/EngineX-Ascend/enginex-ascend-910-vllm/src/commit/03f1343d469fbc4c3ee114c894c9cadd1ab0f906/benchmarks