拓冰网站定制 
1. 为什么你的 vLLM 推理服务需要一次可复现的性能评估你已经在红帽 AI 推理服务上把 vLLM 跑起来了模型能出字接口能通但这台机器到底能扛多少并发、首 token 要等多久、P99 延迟会不会在业务高峰期炸掉这些问题不测一遍心里没底。LLM 推理服务和传统 Web 服务不一样它的资源消耗跟输入长度、输出长度、并发数强相关同一个模型在不同请求形态下吞吐能差好几倍。所以性能评估不是跑个脚本看个数字而是要固定变量、可复现、能横向对比。我这次要做的是在红帽 AI 推理服务vLLM上用 GuideLLM 这个专门为 LLM 部署设计的压测工具完成一次从部署参数到压测配置再到结果解读的完整闭环。GuideLLM 和普通的 HTTP 压测工具最大的区别在于它理解 token。它会按你指定的 prompt_tokens 和 output_tokens 去构造请求统计 TTFT、ITL、TPOT 这些 LLM 专属指标而不是只给你一个 QPS。这对做容量规划的人来说非常关键。适合谁看已经在用 vLLM 或红帽 AI 推理服务部署模型、需要给业务方一个「这台机器能撑多少 RPS」结论的工程师正在做硬件选型、想知道「要达到 P99 TTFT 80ms 需要几张卡」的架构同学以及想把性能回归测试纳入 CI 的团队。读完你能拿到一套可以直接复制的 vLLM 启动参数、GuideLLM 压测命令以及一份能对照排查报错的清单。核心检索词先摆出来红帽 AI 推理服务 vLLM 性能评估、GuideLLM 压测 LLM 吞吐延迟、vLLM 推理服务 TTFT ITL TPOT 指标。这三个词贯穿全文你搜进来看到的就是这些内容。在动手之前先把几个关键指标的定义对齐不然后面看报告会懵。RPS 是每秒请求数衡量并发处理能力Request Latency 是单请求从发出到结束的总时间等于 TTFT 加生成时间TTFT 是首 token 时间面向用户的应用最在意这个ITL 是 token 间延迟不含首 token反映生成流畅度TPOT 是每个输出 token 的平均耗时等于生成时间除以输出 token 总数是吞吐效率指标。这几个指标里TTFT 和 TPOT 是你要重点盯的因为它们直接决定用户体验和单位成本。2. 前置准备红帽 AI 推理服务与 GuideLLM 环境搭建这一节把地基打好。红帽 AI 推理服务本质上是把 vLLM 做了企业级封装提供了运维、监控、多模型管理等能力底层推理引擎还是 vLLM。所以你在红帽环境里验证过的 vLLM 参数大部分可以直接迁移。如果你还没装好推理服务先按官方入门文档把服务跑起来确认vllm serve能正常加载模型。先确认你的 Python 环境。建议用独立虚拟环境避免和系统包打架python3 -m venv myenv source myenv/bin/activate pip install --upgrade pip然后安装 vLLM 和 GuideLLM。注意 GuideLLM 是 vLLM 项目下的独立工具包安装命令就是pip install guidellm。同时把压测脚本需要的依赖也装上因为 vLLM 自带的 benchmark_serving.py 会用到 pandas 和 datasetspip install vllm pandas datasets guidellm如果你只想用 GuideLLM其实pip install guidellm就够了它自带请求生成器不依赖 datasets。但为了后面能对照 vLLM 原生脚本的结果建议一起装。模型方面我用 RedHatAI/Llama-3.2-1B-Instruct-FP8 做演示这个模型小、加载快、FP8 量化后显存占用低适合在单卡上快速验证流程。你换成自己的模型也行只要把后面的 model 参数替换掉。启动 vLLM 服务。这里给一组我实测比较稳的参数重点是--max-model-len要和你的压测输入输出长度匹配--gpu-memory-utilization控制显存占用比例vllm serve RedHatAI/Llama-3.2-1B-Instruct-FP8 \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 4096 \ --gpu-memory-utilization 0.90 \ --dtype auto \ --disable-log-requests--disable-log-requests在压测时很有用否则每个请求都打日志I/O 会成为瓶颈测出来的吞吐偏低。等服务起来后用 curl 确认接口通curl http://localhost:8000/v1/models返回模型列表就说明服务正常。这一步别跳过后面 GuideLLM 报连接错误时你能快速判断是服务没起还是压测配置写错了。关于 TaoToken 的前置说明如果你在本地做压测的同时还想用云端 API 做对照测试或者团队里有人用 Coding Plan 跑 Agent 任务可以先把 key 准备好。TaoToken 的 API 地址是 https://taotoken.net/api控制台在 https://taotoken.net/consoleAPI Keys 管理页在 https://taotoken.net/api-keys。这些和本地 vLLM 压测是两条线本地压测不依赖外部服务但做模型效果对照时会用到。模型对话入口在 https://taotoken.net/model-chat接入文档在 https://taotoken.net/docCoding Plan 在 https://taotoken.net/coding-plan。先把这些地址记下来后面 CTA 会用到。环境搭好后建议先跑一次小规模请求确认端到端通再上 GuideLLM。很多人一上来就 sweep结果报错信息混在一起排查成本高。3. 可复制配置vLLM 部署参数与 GuideLLM 压测文件这一节是全文的核心操作区。我会给你三样东西一份 vLLM 启动配置、一份 GuideLLM 的 YAML 压测配置、以及对应的命令行调用方式。你直接复制改路径就能用。先说 vLLM 的启动配置。红帽 AI 推理服务支持用配置文件方式启动我把它写成一个 TOML 片段方便你纳入版本管理# vllm-service.toml [model] name RedHatAI/Llama-3.2-1B-Instruct-FP8 dtype auto max_model_len 4096 gpu_memory_utilization 0.90 [server] host 0.0.0.0 port 8000 disable_log_requests true [engine] enable_prefix_caching true max_num_seqs 256enable_prefix_caching对多轮对话或共享前缀的请求提升明显压测时如果 prompt 有公共前缀开启它能显著降低 TTFT。max_num_seqs控制同时调度的序列数太小会限制并发太大可能 OOM256 是个保守起点。接下来是 GuideLLM 的压测配置。GuideLLM 支持 YAML 配置文件比纯命令行更好维护。我写一份guidellm-bench.yaml# guidellm-bench.yaml target: http://localhost:8000 rate_type: sweep max_seconds: 30 data: prompt_tokens: 512 output_tokens: 256 profile: type: sweep strategies: - synchronous - throughput - constant constant_rates: [1.0, 2.0, 4.0, 8.0]这份配置的意思是对 localhost:8000 做 sweep 压测每个策略跑 30 秒请求形态固定为输入 512 token、输出 256 token。sweep 会依次跑同步、吞吐、以及几个固定速率档位帮你找到延迟开始劣化的拐点。constant_rates里的数字是 RPS你可以根据自己机器的预期能力调整。如果你不想用 YAML等价的命令行是guidellm benchmark \ --target http://localhost:8000 \ --rate-type sweep \ --max-seconds 30 \ --data prompt_tokens512,output_tokens256两种方式结果一致YAML 适合反复跑和进 CI命令行适合临时验证。这里有个关键点GuideLLM 默认走 OpenAI 兼容接口也就是/v1/completions或/v1/chat/completions。vLLM 原生就兼容这套接口所以不需要额外适配。但你要确认--target后面不要带/v1GuideLLM 会自己拼路径。我见过有人写成http://localhost:8000/v1结果 404排查半天。另外如果你的服务开了鉴权GuideLLM 支持传 authorization 头在 YAML 里加backend: authorization: Bearer your-token本地压测一般不开鉴权但红帽 AI 推理服务在生产环境通常会配提前知道这个字段能省事。配置写好后先别急着跑全量 sweep。用--max-seconds 5跑个短测确认没有连接错误、模型名对得上、请求能正常返回。短测通过后再跑 30 秒的正式压测。这个习惯能帮你把「配置错误」和「性能问题」分开。4. 验证请求与结果解读从 Benchmark 报告读出硬件需求压测跑起来后GuideLLM 会实时打印进度结束后输出两大块Benchmarks Info 和 Benchmarks Stats。Info 是每个策略的请求数、token 数统计Stats 是延迟和吞吐指标。我拿一次实测结果来带你读。先看 Info 部分。synchronous 策略下30 秒完成 14 个请求1 个未完成throughput 策略下完成 161 个510 个未完成。未完成不代表失败而是压测时间到了请求还没返回说明吞吐策略下系统被打满了。Err 列全是 0说明没有报错请求服务稳定。再看 Stats 部分这是重点。synchronous 策略下Out Tok/sec 是 121.5Req Latency mean 是 2.11msTTFT mean 24.7msITL mean 8.2msTPOT mean 8.1ms。这个延迟非常低因为同步策略一次只发一个请求系统毫无压力。随着 constant 速率从 1.09 升到 5.37你能看到清晰的趋势TTFT mean 从 21.6ms 涨到 37.3msITL mean 从 8.8ms 涨到 11.9msTPOT 从 8.8ms 涨到 11.9ms。延迟在缓慢上升但还没到崩溃点。throughput 策略下并发冲到 141.45TTFT mean 飙到 1713.3msP99 到 3793.7ms这就是系统被打满后的表现。现在做容量推算。假设业务要求 P99 TTFT 低于 80ms。看 constant 档位constant4.76 的 TTFT P99 是 75.3msconstant5.37 的 P99 是 90.7ms已经超标。所以这台硬件在满足 P99 TTFT 80ms 的前提下能支撑的 RPS 大约是 4.76。如果业务需要 50 RPS那 50 除以 4.76 约等于 10.5向上取整需要 11 台同配置服务器。这个推算方法就是原文里提到的思路我把它具体化了。再验证一下请求是否真的成功。压测结束后你可以单独发一个请求确认服务还在正常响应curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d { model: RedHatAI/Llama-3.2-1B-Instruct-FP8, prompt: Explain vLLM in one sentence., max_tokens: 64 }返回里有choices字段和生成的文本就说明服务健康。这一步是压测后的 sanity check别省。GuideLLM 还会把完整报告存成 JSON默认路径在输出里会打印比如/root/benchmarks.json。你可以用 jq 提取关键指标做对比jq .benchmarks[] | {name: .name, ttft_p99: .stats.ttft.p99, tpot_mean: .stats.tpot.mean} /root/benchmarks.json这样每次压测后能快速生成一张对比表纳入回归测试。我试过把不同模型、不同量化版本的报告放一起对比FP8 相比 FP16 在同等硬件上 TPOT 能降 20% 左右但具体数字取决于模型和输入长度你得自己测。读报告时有个坑mean 和 median 差距大说明分布偏斜这时候要看 P99。比如 throughput 策略下 TTFT mean 1713ms、median 1608ms、P99 3793msP99 是 mean 的两倍多说明有长尾请求。面向用户的应用必须盯 P99不能只看均值。5. 常见报错排查401、连接失败与 choices 解析异常压测过程中最容易撞上的几类错误我按出现频率排一下每个都给你定位方法。第一类401 Unauthorized。如果你在红帽 AI 推理服务上开了鉴权GuideLLM 没带 token 就会 401。报错长这样Error: backend request failed with status 401: Unauthorized解决方法是确认服务端鉴权配置然后在 GuideLLM 配置里加 authorization 字段。如果你用的是 TaoToken 的 API 做对照测试key 要从 https://taotoken.net/api-keys 拿Base URL 填 https://taotoken.net/apiModel ID 填你实际调用的模型名。这三件套缺一不可Base URL、Key、Model ID。很多人只填了 URL 忘了 model报 404 或 model not found。第二类local proxy failed 或 connection refused。报错类似Error: failed to connect to http://localhost:8000: Connection refused这说明 vLLM 服务没起来或者端口不对。先curl http://localhost:8000/v1/models确认。如果服务在容器里注意端口映射--host 0.0.0.0不能少否则只监听 127.0.0.1容器外访问不到。第三类reading choices 相关错误。GuideLLM 解析响应时如果拿不到choices字段会报Error: failed to parse response: missing choices in response body这通常是接口路径不对。GuideLLM 默认走/v1/completions如果你用的是 chat 模型且服务只开了/v1/chat/completions就会解析失败。检查 vLLM 启动参数或者确认模型是否支持 completions 接口。Llama-3.2-Instruct 系列建议走 chat 接口在 GuideLLM 里可以指定路径。第四类OOM 或 CUDA out of memory。压测时并发一高显存不够就崩。报错torch.cuda.OutOfMemoryError: CUDA out of memory解决方法是降--gpu-memory-utilization或者降max_num_seqs或者缩短max_model_len。压测的输入输出长度如果超过max_model_len也会触发异常确保prompt_tokens output_tokens max_model_len。第五类OAuth 或 token 过期。如果你用云端 API 做对照token 过期会报 401 或 403。重新生成 key 即可。本地 vLLM 不涉及这个问题。排查顺序建议先 curl 确认服务活着再确认接口路径再确认鉴权最后看显存。这个顺序能覆盖 90% 的问题。每次改配置后重新跑 5 秒短测别直接上 30 秒省时间。6. 把压测纳入日常从一次评估到持续回归一次压测只能告诉你「此刻这台机器能扛多少」但模型更新、驱动升级、参数调整都会改变性能。所以真正有价值的做法是把这套流程固化成回归测试。具体怎么做把guidellm-bench.yaml和 vLLM 启动配置一起放进 Git每次模型或环境变更后跑一次把benchmarks.json存档用脚本对比关键指标的波动。比如 TTFT P99 超过基线 20% 就告警。这样你能在性能劣化影响业务之前发现它。如果你团队用 Coding Plan 跑长期 Agent 任务压测数据还能帮你决定该用本地推理还是云端 API。本地推理在固定负载下单位成本低但弹性差云端 API 弹性好但按 token 计费。用 GuideLLM 测出本地的 RPS 上限和延迟曲线后你能算出本地能覆盖多少峰值流量超出部分走云端这个混合策略比拍脑袋靠谱。最后给一个实用技巧压测时把--max-seconds设成业务高峰的典型时长比如 60 秒或 120 秒短测容易低估长尾延迟。另外warmup 很重要vLLM 首次请求会触发编译和缓存填充前几个请求延迟偏高GuideLLM 支持 warmup 配置正式测之前先跑几个请求把模型热起来。这套流程我在不同硬件上跑过多次最深的体会是不要迷信单次结果多跑几轮取稳定值不要只看吞吐延迟曲线才是容量规划的依据不要跳过短测配置错误和性能问题混在一起最难查。把这三条记住你的 vLLM 性能评估就能做得又稳又可复现。 红帽 AI 推理服务（vLLM）实战：用 GuideLLM 评估 LLM 模型性能
1. 为什么你的 vLLM 推理服务需要一次可复现的性能评估你已经在红帽 AI 推理服务上把 vLLM 跑起来了模型能出字接口能通但这台机器到底能扛多少并发、首 token 要等多久、P99 延迟会不会在业务高峰期炸掉这些问题不测一遍心里没底。LLM 推理服务和传统 Web 服务不一样它的资源消耗跟输入长度、输出长度、并发数强相关同一个模型在不同请求形态下吞吐能差好几倍。所以性能评估不是跑个脚本看个数字而是要固定变量、可复现、能横向对比。我这次要做的是在红帽 AI 推理服务vLLM上用 GuideLLM 这个专门为 LLM 部署设计的压测工具完成一次从部署参数到压测配置再到结果解读的完整闭环。GuideLLM 和普通的 HTTP 压测工具最大的区别在于它理解 token。它会按你指定的 prompt_tokens 和 output_tokens 去构造请求统计 TTFT、ITL、TPOT 这些 LLM 专属指标而不是只给你一个 QPS。这对做容量规划的人来说非常关键。适合谁看已经在用 vLLM 或红帽 AI 推理服务部署模型、需要给业务方一个「这台机器能撑多少 RPS」结论的工程师正在做硬件选型、想知道「要达到 P99 TTFT 80ms 需要几张卡」的架构同学以及想把性能回归测试纳入 CI 的团队。读完你能拿到一套可以直接复制的 vLLM 启动参数、GuideLLM 压测命令以及一份能对照排查报错的清单。核心检索词先摆出来红帽 AI 推理服务 vLLM 性能评估、GuideLLM 压测 LLM 吞吐延迟、vLLM 推理服务 TTFT ITL TPOT 指标。这三个词贯穿全文你搜进来看到的就是这些内容。在动手之前先把几个关键指标的定义对齐不然后面看报告会懵。RPS 是每秒请求数衡量并发处理能力Request Latency 是单请求从发出到结束的总时间等于 TTFT 加生成时间TTFT 是首 token 时间面向用户的应用最在意这个ITL 是 token 间延迟不含首 token反映生成流畅度TPOT 是每个输出 token 的平均耗时等于生成时间除以输出 token 总数是吞吐效率指标。这几个指标里TTFT 和 TPOT 是你要重点盯的因为它们直接决定用户体验和单位成本。2. 前置准备红帽 AI 推理服务与 GuideLLM 环境搭建这一节把地基打好。红帽 AI 推理服务本质上是把 vLLM 做了企业级封装提供了运维、监控、多模型管理等能力底层推理引擎还是 vLLM。所以你在红帽环境里验证过的 vLLM 参数大部分可以直接迁移。如果你还没装好推理服务先按官方入门文档把服务跑起来确认vllm serve能正常加载模型。先确认你的 Python 环境。建议用独立虚拟环境避免和系统包打架python3 -m venv myenv source myenv/bin/activate pip install --upgrade pip然后安装 vLLM 和 GuideLLM。注意 GuideLLM 是 vLLM 项目下的独立工具包安装命令就是pip install guidellm。同时把压测脚本需要的依赖也装上因为 vLLM 自带的 benchmark_serving.py 会用到 pandas 和 datasetspip install vllm pandas datasets guidellm如果你只想用 GuideLLM其实pip install guidellm就够了它自带请求生成器不依赖 datasets。但为了后面能对照 vLLM 原生脚本的结果建议一起装。模型方面我用 RedHatAI/Llama-3.2-1B-Instruct-FP8 做演示这个模型小、加载快、FP8 量化后显存占用低适合在单卡上快速验证流程。你换成自己的模型也行只要把后面的 model 参数替换掉。启动 vLLM 服务。这里给一组我实测比较稳的参数重点是--max-model-len要和你的压测输入输出长度匹配--gpu-memory-utilization控制显存占用比例vllm serve RedHatAI/Llama-3.2-1B-Instruct-FP8 \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 4096 \ --gpu-memory-utilization 0.90 \ --dtype auto \ --disable-log-requests--disable-log-requests在压测时很有用否则每个请求都打日志I/O 会成为瓶颈测出来的吞吐偏低。等服务起来后用 curl 确认接口通curl http://localhost:8000/v1/models返回模型列表就说明服务正常。这一步别跳过后面 GuideLLM 报连接错误时你能快速判断是服务没起还是压测配置写错了。关于 TaoToken 的前置说明如果你在本地做压测的同时还想用云端 API 做对照测试或者团队里有人用 Coding Plan 跑 Agent 任务可以先把 key 准备好。TaoToken 的 API 地址是 https://taotoken.net/api控制台在 https://taotoken.net/consoleAPI Keys 管理页在 https://taotoken.net/api-keys。这些和本地 vLLM 压测是两条线本地压测不依赖外部服务但做模型效果对照时会用到。模型对话入口在 https://taotoken.net/model-chat接入文档在 https://taotoken.net/docCoding Plan 在 https://taotoken.net/coding-plan。先把这些地址记下来后面 CTA 会用到。环境搭好后建议先跑一次小规模请求确认端到端通再上 GuideLLM。很多人一上来就 sweep结果报错信息混在一起排查成本高。3. 可复制配置vLLM 部署参数与 GuideLLM 压测文件这一节是全文的核心操作区。我会给你三样东西一份 vLLM 启动配置、一份 GuideLLM 的 YAML 压测配置、以及对应的命令行调用方式。你直接复制改路径就能用。先说 vLLM 的启动配置。红帽 AI 推理服务支持用配置文件方式启动我把它写成一个 TOML 片段方便你纳入版本管理# vllm-service.toml [model] name RedHatAI/Llama-3.2-1B-Instruct-FP8 dtype auto max_model_len 4096 gpu_memory_utilization 0.90 [server] host 0.0.0.0 port 8000 disable_log_requests true [engine] enable_prefix_caching true max_num_seqs 256enable_prefix_caching对多轮对话或共享前缀的请求提升明显压测时如果 prompt 有公共前缀开启它能显著降低 TTFT。max_num_seqs控制同时调度的序列数太小会限制并发太大可能 OOM256 是个保守起点。接下来是 GuideLLM 的压测配置。GuideLLM 支持 YAML 配置文件比纯命令行更好维护。我写一份guidellm-bench.yaml# guidellm-bench.yaml target: http://localhost:8000 rate_type: sweep max_seconds: 30 data: prompt_tokens: 512 output_tokens: 256 profile: type: sweep strategies: - synchronous - throughput - constant constant_rates: [1.0, 2.0, 4.0, 8.0]这份配置的意思是对 localhost:8000 做 sweep 压测每个策略跑 30 秒请求形态固定为输入 512 token、输出 256 token。sweep 会依次跑同步、吞吐、以及几个固定速率档位帮你找到延迟开始劣化的拐点。constant_rates里的数字是 RPS你可以根据自己机器的预期能力调整。如果你不想用 YAML等价的命令行是guidellm benchmark \ --target http://localhost:8000 \ --rate-type sweep \ --max-seconds 30 \ --data prompt_tokens512,output_tokens256两种方式结果一致YAML 适合反复跑和进 CI命令行适合临时验证。这里有个关键点GuideLLM 默认走 OpenAI 兼容接口也就是/v1/completions或/v1/chat/completions。vLLM 原生就兼容这套接口所以不需要额外适配。但你要确认--target后面不要带/v1GuideLLM 会自己拼路径。我见过有人写成http://localhost:8000/v1结果 404排查半天。另外如果你的服务开了鉴权GuideLLM 支持传 authorization 头在 YAML 里加backend: authorization: Bearer your-token本地压测一般不开鉴权但红帽 AI 推理服务在生产环境通常会配提前知道这个字段能省事。配置写好后先别急着跑全量 sweep。用--max-seconds 5跑个短测确认没有连接错误、模型名对得上、请求能正常返回。短测通过后再跑 30 秒的正式压测。这个习惯能帮你把「配置错误」和「性能问题」分开。4. 验证请求与结果解读从 Benchmark 报告读出硬件需求压测跑起来后GuideLLM 会实时打印进度结束后输出两大块Benchmarks Info 和 Benchmarks Stats。Info 是每个策略的请求数、token 数统计Stats 是延迟和吞吐指标。我拿一次实测结果来带你读。先看 Info 部分。synchronous 策略下30 秒完成 14 个请求1 个未完成throughput 策略下完成 161 个510 个未完成。未完成不代表失败而是压测时间到了请求还没返回说明吞吐策略下系统被打满了。Err 列全是 0说明没有报错请求服务稳定。再看 Stats 部分这是重点。synchronous 策略下Out Tok/sec 是 121.5Req Latency mean 是 2.11msTTFT mean 24.7msITL mean 8.2msTPOT mean 8.1ms。这个延迟非常低因为同步策略一次只发一个请求系统毫无压力。随着 constant 速率从 1.09 升到 5.37你能看到清晰的趋势TTFT mean 从 21.6ms 涨到 37.3msITL mean 从 8.8ms 涨到 11.9msTPOT 从 8.8ms 涨到 11.9ms。延迟在缓慢上升但还没到崩溃点。throughput 策略下并发冲到 141.45TTFT mean 飙到 1713.3msP99 到 3793.7ms这就是系统被打满后的表现。现在做容量推算。假设业务要求 P99 TTFT 低于 80ms。看 constant 档位constant4.76 的 TTFT P99 是 75.3msconstant5.37 的 P99 是 90.7ms已经超标。所以这台硬件在满足 P99 TTFT 80ms 的前提下能支撑的 RPS 大约是 4.76。如果业务需要 50 RPS那 50 除以 4.76 约等于 10.5向上取整需要 11 台同配置服务器。这个推算方法就是原文里提到的思路我把它具体化了。再验证一下请求是否真的成功。压测结束后你可以单独发一个请求确认服务还在正常响应curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d { model: RedHatAI/Llama-3.2-1B-Instruct-FP8, prompt: Explain vLLM in one sentence., max_tokens: 64 }返回里有choices字段和生成的文本就说明服务健康。这一步是压测后的 sanity check别省。GuideLLM 还会把完整报告存成 JSON默认路径在输出里会打印比如/root/benchmarks.json。你可以用 jq 提取关键指标做对比jq .benchmarks[] | {name: .name, ttft_p99: .stats.ttft.p99, tpot_mean: .stats.tpot.mean} /root/benchmarks.json这样每次压测后能快速生成一张对比表纳入回归测试。我试过把不同模型、不同量化版本的报告放一起对比FP8 相比 FP16 在同等硬件上 TPOT 能降 20% 左右但具体数字取决于模型和输入长度你得自己测。读报告时有个坑mean 和 median 差距大说明分布偏斜这时候要看 P99。比如 throughput 策略下 TTFT mean 1713ms、median 1608ms、P99 3793msP99 是 mean 的两倍多说明有长尾请求。面向用户的应用必须盯 P99不能只看均值。5. 常见报错排查401、连接失败与 choices 解析异常压测过程中最容易撞上的几类错误我按出现频率排一下每个都给你定位方法。第一类401 Unauthorized。如果你在红帽 AI 推理服务上开了鉴权GuideLLM 没带 token 就会 401。报错长这样Error: backend request failed with status 401: Unauthorized解决方法是确认服务端鉴权配置然后在 GuideLLM 配置里加 authorization 字段。如果你用的是 TaoToken 的 API 做对照测试key 要从 https://taotoken.net/api-keys 拿Base URL 填 https://taotoken.net/apiModel ID 填你实际调用的模型名。这三件套缺一不可Base URL、Key、Model ID。很多人只填了 URL 忘了 model报 404 或 model not found。第二类local proxy failed 或 connection refused。报错类似Error: failed to connect to http://localhost:8000: Connection refused这说明 vLLM 服务没起来或者端口不对。先curl http://localhost:8000/v1/models确认。如果服务在容器里注意端口映射--host 0.0.0.0不能少否则只监听 127.0.0.1容器外访问不到。第三类reading choices 相关错误。GuideLLM 解析响应时如果拿不到choices字段会报Error: failed to parse response: missing choices in response body这通常是接口路径不对。GuideLLM 默认走/v1/completions如果你用的是 chat 模型且服务只开了/v1/chat/completions就会解析失败。检查 vLLM 启动参数或者确认模型是否支持 completions 接口。Llama-3.2-Instruct 系列建议走 chat 接口在 GuideLLM 里可以指定路径。第四类OOM 或 CUDA out of memory。压测时并发一高显存不够就崩。报错torch.cuda.OutOfMemoryError: CUDA out of memory解决方法是降--gpu-memory-utilization或者降max_num_seqs或者缩短max_model_len。压测的输入输出长度如果超过max_model_len也会触发异常确保prompt_tokens output_tokens max_model_len。第五类OAuth 或 token 过期。如果你用云端 API 做对照token 过期会报 401 或 403。重新生成 key 即可。本地 vLLM 不涉及这个问题。排查顺序建议先 curl 确认服务活着再确认接口路径再确认鉴权最后看显存。这个顺序能覆盖 90% 的问题。每次改配置后重新跑 5 秒短测别直接上 30 秒省时间。6. 把压测纳入日常从一次评估到持续回归一次压测只能告诉你「此刻这台机器能扛多少」但模型更新、驱动升级、参数调整都会改变性能。所以真正有价值的做法是把这套流程固化成回归测试。具体怎么做把guidellm-bench.yaml和 vLLM 启动配置一起放进 Git每次模型或环境变更后跑一次把benchmarks.json存档用脚本对比关键指标的波动。比如 TTFT P99 超过基线 20% 就告警。这样你能在性能劣化影响业务之前发现它。如果你团队用 Coding Plan 跑长期 Agent 任务压测数据还能帮你决定该用本地推理还是云端 API。本地推理在固定负载下单位成本低但弹性差云端 API 弹性好但按 token 计费。用 GuideLLM 测出本地的 RPS 上限和延迟曲线后你能算出本地能覆盖多少峰值流量超出部分走云端这个混合策略比拍脑袋靠谱。最后给一个实用技巧压测时把--max-seconds设成业务高峰的典型时长比如 60 秒或 120 秒短测容易低估长尾延迟。另外warmup 很重要vLLM 首次请求会触发编译和缓存填充前几个请求延迟偏高GuideLLM 支持 warmup 配置正式测之前先跑几个请求把模型热起来。这套流程我在不同硬件上跑过多次最深的体会是不要迷信单次结果多跑几轮取稳定值不要只看吞吐延迟曲线才是容量规划的依据不要跳过短测配置错误和性能问题混在一起最难查。把这三条记住你的 vLLM 性能评估就能做得又稳又可复现。