vLLM 基准测试实战：4步压低首字延迟

vLLM 基准测试实战4步压低首字延迟【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm把 LLM 服务上线后最意外的往往不是能不能跑而是明明之前挺快。单用户对话没问题并发一上来首字响应翻倍请求开始排队。这篇文章就 vLLM 性能优化这件事带你实操四步怎么测、怎么读数、怎么调参数、怎么上生产不翻车。vLLM 本身是一个高吞吐、省显存的 LLM 推理引擎靠 PagedAttention把 KV 缓存切成固定小块分页管理和连续批处理支撑起了它的性能。而你要做的是搞清楚你的服务到底卡在哪。 怎么测一条命令跑出第一份 vLLM 基准测试先说结论没有基线所有优化都是猜。最小环境准备分两步装上 vLLM把要上线的模型起成一个 OpenAI 兼容服务。git clone https://gitcode.com/GitHub_Trending/vl/vllm cd vllm pip install -e .然后启动服务vllm serve 你的模型 --gpu-memory-utilization 0.90接着跑基准。vLLM 自带vllm bench serve子命令源码在vllm/benchmarks/它会按指定长度随机生成请求、以指定速率打到你的服务上vllm bench serve --dataset-name random \ --input-len 512 --output-len 128 \ --num-prompts 100 --request-rate 10跑完终端会直接打印 TTFT、TPOT、吞吐等汇总完整数据落成一个 json 文件方便后面反复对比。数据集的分布长这样注意--num-prompts和--request-rate就是你的压测强度先低后高一次别打满。 怎么读TTFT、TPOT、吞吐三个数字各指向哪报告里真正重要的数字就三个白话解释一下TTFTTime To First Token请求发出到收到第一个字的时间。它由 prefill 阶段决定——输入多长、前面排了多少队基本都体现在这里。TPOTTime Per Output Token之后每生成一个字的平均耗时。这是 decode 阶段批越大单步计算量越大TPOT 对 batch 敏感。吞吐token/秒整机单位时间的产出。它和单请求延迟是跷跷板关系吞吐涨不代表延迟降。三个数字的组合指向不同瓶颈看什么数字现象瓶颈大概率在哪TTFT高而 TPOT 正常首字慢、生成稳prefill 排队输入长或并发挤TPOT高而 TTFT 正常首字快、越生越慢decode 压力大batch 过满或 KV 缓存吃紧吞吐低两项延迟都正常机器没吃满batch 没填实还有并发余量如果你跑的是 MoE混合专家模型每步只激活部分专家路由不均衡会进一步拉高 TPOT但排查路径一样还是从这三个数字入手。⚙️ 怎么调4 个高杠杆参数的改前改后对比定位到瓶颈后动手。下表按参数 → 改前 → 改后 → 预期变化组织所有幅度都是示例值方向通常成立具体量级必须用你自己的模型和硬件复测。参数改前改后预期变化示例值--gpu-memory-utilization0.90 或默认 0.920.92~0.95以不 OOM 为界KV 缓存变多并发容量上升高并发下 TTFT 下降OOM 就回调--max-num-batched-tokens默认 20484096~8192长 prompt 的 prefill 分更少块TTFT 明显下降TPOT 若被抬升就回调--kv-cache-dtypeauto随计算精度每值 2 字节fp8每值 1 字节KV 显存减半等效并发容量翻倍需抽查输出质量prefix caching未确认可能没开确认开启vLLM 默认开启再用prefix_repetition数据集复测前缀重复率高的场景 TTFT 可降三成以上示例值重复率低则无感逐项说两句--gpu-memory-utilization它决定 vLLM 能吃掉多大比例的 GPU 显存权重 KV 缓存。默认 0.92往上加等于直接扩容 KV 缓存是收益最物理的一个参数。--max-num-batched-tokens每步调度允许处理的最大 token 数默认 2048。长输入的 prefill 会被切成多块调大它等于减少排队块数对输入长、首字慢的场景最直接。--kv-cache-dtype fp8PagedAttention 把 KV 缓存分页管理页里存的就是 fp8 还是 bf16。这一格的结构长这样换成 fp8每值从 2 字节变 1 字节省的是实打实的显存代价是精度风险上线前抽一批样本对比输出。prefix caching同一个 system prompt 或工具说明前缀算过一次就能整段复用 KV。对话、Agent 场景重复率天然高确认它开着比任何调参都便宜。️ 怎么稳上线前检查清单调完参最怕测试里好生产里坏。发布前把下面四项勾完基线落档把这次vllm bench serve的 json 存进版本库以后换模型、升 vLLM 版本、动参数同命令重跑一次只对比数字不凭感觉。阈值告警至少盯两个指标——TTFT 的 P99示例值超过 1s 告警和吞吐相对基线掉 20% 以上告警。阈值按你的业务 SLA 定别照抄。指标都从服务的/metrics端点以 Prometheus 格式暴露接现有监控只配一条抓取。余量体检启动后看日志里的 KV 缓存水位如果常态打满、请求在排队回到上面前两个参数重新调说明容量规划本身就小了。回滚路径旧参数文件留一份新配置先灰度观察一天再放量。监控时把 KV 缓存水位和吞吐放在一起看关系大致如此收尾第一步就一件事拿你现在的模型和并发水平把第一节的vllm bench serve命令跑一遍把 TTFT、TPOT、吞吐抄进一份文档存档。基线有了后面读数、调参、设告警才有得比。参数细节可以翻仓库里的 docs/benchmarking/cli.md 继续往下挖。【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考