5 类场景实测 vLLM 性能基准测试完整指南3 步跑通【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm模型用 vLLM 跑起来了但用户嫌慢你却说不出慢在哪没有一组 vLLM 性能基准测试数据任何优化都是凭感觉。vLLM 是面向大语言模型的高吞吐推理与部署引擎内置的vllm bench命令行可以直接压测延迟、吞吐和缓存复用效果。本文按 5 个真实场景走一遍从安装到出第一组数字只需 3 步再讲清楚每个指标怎么读、哪些配置值得试、重复测试为什么会虚高。全程不堆理论命令都能直接复制。先搞清楚什么场景该做 vLLM 基准测试不是所有时候都值得压测。挑对时机结果才有用。新模型或新显卡上线换了模型、换了显卡、改了张量并行度吞吐量变化可能很大。上线前跑一轮离线吞吐测试拿到一个可对比的基线出问题才知道是回归还是负载变了。版本升级前后对比vLLM 迭代很快。升级前记录一版结果升级后同参数重跑数字掉了能立刻定位——注意两边数据集、并发、seed 必须完全一致否则对比无效。生产 SLA 验收用户要求P99 首 token 不超 500ms这类指标时用vllm bench serve在接近生产负载的压力下实测比口头承诺可信。启动日志里会打印 KV 缓存容量和理论最大并发约等于 KV 缓存 token 数除以max_model_len用它设置压测并发测出来的 SLA 数据才站得住。5 分钟跑通第一组数字最小路径只有三步装依赖、起服务、跑离线压测。安装与环境从仓库安装开发版git clone https://gitcode.com/GitHub_Trending/vl/vllm cd vllm pip install -e .启动服务并压测vllm serve NousResearch/Hermes-3-Llama-3.1-8B然后另开终端用仓库自带的 sonnet 语料打离线吞吐测试vllm bench throughput \ --model NousResearch/Hermes-3-Llama-3.1-8B \ --dataset-name sonnet \ --dataset-path vllm/benchmarks/sonnet.txt \ --num-prompts 10输出会直接给出请求吞吐和总 token 吞吐如4656 total tokens/s。这是你的第一组基线数字。在线压测看延迟想模拟真实服务场景换成vllm bench serve它会对运行中的服务发请求并统计延迟。官方示例用的是 ShareGPT 数据集也可以指定--dataset-name random用合成数据省掉下载步骤。读报告4 个指标决定你怎么调参压测报告里数字很多盯住这 4 个就够。指标含义何时关注偏高先查什么TTFT 首 token 时间请求发出到收到第一个 token 的耗时聊天机器人、流式回答输入长度、max-num-batched-tokensTPOT 每 token 时间(端到端耗时 − TTFT) ÷ (输出 token 数 − 1)长文本生成、打字机体验批大小、注意力后端ITL token 间隔相邻两次流式输出之间的间隔观察输出是否卡顿调度与显存压力吞吐 (tok/s)每秒处理的总 token 数容量规划、成本核算并发数是否打满 KV 缓存两点容易踩错标准解码下 ITL 和 TPOT 通常接近但开投机解码后一次输出可能带多个 tokenTPOT 会把时间摊到所有 token 上两个指标就不再相等。并发别拍脑袋。用启动日志的 KV 缓存容量做参照容量规划压到理论最大并发的 80%~90%SLA 验收压到理论上限两种目的参数不同。实战对比让数据替你做决定用 sweep 自动扫参数手动改参数重启服务太慢。vllm bench sweep serve可以读一份 JSON自动对每组配置重启服务、各跑多轮默认 3 轮并清缓存vllm bench sweep serve \ --serve-cmd vllm serve meta-llama/Llama-2-7b-chat-hf \ --bench-cmd vllm bench serve --model meta-llama/Llama-2-7b-chat-hf --dataset-name random \ --serve-params serve_params.json \ --output-dir resultsserve_params.json里写参数组合即可例如{max_num_seqs: 64, max_num_batched_tokens: 2048}。优化目标关键参数建议试的值看完什么压低单请求延迟max-num-batched-tokens4096TTFT 是否下降、吞吐是否可接受拉高并发吞吐max-num-seqs128吞吐拐点出现在哪省显存kv-cache-dtypefp8缓存容量变化与精度影响前缀缓存对结果的影响聊天场景里大量请求共享系统提示词前缀缓存会直接改写 TTFT 和吞吐。验证方法同一条长提示重复发 100 次开和关--enable-prefix-caching各测一遍命中率越高差距越明显。下面是 KV 缓存在混合注意力下分块存储的布局示意理解按块复用对读数很有帮助4 个常见坑先排雷再读数重测结果虚高对同一服务反复跑基准测试第二轮起提示词命中前缀缓存吞吐会不真实地变高。要么换 seed、重启服务要么直接用 sweep它每轮之间自动调缓存重置接口。并发超出 KV 缓存上限并发设太高请求会排队等显存延迟飙升但吞吐不涨。先看启动日志的Maximum concurrency再回头调--max-concurrency。投机解码下 ITL ≠ TPOT开了 ngram 之类的投机解码后一次流式输出可能含多个 tokenITL 只统计输出间隔、TPOT 按 token 数摊薄二者会明显不同。报告里别拿 ITL 当 TPOT 汇报。只看延迟不看 GPU 利用率延迟不达标时先确认 GPU 是否打满。利用率长期低于六成多半是参数或并发没配够而不是引擎本身慢。进阶把压测变成持续习惯扫描负载找拐点sweep serve_workload按并发或请求率逐档加压帮你找到延迟和吞吐的权衡点再据此定生产并发上限。用可视化定位问题给vllm bench serve加--plot-timeline --plot-dataset-stats会生成请求时间线 HTML 和数据集 token 分布图。某类请求的长尾出现在哪个阶段一眼可见。固定基线进 CI数据集、seed、并发、参数组合写进脚本每次发版自动跑。数字一波动就知道是哪次变更引入的——这才是基准测试的长期价值。总结vLLM 基准测试不神秘选对场景上线、升级、SLA 验收用vllm bench的 throughput/serve/sweep 三个子命令读透 TTFT、TPOT、ITL 和吞吐四个指标避开缓存复用虚高这类坑。最后一条建议今天就用 sonnet 语料跑一遍离线吞吐把数字记下来——没有基线一切优化都是空谈。【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考