4、基准测试工具与框架：常用工具如vLLM benchmark、LLMPerf、lm-evaluation-harness、自定义脚本的选型与配置

在vLLM性能调优的工程实践中，基准测试工具的选择直接决定了调优方向的准确性与效率。不同工具在测量粒度、负载模型、指标口径上差异显著——有的工具擅长压测吞吐量，有的专注于端到端延迟分布，有的则面向模型质量评估而非性能。若选型不当，轻则测得数据无法指导调优，重则因指标口径不一致导致误判瓶颈。本章将系统梳理vLLM生态中最常用的四类基准测试工具，从核心原理、操作流程、实战案例到常见误区，帮助读者建立一套科学的工具选型与配置方法论。

vLLM基准测试工具选型与配置决策框架 测试目标定义 vLLM benchmark 吞吐量 / 首token延迟 / TTFT LLMPerf 端到端延迟 / 并发控制 / 分位数 lm-evaluation-harness 模型质量 / 任务准确率 / 困惑度 自定义脚本 混合负载 / 业务模拟 / 长尾场景 选型决策条件 • 吞吐量优先 → vLLM benchmark（固定并发、连续请求、测量聚合吞吐） • 延迟敏感 → LLMPerf（可变并发、记录每次请求延迟、输出P50/P95/P99） • 质量验证 → lm-evaluation-harness（标准任务集、与性能数据交叉验证） • 业务仿真 → 自定义脚本（真实请求序列、混合输入长度、超时重试逻辑） • 组合策略：先vLLM benchmark粗筛 → LLMPerf细测延迟 → 自定义脚本验证业务场景

上图展示了四类工具在测试目标上的分工与决策路径。实际项目中，它们并非互斥关系，而是形成“粗筛—细测—验证”的递进链路。下面逐一展开每类工具的核心原理、配置要点与实战经验。

4.1 vLLM benchmark：吞吐量与首Token延迟的快速压测

核心原理

vLLM benchmark是vLLM官方仓库自带的性能测试脚本，位于benchmarks/benchmark_serving.py和benchmark_throughput.py。其核心原理是：通过HTTP请求向vLLM服务发送固定数量的请求，记录每个请求的发送时间、首token到达时间、完整响应时间，进而计算吞吐量（requests/s或tokens/s）、首token延迟（TTFT）和端到端延迟。该工具最大的优势在于与vLLM服务深度集成，能直接利用vLLM的--metrics接口获取细粒度性能计数，且支持连续请求与突发请求两种模式。

操作流程与关键参数

# 启动vLLM服务（示例：Llama-3-8B，A100-80G）
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-3-8B \
    --tensor-parallel-size 1 \
    --max-model-len 4096 \
    --gpu-memory-utilization 0.90

# 运行benchmark_serving.py
python benchmarks/benchmark_serving.py \
    --backend vllm \
    --model meta-llama/Llama-3-8B \
    --tokenizer meta-llama/Llama-3-8B \
    --dataset sharegpt \
    --num-prompts 500 \
    --request-rate 20 \
    --max-concurrency 50 \
    --output-json result.json

关键参数说明：--request-rate控制每秒发送的请求数，设置为inf表示以最大速率发送（压测极限吞吐）；--max-concurrency限制同时处理的请求数，模拟真实并发场景；--dataset支持sharegpt、sonnet等预设数据集，也可通过--dataset-path指定自定义JSONL文件。输出JSON中包含avg_tpot（平均每个输出token耗时）、avg_e2e_latency（端到端平均延迟）、p99_tpot等指标。

案例拆解：吞吐量瓶颈定位

某团队部署Llama-3-70B（4卡A100-80G，张量并行=4），初始配置下测得吞吐量仅320 tokens/s，远低于预期。通过vLLM benchmark的--output-json输出发现：avg_tpot为45ms，但p99_tpot高达120ms，且avg_num_preemptions（抢占次数）为0.8次/请求。分析判断：高p99延迟源于KV cache碎片化导致的显存不足，触发隐式抢占。操作步骤：①将--gpu-memory-utilization从0.85提升至0.92；②启用--enable-chunked-prefill（块状预填充）；③将--max-num-seqs从256降至128。调整后重新压测，吞吐量提升至480 tokens/s，p99_tpot降至65ms。复盘经验：vLLM benchmark的抢占计数指标是判断显存压力的关键信号，不应只关注平均延迟。

风险提示：vLLM benchmark的--request-rate设置为inf时，会以最快速度发送请求，可能导致客户端本身成为瓶颈（如socket连接数耗尽）。建议先以--request-rate 50起步，逐步增加，观察吞吐量是否线性增长，若增长停滞则需检查客户端资源。

