快速结论:同一台机器、同一服务端上,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 客户端和 Rustvllm-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 后端会让尾部
usagechunk 延长 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 和实际请求参数是否一致。
解决步骤
- 在 Rust 侧重跑时显式指定
--temperature 0,与旧版 Python 客户端的贪心解码对齐;或在 Python 侧加--temperature 0.6 --top-p 0.9,与 Rust 侧采用相同采样设置。 - 用相同参数重复跑一次,确认数值接近。Issue 中用户执行
--temperature=0后结果已对齐。 - (可优先尝试)交替运行 Python、Rust、Python、Rust 多轮,排除服务端预热和状态漂移。
- (可优先尝试)对照服务端日志中的 batch size 与实际请求参数,确认两次测试条件一致。
- 升级 Python 侧 vLLM 到 v0.19.2 及以上,可获得温度告警,并改用服务端
usage.prompt_tokens;如使用 Rust 客户端,注意 #59251 修复是否已合入。
验证方法
在统一 temperature(以及 top_p)后复跑两个客户端,Mean TTFT、Mean TPOT、Mean ITL 等指标应明显靠拢。本 Issue 中 Rust 加 --temperature=0 后数值已与 Python 结果对齐,即视为问题解决。
参考来源
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。
![[Bug]: [ROCm] Qwen4Exp (AMD path): PLE n-gram IDs read a stale query_start_loc tail during PIECEWISE CUDA-graph replay](https://www.chat-gpts.plus/wp-content/uploads/2026/11/61486-25e2f379-768x403.jpg)
![[Bug]: V1 thinking budget corrupts a multi-token reasoning_end_str under speculative decoding](https://www.chat-gpts.plus/wp-content/uploads/2026/11/58485-85e0f342-768x403.jpg)
