Skip to content

fix: load Qwen2.5-VL vision tower weights under FSDP2 - Do not merge#2431

Closed
yuekaizhang wants to merge 1 commit into
mainfrom
fix_qwen_vl
Closed

fix: load Qwen2.5-VL vision tower weights under FSDP2 - Do not merge#2431
yuekaizhang wants to merge 1 commit into
mainfrom
fix_qwen_vl

Conversation

@yuekaizhang

Copy link
Copy Markdown
Contributor

The PR fixed a bug:

transformers >=5.5 nests the Qwen2.5-VL vision tower under model.visual.*, but HF checkpoints store it flat (visual.*). get_combined_key_mapping only picked up the transformers WeightRenaming for the language model (model.* -> model.language_model.*) and had no rule for visual.*, so the entire vision tower silently failed to load (set_model_state_dict strict=False) and was left randomly initialized.

Add a non-destructive ^visual\. -> model.visual. rule for the Qwen VL family (qwen2_5_vl, qwen2_vl), augmenting rather than overriding the transformers language-model renaming.

…a-init

transformers >=5.5 nests the Qwen2.5-VL vision tower under `model.visual.*`, but HF checkpoints store it flat (`visual.*`). get_combined_key_mapping only picked up the transformers WeightRenaming for the language model (`model.*` -> `model.language_model.*`) and had no rule for `visual.*`, so the entire vision tower silently failed to load (set_model_state_dict strict=False) and was left randomly initialized. Each process then got a different random vision encoder, producing a nondeterministic, degraded multimodal forward (e.g. NeMo-RL sft_avlm Qwen2.5-VL val loss jumped from ~4.0 to 5-10 and varied run-to-run).

Add a non-destructive `^visual\.` -> `model.visual.` rule for the Qwen VL family (qwen2_5_vl, qwen2_vl), augmenting rather than overriding the transformers language-model renaming.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Yuekai Zhang <zhangyuekai@foxmail.com>
@copy-pr-bot

copy-pr-bot Bot commented Jun 5, 2026

Copy link
Copy Markdown

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@HuiyingLi

Copy link
Copy Markdown
Contributor

/ok to test 20c2f3d

@HuiyingLi HuiyingLi changed the title fix: load Qwen2.5-VL vision tower weights under FSDP2 fix: [Do Not Merge] load Qwen2.5-VL vision tower weights under FSDP2 Jun 6, 2026
@sharonyu-115

sharonyu-115 commented Jun 6, 2026

Copy link
Copy Markdown
Contributor

The problem should have been addressed already by transformers 5.6: https://github.com/huggingface/transformers/blob/e933550ec03334b47d2f6f3c92125290c4cd5295/src/transformers/conversion_mapping.py#L134 (PR huggingface/transformers#45358). We ran into this problem with NeMo RL (NVIDIA-NeMo/RL#2224) because NeMo RL pins at an earlier Automodel commit which uses transformers 5.5. Applying a temporary patch in NeMo RL could be a workaround.

@sharonyu-115 sharonyu-115 changed the title fix: [Do Not Merge] load Qwen2.5-VL vision tower weights under FSDP2 fix: load Qwen2.5-VL vision tower weights under FSDP2 - Do not merge Jun 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants