AI 推理平台性能基准测试搭建步骤
依据 MLPerf、vLLM 与 FastAPI 官方文档搭建推理服务基准测试，采集吞吐、TTFT 和 TPOT，并说明资源占用需另按项目监控文档核验。
搭建大模型部署的性能基准测试，先固定被测系统、测试场景、数据集、负载参数和统计口径，再运行客户端压测并复核报告。完整结果必须能追溯到同一份配置和指标定义；只保留一个平均延迟或吞吐数字，不能证明结果可复现。
大模型部署基准测试前要准备什么
先建立被测系统清单，至少记录模型与版本、量化设置、推理服务和运行时版本、启动参数、GPU 型号及显存、驱动、容器镜像、数据集版本与 endpoint。模型、硬件、软件或启动参数发生变化时，应建立新的测试配置，不要与旧结果直接合并。
如果 API 层使用 FastAPI，先确认返回路径确实逐块输出。FastAPI 的 StreamingResponse 指南说明，path operation 声明 response_class=StreamingResponse 后可以用 yield 逐块发送数据，但应用仍负责生成和编码字节。若接口实际一次性返回完整 JSON，就不能把结果解释为流式 TTFT 或 ITL。
选择场景并统一指标
如果目标是 MLPerf Inference，应按 MLPerf Inference Rules选择场景。提交必须使用 LoadGen，由它按场景生成查询、跟踪延迟、验证准确率并计算最终指标。
| 场景 | 请求方式 | 约束与结果 |
|---|---|---|
| Server | 按 Poisson 分布发送查询 | 使用 benchmark-specific latency constraint，指标为可支持的最大 Poisson throughput |
| Offline | 启动时以单个 query 发送全部样本 | 没有 latency constraint，指标为 measured throughput |
| Single stream | 上一个请求完成后发送下一个 | 指标为 90th-percentile early-stopping latency estimate |
对 LLM，MLPerf 还收集首 token 延迟 TTFT，以及生成 token 之间的平均间隔 TPOT；Server 的延迟约束按类别写成 TTFT/TPOT limit pair。记录结果时必须同时保留场景、约束和指标定义，不能只抄一个数值。
下载数据并执行 vLLM 在线基准
以下地址、命令、参数与报告定义均以 vLLM Benchmark CLI 文档为准。该文档把 vllm bench 定位为功能评估和回归测试工具，ShareGPT 可用于在线和离线基准。
先下载文档给出的 ShareGPT 文件：
wget https://huggingface.co/datasets/anon8231489123/ShareGPT_Vicuna_unfiltered/resolve/main/ShareGPT_V3_unfiltered_cleaned_split.json
被测服务能够响应后，执行在线基准命令：
vllm bench serve \
--backend vllm \
--model NousResearch/Hermes-3-Llama-3.1-8B \
--endpoint /v1/completions \
--dataset-name sharegpt
远程 endpoint 的连接参数没有包含在这条命令中，应按当前版本 CLI 文档补齐，不要猜测参数名。若改用自有数据，文档要求文件采用 .jsonl 格式，每条记录包含 prompt 字段，并通过 --dataset-name custom 选择；文件路径参数同样应以当前 CLI 文档为准。
| 参数 | 文档定义 |
|---|---|
--request-rate |
设置每秒目标请求数；inf 表示最大吞吐测试，默认值也是 inf，会立即发送全部请求 |
--max-concurrency |
限制尚未完成的请求数；不提供时并发数不受限制 |
--burstiness |
使用 Gamma 分布控制流量波动，范围为 > 0；1.0 对应 Poisson 流量，较低值更集中突发，较高值更均匀 |
--ramp-up-strategy |
请求速率可按 linear 或 exponential 策略逐步提升 |
报告应包含 request throughput、output-token throughput 和 total-token throughput。TTFT 在客户端测量，从发送请求到收到首个 streamed output；ITL 是连续 streamed output 之间的间隔，并汇总成功请求；TPOT 则按请求计算，排除首 token 后再跨请求汇总。
还要记录两个容易影响解释的情况：重复对同一服务器运行 vllm bench serve，可能复用 prefix cache 中的 prompt 并抬高 throughput；使用 speculative decoding 时，一个 streamed output 可能包含多个 token，因此 ITL 与 TPOT 会分离。不同工具的指标名称并未统一，不能只按相同名称认定口径相同。
如何确认结果可用
按以下顺序复核：
- 配置一致：确认模型、数据集、endpoint、请求速率、并发限制、流量分布和爬升策略均有记录。
- 报告完整：检查请求吞吐、两类 token 吞吐以及 TTFT、ITL、TPOT 是否齐全，并确认单位与汇总方式。
- 比较条件一致：不要把 Server、Offline、Single stream 的结果混在一起，也不要把最大吞吐测试与固定请求速率测试直接对比。
- 资源占用单列：吞吐和延迟不能替代显存、功耗或利用率记录。相关采集方法取决于所用项目当前监控文档，不应从吞吐结果反推。
常见出错点
最常见的问题是接口并未真正流式返回、不同报告使用不同指标定义，以及重复测试受到 prefix cache 影响。工具链还要检查维护状态：NVIDIA 的 GenAI-Perf README表明该工具已不再积极开发新功能，并将新的性能基准测试需求指向 AIPerf。已有脚本应单独保留结果，新工具则应先按当前文档核对命令和指标定义，不能直接假设参数兼容。
本文步骤依据正文链接的官方文档整理，使用前应按当前版本复核。