RuntimeError: Worker failed with error ‘No common block size for 64

问题场景

用户用 vllm serve 启动 deepseek-ai/DeepSeek-V4.1-Flash，单节点 8 卡 TP8，attention backend 为 FLASHINFER_MLA_SPARSE_DSV41，indexer_kv_dtype 用 fp8，KV cache dtype fp8，开启 engram cpu_offload 与 --language-model-only。启动阶段即崩溃，服务无法起来。排查过程中已逐项越过前置门槛：indexer_kv_dtype=mxfp4 在 SM120 被拒（要求 Blackwell datacenter SM10x），indexer_sparse_logits 需要 MXFP4 indexer cache，flashinfer-jit-cache shim 需单独安装，torch/nightly 升级带来的 torchaudio CUDA 不匹配需卸载 torchaudio，并已应用 #53425（仅覆盖 deepseek_v4 家族，未覆盖 deepseek_v41 的两级 block-size 链）。

报错原文

ValueError: SM120 sparse-MLA has no decode kernel for this shape: num_tokens=8,
num_heads=8, topk=128, d_qk=512, page_block_size=32, model_type=dsv4, extra_topk=0.

RuntimeError: Worker failed with error 'No common block size for 64
(FLASHINFER_MLA_SPARSE_DSV41: [128]; ...)

原因分析

最可能的原因是 page block size 几何不匹配：DeepSeek-V4.1 的两级稀疏注意力给每层一个 compress_ratio（该 checkpoint 为 [0,0,2,2,...,2,1,1,1,1,1]），vLLM 按 attn_metadata.block_size // compress_ratio 计算压缩层 KV page block size，ratio-2 层在全局 block_size=64 时得到 pbs=32。而 FlashInfer 的 SM120 调度 planner（flashinfer/mla/_sparse_mla_sm120_plan.py）把 _PAGE_BLOCK_SIZE 硬编码为 64，dsv4 解码 kernel 只在 pbs=64 实例化，报错本身也把 page_block_size=32 列为不支持。

同时不存在可用的全局 block size：改 128 时 vLLM 报 No common block size for 64（SM120 kernel 集同样没有 pbs=128 的 dsv4 实例）。调试栈确认失败路径为 deepseek_v41/attention.py::forward → nvidia/flashinfer_sparse.py::_forward_prefill → flashinfer_trtllm_batch_decode_sparse_mla_dsv4，其中 page_block_size=32 由压缩 cache 的 tensor shape 推导而来。也就是说，混合 ratio 1/2 的两级结构与当前只覆盖 pbs=64 的 SM120 kernel 实例集不兼容。

补充（PR #56509 实测后）：即使把 SM120 的 swa_block_size 强制为 64 绕过崩溃，输出仍全为 U+FFFD。由于 DeepGEMM 与 Marlin 两种 MoE 后端产生同样乱码，嫌疑集中在共享的注意力/indexer 层在 64 几何下的 SWA 逻辑（可能读错 KV 位置），或 MXFP8 激活量化路径；这部分属于推测，尚未确认。

环境排查

• 确认 vLLM 版本是否为 0.32.0 release tag 或对应 nightly，以及是否已包含 #53425、#56509 等改动。
• 确认 FlashInfer 0.7.0 三件套（flashinfer-python、flashinfer-cubin、flashinfer-jit-cache sm120f+cu130）齐全，4KB 的 flashinfer-jit-cache shim 是否以 --no-deps 安装（提供 flashinfer_jit_cache.__version__）。
• 确认 GPU 为 SM120（RTX PRO 6000 Blackwell）还是 SM121，以及是否属于官方配方验证的 H100/H200/B200/GB200 级别。
• 确认 attention-config：indexer_kv_dtype 是否为 fp8（mxfp4 在 SM120 被拒）、是否误开 indexer_sparse_logits。
• 确认全局 block_size 取值（64 或 128），以及 ratio-2 压缩层推导出的 pbs。
• 确认 torch / torchaudio 的 CUDA 版本是否匹配；如有 torchaudio CUDA 不匹配，按 Issue 做法卸载 torchaudio。
• 确认 MoE backend：SM120 上 triton、b12x 不受支持；auto 会选 DEEPGEMM_MXFP4。

解决步骤

1. 先用当前 nightly 原样复现，记录完整报错，确认属于 page 几何问题而非 kv dtype 或 indexer 配置被拒。
2. 修正前置条件：indexer_kv_dtype 改为 fp8；移除 indexer_sparse_logits；补齐 flashinfer-jit-cache shim（--no-deps）并卸载 CUDA 不匹配的 torchaudio。
3. 可优先尝试：在 nightly 上应用 PR #56509（ratio 专属 kernel block size [64, 128]），以官方复现命令启动，观察是否越过 page_block_size=32 崩溃。
4. 若 auto 选择的 DEEPGEMM_MXFP4 后端崩溃，显式加 --moe-backend marlin 作为临时绕行（该绕行已在 Issue 中验证可启动）。
5. 启动成功后做输出质量检查：发送简短 prompt，检查返回内容是否为 U+FFFD 替换字符。
6. 若 #56509 下输出仍为乱码，说明 page 几何已绕过但计算正确性问题未解决；不要投入生产，可回到上游等待修复（FlashInfer 增加 pbs=32 实例，或 vLLM 支持按层/按 cache 的 block size）。
7. 若有余力，按维护者建议同时测试 #57292 搭配 flashinfer-ai/flashinfer#5174，反馈启动、短 gsm8k/lm-eval 与解码吞吐数据，帮助确定保留哪种几何。

验证方法

验证分两层：其一，服务能正常启动、加载权重、health 返回 200、日志无 SM120 sparse-MLA has no decode kernel 或 No common block size；其二，也是更关键的，用 "Hello"、"What is 17*19?" 这类短 prompt 检查输出是否含 U+FFFD（hex efbfbd）。只有启动成功且输出为正常文本，才算真正修复；Issue 中 #56509 仅满足第一层。

参考来源

vllm-project/vllm #59203

AI 工具推荐

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

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

了解 GamsGo AI

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