Question 1

为什么在 SM80/SM86/SM89 GPU 上，VLLM_BATCH_INVARIANT=1 对 AWQ 模型不具备批次不变性(输出结果具有非确定性)?

Accepted Answer

根本原因：当 VLLM_BATCH_INVARIANT=1 时，`AutoAWQLinearMethod` 会反量化权重并调用 `torch.matmul`。在 torch.compile 下，Inductor 会将该 matmul 降级为 `extern_kernels.mm(..., out=...)`（aten::mm.out → cuBLAS），绕过了 vLLM 针对 `aten::matmul` 的批处理不变 torch.library 覆盖，因此结果会依赖于批处理大小。

修复：升级到包含 PR #60479（在 `AutoAWQLinearMethod` 和 `AutoGPTQLinearMethod` 中直接调用 `matmul_batch_invariant`）以及 PR #52231（覆盖 Inductor 在 SM80 上为 mm/addmm 生成的 `.out` 重载）的 vLLM 版本。已在当前 main/nightly 镜像上验证：`tests/v1/determinism/test_batch_invariance.py` 在 sm86 上针对 `Qwen/Qwen3-8B-AWQ` 通过 22/22，并且使用 `VLLM_BATCH_INVARIANT=1 vllm serve Qwen/Qwen3-8B-AWQ` 提供服务时 logprob 差异为零。

旧版本的变通方法：使用 `--enforce-eager` 启动（eager 模式会将 matmul 路由到批处理不变的覆盖）。请注意，仅禁用 CUDA graphs 而不使用 enforce-eager 并不能恢复不变性。

Question 2

如何修复 vLLM 在 FP8 模型（RTX Blackwell SM120）上使用 DeepGEMM 时崩溃并报错 "RuntimeError: not home_path.empty()" 的问题？

Accepted Answer

此崩溃的原因是：vLLM 在处理块缩放 FP8 模型（例如 `Qwen/Qwen3-0.6B-FP8`）时选择了 DeepGEMM 内核，但 DeepGEMM 需要借助 CUDA 工具包（`nvcc`、`CUDA_HOME`、主机编译器）进行 JIT 编译，而标准的仅 wheel 的 `pip install vllm` 安装环境中缺少这些工具。内核选择逻辑只检查模块是否可导入，而不检查工具链是否可用。**解决方法：** 禁用 DeepGEMM，强制回退到 CUTLASS 块 FP8 内核：
```bash
export VLLM_USE_DEEP_GEMM=0
python -c "from vllm import LLM; LLM('Qwen/Qwen3-0.6B-FP8', max_model_len=2048)"
```
设置 `VLLM_USE_DEEP_GEMM=0` 后，将选择 `CutlassFp8BlockScaledMMKernel`，模型可正常运行。**替代修复方案：** 安装完整的 CUDA 工具包（配置好 `nvcc` 和 `CUDA_HOME`），并安装主机 C++ 编译器，使 DeepGEMM JIT 能够在运行时完成编译。

Question 3

为什么 vLLM EngineCore 在收到格式错误的 structured_outputs 语法请求后会崩溃并抛出 EngineDeadError？

Accepted Answer

vLLM v0.20.0–v0.21.0 中的一个已知 bug（V1 引擎，默认 `auto` 结构化输出后端）。`StructuredOutputManager` 会在收到第一个有效语法请求时锁定 xgrammar 后端，并在进程的整个生命周期内保持锁定状态，而 `XgrammarBackend.compile_grammar` 没有任何异常处理。此后任何携带无效 EBNF 语法（例如重复的 `root ::=` 规则）的请求都会从后台编译 future 中抛出异常，异常传播至 `EngineCore.run_busy_loop`，并以 HTTP 500 使引擎崩溃（所有 TP worker 全部关闭）。修复方案：升级到包含 PR #44401 的 vLLM 构建版本，该 PR 会捕获编译失败，使引擎保持存活并对格式错误的语法返回 HTTP 400。受影响版本上的临时解决方案：在提交前于客户端验证 EBNF 语法（例如使用 `xgrammar` Python 包进行测试编译），因为只有当格式错误的语法在某个已锁定 xgrammar 的有效语法之后发送时，才会触发崩溃。

Question 4

如何修复在 vLLM 中以 DSpark 自适应验证和 FULL_AND_PIECEWISE cudagraph 模式运行 DeepSeek-V4.1 时出现的 CUDA 非法内存访问问题？

Accepted Answer

该崩溃（`CUDA error: an illegal memory access was encountered`，在 `AdaptiveVerification.record_confidences` 中抛出）发生在 vLLM 0.31.0 上：当 DSpark 自适应验证与 `cudagraph_mode=FULL_AND_PIECEWISE` 同时启用，并处于高并发混合 prefill+decode 批次时。根本原因：DeepSeek-V4.1 FlashInfer 稀疏注意力构建器（`DeepseekV4FlashInferSparseMLAMetadataBuilder`、`DeepseekSparseSWAFlashInferMetadataBuilder`，以及 compressor/FlashMLA 构建器）声明了 `AttentionCGSupport.ALWAYS`，错误地允许 prefill/混合批次进入 FULL cudagraph。有两个已验证的临时规避方案（在 c96–c128 并发下稳定运行 15–30 分钟）：1）在 speculative 配置中禁用自适应验证：`--speculative-config '{"method":"dspark","num_speculative_tokens":5,"enable_adaptive_verification":false}'`——实测吞吐量在噪声范围内相同（每 GPU 输出 1,643 vs 1,608 tok/s）。2）保持自适应验证开启，但将 cudagraph 限制为仅 decode：`--compilation-config '{"mode":"VLLM_COMPILE","cudagraph_mode":"FULL_DECODE_ONLY"}'`。永久修复方案是将这些构建器改为 `AttentionCGSupport.UNIFORM_BATCH`，并实现 `get_varlen_cudagraph_max_query_len`，使其返回 `max_decode_query_len(vllm_config)`；该问题在较新的 main 构建版本上无法复现，因此将 vLLM 升级到 0.31.0 之后的版本可能会解决此问题。

Question 5

为什么 DSpark 投机解码在 vLLM 上运行 DeepSeek-V4.1-Flash-1017 时会产生重复且乱码的推理输出？

Accepted Answer

这是一个已确认的 vLLM bug(#62417):在启用 `--speculative-config '{"method":"dspark","num_speculative_tokens":N}'` 的情况下,DeepSeek-V4.1-Flash-1017 checkpoint 上 `/v1/chat/completions` 思考模式的输出会退化为 token 循环(例如 "to invoketo invoke..."、"*75*75*75..."),并且永远无法生成结构化的工具调用。该问题可在 vLLM 0.32.0 和 nightly(torch 2.13/2.14)上复现,在所有 k 值(3/4/5/7)以及任意 temperature 下均会出现。原因在于 1017 checkpoint 微调后的 `mtp.*` 草稿头与 DSpark 之间的相互作用;tokenizer、模板和 parser 标志均已排除。解决方法:移除 `--speculative-config` 标志以禁用投机解码 —— 此后 reasoning/content 分离和 `tool_calls` 即可正常工作(已在 12/12 个 agent 会话中验证)。或者,使用原始的 `DeepSeek-V4.1-Flash` checkpoint,它与 DSpark 配合运行良好。纯文本 `/v1/completions` 不受影响,因此投机解码对非聊天工作负载仍然是安全的。

vllm

核心功能

避坑指南

适用场景

标签

快速上手

相似推荐