[Bug]: HunYuan Dense V1 fails CUDA graph capture on v0.29 — HF dynamic RoPE does a host-side sync during capture

快速结论：该报错通常出现在 vLLM 0.29 启动走 Transformers 后端的 dynamic RoPE 模型（如 HunYuan Dense V1 / HunYuan-MT2-7B）并启用 CUDA graph 捕获时；优先排查 RoPE 中的 host-side 同步，必要时先用 cudagraph_mode=NONE 绕过。

适用环境：Issue 已确认 vLLM 0.29.0（官方镜像）、2× L40S（TP=1 也能复现）、transformers 5.16、模型 hy-mt2-7b（HunYuanDenseV1ForCausalLM，rope_scaling 为 dynamic，max_position_embeddings=262144）。

最快修复方案：暂无确认的一步修复方案。Issue 中已验证的临时绕过方式是启动时加 --compilation-config '{"cudagraph_mode": "NONE"}'，可正常启动但有 decode 性能损失。

注意事项：上游 Transformers 侧修复是否覆盖 HunYuan Dense V1 尚未确定；仓库侧补丁还在验证阶段，未合入。绕过方案会关闭 CUDA graph，因此不能作为长期性能方案。

问题场景

在 vLLM 0.29.0 上用默认 CUDA graph 模式启动 HunYuan Dense V1 模型（例如 vllm serve hy-mt2-7b --tensor-parallel-size 2，默认 cudagraph_mode=FULL）时触发。vLLM 先降级为 FULL_AND_PIECEWISE（FlashAttentionBackend、UNIFORM_BATCH），随后在 CUDA graph capture 阶段崩溃，服务无法启动。该模型自 #53615 后改走 Transformers 后端。

报错原文

[Bug]: HunYuan Dense V1 fails CUDA graph capture on v0.29 — HF dynamic RoPE does a host-side sync during capture

torch.AcceleratorError: CUDA error: operation not permitted when stream is capturing
  transformers/modeling_rope_utils.py:100  `if seq_len > max_seq_len_cached:`
  called from modeling_hunyuan_v1_dense.py:436 `position_embeddings = self.rotary_emb(...)`

原因分析

最可能的原因：dynamic-rope 的 checkpoint 会经过 Transformers 的 @dynamic_rope_update 装饰器，其中 dynamic_frequency_update 执行 seq_len = torch.max(position_ids) + 1; if seq_len > max_seq_len_cached:。这个 Tensor.__bool__ 分支会强制一次 D2H 同步，而 D2H 同步在 CUDA graph capture 内是非法的，于是捕获失效（capture_end 时报 cudaErrorStreamCaptureInvalidated），启动失败。

Issue 指出，除 NONE 外的所有 cudagraph 模式都会失败；PIECEWISE 捕获在开启 torch.compile 时可过 19/19，但 FULL 阶段 / profile_cudagraph_memory 仍会执行 raw forward 并崩溃。

值得注意的是，在 vLLM 中 max_model_len <= max_position_embeddings，因此对这些 checkpoint 而言整个 dynamic update 实际是 no-op，但检查本身仍会同步。≤0.28 中 native hunyuan_v1.py 在 __init__ 里静态计算 NTK-alpha inv_freq，所以 CUDA graphs 当时可用。

环境排查

确认 vLLM 版本：0.29.0（官方镜像）。
确认 transformers 版本：5.16。
确认模型：hy-mt2-7b HunYuanDenseV1ForCausalLM，rope_scaling = {"type": "dynamic", ...}，max_position_embeddings=262144。
确认显卡与并行：2× L40S；TP=1 也能复现。
确认启动参数：默认 cudagraph_mode=FULL，以及实际落到的后端（FlashAttentionBackend、UNIFORM_BATCH）。
确认是否使用 Transformers 后端加载该模型（#53615 之后的默认路径）。

解决步骤

先复现并确认报错栈中同时出现 modeling_rope_utils.py:100 与 modeling_hunyuan_v1_dense.py:436，确认问题落在 dynamic RoPE 的 host-side 同步上。
快速绕过：启动时加 --compilation-config '{"cudagraph_mode": "NONE"}'，验证服务可正常起来；注意这只是 issue 中已验证的 workaround，会带来 decode 性能损失。
可优先尝试方向一：在 vLLM 侧 vllm/model_executor/models/transformers/base.py 中，当 max_model_len <= max_position_embeddings 时绕过 dynamic_rope_update（此时该 update 为 no-op）。
可优先尝试方向二：对 dynamic-rope 模型给出警告并强制 cudagraph_mode=NONE。
可优先尝试方向三：推动上游 transformers 让 dynamic_frequency_update 变成 capture-safe（参考 huggingface/transformers#48960，但该 PR 未覆盖 HunYuan Dense V1）。
相关改动仍在验证阶段：维护者表示会在 HunYuan-MT2-7B 上确认编译与 full CUDA-graph capture 真正启用、且输出不变后再提 PR；在合入前不要把该补丁当作已验证方案。

验证方法

若采用 cudagraph_mode=NONE 绕过，验证点是服务能正常启动并完成推理，但需确认已放弃 CUDA graph 加速。若采用仓库侧或上游修复，按 Issue 讨论中的验证口径：确认 compilation 与 full CUDA-graph capture 实际启用，并与关闭 capture 时的输出保持一致。由于修复尚未合入，以上验证步骤目前属于待确认状态。