[Bug] MTP draft model does not inherit –hf-overrides (YaRN): length gate + dummy-0 drafts silently kill speculative acceptance beyond the d

快速结论：在 vLLM V1 引擎中，当用 --hf-overrides（dict 形式，例如 YaRN ×4）把目标模型的上下文扩展后，MTP draft 模型不会继承这次覆盖；draft 仍使用原生 max_position_embeddings（如 262,144）作为 max_model_len。一旦批次内最长序列（prompt + 已生成）加 num_spec_tokens 超过该值，长度门控就会跳过 draft proposal，并用 dummy token 0 填充，导致投机接受率几乎归零，且无任何日志。优先排查 draft 的 max_model_len 是否小于目标模型的有效 max_model_len。

适用环境：Issue 已确认环境为 vLLM 0.26.0（V1 引擎），镜像 vllm/vllm-openai:latest（commit ffb2d59b1c05），同一代码路径在 main 分支也存在；模型为 Qwen3-Next 风格混合 GDN 模型（48 层 linear-attention GDN + 16 层 full-attention + 1 层 MTP draft），fp8 权重与 fp8 KV cache；硬件为 2× NVIDIA H20 96 GB，--tensor-parallel-size 2。Issue 未提供 Python、CUDA、PyTorch 版本信息，此处不作补充。

最快修复方案：暂无确认的一步修复方案。Issue 中讨论并验证有效的做法是将 YaRN/rope 覆盖真正传递到 draft 模型（使 draft 派生的 max_model_len 变为 1,048,576，再被目标模型的 1,000,000 截断，门控不再触发）。Issue 作者实测的等价方式是把覆盖直接写入 draft 的 config.json，但这不是上游提供的开关式修复。

注意事项：该问题不会报错、不会写日志，目标输出仍然正确，唯一的信号是 spec-decode 指标（acceptance 崩塌到接近 0）。由于门控读取的是批次内最大 max_seq_len，且 dummy 用 .expand 覆盖整批 req_ids，只要有一个长会话越过边界，同批次其他短请求也会被一并拖入“死区”，直到该会话结束。dummy token 0 并非结构性零接受，random kernel 下会以目标模型对 token 0 的概率被接受，因此可能出现少量偶发接受（Issue 中 312 K 行读到 0.05%）。另外，讨论中指出启动警告的判定条件应比较 draft_model_config.max_model_len 与目标有效 max_model_len，而不是原生 max_position_embeddings；若按后者实现会误报或漏报。

问题场景

在 vLLM V1 引擎上运行 MTP 投机解码（--speculative-config '{"method":"mtp","num_speculative_tokens":2}'），同时通过 --hf-overrides 以 dict 形式传入 YaRN 扩展（如 factor=4.0，原生 262,144 → 1,000,000），并启用 --max-model-len 1000000、--kv-cache-dtype fp8、prefix caching 与 chunked prefill。当会话长度增长到 draft 的原生 max_model_len（262,144）附近时，spec-decode 接受率整体崩塌，但目标模型输出正常、无报错日志。

报错原文

[Bug] MTP draft model does not inherit --hf-overrides (YaRN): length gate + dummy-0 drafts silently kill speculative acceptance beyond the draft's max_model_len

原因分析

最可能的机制（Issue 已在 v0.26.0 源码逐行核对）：

vllm/config/speculative.py 中的 compose_draft_hf_overrides() 明确不把 dict 形式覆盖应用到 draft（注释称其为 target-specific key patches）。启动日志因此显示目标模型 Using max model len 1000000，而 MTP draft 为 Using max model len 262144。
draft 的 rope 本身不是分歧点：model_executor/model_loader/utils.py:63 的 initialize_model 只把 vllm_config 传给新式模型类，draft 的 model_config 参数被接收但未转发；qwen3_5_mtp.py:70,73 读取的是 vllm_config.model_config.hf_text_config（目标模型已覆盖的配置），_ROPE_DICT 也让 MTP 层拿到目标模型的 rope 对象。
真正分歧的是 draft 的 max_model_len：gpu_model_runner.py:665-669 以 draft_config.max_model_len 设置 effective_drafter_max_model_len；_input_fits_in_drafter（:4481-4493）判断 max_seq_len + num_spec_tokens <= effective_drafter_max_model_len。MTP 的 use_dflash() 为 false，故条件为 max_seq_len + 2 <= 262144；max_seq_len 取批次内最长总序列（prompt + 已生成，乐观计数）。
门控失败时 :4601 跳过 propose_draft_token_ids，:4647 用 torch.zeros(...).expand(len(req_ids), num_spec_tokens) 为整批请求填入 dummy token 0，下一行把 _draft_probs 置 None。
rejection_sampler.py:30 只为 -1 保留占位语义，token 0 是普通 token：greedy kernel 下仅当目标 argmax 为 0 才存活（:759），random kernel 下以目标对 0 的概率被接受（:818-831），因此接近零但非结构性零。

环境排查

确认 vLLM 版本为 0.26.0 或 main，Issue 中行号基于该版本；其他版本行号可能不同。
检查启动日志中的两行 Using max model len：目标模型应为扩展后的值（如 1000000），若 MTP draft 仍显示原生值（如 262144），即命中本问题。
确认 --hf-overrides 以 dict 形式传入，且包含 text_config.rope_parameters 等 rope 相关字段。
确认 --speculative-config 使用 "method":"mtp"，并记录 num_speculative_tokens 的值（门控条件为其加上 max_seq_len）。
确认硬件与并行配置（如 2× H20、--tensor-parallel-size 2）与复现环境一致；Issue 未提供 Python/CUDA/PyTorch 版本，无需据此排查。

解决步骤

先通过启动日志与 spec-decode 指标确认现象：draft 的 max_model_len 小于目标有效值，且长会话期间 acceptance 在 per-position 指标上接近 0.000/0.000，同时同批次短请求的接受率也被拖低。
可优先尝试：让 YaRN/rope 覆盖真正作用于 draft 模型，使 draft 的派生长度变为扩展值（Issue 中为 1,048,576，会被目标模型的 1,000,000 截断），门控不再触发。Issue 作者实测等价做法是把覆盖直接写入 draft 的 config.json，之后 2×312 K 并发从 0.05% 接受率 / 平均长度 1.00 恢复到 2.27–2.35；该做法对每个部署需要自行维护配置文件。
关注上游对 compose_draft_hf_overrides() 的修复进展（使 dict 覆盖能传递到 draft）。如果采用启动警告方案，注意判定条件应比较 draft_model_config.max_model_len 与目标有效 max_model_len，而非原生 max_position_embeddings。
在修复落地前，也可以从运行侧规避：控制会话长度不超过 draft 的 max_model_len 减 num_spec_tokens 的边界，或避免让超长会话与短请求共批次；这只缓解症状，并非根治。
若无法修改 draft 配置，可临时关闭 MTP 投机解码（去掉 --speculative-config 中的 mtp 配置）以消除“验证 dummy 仍付目标侧成本”的额外开销，但会失去投机加速。

验证方法

重启后先检查启动日志：目标与 MTP draft 的 Using max model len 应一致（或 draft 不小于目标有效值），draft 的 rope 参数应与覆盖后配置一致。在超过原 draft 边界的会话上运行并发请求，观察 spec-decode 指标：acceptance 不再整体跌至 0.000/0.000，per-position 指标恢复正常水平，平均接受长度明显大于 1；同时确认目标模型输出文本本身未发生变化。Issue 中修复后的对照数据为 2×312 K 并发接受率 2.27–2.35、平均长度从 1.00 回升。