大模型推理服务性能压测教程：用 llm_benchmark.py 测透 TTFT 与吞吐，TaoToken 统一 Key 接入

1. 上线前不压测等于把事故留给用户大模型推理服务性能压测说白了就是在服务正式对外之前用一套可复现的脚本把它的极限摸清楚。你要回答三个问题首 Token 多久能吐出来TTFT、每秒能稳定生成多少 Token吞吐、并发涨到多少开始崩饱和点。这三个数不测容量规划就是拍脑袋线上第一次流量高峰就会教你做人。我见过太多团队的做法是本地 curl 发一条请求看到有返回就认为服务没问题。结果上线后 20 个用户同时提问TTFT 从 0.1 秒飙到 5 秒前端转圈转到用户关页面。问题不在于模型不行而在于没人系统性地跑过并发梯度。这篇教程围绕llm_benchmark.py这个压测脚本展开它针对 Chat 类大模型接口设计兼容 OpenAI Chat Completion 流式格式能一次性输出 TTFT 的 avg/p50/p90/p99、单请求生成速率、系统总 TPS、QPS 和端到端延迟分布。适合谁负责推理服务上线的后端工程师、做模型部署的算法同学、需要写性能验收报告的技术负责人。测试矩阵按 T1 到 T4 四组场景设计从最短输出到长文生成覆盖真实业务里从打招呼到写文档的全部形态。同时我会演示怎么用 TaoToken 的统一 Key 和 API 通道接入被测服务——这样你压测不同模型时不用来回改鉴权逻辑一套 Key 打通多个推理端点横向对比时特别省事。判定标准也很直接TTFT P90 突增说明排队严重system_tps 涨幅低于 5% 说明到饱和点了失败率大于 0 说明服务扛不住当前并发。下面从环境准备开始一步步走完。2. 压测环境准备与 llm_benchmark.py 参数速查2.1 客户端环境压测客户端建议用 LinuxopenEuler 或 Ubuntu 都行Python 版本不低于 3.8。核心依赖只有一个 aiohttp因为脚本用异步协程发流式请求同步库在高并发下会拖后腿。pip install aiohttp --break-system-packages # 若系统有保护可加 --user网络这块有个坑要提前说压测客户端和被测服务尽量在同一内网避免公网延迟污染 TTFT 数据。TTFT 本身就在百毫秒量级公网抖动几十毫秒足以让结论失真。把llm_benchmark.py下载到工作目录可选赋执行权限chmod x llm_benchmark.py确认被测服务的地址和模型名接口必须兼容 OpenAI Chat Completion 流式格式也就是支持stream和stream_options。记录两个值URL: http://1xx.xx.xx.6x:233xx/v1/chat/completions Model: QwQ-32B2.2 参数速查表先跑一次帮助命令看全量参数python llm_benchmark.py --help关键参数对照如下参数必填说明示例--url是服务端 API 地址http://127.0.0.1:8000/v1/chat/completions--model是模型名称须服务端识别Qwen2.5-14B--prompt否测试用提示词默认脚本内置你好--max-tokens否最大输出 token 数默认 5122048--timeout否单请求超时秒数默认 120180--num-requests否每个并发档位的请求总数默认 20建议 ≥5050--concurrency否固定单一并发数与 sweep 二选一10--concurrency-sweep否并发扫描档位逗号分隔1,5,10,20,50--api-key否服务需要认证时填 Bearer 后的值sk-xxx--num-requests这个参数值得单独强调。分位数 P90/P99 的统计意义依赖样本量脚本在成功样本数小于 10 时会打印警告。想拿到可信的 P99每个档位至少 50 个请求100 个更稳。2.3 用 TaoToken 统一 Key 接入被测服务压测经常要横向对比多个模型如果每个模型一套鉴权、一个地址脚本参数改到崩溃。TaoToken 提供统一的 Key 和 API 通道把不同推理端点收敛到一个入口压测时只改--model就行。先在控制台创建 API Keyhttps://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsole拿到 Key 后把被测地址指向 TaoToken 的 API 入口鉴权用同一个 Keypython llm_benchmark.py \ --url https://taotoken.net/api/v1/chat/completions \ --model QwQ-32B \ --api-key sk-你的Key \ --concurrency-sweep 1,5,10,20,50 \ --num-requests 50这样 T1 到 T4 四组场景、多个模型全部共用一套鉴权。API 入口是https://taotoken.net/api注意这个地址不带 UTM 参数直接用于脚本配置。Key 的管理和轮换在 API Keys 页面https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keys如果你要压测的是自建推理服务也可以把 TaoToken 当作对照基准——同一套脚本、同一套 Key分别打自建端点和统一通道横向数据直接可比。3. 可复制的压测配置与四场景测试矩阵3.1 测试场景设计 T1~T4压测不能只测一种输入。短输出和长输出的瓶颈完全不同短输出考验调度和 prefill长输出考验 decode 阶段的持续吞吐。所以设计四组场景场景编号场景名称--max-tokensprompt 核心目的T1TTFT 基线16你好排除生成耗时获取纯调度/prefill 延迟基线T2实时对话64用一句话总结人工智能在建筑领域最核心的应用。模拟实时交互体验响应速度T3基准场景512请详细介绍一下人工智能在建筑行业的应用场景包括但不限于智能监控、人脸识别等方面尽量展开说明。横向对比主场景最贴近业务T4文书生成2048与 T3 相同 prompt隔离输出长度变量测试长输出稳定性关键点T3 和 T4 必须用相同 prompt只有--max-tokens不同。这样才能干净地对比输出长度对 TPS 的影响否则 prompt 一变prefill 成本也变了结论就不纯。3.2 单场景并发扫描以 T3 为例跑一次并发扫描python llm_benchmark.py \ --url https://taotoken.net/api/v1/chat/completions \ --model QwQ-32B \ --api-key sk-你的Key \ --prompt 请详细介绍一下人工智能在建筑行业的应用场景包括但不限于智能监控、人脸识别等方面尽量展开说明。 \ --max-tokens 512 \ --timeout 120 \ --num-requests 50 \ --concurrency-sweep 1,5,10,20,503.3 四场景自动化脚本手动跑四遍容易漏参数写个 Shell 脚本顺序执行每次之间 sleep 5 秒让服务恢复#!/bin/bash MODEL_URLhttps://taotoken.net/api/v1/chat/completions MODEL_NAMEQwQ-32B API_KEYsk-你的Key # T1 python llm_benchmark.py --url $MODEL_URL --model $MODEL_NAME --api-key $API_KEY \ --prompt 你好 --max-tokens 16 --timeout 120 --num-requests 50 \ --concurrency-sweep 1,5,10,20,50 sleep 5 # T2 python llm_benchmark.py --url $MODEL_URL --model $MODEL_NAME --api-key $API_KEY \ --prompt 用一句话总结人工智能在建筑领域最核心的应用。 --max-tokens 64 \ --timeout 120 --num-requests 50 --concurrency-sweep 1,5,10,20,50 sleep 5 # T3 python llm_benchmark.py --url $MODEL_URL --model $MODEL_NAME --api-key $API_KEY \ --prompt 请详细介绍一下人工智能在建筑行业的应用场景包括但不限于智能监控、人脸识别等方面尽量展开说明。 \ --max-tokens 512 --timeout 120 --num-requests 50 --concurrency-sweep 1,5,10,20,50 sleep 5 # T4 python llm_benchmark.py --url $MODEL_URL --model $MODEL_NAME --api-key $API_KEY \ --prompt 请详细介绍一下人工智能在建筑行业的应用场景包括但不限于智能监控、人脸识别等方面尽量展开说明。 \ --max-tokens 2048 --timeout 120 --num-requests 50 --concurrency-sweep 1,5,10,20,50T4 高并发下如果大量超时脚本可能卡住可以提前 CtrlC 终止该档位记录失败率后继续下一档。输出重定向到日志文件方便后续提取数据bash run_test.sh 21 | tee model_name_T3.log3.4 用 settings 片段固化配置如果你用 Cline 或 Claude Code 这类工具做压测编排可以把连接配置写成 JSON避免每次手敲参数。以 Cline MCP 风格的配置为例{ mcpServers: { llm-benchmark: { command: python, args: [llm_benchmark.py], env: { BASE_URL: https://taotoken.net/api/v1/chat/completions, API_KEY: sk-你的Key, MODEL_ID: QwQ-32B } } } }三件套记牢Base URL 指向https://taotoken.net/apiKey 用控制台创建的Model ID 填服务端能识别的模型名。这三者缺一不可配错任何一个都会在验证阶段报错。4. 验证请求与成功结果解读4.1 脚本输出示例跑完一轮并发扫描终端会打印每个档位的汇总。以并发 50 为例并发数: 50 | 请求数: 50 (成功 50 / 失败 0) 墙钟总耗时: 52.34s | QPS: 0.96 系统总Token吞吐 (system TPS): 1003.44 tokens/s -- 核心并发能力指标 单请求平均生成速率: 39.87 tokens/s TTFT avg/p50/p90/p99: 0.083s / 0.083s / 0.091s / 0.097s 总延迟 avg/p50/p90/p99: 12.84s / 12.58s / 13.51s / 14.05s看到这组数说明服务在 50 并发下还没崩失败率 0TTFT P99 不到 0.1 秒系统吞吐稳定在 1000 tokens/s 以上。4.2 指标定义与业务含义指标含义业务意义TTFT P50/P90/P99首 Token 延迟分布用户感知的响应速度P90 反映绝大多数体验system_tps所有请求累计 token 数 ÷ 墙钟总耗时服务端总吞吐能力横向对比核心单请求平均生成速率token 数 ÷ 该请求总耗时纯生成阶段模型本身生成速度不含排队总延迟 P50/P90/P99端到端完整响应耗时用户等待完整结果的时间饱和拐点system_tps 不再随并发增加而增长的点容量规划上限超过则排队加剧4.3 关键判断规则TTFT 劣化拐点观察 TTFT P90 随并发变化。如果某个并发下突增比如从 0.5 秒跳到 3 秒说明服务开始严重排队这个并发就是体验红线。吞吐拐点在汇总对比表里当 system_tps 涨幅显著减小低于 5%或开始下降时当前并发即为饱和点。继续加压只会让延迟涨、吞吐不涨。稳定性失败率大于 0% 说明服务不堪重负需要降低并发或优化。哪怕只有 1 个失败也要在报告里标注。4.4 汇总对比表脚本在多个档位跑完后会自动打印汇总表汇总对比表 (寻找系统吞吐的拐点/饱和点): 并发 成功率 系统TPS QPS TTFT_p50(s) TTFT_p90(s) 延迟_p50(s) 延迟_p90(s) 1 50/50 39.87 0.96 0.083 0.091 12.84 13.51 5 50/50 198.20 4.80 0.085 0.095 12.90 13.60 10 50/50 395.10 9.55 0.090 0.110 13.00 13.80 20 50/50 780.50 18.90 0.120 0.210 13.20 14.20 50 50/50 1003.44 24.30 0.150 0.460 13.50 15.10从这张表能读出并发从 1 涨到 50system_tps 从 39 涨到 1003但 20 到 50 这段涨幅明显放缓TTFT P90 从 0.21 秒涨到 0.46 秒。说明 50 并发接近饱和再往上加收益很小、延迟代价很大。4.5 填写单请求基准T3 并发1从 T3 并发1 的行里提取平均 TTFT、单请求 TPS、平均总延迟。平均输出 Token 数/请求 ≈ 单请求 TPS × 平均总延迟。还要查服务端返回的finish_reason如果输出 token 数远小于--max-tokens且 finish_reason 为 stop说明模型提前结束TPS 会虚高报告里要注明。5. 常见报错排查与真实错误对照5.1 ModuleNotFoundError: No module named aiohttp脚本启动就报这个说明依赖没装。执行pip install aiohttp系统受限时加--user或--break-system-packagesPython 3.11。5.2 HTTP 401: Unauthorized这是压测里最高频的报错。原因通常是 Key 没传、传错或者 Base URL 和 Key 不匹配。检查三点--api-key是否填了 Bearer 后的值URL 是否指向https://taotoken.net/api/v1/chat/completionsKey 是否在控制台被禁用或过期。重新在 API Keys 页面生成一个再试。5.3 local proxy failed / connection refused报错里出现 local proxy failed一般是客户端网络配置问题或者被测地址写错。先确认 URL 能通curl -I https://taotoken.net/api/v1/chat/completions如果 curl 也失败说明地址或网络层有问题不是脚本的锅。注意不要用任何非正规网络工具企业内网直接走正常出口即可。5.4 reading choices 相关解析错误脚本解析流式响应时如果服务端返回格式不标准可能报 choices 解析异常。检查服务端是否真的返回 OpenAI 兼容的 SSE 格式每行以data:开头最后有data: [DONE]。如果服务端返回的是自定义格式需要改脚本的解析逻辑。5.5 OAuth / 鉴权方式不匹配有些服务用 OAuth 而非 Bearer Token脚本默认发Authorization: Bearer xxx。如果服务端要求 OAuth 流程需要先换 token 再填入--api-key。用 TaoToken 统一通道时不存在这个问题标准 Bearer 即可。5.6 高并发下大量超时T4 场景 2048 tokens 输出50 并发下很容易超时。两个处理办法把--timeout调小如 60s让失败快速返回或者直接 CtrlC 终止当前档位记录失败率后继续。报告里注明并发50 时因超时主动终止。5.7 分位数不稳定P90/P99 波动大通常是样本太少。--num-requests至少 30建议 50 以上。脚本在成功样本数小于 10 时会打印警告看到警告就加请求数重测。5.8 不同模型 sweep 档位不一致横向对比时所有模型的--concurrency-sweep必须一致否则对比失去意义。如果某模型在 50 并发下全失败仍执行 50 档并记录失败率但性能数据留空。5.9 能否测 Embedding 或 Reranker本脚本只针对 Chat 类流式输出。Embedding/Reranker 有独立的压测脚本指标是 sentences/s 或 pairs/s用法类似但输出结构不同别混用。6. 用统一 Key 把压测流程固化下来压测做完一轮最有价值的不是某一次的绝对数字而是可复现的对比能力。下次模型升级、服务扩容、参数调整你要能用同一套脚本、同一套 Key、同一套场景矩阵再跑一遍直接对比。TaoToken 在这里的作用是把鉴权和地址收敛掉。你不需要为每个模型维护一套 Key也不用在脚本里写一堆 if-else 切地址。Base URL 固定为https://taotoken.net/apiKey 在控制台统一管理Model ID 按需切换。压测脚本里只改--model一个参数横向对比就成立了。如果你要长期做推理服务的性能验证建议把压测纳入 CI 流程每次模型版本更新自动跑 T1~T4把 system_tps 和 TTFT P90 存进时序库画趋势图。一旦某次更新导致 TTFT P90 劣化超过阈值自动告警。这套流程的入口就是统一 Key 加固定脚本。需要长期跑编码类 Agent 压测的可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan想先手动验证模型返回是否正常用模型对话页面发一条请求确认通道通https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel-chat接入细节和参数说明在文档里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc最后给一个实操建议压测报告里一定要写清楚测试条件——客户端配置、网络环境、并发档位、请求数、prompt 内容、max-tokens。没有这些上下文数字就是孤立的别人无法复现也无法判断你的结论是否可信。把run_test.sh和日志一起归档下次对比时直接翻出来。