企业官网建设流程全解析

厂商材料里的性能数字，几乎都是理想条件下测出来的：特定 GPU、特定版本、固定长度的输入输出，并发也不一定高。模型拉回自己环境一跑，数字经常对不上。所以选型、验收、做容量规划之前，都得自己压一遍。

这篇讲四件事：有哪些压测工具、怎么用、参数什么意思、怎么挑。顺带把比工具更容易踩坑的方法论也说清楚。

为什么要压测

大模型压测和传统接口压测有两点不一样：

• 输出是流式的。一次请求持续几秒到几分钟，一个 token 一个 token 往外吐，只看总耗时不够用。
• 结果按 token 算。吞吐除了每秒请求数，更要看每秒输出 token 数，后者直接对应成本和计费。

一般四种场景会用到压测：

• 引擎选型：vLLM、SGLang、TensorRT-LLM，哪个在你的模型和硬件上最快。
• 容量规划：业务峰值多少并发，需要买多少卡。
• SLO 验收：合同写了 TTFT P99 小于 500ms，得测了才知道达没达标。
• 调优验证：改了参数、升了版本，是变快了还是变慢了。

先把指标搞清楚

一次大模型请求的完整生命周期是这样的，所有指标都挂在这条时间轴上：

逐个解释：

• TTFT（Time To First Token）：从发出请求到收到第一个 token 的时间。对应用户感受到的「等了多久才响应」，包含网络、排队和 Prefill 计算。
• TPOT（Time Per Output Token）：后面每个 token 的平均生成耗时，决定「流速」快不快。
• ITL（Inter-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 → 生成）整体压测，只有它们能干。

怎么上手

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 10

vLLM 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-result

GenAI-Perf

NVIDIA 出品，长在 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 100

k6 和 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" } }); }

其他工具

• LLMPerf：Anyscale 早期做的 API 排行榜工具，基于 Ray，天然支持分布式。功能上已经落后，2024 年后基本没更新，但存量文章多，老教程里看到就是它。
• GuideLLM：一条命令自动扫完一个并发区间，直接产出完整的延迟-吞吐曲线，适合快速摸底一个服务的容量边界。
• llama-bench：llama.cpp 自带，本地跑 gguf 模型时用，几秒测出 prefill（pp）和生成（tg）速度，单位都是 tokens/s。
• SGLang bench_serving：和 vLLM bench 同类的工具，参数大同小异，测 SGLang 服务时用它。

通用参数速查

各家工具参数名不一样，但控制的就是这几件事：

工具差异在哪

同一个服务用两个工具压，数字经常对不上。差异主要来自三个地方。

差异一：指标口径不一样

单说 token 吞吐，就有好几种算法：总输出 tokens 除以总墙钟时间的，剔除启动爬坡段再算的，差别不小。TTFT 也一样，有的口径含网络和排队，有的不含。所以跨工具的数字不要直接对比。EvalScope 的文档里专门有一页讲怎么和 vLLM bench 做口径对齐，值得一读。

差异二：加载模型不一样

闭环和开环是两种完全不同的压法：

差异三：数据集不一样

ShareGPT 的输入输出长度是真实对话分布，有长有短；random 固定 512/128 这种，prefill 和 decode 的比例恒定，调度器没有意外要处理。后者测出来的数字普遍比前者好看。用哪个都行，但要写清楚。

⚠️ 横向对比时，同一个工具、同一份数据集、同一组参数，缺一不可。跨工具的数字只参考趋势，不参考绝对值。

怎么选型

大多数人的情况可以归成两类：自建部署的，从引擎自带的 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 分位数，不要只放平均值

工具只是手段。想清楚为什么压、压给谁看，数字才有意义。