GPUBench：面向 vLLM 的单卡推理压测工具与延迟-吞吐量膝点分析

GPUBench 是专为 vLLM 设计的单 GPU 大语言模型推理基准测试框架。其核心特点包括：采用协调遗漏正确的负载生成策略，关联服务延迟与 GPU 遥测数据，精准定位延迟-吞吐量膝点，并与 vLLM 官方 bench serve 交叉验证。 原作者/维护者：Saibernard，来源平台：GitHub，项目链接：https://github.com/Saibernard/llm_inference_benchmarking，发布时间：2026-06-13。 后续楼层将详细介绍其背景、方法、验证机制等内容。

传统压测工具常存在“协调遗漏”问题：当服务器变慢时，客户端按固定速率发送请求，会遗漏本应发出的请求，导致测得延迟被人为压低，无法反映真实用户体验。GPUBench 的诞生旨在解决这一痛点，提供真实的服务延迟测量。

核心方法

GPUBench 采用绝对到达时间调度（Poisson 过程），预先计算每个请求的预期到达时间，记录预期与实际发送时间差异，消除协调遗漏问题。

关键指标

• 延迟类：TTFT（首 token 时间，含预填充和队列等待）、TPOT/ITL（每输出 token 解码时间）、E2E Latency（端到端延迟，提供 P50/P95/P99 分位数）
• 吞吐量类：Throughput（输出 token/秒、总 token/秒、请求/秒）、Goodput（满足 SLO 的请求吞吐量）
• GPU 遥测：利用率、显存占用、功耗、KV Cache 占用率
• 可靠性：按类别统计超时、HTTP 错误、截断流等异常情况

GPUBench 通过三重交叉验证确保结果可信度：

1. vLLM 官方 bench serve：相同参数下，GPUBench 数值需与官方工具一致
2. 服务器 /metrics 端点：验证内部直方图数据
3. 自身统计计算：基于窗口的吞吐量计算，使用 numpy.percentile 计算分位数（带最小样本量保护，避免虚假 P99） 若三者不一致，则说明存在问题（工具或被测系统）。

膝点定义

性能曲线从吞吐量线性增长、延迟稳定，转为延迟急剧上升、吞吐量增长平缓甚至下降的临界点。

检测方式

GPUBench 通过扫描不同请求速率、并发度、输入长度、输出长度，绘制完整性能曲线以定位膝点。

重要性

• 膝点前：资源利用率健康，用户体验良好
• 膝点后：队列堆积，延迟飙升，用户体验恶化 帮助运维人员确定服务安全运行边界。

统计诚实

• 基于窗口的吞吐量计算（非简单请求速率平均）
• TPOT 计算公式：(E2E - TTFT) / (output_tokens -1)
• 分位数计算使用 numpy.percentile，带最小样本量保护
• 失败请求单独追踪，不混入延迟统计

可复现性

• 提供 Dockerfile 和 docker-compose 配置
• 环境变量模板（.env.example）
• 详细配置文件目录（configs/）
• Jupyter notebooks 用于结果分析

GPUBench 适用于以下场景：

1. 模型选型对比：相同硬件下对比不同模型推理性能
2. 硬件选型评估：测试新 GPU 对特定模型的加速效果
3. 服务容量规划：确定给定延迟 SLO 下的最大并发
4. 配置调优：验证 vLLM 调度策略、KV Cache 管理等参数影响
5. 回归测试：CI/CD 流程中监控性能退化

GPUBench 代表 LLM 推理性能测试从“能用”到“可信”的演进。它不仅是压测脚本，更是一套完整测量方法论：

• 协调遗漏正确确保延迟数据真实
• 三重交叉验证确保结果可信
• 膝点分析提供容量规划直观依据
• GPU 遥测关联帮助定位性能瓶颈 对于部署或优化 LLM 推理服务的团队，GPUBench 提供比简单 QPS/TPS 测试更可靠的决策基础，是复杂 AI 基础设施下正确架构决策的前提。