一文讲透大模型压测工具 —— 工具清单、常用参数、功能差异、选型建议

厂商材料里的性能数字几乎都是理想条件下测出来的特定 GPU、特定版本、固定长度的输入输出并发也不一定高。模型拉回自己环境一跑数字经常对不上。所以选型、验收、做容量规划之前都得自己压一遍。这篇讲四件事有哪些压测工具、怎么用、参数什么意思、怎么挑。顺带把比工具更容易踩坑的方法论也说清楚。为什么要压测大模型压测和传统接口压测有两点不一样输出是流式的。一次请求持续几秒到几分钟一个 token 一个 token 往外吐只看总耗时不够用。结果按 token 算。吞吐除了每秒请求数更要看每秒输出 token 数后者直接对应成本和计费。一般四种场景会用到压测引擎选型vLLM、SGLang、TensorRT-LLM哪个在你的模型和硬件上最快。容量规划业务峰值多少并发需要买多少卡。SLO 验收合同写了 TTFT P99 小于 500ms得测了才知道达没达标。调优验证改了参数、升了版本是变快了还是变慢了。先把指标搞清楚一次大模型请求的完整生命周期是这样的所有指标都挂在这条时间轴上逐个解释TTFTTime To First Token从发出请求到收到第一个 token 的时间。对应用户感受到的「等了多久才响应」包含网络、排队和 Prefill 计算。TPOTTime Per Output Token后面每个 token 的平均生成耗时决定「流速」快不快。ITLInter-Token Latency相邻两个 token 之间的间隔。TPOT 是平均值ITL 是分布调度抖动、请求被抢占这类问题ITL 曲线上看得最清楚。吞吐请求吞吐req/s看服务能力token 吞吐output tokens/s算成本、对账后者更常用。成功率与分位数延迟一律看 P50/P90/P99别看平均值高负载下平均值会把排队掩盖掉。 对话类产品重点盯 TTFT用户等的是「开始回答」长文生成类重点盯 TPOT 和 E2E用户等的是「全文出完」。压测前先想清楚自己的业务吃哪个指标。指标之外还有一件事必须理解吞吐和延迟是对立的。并发低时吞吐随并发线性上涨延迟几乎不变过了拐点GPU 已经吃满再加并发只会让队列越积越长吞吐不再涨延迟陡增。所以任何不带并发条件的性能数字都没有意义——「吞吐 5000 tokens/s」在并发 8 和并发 64 下完全是两个故事。主流工具一览压测工具分三类分别解决三个问题引擎自带型跟着推理引擎走装引擎就有参数贴合自家引擎测的是引擎本身的能力上限。专业压测工具独立安装面向「服务」压测只要能提供 OpenAI 兼容接口就能打指标和报告更全。通用压测工具k6、Locust 这类。强项是把多个接口编成业务流——比如 RAG 链路embedding → 检索 → rerank → 生成整体压测只有它们能干。工具出品方维护状态适用场景vLLM bench servevLLM 官方活跃测 vLLM 服务、引擎对比SGLang bench_servingSGLang 官方活跃测 SGLang 服务llama-benchllama.cpp活跃本地 gguf 模型摸底EvalScope Perf阿里魔搭活跃API 与自建服务压测、SLA 调优GenAI-PerfNVIDIA活跃向 AIPerf 迁移Triton/NIM 栈深度调优GuideLLMNeural Magic活跃快速拿到延迟-吞吐曲线LLMPerfAnyscale基本停更早期 API 对比历史参考k6Grafana Labs活跃业务链路、混合流量Locust开源社区活跃Python 服务内嵌压测怎么上手EvalScope Perf魔搭社区出品pip 一行装好。特点是覆盖面广任何 OpenAI 兼容 API 都能压内置 random、openqa 等数据集也支持自定义 jsonl 和多轮对话还能做 SLA 自动调优——给定 TTFT/TPOT 目标它自动帮你找出满足目标的最大吞吐并发。结果可以接 wandb 做可视化。中文文档齐全国内网络环境下依赖也好装。EvalScope Perf 基本用法 # 安装 pip install evalscope[perf] # 并发 10共 100 条请求输出固定 128 tokens evalscope perf \ --url http://localhost:8000/v1/chat/completions \ --api openai --model qwen2.5-7b-instruct \ --dataset random --min-tokens 128 --max-tokens 128 \ --number 100 --parallel 10vLLM bench serve开源引擎测试的事实标准论文和厂商报告里的数字大多出自它。装了 vLLM 就有直接用 vllm bench serve。数据集支持 sharegpt真实对话长度分布、random固定长度等--max-concurrency 是闭环并发--request-rate 是开环速率--save-result 可以把结果存成 JSON方便脚本化跑多组对比。vLLM bench serve 基本用法 vllm bench serve \ --model qwen2.5-7b-instruct \ --endpoint /v1/chat/completions \ --dataset-name random --random-input-len 512 --random-output-len 128 \ --num-prompts 200 --max-concurrency 16 \ --ignore-eos --save-resultGenAI-PerfNVIDIA 出品长在 Triton 生态里。既能压 Triton 原生后端gRPC也能压 OpenAI 兼容接口输出 TTFT、ITL、token 吞吐等指标配合它家的分析工具还能关联 GPU 利用率一起看适合 NIM/Triton 技术栈做深度调优。注意 NVIDIA 正在推下一代工具 AIPerf 接替 GenAI-Perf新上车的朋友先看官方文档确认用哪个。GenAI-Perf 基本用法参数以官方文档为准 genai-perf profile \ --model qwen2.5-7b-instruct \ --endpoint-type chat --service-kind openai \ --url http://localhost:8000 \ --concurrency 10 --request-count 100k6 和 Locust只有压业务链路时才需要这一类。k6 用 JS 写脚本可以把 embedding、检索、生成多个接口编排成一个完整流程加自定义检查还能直接进 CI。缺点是流式输出要自己解析 SSE统计 TTFT/TPOT 得自己写代码单测一个模型不如上面的工具省事。Locust 是 Python 版思路一样适合压测逻辑想和服务代码放一起的团队。JMeter 不建议用在 LLM 场景流式长连接和 token 级统计都不是它的强项脚本维护成本也高。k6 压 OpenAI 兼容接口示意 import http from k6/http; export default function () { http.post(http://localhost:8000/v1/chat/completions, JSON.stringify({ model: qwen2.5-7b-instruct, messages: [{ role: user, content: ... }], stream: true }), { headers: { Content-Type: application/json } }); }其他工具LLMPerfAnyscale 早期做的 API 排行榜工具基于 Ray天然支持分布式。功能上已经落后2024 年后基本没更新但存量文章多老教程里看到就是它。GuideLLM一条命令自动扫完一个并发区间直接产出完整的延迟-吞吐曲线适合快速摸底一个服务的容量边界。llama-benchllama.cpp 自带本地跑 gguf 模型时用几秒测出 prefillpp和生成tg速度单位都是 tokens/s。SGLang bench_serving和 vLLM bench 同类的工具参数大同小异测 SGLang 服务时用它。通用参数速查各家工具参数名不一样但控制的就是这几件事参数常见写法影响什么并发数--parallel / --max-concurrency同时在途的请求数直接决定吞吐和排队发送速率--rate / --request-rate每秒发出几个请求模拟真实到达节奏总请求数--number / --num-prompts样本量太少则 P99 不可信输入长度--min/max-prompt-tokens决定 prefill 耗时和 KV cache 占用输出长度--min/max-tokens决定 decode 时长对吞吐影响最直接数据集--dataset / --dataset-name请求内容的来源长度分布影响结果流式输出stream: true不流式就测不了 TTFT 和 TPOT超时--read-timeout压得深时排队久超时会误判成失败工具差异在哪同一个服务用两个工具压数字经常对不上。差异主要来自三个地方。差异一指标口径不一样单说 token 吞吐就有好几种算法总输出 tokens 除以总墙钟时间的剔除启动爬坡段再算的差别不小。TTFT 也一样有的口径含网络和排队有的不含。所以跨工具的数字不要直接对比。EvalScope 的文档里专门有一页讲怎么和 vLLM bench 做口径对齐值得一读。差异二加载模型不一样闭环和开环是两种完全不同的压法差异三数据集不一样ShareGPT 的输入输出长度是真实对话分布有长有短random 固定 512/128 这种prefill 和 decode 的比例恒定调度器没有意外要处理。后者测出来的数字普遍比前者好看。用哪个都行但要写清楚。⚠️ 横向对比时同一个工具、同一份数据集、同一组参数缺一不可。跨工具的数字只参考趋势不参考绝对值。维度EvalScope PerfvLLM benchGenAI-Perfk6定位通用压测平台引擎官方工具推理栈分析通用压测协议OpenAI 兼容 可扩展OpenAI 兼容OpenAI / Triton gRPC任意 HTTP数据集random/openqa/自定义sharegpt/random/自定义合成数据为主脚本里随意造加载模型闭环 / 开环闭环 / 开环闭环并发脚本决定最灵活报告表格 wandb 可视化终端 JSON 存档终端 CSVGrafana / HTML擅长验收、SLA 调优引擎横向对比NVIDIA 栈调优业务混合流量怎么选型大多数人的情况可以归成两类自建部署的从引擎自带的 bench 开始数字和官方口径一致出了问题好对质用 API 的从 EvalScope Perf 开始接口兼容性好报告字段全。拿不准就用 EvalScope覆盖面最广试错成本最低。方法比工具重要压测这件事流程对了工具随便挑一个都能用流程错了再好的工具也是白跑。正确的顺序是这样目标是 SLO 验证就按合同里的指标和流量模型压目标是容量规划就要扫出一整条吞吐-延迟曲线找拐点目标是引擎对比控制变量比绝对数字重要。目标不一样压法完全不同。数据集尽量贴近真实。优先级真实业务采样 ShareGPT 随机定长。定长数据测出来的数字普遍比真实情况好看——长度不抖动调度没有意外重复的 prompt 还可能吃到前缀缓存。常见坑列在这里1不预热。第一批请求要经历 CUDA graph 编译、cache 初始化数字很难看。先跑一轮预热正式结果里剔除前几个请求。2前缀缓存干扰。同一批 prompt 反复发前缀缓存命中率越来越高TTFT 好看得不真实。prompt 随机化或者在服务端把前缀缓存关掉再测。3输出长度失控。不限制输出长度时同一个 prompt 可能回 50 个 token也可能回 500 个吞吐数字全是噪声。用数据集固定长度或者加 ignore_eos 强制输出到上限。4推理模式口径变了。reasoning 模型的输出包含思维链 token输出长度暴涨TTFT 的第一个 token 是思维内容用户看到正文的时间更晚。推理和非推理模型放一起对比之前先把口径定义清楚。5只看平均值。高负载下大部分请求正常、少数请求在排队平均值看着挺好用户体验已经在骂了。看 P90、P99。6施压机自己成了瓶颈。客户端的 CPU、带宽、连接数限制都会造成「服务端不行了」的假象。上高并发之前先确认施压机没打满。再说运行水位怎么选。看前面那张饱和曲线图找到拐点生产水位建议压在拐点吞吐的 70% 左右延迟还在低位区间也给突发流量留了余量。压着拐点跑一个流量尖峰过来就是大面积超时。最后补一个成本视角。性能要除以价格才是性价比同一个模型比不同服务商或不同引擎用「每卡 tokens/s」或者「每元 tokens/s」比裸吞吐更有决策价值。写在最后压测报告少了可复现的参数等于没测。一份能用的报告这些要素缺一不可1 硬件与环境GPU 型号、卡数、TP/PP 配置、推理框架和版本2 模型与量化模型名称、量化方案3 请求形态输入输出长度分布、用的什么数据集4 负载配置闭环并发还是开环速率、具体数值、总请求数5 指标口径吞吐怎么算的、是否流式、超时阈值6 结果P50/P90/P99 分位数不要只放平均值工具只是手段。想清楚为什么压、压给谁看数字才有意义。