[Model Support] DeepSeek-V4.1 Tracking Issue

快速结论：这是 DeepSeek-V4.1（DSv4.1）模型支持的 Tracking Issue，不是单一报错。若你在 vLLM 加载 DeepSeek-V4.1-Flash 时遇到模型无法解析（如 [Model Support] DeepSeek-V4.1 Tracking Issue）、ROCm 段错误或 Engram 低并发卡顿，优先确认是否已包含 DeepseekV41ForCausalLM 的注册条目（#56214），再按 ROCm / Engram 两条分支排查。

适用环境：Issue 已确认的环境包括 H200（SM90）、SM120、GB200、GB300、MI350X、GB10（DGX Spark）以及 ROCm 路径；涉及 TP4、无 EP、mxfp4 MoE、CUDA graph、Engram + cpu_offload=true。未在 Issue 中给出 Python、CUDA、PyTorch 的具体版本号，因此这些需你自行核对，不在本指南中假定。

最快修复方案：暂无确认的一步修复方案。Issue 明确说明所有后续工作都堆叠在 #56214 之上，在该 PR 合入前，模型无法从 main 解析；可优先尝试的工作是在包含 DeepseekV41ForCausalLM registry entry、config 与 tokenizer wiring 的分支上运行，而不是直接使用 main。

注意事项：这是 Tracking Issue，不是单一 bug 修复贴。DSv4.1 是独立于 V4 的架构，有独立的 tree、tokenizer mode、parsers 和 config class，不要把 4.1 的问题归到 DSv4 标签下。Issue 中 H200 报告与 DGX Spark 报告的环境不同，不能互相直接套用结论；DGX Spark 的吞吐提升不能推断为通用提升。

问题场景

用户使用 vLLM 加载 deepseek-ai/DeepSeek-V4.1-Flash，参考 recipes 中的 models/deepseek-ai/DeepSeek-V4.1-Flash.yaml。常见触发场景包括：

在 main 分支上直接启动模型，模型无法解析，因为 DeepseekV41ForCausalLM 尚未进入 registry.py。
在 ROCm / AMD 路径上运行，遇到第 3 个 decode token 时段错误，或 TileLang mHC 融合 kernel 不可用。
启用 Engram，在低并发场景出现卡顿，表现为 Python future 提交、唤醒和上下文切换开销偏高。
误将 V4.1 问题提交到 DSv4 标签，实际应使用 DSv4.1 标签。

报错原文

[Model Support] DeepSeek-V4.1 Tracking Issue
deepseek-ai/DeepSeek-V4.1-Flash
DeepseekV41ForCausalLM
FULL_DECODE_ONLY
--no-async-scheduling
segfault on 3rd decode token
DSv4.1
DSv4

原因分析

可能原因按 Issue 内容分为以下几类：

模型注册缺失：#56214 负责为 DeepseekV41ForCausalLM 添加 registry entry、config 和 tokenizer wiring，属于 keystone 工作且处于 review 状态。在该 PR 落地前，main 上无法解析该模型。
架构识别错误：V4.1 与 V4 是不同架构，拥有独立的配置类和 tokenizer 模式。如果按 V4 的方式配置或归类，可能无法正确加载。
ROCm 路径问题：#56347 报告在 ROCm 上使用 FULL_DECODE_ONLY 时，第 3 个 decode token 出现段错误，除非添加 --no-async-scheduling。这是已记录的 bug。
Engram 低并发开销：在 GB10/DGX Spark 上，低并发卡顿来自 Python future 提交、唤醒和上下文切换，而不是 mmap gather 实现本身；该结论来自 recipe 派生的阻塞式 preadv reader，与 #56757 的 mmap/NumPy gather 路径不同。

环境排查

确认 vLLM 代码版本是否包含 #56214：检查 registry.py 中是否存在 DeepseekV41ForCausalLM 条目。
确认 Issue 标签是否为 DSv4.1，而不是 DSv4。V4.1 已从旧标签自动化中分离。
确认运行硬件：H200（SM90）、SM120、GB200、GB300、MI350X 或 GB10（DGX Spark）。
确认并行配置：H200 报告使用 TP4、无 EP、--max-model-len auto、--max-num-seqs 16、k=5；不使用 EP、DP、KV-cache dtype override 和 adaptive verification。
确认 Engram 配置：H200 报告的可用配置包含 cpu_offload=true、前缀缓存、多模态 encoder TP（--mm-encoder-tp-mode data）。
ROCm 环境：确认是否设置 --no-async-scheduling，以及是否使用 #56342 的 TileLang mHC 融合 kernel 和 recipes#952 的 CUDA graph 模式。
Issue 未给出统一的 Python、CUDA、PyTorch 版本号，请按你实际安装的 vLLM 依赖矩阵核对。

解决步骤

先确认你关心的具体症状属于哪一类：模型无法解析、ROCm 段错误、还是 Engram 低并发卡顿。不同分支的处理方式不同。
如果是模型无法解析：不要在 main 上直接跑，基于 #56214（DeepseekV41ForCausalLM registry entry、config、tokenizer wiring）进行构建或等待其合入；不要按 V4 的方式配置。
如果是 ROCm 段错误：根据 #56347，在 FULL_DECODE_ONLY 下可优先尝试添加 --no-async-scheduling 规避第 3 个 decode token 的 segfault。该方案来自 Issue 记录的 bug 规避方式。
如果是 ROCm 需要融合 kernel：参考 #56342 的 AMD 路径 TileLang mHC 融合 kernel，以及 recipes#952 中可用的 CUDA graph 模式。
如果是 Engram 低并发卡顿：注意该问题来自阻塞式 preadv reader 路径，不要直接把 DGX Spark 上的补丁复制到 #56757 的 mmap/NumPy gather 路径。Issue 中给出的方向是：对已驻留 page cache 的行用串行 preadv(..., RWF_NOWAIT)，仅残余 EAGAIN 行交给阻塞池。
如果复制 H200 recipe：注意 k=5 配合 --max-num-seqs 16，使 max_num_seqs * k（80）远低于 --max-num-batched-tokens（8192），对应 #56443 讨论的条件。
修正标签归类：如果提交新 issue，使用 DSv4.1，不要用 DSv4；自动化边界修复见 #56332。

验证方法

确认模型能够解析并加载：检查 vLLM 启动日志中 DeepseekV41ForCausalLM 是否被正确识别，模型不再因 registry 缺失而报错。对于 ROCm 段错误，确认添加 --no-async-scheduling 后 decode 不再在第 3 个 token 崩溃。对于 H200 配置，Issue 报告 48 小时 / 36,607 请求、0 错误、acceptance length 3.43 可作为参考基准。对于 DGX Spark Engram 路径，Issue 报告 24 小时 soak 约 3,921 完成请求、1.064B prompt tokens、4.378M generated tokens，且零 error/abort/preemption/rank-restart。注意这些数字来自特定配置，不能视为通用性能保证；DGX Spark 报告明确说明未匹配生产负载组合，因此不构成通用吞吐提升结论。