vllm - ✅(Solved) Fix [Bug]: Qwen3_next a/b are not contiguous [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
vllm-project/vllm#41112Fetched 2026-04-29 06:12:18
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
Participants
Timeline (top)
cross-referenced ×1labeled ×1

Fix Action

Fixed

PR fix notes

PR #41142: [Bugfix][Qwen3-Next] Force a/b contiguity in fix_query_key_value_ordering

Description (problem / solution / changelog)

Summary

Fixes #41112.

In GatedDeltaNetAttention.fix_query_key_value_ordering, the final reshape of b and a:

b = b.reshape(b.size(0), self.num_v_heads // self.tp_size)
a = a.reshape(a.size(0), self.num_v_heads // self.tp_size)

returns a non-contiguous view when num_v_heads == num_k_heads (i.e. np/ng == 1): the size-1 inner dim from the prior torch.split is squeezed without copying, leaving strides like (2K, 2) on the [B, num_v_heads] output.

This breaks fused_post_conv_prep (introduced in #37813), whose Triton kernel indexes a/b as

a_offsets = offs_t * stride_a_tok + i_hv
b_offsets = offs_t * stride_b_tok + i_hv

— it implicitly assumes the head dim has stride 1, so on a non-contiguous input it reads the wrong memory and the assertion downstream fires.

Fix

Call .contiguous() on b and a after the final reshape. This matches the non-interleaved (Qwen3.5) and LoRA paths in the same file which already do b = b.contiguous(); a = a.contiguous() after ba.chunk(...).

For typical Qwen3-Next configs (np/ng > 1, e.g. 32 v-heads / 16 k-heads) the reshape already produces a contiguous tensor, so .contiguous() is a true no-op — no performance impact on the default path.

Test plan

I believe this change is correct based on code review of:

  • the non-interleaved sibling paths in the same file that already explicitly .contiguous() after the analogous split,
  • the fused_post_conv_prep kernel's stride assumption.

I do not currently have a GPU available to run the upstream tests/kernels/test_fused_gdn_post_conv.py or an end-to-end Qwen3-Next generate, so I'd appreciate maintainers / anyone with access running:

  • pytest tests/kernels/test_fused_gdn_post_conv.py -v
  • An end-to-end Qwen3-Next prefill smoke test exercising gqa_interleaved_layout=True (e.g. via tests/v1/e2e/test_hybrid_chunked_prefill.py -k qwen3_next)
  • Reproducer from #41112 (the case where a/b end up non-contiguous after fix_query_key_value_ordering)

Changed files

  • vllm/model_executor/layers/mamba/gdn_linear_attn.py (modified, +5/-2)
RAW_BUFFERClick to expand / collapse

Your current environment

🐛 Describe the bug

<img width="600" height="800" alt="Image" src="https://github.com/user-attachments/assets/9bb5d089-0518-40fc-9824-ed0ed086ebd8" />

after "fix_query_key_value_ordering", a and b are not contiguous, which later causes the assertion to fail

Before submitting a new issue...

  • Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.

extent analysis

TL;DR

Reorder the query key-value pairs to ensure a and b are contiguous after applying the "fix_query_key_value_ordering" fix.

Guidance

  • Verify the ordering of query key-value pairs before and after applying the "fix_query_key_value_ordering" fix to identify any changes causing a and b to become non-contiguous.
  • Check the implementation of "fix_query_key_value_ordering" to ensure it correctly maintains the contiguity of a and b.
  • Review the assertion that fails to understand the contiguity requirement and how it relates to the query key-value pairs.

Notes

The provided image is not accessible, which may contain crucial information about the issue. The guidance provided is based on the text description only.

Recommendation

Apply workaround: Reorder the query key-value pairs manually if "fix_query_key_value_ordering" does not maintain the contiguity of a and b, as this seems to be the root cause of the assertion failure.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

vllm - ✅(Solved) Fix [Bug]: Qwen3_next a/b are not contiguous [1 pull requests, 1 participants]