[Bug]: DeepSeek-V4.1 DSpark adaptive verification + FULL_AND_PIECEWISE: illegal memory access under concurrent prefill (FlashInfer sparse DS

快速结论：该报错通常出现在 DeepSeek-V4.1 DSpark 自适应验证（adaptive verification）开启、且 cudagraph_mode=FULL_AND_PIECEWISE 的高并发混合 prefill+decode 负载下；优先排查 FlashInfer sparse DSV4.1 相关 metadata builder 的 CUDA Graph 兼容性声明（AttentionCGSupport.ALWAYS）是否让混合批次进入了 FULL graph。

适用环境：Issue 中确认的环境为 vLLM vllm/vllm-openai:v0.31.0（digest sha256:a4a4c0437bf7…）、2× B300（SM103）、TP2、Model Runner V2、模型 DeepSeek-V4.1-Flash（rev dba1be0a40aa45a94ad051997016db3960a90277）。复现测试也涉及 4× DGX Spark（GB10，sm_121a，TP=4，统一内存）。Python、CUDA、PyTorch 版本在 Issue 中未明确给出。

最快修复方案：暂无确认的一步修复方案。Issue 中明确验证过的规避方案是关闭自适应验证：在 --speculative-config 中设置 "enable_adaptive_verification": false；在该配置下 FULL_AND_PIECEWISE 保持稳定运行，吞吐在噪声范围内基本一致。

注意事项：关闭自适应验证是规避而非根因修复。Issue 提出将相关 builder 改为 UNIFORM_BATCH 并让 get_varlen_cudagraph_max_query_len 返回 max_decode_query_len(vllm_config)，但该改动未被明确确认为已验证修复；#59751 只修改通用 FlashInferMLASparseTRTLLMMetadataBuilder，不覆盖 DSV4.1 这条路径。另有复现者在当前 main（71e9320633）使用 DeepSeek-V4.1-Flash-1017 未能复现，说明触发条件可能依赖特定版本或负载组合。GB10 上该问题可能表现为整机静默死机而非可捕获的 CUDA 报错，仅靠 SSH 看门狗无法恢复。

问题场景

使用 vLLM 部署 DeepSeek-V4.1-Flash，开启 DSpark 投机解码并启用 enable_adaptive_verification: true，同时设置 cudagraph_mode=FULL_AND_PIECEWISE，注意力后端为 FLASHINFER_MLA_SPARSE_DSV41。在闭环多轮对话、约 96 并发流、prompt 长度 0.6K–118K、prefix cache 命中率约 90% 的负载下，调度器进入混合 prefill+decode 批次时引擎崩溃。原报告在 30–60 秒内复现，4 次尝试全部复现，当时约 90 个请求在跑、KV cache 仅使用约 3%。

报错原文

CUDA error: an illegal memory access was encountered

报错位置出现在 AdaptiveVerification.record_confidences（vllm/v1/worker/gpu/spec_decode/adaptive_verification.py:264，由 model_runner.sample_tokens 调用）的事件同步处。Issue 说明该错误是异步的，这一帧只是错误被上报的位置，并非真正的出错点。

原因分析

根据 Issue 的 A/B 结果，问题与“自适应验证开启”和“FULL_AND_PIECEWISE”同时存在强相关：

自适应验证开启 + FULL_AND_PIECEWISE：1 分钟内出现 IMA，4/4 复现；
自适应验证关闭 + FULL_AND_PIECEWISE：稳定运行 30 分钟 c96 加 15 分钟 c128；
自适应验证开启 + FULL_DECODE_ONLY：稳定运行 15 分钟 c128。

可能原因是：0.31.0 中 DSV4.1 的 FlashInfer sparse builders（DeepseekV4FlashInferSparseMLAMetadataBuilder、DeepseekSparseSWAFlashInferMetadataBuilder，以及 compressor 和 FlashMLA builders）都声明了 AttentionCGSupport.ALWAYS，导致混合/预填充批次被纳入 FULL graph 捕获，进而触发非法内存访问。Issue 认为这与 #59681 / #59751 属于同一类问题，但 #59751 只改通用 builder，无法覆盖该路径。在 GB10 统一内存平台上，同一类非法访问可能直接落到主机内存，表现为整机冻结而非 CUDA 错误。

环境排查

确认 vLLM 版本是否为 vllm/vllm-openai:v0.31.0（或其他含相同 builder 声明的版本）。
确认是否使用 DeepSeek-V4.1 系列模型，以及对应的 tokenizer-mode deepseek_v41。
确认 --speculative-config 中 enable_adaptive_verification 是否为 true。
确认 --compilation-config 中 cudagraph_mode 是否为 FULL_AND_PIECEWISE。
确认注意力后端是否为 FLASHINFER_MLA_SPARSE_DSV41，以及是否设置了 indexer_kv_dtype: mxfp4、indexer_sparse_logits: true。
确认是否处于高并发混合 prefill+decode 负载（Issue 中为 96 并发流）。
GB10/DGX Spark 用户需额外确认是否为统一内存平台，并检查内核日志是否为空、journalctl --list-boots 是否有非正常关机边界。

解决步骤

可优先尝试：将 --speculative-config 中的 "enable_adaptive_verification" 改为 false，其余参数保持不变，重启服务。
若仍希望使用自适应验证，可优先尝试将 --compilation-config 中的 cudagraph_mode 改为 FULL_DECODE_ONLY；Issue 中该组合在 c128 下稳定运行 15 分钟。
检查当前版本中 vllm/models/deepseek_v41/nvidia/flashinfer_sparse.py 的上述 builder 是否仍声明 AttentionCGSupport.ALWAYS；若使用包含修复的分支或后续版本，确认其是否实现了 Issue 提出的 UNIFORM_BATCH 与 get_varlen_cudagraph_max_query_len 返回 max_decode_query_len(vllm_config) 的改动。
GB10 用户若遇到主机静默冻结，应先确认所用分支/版本是否实现了 #59986 中的 UNIFORM_BATCH 准入逻辑，再用于含 prefill 的批次；同时准备带电源路径的看门狗，仅靠 SSH 重启无法恢复冻结主机。

验证方法

以原报告的触发条件复测：96 并发闭环多轮对话、混合 prefill+decode 负载，观察服务是否能持续运行超过原先 30–60 秒的崩溃窗口。Issue 中关闭自适应验证后稳定运行 30 分钟 c96 加 15 分钟 c128，可作为对照。若在 GB10 上验证，除引擎日志外还应监控指标是否持续更新（指标停滞比 CUDA 报错更早暴露冻结），并确认主机未掉线。