4.2 LLMPerf：延迟分布与并发控制的精细化测量

核心原理

LLMPerf是微软开源的LLM性能测试工具，其设计哲学是“以客户端为中心”的负载生成。与vLLM benchmark不同，LLMPerf不依赖vLLM内部指标，而是完全基于HTTP响应时间戳计算延迟，因此适用于任何OpenAI兼容API服务。它支持三种负载模式：固定并发（constant）、逐步增加并发（step）、随机到达（poisson），能输出完整的延迟分布直方图与分位数表。

配置与执行

# 安装
pip install llmperf

# 运行（以Poisson到达模式为例）
llmperf \
    --model meta-llama/Llama-3-8B \
    --max-concurrency 100 \
    --num-requests 1000 \
    --arrival-rate 20 \
    --input-tokens-mean 512 \
    --input-tokens-stddev 128 \
    --output-tokens-mean 256 \
    --output-tokens-stddev 64 \
    --endpoint http://localhost:8000/v1/completions \
    --api-key dummy \
    --output-dir ./results

LLMPerf的独特优势在于--input-tokens-mean/stddev和--output-tokens-mean/stddev参数，可模拟真实业务中请求长度不均衡的情况。输出结果包含latency_percentiles.json（P50/P90/P95/P99）、throughput.json（每秒请求数、每秒token数）、timeline.json（每次请求的详细时间线）。

实战场景：延迟SLA验证

某金融客户要求P95端到端延迟不超过2秒。使用LLMPerf以Poisson模式（平均到达率15 req/s，输入token均值800，输出均值200）压测，结果P95为2.8秒，不达标。进一步分析timeline.json发现：延迟主要发生在time_to_first_token阶段（平均1.9秒），而inter_token_latency仅15ms。判断瓶颈在prefill阶段。操作：将--enable-chunked-prefill与--max-num-batched-tokens从4096降至2048，使prefill与decode交错执行。重新测试P95降至1.6秒。复盘：LLMPerf的时间线拆解能力（区分TTFT与TPOT）是定位延迟瓶颈的关键，而vLLM benchmark的聚合指标无法提供此粒度。

经验提醒：LLMPerf的--arrival-rate参数应基于生产环境的真实QPS设定，而非随意指定。若生产环境有峰值波动，建议使用--arrival-rate-multiplier模拟突发流量（如2倍峰值持续30秒）。

4.3 lm-evaluation-harness：模型质量与性能的交叉验证

核心原理

lm-evaluation-harness（EleutherAI出品）是评估LLM任务准确率的标准化工具，支持MMLU、HellaSwag、GSM8K、HumanEval等数十个基准任务。虽然它不直接测量性能指标，但在调优过程中不可或缺——因为性能优化不能以牺牲模型质量为代价。例如，量化（AWQ/GPTQ）或KV cache量化可能提升吞吐量但降低准确率，必须通过该工具验证。

配置与执行

# 安装
pip install lm-eval

# 运行MMLU任务（5-shot）
lm_eval --model vllm \
    --model_args pretrained=meta-llama/Llama-3-8B,tensor_parallel_size=2,dtype=bfloat16 \
    --tasks mmlu \
    --num_fewshot 5 \
    --batch_size auto \
    --output_path ./eval_results/mmlu.json

关键点：--model vllm表示通过vLLM后端加载模型，这样评估时也走vLLM推理引擎，确保与生产环境一致。--batch_size auto让工具自动选择最优batch大小，避免OOM。输出结果包含每个子任务的准确率、标准差，以及总体平均分。

案例：量化调优的质量验证

某团队将Llama-3-8B从FP16改为AWQ 4bit量化后，vLLM benchmark显示吞吐量提升1.8倍，但MMLU准确率从68.2%降至64.5%，下降3.7个百分点。进一步用lm-evaluation-harness测试GSM8K（数学推理），准确率从52.1%降至47.8%。分析判断：量化对推理类任务影响更大。操作：改用GPTQ 4bit（group_size=128）重新量化，MMLU回升至66.8%，GSM8K回升至50.2%，吞吐量仍提升1.5倍。复盘：性能调优必须建立“质量回归基线”，建议每次调优后运行至少3个代表性任务（如MMLU、GSM8K、HellaSwag），并设置质量下降阈值（如不超过1个百分点）。

风险提示：lm-evaluation-harness的--batch_size auto在vLLM后端下可能因显存不足而失败。建议先手动设置--batch_size 16测试，再逐步增大。另外，评估结果受--num_fewshot影响显著，不同模型对比时必须保持相同的fewshot设置。

4.4 自定义脚本：业务场景的精确仿真

核心原理

