[Bug]: GPT-OSS 20b/120b [backend_xgrammar.py:160] Failed to advance FSM for request

快速结论：该报错通常出现在 vLLM 运行 GPT-OSS 20b/120b 模型时，与异步调度（async-scheduling）配置有关。优先尝试移除 --async-scheduling 启动参数，该方案已获用户验证。

适用环境：vLLM；GPT-OSS 20b（单 H100）、GPT-OSS 120b（2×H200）；Docker 镜像 vllm-openai:gptoss。涉及 vLLM 0.27.1 版本。

最快修复方案：在启动命令中移除 --async-scheduling 参数。该方案在 Issue 评论区已被用户确认有效。

注意事项：部分用户反馈在 vLLM 0.27.1 中即使不带该参数仍会复现，说明可能还有其他原因；移除该参数可能影响调度性能，建议根据实际负载权衡。

问题场景

用户在使用 vLLM 部署 GPT-OSS 20b（单卡 H100）和 GPT-OSS 120b（双卡 H200）时，服务端在推理过程中反复输出报错日志 [backend_xgrammar.py:160] Failed to advance FSM for request，导致请求处理异常。用户使用了官方提供的 Docker 镜像 vllm-openai:gptoss 进行部署。

报错原文

[Bug]: GPT-OSS 20b/120b [backend_xgrammar.py:160] Failed to advance FSM for request

原因分析

该报错位于 backend_xgrammar.py 的 FSM（有限状态机）推进逻辑中，可能原因：

异步调度与结构化输出（xgrammar）状态机协作不兼容。Issue 评论区用户验证移除 --async-scheduling 后问题消失，说明异步调度可能导致 FSM 状态推进时的竞态条件或上下文丢失。

同时，后续有用户反映在 vLLM 0.27.1 中即使不带该参数也会触发，说明该版本可能存在独立于异步调度的问题，可能与 xgrammar 版本或模型配置有关。

环境排查

确认 vLLM 版本：0.27.1 已有复现反馈，建议检查是否为最新修复版本。
确认 Docker 镜像：vllm-openai:gptoss 是否与当前 vLLM 版本匹配。
检查启动参数：确认是否包含 --async-scheduling 或相关调度配置。
检查模型路径与 GPU 显存分配是否正常（20b 单卡 / 120b 双卡）。
收集完整的 collect_env.py 输出，核对 CUDA、PyTorch 版本是否满足模型要求。

解决步骤

立即尝试：在 vLLM 启动命令中移除 --async-scheduling 参数，重启服务并复测推理请求。（该方案已有用户确认有效，可优先尝试）
如果移除后仍复现（如在 vLLM 0.27.1 中），尝试升级到更新版本的 vLLM，查看是否已修复该问题。
检查 xgrammar 依赖版本，必要时锁定或更新到与 vLLM 兼容的版本。
查阅 vLLM GitHub Issues 中关于 Failed to advance FSM 的后续跟踪，确认是否有官方修复补丁或推荐配置。
如果上述步骤未解决，在 vLLM 仓库提交新 Issue，附上完整的 collect_env.py 输出、启动参数和复现日志。

验证方法

移除 --async-scheduling 后，连续发送多个正常与结构化输出请求，观察服务端日志中是否不再出现 [backend_xgrammar.py:160] Failed to advance FSM for request，且所有请求均能正常返回结果。同时关注 vLLM 新版本发布说明，确认该问题是否已在后续版本修复。