[Bug]: rust vllm-bench result is quite different from vllm bench serve

同一台机器、同一服务端上,Rust vllm-bench 与 Python vllm bench serve 的吞吐/延迟差异明显时,通常不是客户端计时或 HTTP 处理问题,而是两边的采样参数不一致(尤其 temperature)。优先检查两个客户端实际发给服务端的 temperature,并统一

快速结论:同一台机器、同一服务端上,Rust vllm-bench 与 Python vllm bench serve 的吞吐/延迟差异明显时,通常不是客户端计时或 HTTP 处理问题,而是两边的采样参数不一致(尤其 temperature)。优先检查两个客户端实际发给服务端的 temperature,并统一它。

适用环境:Issue 中环境为 Ubuntu 22.04.5、Python 3.10.12、PyTorch 2.13.0+cu130(CUDA 13.0),使用 Tenstorrent 平台插件(tt),模型为 Llama-3.1-8B-Instruct;collect_env.py 显示本机无 CUDA 设备。Python 侧基准由 tt-inference-server 的 run.py 自动安装,用户推测为 v0.13.0。

最快修复方案:已确认有效:给 Rust vllm-bench 显式加上 --temperature 0 后,结果与 Python 侧对齐(等价做法是 Python 侧改为 --temperature 0.6 --top-p 0.9)。

注意事项:Rust 客户端的“不传 temperature”行为与 Python 新版一致,是否对齐取决于服务端 generation_config.json;本次验证是 Llama-3.1-8B-Instruct(temperature=0.6、top_p=0.9)。对比前还需排除服务端预热和状态漂移、以及版本差异带来的指标口径不同。

问题场景

用户在同一主机(不同 venv/docker 容器)上运行 vllm bench serve(Python)和 Rust 版 vllm-bench,两者都指向同一个 vLLM 服务端(Tenstorrent 平台),参数为 --max-concurrency 32 --random-input-len 128 --random-output-len 128 --header Accept-Encoding=identity --extra-body '{"truncate_prompt_tokens": 128}'、256 条 prompt,但两次基准结果差异很大(解码速度约 4 倍)。

报错原文

[Bug]: rust vllm-bench result is quite different from vllm bench serve

原因分析

最可能原因:采样参数不同,而不是 Rust 客户端的计时或 HTTP 处理有误。

  • Python 侧输出了 Total input tokens: 32512,正好等于 256 × 127,这是客户端侧 prompt 长度。自 #38654(v0.19.2)起,vllm bench serve 改为报告服务端的 usage.prompt_tokens。因此可以判断该 Python 客户端版本低于 v0.19.2(用户推测为 tt-inference-server 引入的 v0.13.0)。
  • 在 #32723(v0.15.0)之前,vllm bench serve 除非显式传 --temperature,否则每个请求都会发送 temperature: 0,即贪心解码。新版 Python 客户端和 Rust vllm-bench 都不发送 temperature,服务端会采用模型 generation_config.json 的设置;Llama-3.1-8B-Instruct 为 temperature=0.6, top_p=0.9。
  • 在该后端上 top-p 采样可能比贪心慢很多,于是表现为 TTFT 接近而解码阶段慢约 4 倍。
  • 用模拟 OpenAI 流式服务端(固定令牌速率)对比时,两个客户端的 Mean TTFT、TPOT、ITL 基本一致,请求体和请求头也相同(Rust 仅不发送 User-Agent),说明 Rust 客户端本身不会把 TPOT 测错 4 倍。
  • 另有两处已知的小问题(不解释 4 倍差异):Rust chat 后端会让尾部 usage chunk 延长 E2EL/TPOT(#59251,对应 Python 侧的 #55508 修复尚未移植);Peak concurrent requests: 64 与 --max-concurrency 32 不符是 #56653 的按秒分桶统计问题。

环境排查

  • 确认 Python vllm bench serve 的版本:低于 v0.19.2 时 Total input tokens 是客户端侧长度,并且默认强制 temperature: 0。
  • 确认 Rust vllm-bench 的版本,以及它是否已包含 temperature 告警。
  • 确认服务端加载的模型及 generation_config.json 中的 temperature / top_p。
  • 确认两个客户端使用相同的输入参数(并发、输入/输出长度、prompt 数、header、extra body)。
  • 两次测试是否为同一服务端进程、是否在对比前发生过预热或状态变化。
  • 检查服务端日志中的运行 batch size 和实际请求参数是否一致。

解决步骤

  1. 在 Rust 侧重跑时显式指定 --temperature 0,与旧版 Python 客户端的贪心解码对齐;或在 Python 侧加 --temperature 0.6 --top-p 0.9,与 Rust 侧采用相同采样设置。
  2. 用相同参数重复跑一次,确认数值接近。Issue 中用户执行 --temperature=0 后结果已对齐。
  3. (可优先尝试)交替运行 Python、Rust、Python、Rust 多轮,排除服务端预热和状态漂移。
  4. (可优先尝试)对照服务端日志中的 batch size 与实际请求参数,确认两次测试条件一致。
  5. 升级 Python 侧 vLLM 到 v0.19.2 及以上,可获得温度告警,并改用服务端 usage.prompt_tokens;如使用 Rust 客户端,注意 #59251 修复是否已合入。

验证方法

在统一 temperature(以及 top_p)后复跑两个客户端,Mean TTFT、Mean TPOT、Mean ITL 等指标应明显靠拢。本 Issue 中 Rust 加 --temperature=0 后数值已与 Python 结果对齐,即视为问题解决。

参考来源

vllm-project/vllm #59154

GamsGo AI

AI 工具推荐

想把多个 AI 模型放在一个入口?

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。

这个方案解决了吗?

celebrityanime
celebrityanime
文章: 33498

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注