快速结论:该问题通常出现在使用 vLLM 部署 Qwen3-Reranker(如 Qwen/Qwen3-Reranker-0.6B)并调用 /score 端点时,当输入数据长度恰好触达模型最大长度(8192 token)附近,进程会挂起。优先排查 truncate_prompt_tokens 的取值,以及是否触发底层的 detokenizer 异常。
适用环境:Ubuntu 22.04.4 LTS(x86_64);Python 3.13.5(conda-forge 打包);PyTorch 2.8.0+cu128;CUDA runtime 12.9.86;NVIDIA driver 535.247.01;4× NVIDIA RTX 6000 Ada Generation;Intel Xeon w7-3445;vLLM 版本未在 Issue 中明确列出。
最快修复方案:将请求中的 truncate_prompt_tokens 改为 8191,避免使用 8192 或 -1(Issue 中已验证 8191 可正常工作,8192 和 -1 会触发挂起)。
注意事项:truncate_prompt_tokens: 8191 属于规避性修复,并非根因修复;该问题可能源于 HuggingFace Tokenizers 的已知缺陷(相关 PR 尚未合并发布),在底层依赖修复前,仍需注意输入长度不要恰好等于模型最大长度。
问题场景
用户使用 vLLM 部署 Qwen/Qwen3-Reranker-0.6B 重排序模型,并通过 HTTP 请求调用 /score 端点对 queries 与 docs 进行打分。当请求携带特定数据(第 12 组 query/document 对)时,进程发生挂起(hang),无法返回响应。该问题与输入长度逼近模型最大长度 8192 有关,也涉及 truncate_prompt_tokens 参数的取值。
报错原文
[Bug]: Qwen3-Reranker: Process Hang with `/score` Endpoint for Specific Data
assert self.detokenizer is not None
File "vllm/v1/engine/output_processor.py", line 242, in _new_completion_output
原因分析
根据 Issue 讨论,问题触发条件与输入 token 数量密切相关:
- 当
truncate_prompt_tokens设置为8192(即模型最大长度)或-1(不截断)时,第 12 组数据会触发挂起。 - 当
truncate_prompt_tokens设置为8191时,同一组数据可以正常返回。 - Issue 中有维护者指出,该问题可能与 HuggingFace Tokenizers 的一个已知缺陷有关(对应 PR huggingface/tokenizers#1859 尚未合并),因此需要等待 Tokenizers 发布新版本并更新 vLLM 的依赖 pin。
- 另一处线索是
assert self.detokenizer is not None断言失败,位于vllm/v1/engine/output_processor.py第 242 行,说明 detokenizer 在特定输入下未被正确初始化或已被释放。
综合来看,可能原因是当输入 token 数恰好达到模型最大长度时,vLLM 内部推理调度与 detokenizer 状态出现异常,导致进程挂起;而底层 Tokenizers 的缺陷可能使该边界条件更容易被触发。
环境排查
- 确认 vLLM 版本,以及是否已包含与 HuggingFace Tokenizers 相关的修复或依赖更新。
- 确认 Python 版本(Issue 中为 3.13.5)与 PyTorch 版本(2.8.0+cu128)是否与当前 vLLM 版本兼容。
- 确认 CUDA runtime(Issue 中为 12.9.86)与 NVIDIA driver(535.247.01)版本,排除驱动层面导致的流同步异常。
- 确认
Qwen/Qwen3-Reranker-0.6B模型的max_model_len是否为 8192(Issue 中相关讨论 #23683 提到该模型使用 max model len 8192)。 - 确认请求体中
truncate_prompt_tokens的取值,以及触发问题的具体 query/document 对的 token 数量。 - 确认是否在
/score端点请求中传入了空字符串或超长文本,排除输入数据本身的边界问题。
解决步骤
- 在调用
/score端点的请求体中,将truncate_prompt_tokens显式设置为8191,而不是8192或-1。这是 Issue 中用户已验证有效的规避方法。 - 如果业务上无法固定为 8191,可先对输入文本做长度预检查,确保拼接后的 token 数不超过 8191,再发送请求。
- 关注 HuggingFace Tokenizers 相关 PR(huggingface/tokenizers#1859)的合并与发布状态,以及 vLLM 是否更新了对应的依赖 pin。在依赖修复发布后,升级 vLLM 与 tokenizers 版本,再尝试使用
-1或 8192。 - 如果问题仍可复现,收集 vLLM 启动日志、请求日志以及
output_processor.py第 242 行附近的完整堆栈,提交到原始 Issue 或新开 Issue 补充信息。 - 作为临时绕过手段,可在请求层对输入长度做截断,避免恰好等于或超过模型最大长度。
验证方法
使用与 Issue 中相同的复现脚本,将 truncate_prompt_tokens 设为 8191,对第 12 组 query/document 对发起 /score 请求,确认接口能正常返回 JSON 结果且进程不再挂起。同时可对比 8192 或 -1 时的表现,确认规避参数的有效性。
参考来源
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。