当标准工具无法模拟特定业务模式时（如多轮对话、混合长度请求、带超时重试逻辑），需要编写自定义压测脚本。其核心价值在于：①精确控制请求内容分布（如20%短问题+80%长文档）；②模拟客户端行为（如用户思考时间、重试策略）；③采集业务级指标（如首token响应时间、完整回复时间、错误率）。

实现框架与关键代码

import asyncio
import aiohttp
import time
import json
import random

async def send_request(session, prompt, max_tokens):
    start = time.monotonic()
    payload = {
        "model": "meta-llama/Llama-3-8B",
        "prompt": prompt,
        "max_tokens": max_tokens,
        "temperature": 0.7
    }
    try:
        async with session.post("http://localhost:8000/v1/completions",
                                json=payload, timeout=aiohttp.ClientTimeout(total=30)) as resp:
            data = await resp.json()
            ttft = data.get("timings", {}).get("first_token_time", None)
            e2e = time.monotonic() - start
            return {"ttft": ttft, "e2e": e2e, "status": resp.status}
    except asyncio.TimeoutError:
        return {"ttft": None, "e2e": time.monotonic() - start, "status": 408}

async def main():
    prompts = load_prompts("business_prompts.jsonl")  # 业务真实请求
    async with aiohttp.ClientSession() as session:
        tasks = []
        for p in prompts:
            tasks.append(send_request(session, p["text"], p["max_tokens"]))
            await asyncio.sleep(random.uniform(0.5, 2.0))  # 模拟用户思考时间
        results = await asyncio.gather(*tasks)
        # 计算P50/P95/P99、错误率、超时率
        analyze(results)

if __name__ == "__main__":
    asyncio.run(main())

该脚本模拟了真实用户“思考-请求-等待”的循环，并记录每次请求的TTFT与端到端延迟。相比标准工具，它能捕捉到“请求间隔不均匀”对服务端排队的影响。

案例：多轮对话场景的压测

某客服机器人场景，每轮对话平均包含3轮交互，每轮输入token约200-500，输出约100-300。使用vLLM benchmark（固定请求率）测得P95延迟1.2秒，看似达标。但自定义脚本模拟真实对话序列（连续3轮，每轮间隔1-3秒）后，发现第3轮P95延迟飙升至3.5秒。分析判断：多轮对话的KV cache累积导致显存压力增大，触发抢占。操作：在vLLM服务中启用--enable-prefix-caching（前缀缓存），并设置--max-num-seqs为64。重新压测，第3轮P95降至1.8秒。复盘：标准工具的单轮请求无法暴露多轮场景的显存累积问题，自定义脚本是验证业务真实体验的必要手段。

选型总结：四类工具形成互补矩阵——vLLM benchmark用于快速获取吞吐量基线；LLMPerf用于延迟分布与并发模型验证；lm-evaluation-harness用于质量回归；自定义脚本用于业务场景仿真。建议在每次调优迭代中，先跑vLLM benchmark（5分钟）确认吞吐量变化，再跑LLMPerf（10分钟）验证延迟分位数，最后用lm-evaluation-harness（15分钟）确保质量不降级。若涉及多轮对话或特殊负载，再补充自定义脚本。

4.5 常见误区与复盘

  • 误区一：只关注平均延迟。平均延迟掩盖了长尾问题。必须同时查看P95/P99，并关注max_latency。vLLM benchmark的--output-json中p99_tpot是必看指标。
  • 误区二：忽略预热阶段。vLLM服务启动后前几十个请求会经历CUDA kernel编译、显存分配等冷启动过程。建议丢弃前10%的请求数据，或先发送50个预热请求。
  • 误区三：不同工具间直接对比数据。vLLM benchmark的avg_e2e_latency包含客户端发送时间，而LLMPerf的e2e_latency从请求发出到响应完成计时，两者口径不同。对比时必须使用同一工具。
  • 误区四：忽略客户端瓶颈。当并发数超过500时，客户端（如Python aiohttp）可能成为瓶颈。建议使用多客户端分布式压测，或使用wrk/ghz等高性能工具。
  • 误区五：质量评估与性能测试分离。只测性能不测质量，可能导致量化或KV cache优化后模型能力下降而不自知。必须建立“性能+质量”双指标基线。

总结：基准测试工具选型不是“选一个最好的”，而是根据测试目标组合使用。vLLM benchmark解决“快不快”，LLMPerf解决“稳不稳”，lm-evaluation-harness解决“好不好”，自定义脚本解决“像不像”。在调优循环中，建议将四者纳入CI/CD流水线，每次代码或配置变更后自动触发，形成性能回归保护网。

← 上一章 📖 返回目录 下一章 →