1. 推理压测为什么总在“跑了个寂寞”你大概率遇到过这种场景本地 vLLM 或 SGLang 服务起好了随手 curl 几下感觉挺快于是拍脑袋定了个“单卡并发 50”的容量结论。上线之后 P99 直接飙到好几秒用户投诉回头一查发现压测时根本没做 warmup也没区分 prefill 和 decode 两个阶段的指标测出来的数字跟生产环境完全不是一回事。LLM 推理引擎的性能调优与基准测试核心要回答三个问题这套硬件加引擎组合到底能扛多少并发P99 延迟是否满足 SLO哪个参数配置能让 GPU 利用率最高回答这些问题靠“感觉”不行靠“单次测试”也不行需要一套可复现的基准测试流程。而压测本身会产生大量请求如果每次都手动切换不同厂商的 Key、改 base_url、对不同的鉴权格式测试脚本会变得极其脆弱换一个模型就要重写一遍接入层。这篇就聚焦落地环节给你一份可复制的压测配置骨架包含并发、输入输出长度、采样参数同时用 TaoToken 统一 Key 把接入层固定下来让你把精力放在指标采集和结果对比上而不是反复折腾鉴权。适合正在本地或云端对推理服务做压测、需要采集 TTFT/TPOT/吞吐等指标的开发者。下面所有命令和配置都可以直接复制运行我会把踩过的坑和验证动作一并写清楚。2. 用 TaoToken 统一 Key 固定压测接入层压测脚本最怕的事情之一是“接入层漂移”。今天测 A 模型用一套 Key明天测 B 模型换一套base_url 和鉴权 header 都不一样结果就是压测代码里到处是 if-else指标还没采到接入逻辑先把你绕晕。TaoToken 在这里的角色是提供一个统一的 OpenAI 兼容通道你只需要维护一个 API Key 和一个 base_url压测客户端不用关心背后具体是哪个模型服务。具体来说TaoToken 提供 OpenAI 兼容的/v1/chat/completions接口压测工具genai-bench、guidellm、genai-perf 等大多原生支持 OpenAI 协议所以接入成本极低。你只需要在压测配置里把base_url指向https://taotoken.net/api把api_key填成你在控制台生成的 Key剩下的并发、输入长度、采样参数都走标准字段。这里有个关键点压测时建议单独申请一个专用 Key不要和线上业务共用。原因是压测会产生高频请求如果和业务混用一方面可能触发限流影响线上另一方面指标里会混入业务流量导致数据不干净。专用 Key 的好处是你可以随时在控制台查看这个 Key 的调用量压测结束后直接禁用干净利落。如果你还没生成 Key可以到控制台的 API Keys 页面创建一个建议命名带上bench前缀方便识别。生成之后先别急着压测用一条最简单的请求验证通道是否通这一步能帮你排除掉 90% 的“压测跑不起来其实是 Key 配错了”的问题。3. 可复制的压测配置骨架下面这份配置骨架覆盖了压测最核心的几个维度并发数、输入输出长度、采样参数、warmup 次数。我把它拆成三段你可以按需组合。3.1 基础连接配置# bench_config.yaml backend: openai base_url: https://taotoken.net/api api_key: sk-your-bench-key model: your-target-model timeout: 120 max_retries: 2这段配置是所有压测工具的公共入口。backend选openai是因为 TaoToken 走 OpenAI 兼容协议genai-bench 和 guidellm 都能直接识别。timeout建议设大一点压测时如果并发高个别请求排队时间会拉长超时设太小会误判为失败。3.2 负载与采样参数# load_config.yaml num_prompts: 500 request_rate: 50 # req/sSweep 时逐档调整 warmup_requests: 50 # 预热请求数不计入统计 random_input_len: 1024 # 输入 token 长度 random_output_len: 256 # 输出 token 长度 temperature: 0.0 # 压测固定为 0保证可复现 top_p: 1.0 ignore_eos: true # 强制生成到 max_tokens避免提前结束temperature设 0 是为了让每次生成的 token 数稳定否则输出长度随机波动会让 TPOT 指标失真。ignore_eos这个参数很多人会忽略如果不设模型可能生成几十个 token 就遇到结束符停了你测出来的吞吐会虚高因为实际输出长度远小于random_output_len。3.3 指标采集配置# metrics_config.yaml metrics: - ttft - tpot - e2e_latency - throughput - itl percentiles: [50, 95, 99] result_dir: ./bench_results save_raw: truesave_raw: true建议打开原始请求级别的延迟数据在排查长尾问题时非常有用。只看聚合后的 P99 你只能知道“有问题”看原始数据才能知道“是哪些请求慢”。4. 验证请求与成功结果解读配置写好了先别急着上高并发。用一条单请求验证通道确认 TaoToken 的 Key 和 base_url 都通再逐步加压。4.1 单请求验证curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-your-bench-key \ -H Content-Type: application/json \ -d { model: your-target-model, messages: [{role: user, content: 用一句话解释什么是 KV Cache}], max_tokens: 64, temperature: 0 } | python -m json.tool返回里能看到choices[0].message.content和usage字段就说明通道正常。usage里的prompt_tokens和completion_tokens是你后续核对输入输出长度的依据。4.2 小并发压测验证python -m sglang.bench_serving \ --backend openai \ --base-url https://taotoken.net/api/v1 \ --api-key sk-your-bench-key \ --model your-target-model \ --dataset-name random \ --num-prompts 100 \ --request-rate 10 \ --random-input 1024 \ --random-output 256 \ --warmup-requests 20跑完之后你会看到类似这样的输出 Serving Benchmark Result Backend: openai Request rate: 10.0 req/s --------------- Latency Metrics --------------- Average TTFT: 142.3 ms P99 TTFT: 389.1 ms Average TPOT: 22.4 ms P99 TPOT: 51.2 ms Average E2E latency: 2841.5 ms --------------- Throughput Metrics --------------- Request throughput: 9.8 req/s Output token throughput: 2508.8 tok/s Total requests: 100 Duration: 10.2 sec这里要重点看三个数P99 TTFT 是否在 SLO 内、TPOT 是否稳定、吞吐是否接近 request_rate。如果 request_rate 设 10 但实际吞吐只有 6说明系统在这个并发下已经开始排队了。4.3 Sweep 找饱和点单点测试只能告诉你“这个并发下还行”Sweep 才能告诉你“极限在哪”。把 request_rate 从 10 逐步拉到 200观察 P99 TTFT 的变化曲线import subprocess, json rates [10, 20, 50, 100, 150, 200] results [] for rate in rates: cmd [ python, -m, sglang.bench_serving, --backend, openai, --base-url, https://taotoken.net/api/v1, --api-key, sk-your-bench-key, --model, your-target-model, --dataset-name, random, --num-prompts, 300, --request-rate, str(rate), --random-input, 1024, --random-output, 256, --warmup-requests, 50, ] out subprocess.run(cmd, capture_outputTrue, textTrue) # 解析输出中的 P99 TTFT 和吞吐 results.append({rate: rate, raw: out.stdout}) for r in results: print(frate{r[rate]})当 P99 TTFT 从几百毫秒突然跳到几秒那个拐点就是饱和点。饱和点之前的最大 request_rate 就是你可以在生产环境设置的并发上限再往上加只会让延迟恶化而吞吐不再增长。5. 本篇常见错排查5.1 压测结果波动大每次跑都不一样最常见的原因是没做 warmup。LLM 推理引擎有冷启动开销首次请求要加载模型、分配 KV Cache、编译 CUDA kernelvLLM 的 Radix Cache 也需要几次请求后才能达到稳定命中率。如果你直接开始统计前几十个请求的延迟会明显偏高把平均值拉歪。正确做法是在正式统计前先发 50 个 warmup 请求然后重置计数器再开始记录。上面配置里的warmup_requests: 50就是干这个的。5.2 吞吐虚高但延迟很低如果你发现吞吐数字很好看但 P99 延迟也不高先检查ignore_eos有没有开。没开的话模型可能生成十几个 token 就停了实际输出长度远小于你设的random_output_len吞吐自然虚高。另一个可能是max_tokens没设对被服务端默认值截断了。5.3 请求大量超时或 429压测时如果出现大量超时或 429 状态码先确认两件事一是你的 TaoToken Key 是否有速率限制压测专用 Key 建议提前确认配额二是timeout设得够不够大高并发下排队时间会拉长timeout 设 30 秒可能不够。建议压测时 timeout 设 120 秒以上避免把排队误判为失败。5.4 指标里混入了非压测流量如果你用的是共享 Key压测期间可能有其他业务请求走同一个 Key导致指标不干净。解决办法就是前面说的压测用专用 Key测完禁用。另外在结果分析时可以按请求的model字段过滤只统计目标模型的请求。5.5 GPU 利用率上不去如果压测时 GPU 利用率长期低于 70%说明配置有优化空间。常见原因有三个并发数不够请求排队没填满 GPUmax_num_seqs或max_batch_size设太小批处理没吃满max_model_len设得过大KV Cache 预留太多显存导致实际可用 batch 变小。调优方向是逐步增大max_num_seqs直到显存接近 OOM同时把gpu_memory_utilization从 0.85 提到 0.95。6. 把压测接入你的日常工作流压测不是跑一次就完事的事情。每次改推理引擎版本、调参数、换硬件都应该重新跑一遍基准测试和基线对比。建议把压测脚本接入 CI每次发版前自动跑一轮检测性能退化。import json def check_regression(baseline_file, current_file, threshold0.1): with open(baseline_file) as f: baseline json.load(f) with open(current_file) as f: current json.load(f) issues [] for metric in [ttft_p99, tpot_p99, throughput]: b, c baseline[metric], current[metric] if metric throughput: if c b * (1 - threshold): issues.append(f{metric} 退化: {c:.1f} {b:.1f}) else: if c b * (1 threshold): issues.append(f{metric} 退化: {c:.1f} {b:.1f}) if issues: print(性能退化检测到:) for i in issues: print(f - {i}) return False print(性能正常) return True这套流程跑顺之后你会发现推理引擎调优从“玄学”变成了“看数据做决策”。每次改一个参数跑一轮压测对比 P99 TTFT 和吞吐的变化哪个参数有效一目了然。如果你在接入压测工具时需要确认模型通道是否正常可以先用模型对话页面发一条请求验证如果是要长期跑编码类 Agent 的压测场景Coding Plan 的配额更适合高频调用压测脚本里用到的 Key 统一在 API Keys 页面管理接入细节可以参考接入文档。把接入层固定下来之后你的压测脚本就只需要关心负载和指标不用再为鉴权分心。