[https://nvbugs/6395830][fix] Qwen-VL mRoPE: move seq-slot delta cach…#16537
[https://nvbugs/6395830][fix] Qwen-VL mRoPE: move seq-slot delta cach…#16537nv-guomingz wants to merge 1 commit into
Conversation
…e update to model device
Text-only startup of the Qwen3.6-27B dense VL checkpoint crashes during
KV-cache capacity estimation in the shared Qwen-VL mRoPE path
(`_prepare_qwen_vl_mrope_config`):
mrope_position_deltas_cache.index_copy_(0, seq_slots, deltas)
RuntimeError: Expected all tensors to be on the same device, but got
source is on cpu, different from other tensors on cuda:0
Root cause: checkpoints carrying `language_model_only: false` with the
dense `Qwen3_5ForConditionalGeneration` arch are routed to
`QwenImageBenchModel`, whose `multimodal_data_device_paths` was missing
the `mrope_config.mrope_position_ids` / `mrope_config.mrope_position_deltas`
entries that its sibling `_Qwen3_5VLModel` lists. The engine's H2D move
(`MultimodalParams.to_device` with `target_keywords`) therefore skips the
mRoPE tensors, leaving the deltas CPU-resident when the GPU seq-slot cache
write (introduced in NVIDIA#11943) consumes them. MoE VL checkpoints
(`Qwen3_5MoeForConditionalGeneration`) never match the image-bench route
and are unaffected.
Fix both layers:
- `QwenImageBenchModel.multimodal_data_device_paths`: add the two
`mrope_config.*` entries, matching `_Qwen3_5VLModel`, so mRoPE tensors
ride the engine's pinned async H2D move like every other Qwen-VL model.
- `_prepare_qwen_vl_mrope_config`: normalize `deltas` onto the cache
device before `index_copy_` as a defensive backstop for any path that
still reaches the write branch with CPU tensors (no-op when devices
already match).
Signed-off-by: nv-guomingz <137257613+nv-guomingz@users.noreply.github.com>
|
/bot run --disable-fail-fast |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe changes track Qwen mRoPE position data for multimodal device movement and align concatenated mRoPE deltas with the seq-slot cache device before ChangesQwen mRoPE device alignment
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
PR_Github #59937 [ run ] triggered by Bot. Commit: |
|
PR_Github #59937 [ run ] completed with state
|
…e update to model device
Text-only startup of the Qwen3.6-27B dense VL checkpoint crashes during KV-cache capacity estimation in the shared Qwen-VL mRoPE path (
_prepare_qwen_vl_mrope_config):Root cause: checkpoints carrying
language_model_only: falsewith the denseQwen3_5ForConditionalGenerationarch are routed toQwenImageBenchModel, whosemultimodal_data_device_pathswas missing themrope_config.mrope_position_ids/mrope_config.mrope_position_deltasentries that its sibling_Qwen3_5VLModellists. The engine's H2D move (MultimodalParams.to_devicewithtarget_keywords) therefore skips the mRoPE tensors, leaving the deltas CPU-resident when the GPU seq-slot cache write (introduced in #11943) consumes them. MoE VL checkpoints (Qwen3_5MoeForConditionalGeneration) never match the image-bench route and are unaffected.Fix both layers:
QwenImageBenchModel.multimodal_data_device_paths: add the twomrope_config.*entries, matching_Qwen3_5VLModel, so mRoPE tensors ride the engine's pinned async H2D move like every other Qwen-VL model._prepare_qwen_vl_mrope_config: normalizedeltasonto the cache device beforeindex_copy_as a defensive backstop for any path that still reaches the write branch with CPU tensors (no-op when devices already match).Summary by CodeRabbit
Description
Test Coverage
PR Checklist
Please review the following before submitting your PR:
PR description clearly explains what and why. If using CodeRabbit's summary, please make sure it makes sense.
PR Follows TRT-LLM CODING GUIDELINES to the best of your knowledge.
Test cases are provided for new code paths (see test instructions)
If PR introduces API changes, an appropriate PR label is added - either
api-compatibleorapi-breaking. Forapi-breaking, includeBREAKINGin the PR title.Any new dependencies have been scanned for license and vulnerabilities
CODEOWNERS updated if ownership changes
Documentation updated as needed
Update tava architecture diagram if there is a significant design change in PR.
The reviewers assigned automatically/manually are appropriate for the PR.
Please check this after reviewing the above items as appropriate for this PR.
GitHub Bot Help
To see a list of available CI bot commands, please comment
/bot help.