vLLM 基准测试只有在其模拟您的应用实际会发送的流量时才有用。一个醒目的每秒 token 数字可能掩盖了缓慢的首个 token、过载的队列，或生产环境中从未出现过的提示词分布。本指南将帮助您进行可重复的服务基准测试：选择工作负载、扫描提供负载、同时记录延迟分布和吞吐量，并在相同质量目标下比较 GPU 配置。
简要回答：在专用 GPU 服务器上，针对固定的 vLLM 版本和模型使用 vllm bench serve。保持模型、精度、提示词和输出长度、采样设置、缓存状态以及客户端位置不变。运行多个请求速率，采集 TTFT、TPOT、端到端延迟、成功请求率和每秒输出 token 数，然后选择在峰值负载下满足服务目标的成本最低配置。单次最大吞吐量测试并不是容量规划。
vLLM 基准测试中应测量什么
| 指标 | 它告诉您的信息 | 常见错误 |
|---|---|---|
| 首个 token 时间（TTFT） | 第一个流式输出到达基准测试客户端之前的延迟 | 只报告平均延迟，而 p95 或 p99 用户仍在队列中等待 |
| 每输出 token 时间（TPOT） | 首个 token 之后的每请求解码时间，在各请求间取平均值 | 在推测解码下，将其视为与每个 token 间隔完全相同 |
| 端到端延迟 | 从提交请求到获得最终输出的时间 | 比较输出长度不同的测试运行 |
| 每秒成功请求数 | 在提供负载下完成的工作量 | 将超时或失败的请求计入容量 |
| 每秒输出 token 数 | 聚合的生成 token 吞吐量 | 未检查延迟目标就按 GPU 价格进行除算 |
| GPU 内存和利用率 | 所选批处理大小、KV 缓存和模型是否能够在保留余量的情况下容纳 | 当队列和尾部延迟已经不达标时，仍将高利用率称为良好 |
vLLM 基准测试文档按测量点定义了 TTFT、token 间延迟和 TPOT。比较工具时请使用这些定义。尤其是，客户端 TTFT 包含传输和前端处理；可选的服务器端指标可以将调度器等待与模型执行分开，但启用它们会增加开销。请将诊断运行与用于展示的结果分开。
运行前固定公平比较条件
记录模型修订版本和分词器、vLLM 版本、GPU 类型和数量、张量并行大小、服务标志、量化格式、上下文长度以及软件环境。对每个候选方案使用相同的提示词和输出目标。如果同时更改模型、精度和 GPU，结果无法告诉您是哪项更改带来了帮助。
至少选择两种工作负载。合成的固定长度工作负载适用于受控扫描；经过脱敏处理的真实请求长度轨迹更适合用于生产决策。保留长提示词、短回答和突发流量的分布。对于聊天产品，请使用相应的基准测试后端来测量聊天端点。对于补全工作负载，请使用补全后端。不要将它们的数字当作请求格式相同来比较。
在运行之前确定通过标准。例如，针对您自己的工作负载，规定所需的成功请求率以及最大的 p95 TTFT 和 p95 端到端延迟。我们不发布通用阈值：它取决于用户体验和输出大小。包含阈值、测量结果以及通过/失败原因的验收表，比单一性能分数更有用。
运行受控服务测试
当前的 vLLM CLI 指南列出了用于在线服务测量的 vllm bench serve，并建议安装 bench extra 以获取其依赖项。以下概述使用 vLLM 文档中的 completions 示例。请将模型和数据集替换为您获得运行许可且适合您硬件的资源。这些命令是可复现的模板，而不是经过测量的 Flatkey 结果。
服务器就绪后，在第二个 shell 中执行：
vllm bench serve \
--backend vllm \
--model YOUR_MODEL_ID \
--endpoint /v1/completions \
--dataset-name sharegpt \
--dataset-path /path/to/ShareGPT_V3_unfiltered_cleaned_split.json \
--num-prompts 1000 \
--request-rate 1 \
--save-result \
--save-detailed然后，在保持其他输入不变的情况下，使用一组较高的 --request-rate
值重复测试。使用足够多的提示词，避免将少量请求误判为尾延迟分布。保存每次运行的原始结果和确切命令。官方在线基准测试示例展示了输出字段，并说明了 --save-result 和 --save-detailed 如何保留证据。对于聊天请求，请使用文档中说明的 openai-chat 后端和 /v1/chat/completions 端点，并搭配支持聊天格式的数据库和模型。
在没有流量计划的情况下，请勿针对共享生产端点运行此基准测试。它会有意制造负载。请使用隔离的测试部署或受控的维护窗口，并记录任何可能影响结果的后台工作。
逐步提高负载，直到找到延迟拐点
在横轴上绘制给定请求速率。将每秒完成请求数、p95 TTFT、p95 端到端延迟和每秒输出 token 数绘制为独立序列。起初，吞吐量可能会随给定负载大致上升。超过可持续区域后，队列会增长，尾延迟会上升，成功吞吐量可能趋于平缓。这个转折点比单次运行中打印出的最大数字更重要。
将预热运行单独处理。vLLM 警告，对同一服务器重复运行基准测试可能会复用缓存前缀并夸大吞吐量。如果缓存复用不是产品工作负载的一部分，请根据官方基准测试指南更改种子，或重置服务器或缓存。如果缓存复用确实符合实际情况，请报告缓存命中率，并包含冷缓存对比。未说明缓存策略的基准测试难以复现。
当一次运行未达到目标时，请检查其过程。TTFT 随队列增长而增加，可能表明出现饱和或准入控制。队列时间稳定但 TPOT 较差，可能表明问题出在解码、内存带宽、并行度或低效的精度选择。如果失败率上升，请在调整模型设置前查看超时、OOM 和服务器日志。一次更改多个变量会掩盖原因。
按被接受的工作量而非原始速度比较 GPU 选项
更大的 GPU 每秒可以生成更多输出 token，但每个被接受请求的成本可能更高。为每种配置计算近似成本：
每 1,000 个成功请求的 GPU 成本 = 每小时 GPU 成本 ÷ 每小时成功请求数 × 1,000
使用针对确切区域和承诺期限的当前报价；如有必要，请纳入非 GPU 基础设施成本或最低计费增量。仅比较满足延迟和错误目标的运行结果。无法达到 p95 TTFT 的较便宜配置，并不是提供相同服务的更便宜方式。
进行初始云端比较时，在仅更改 GPU 规格的同时保持模型和服务配置固定。然后一次只测试少量调优变更，例如批处理和内存设置。记录利用率、VRAM 余量、队列深度、请求成功率和基准测试产物。Flatkey Compute 可以是待评估的容量选项之一；在将其用于成本比较之前，请核实所提供的 GPU、区域和当前报价。本指南并不声称某个特定 GPU 始终更快或更便宜。
可交给审阅者的 vLLM 基准测试结果
对于每次运行，请记录：模型及修订版本；vLLM 和驱动程序版本；GPU 和拓扑；命令和数据集校验和；输入/输出长度分布；客户端位置；缓存策略；请求速率；完成和失败的请求数；p50/p95/p99 TTFT；p50/p95/p99 端到端延迟；输出 token 吞吐量；GPU 利用率和 VRAM；每小时报价；每个被接受请求的成本；以及相对于预先确定目标的通过/失败结果。
此时也应让安全性和质量保持可见。基准测试提示词应清除客户数据，在比较量化模型或不同模型修订版本时，应检查输出质量。改变任务质量的表面速度提升，并非同等条件下的优势。
常见问题
vllm bench throughput 与 vllm bench serve 相同吗？
不。第一个面向离线推理吞吐量；第二个向正在运行的服务器发送在线请求，并衡量面向客户端的服务行为。对于 API 部署的延迟和容量规划，请使用 bench serve。vLLM CLI 参考列出了这两个命令。
我应该先优化哪个指标？
从服务目标开始：预期峰值流量下的成功率和尾延迟。然后，在满足要求的配置中最小化成本。聚合令牌吞吐量有助于诊断容量，但无法替代面向用户的延迟目标。
我可以比较不同提供商发布的基准测试数据吗？
只有在模型、精度、工作负载、输出长度、端点、缓存策略、请求速率范围和测量定义一致时才可以。在大多数情况下，在两个环境中重新运行相同的工作负载，能够得出更具说服力的比较。
下一步：选取一条有代表性的追踪记录，确定通过标准，在两种 GPU 配置上进行简短的速率扫描，并将完整结果与决策一同保存。如果您还在调整精度，请使用单独的 vLLM 量化指南，在将任何速度差异归因于 GPU 之前评估内存和质量。
