fix(qwen3_next/qwen3_5): repair gdn import after mamba.gdn package refactor - #208
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Repairs the import of
GatedDeltaNetAttentioninqwen3_next.pyandqwen3_5.py. Both pointed at the flat modulevllm.model_executor.layers.mamba.gdn_linear_attn, which the upstream mamba-attention refactor (vllm-project#41126) moved into themamba.gdnpackage asmamba.gdn.qwen_gdn_linear_attn.QwenGatedDeltaNetAttention. The integration merge (#186) left these two files on the dead path, so Qwen3-Next and Qwen3.5 failed to import entirely.Changes:
QwenGatedDeltaNetAttentionfrommamba.gdn.qwen_gdn_linear_attnand use it forself.linear_attn(matches upstream/main's ownqwen3_next.py/qwen3_5.py).qwen3_5.pyadditionally dropped thecreate_in_proj_qkvz=...kwarg: the presentQwenGatedDeltaNetAttentionctor (identical to upstream/main) does not accept it. Upstream'sqwen3_5.pydoes not pass it either. The fork's steering wiring in this file is untouched.Why this is not duplicating an existing PR
This is an internal
feat/integrationmerge-skew repair; the corresponding files are already correct on upstream/main, so there is no upstream PR to duplicate.Tests run
tests/model_executor/test_qwen3_5_quantization.py— 2 failed → 2 passed with this change (it importsqwen3_5, so it was failing onfeat/integration; verified red without the fix, green with it).import vllm.model_executor.models.qwen3_next, qwen3_5now succeeds (previouslyModuleNotFoundError).mlp_in/mlp_outbranch (feat(capture): wire mlp_in/mlp_out hooks for transcoder training #206), the previously-skippedtest_qwen3_next_mlp_hooksruns and passes (5/5 intest_mlp_capture_hooks.py).Known limitation
Dropping
create_in_proj_qkvzmeans LoRA-on-Qwen3.5 reverts to the always-fusedin_proj_qkvzpath (same as upstream/main). Restoring the LoRA-aware split requires porting the newerQwenGatedDeltaNetAttentionthat accepts the kwarg; out of scope for this import repair.Not validated here
End-to-end GPU inference (Qwen3-Next / Qwen3.5 weights on a GPU, mamba/linear-attn forward) — needs hardware + weights, not runnable in this environment.
AI assistance was used for this change.