[ROCm][V4.1] Let the sparse indexer consume device query lengths

[maeehart]

Summary

The published DeepSeek-V4.1-Flash DSpark JSON sets enable_adaptive_verification:true. On ROCm that dies in maybe_create_adaptive_verification_manager during initialize_kv_cache, after the weights load:

ValueError: Adaptive verification trims verification requests on device, which the DeepseekV41IndexerBackend attention backend does not support. Pass enable_adaptive_verification=false in the speculative config, or use a backend that does.

DeepseekV41IndexerBackend hard-wires the V3.2 indexer (get_attn_backend in vllm/models/deepseek_v4_1/attention.py returns that class). supports_device_cpu_query_lens_mismatch() was True only for CUDA DeepGEMM SM100 varlen or SM90 flatten. The attention selector never runs for this model.

What this PR does

• Return True from _supports_flattened_device_query_lens() on ROCm. That is the Hopper analogue. ROCm DSpark already flattens (_supports_native_decode is only next_n in {1, 2}), and build() already diffs device query_start_loc then expands with _prepare_decode_tensors.
• Do not route ROCm through _indexer_decode_metadata_kernel from [Perf] Fuse DSV4.1 input metadata preparation with Triton #56562. That kernel is the SM100 varlen path. Hopper flatten does not use it. HIP rocm_aiter_sparse_attn_indexer already reads decode_metadata.decode_lens / seq_lens / block_table from the flatten (vllm/v1/attention/ops/rocm_aiter_mla_sparse.py).
• NVIDIA is unchanged.

The recipe workaround (AMD enable_adaptive_verification:false) is vllm-project/recipes#963. This PR is the engine-side fix so that flag can stay true.

Validation

• Reproduced the ValueError on MI355X TP4 with Hub nightly eed1f3d0c (sha256:960228cfcb5de9f4cd22d28998d1125be62b546c3d220a884f570343e99ffcee) and the published DSpark JSON. The failing helpers are in that tree.
• Did not yet serve with this patch and enable_adaptive_verification:true.

Test plan

• On gfx950, serve DeepSeek-V4.1-Flash TP4 with the recipe DSpark JSON (enable_adaptive_verification:true) and this patch
• Confirm the ValueError is gone and DSpark decode runs
• Recipe 17*19 curl returns 323
• CUDA SM90/SM100 indexer paths unchanged

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[maeehart]

This patch is not enough for enable_adaptive_verification:true on ROCm. Closing it.

maybe_create_adaptive_verification_manager has two checks. Returning True from _supports_flattened_device_query_lens() on ROCm passed the first one (supports_device_cpu_query_lens_mismatch). The second check then raised:

ValueError: Adaptive verification captures varlen decode cudagraphs, so every target attention builder must report AttentionCGSupport.ALWAYS, but DeepseekV41ROCMAiterSparseSWABackend reports AttentionCGSupport.UNIFORM_BATCH.

That is adaptive_verification.py:492. The sparse SWA backend reports UNIFORM_BATCH because that is the ROCm graph path that actually starts. Flipping the builder to ALWAYS without varlen decode graph support would be another capability lie.

The working AMD command is enable_adaptive_verification:false. Hub nightly eed1f3d0c (sha256:960228cfcb5de9f4cd22d28998d1125be62b546c3d220a884f570343e99ffcee) on MI355X TP4 started with that flag, and the recipe 17*19 curl returned 323. That workaround is vllm-project/recipes#963.