[Bug]: Qwen3-Next NVFP4 quants silently produce garbage when linear_attn weights are missing from quantization_config.ignore

Your current environment

• vLLM: 0.20.0.dev (also reproduces on 0.16.0rc2 per sglang#20973)
• Hardware: NVIDIA DGX Spark (GB10, sm_121); reproduces on any GPU
• Model: RedHatAI/Qwen3.6-35B-A3B-NVFP4 (also Sehyo/Qwen3.5-35B-A3B-NVFP4, AxionML/Qwen3.5-35B-A3B-NVFP4, apolo13x/Qwen3.5-35B-A3B-NVFP4, mmangkad/Qwen3.6-35B-A3B-NVFP4 — every NVFP4 quant of a Qwen3-Next-family model I've tried)
• Serving: any vLLM config with --enable-prefix-caching, compressed-tensors quantization

🐛 Describe the bug

Every community NVFP4 quant of a Qwen3-Next-family model (Qwen 3.5, 3.6, and presumably 3.7 going forward) ships a quantization_config.ignore list that names the old split tensor names for the linear-attention block:

model.language_model.layers.{i}.linear_attn.in_proj_qkv
model.language_model.layers.{i}.linear_attn.in_proj_z
model.language_model.layers.{i}.linear_attn.in_proj_b
model.language_model.layers.{i}.linear_attn.in_proj_a

The actual safetensors shards, however, use the new combined names:

model.language_model.layers.{i}.linear_attn.in_proj_qkvz
model.language_model.layers.{i}.linear_attn.in_proj_ba

At load time, vLLM:

1. Sees the combined in_proj_qkvz / in_proj_ba weights in the checkpoint
2. Checks quantization_config.ignore for them — they're not there
3. Attempts to load them as NVFP4-quantized (expecting scale factors that don't exist)
4. Silently skips them (log message only: Parameter layers.X.linear_attn.in_proj_qkvz.weight not found in params_dict, skip loading)
5. Leaves those layers effectively zero-valued at inference time

Result: the model serves and produces output, but the output is degenerate — every token collapses to the same character (we observed !!!!!!!!... for every prompt with temperature=0).

This is a silent correctness failure — no exception, no WARNING about the nvfp4 path, inference continues with broken weights.

Steps to reproduce

vllm serve RedHatAI/Qwen3.6-35B-A3B-NVFP4 \
  --trust-remote-code --tensor-parallel-size 1

Then:

curl -s -X POST http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"RedHatAI/Qwen3.6-35B-A3B-NVFP4",
       "messages":[{"role":"user","content":"Hello"}],
       "max_tokens":20,"temperature":0.0}' | jq -r '.choices[0].message.content'

Expected: a coherent greeting. Actual: !!!!!!!!!!!!!!!!!!!!.

During startup, vLLM logs (paraphrased) for every hybrid-attention layer:

WARNING ... Parameter layers.N.linear_attn.in_proj_qkvz.weight not found in params_dict, skip loading
WARNING ... Parameter layers.N.linear_attn.in_proj_ba.weight not found in params_dict, skip loading

Workaround

Patch the model's config.json to add the combined-name patterns to the ignore list before serving:

import json, pathlib
cfg_path = pathlib.Path(".../snapshot/config.json")
with open(cfg_path) as f: cfg = json.load(f)
ig = cfg["quantization_config"]["ignore"]
for pat in [r"re:.*linear_attn\.in_proj_qkvz$",
            r"re:.*linear_attn\.in_proj_ba$"]:
    if pat not in ig: ig.append(pat)
with open(cfg_path, "w") as f: json.dump(cfg, f, indent=2)

This tells vLLM to load those layers as unquantized BF16 (which is what the safetensors actually contain), and the model serves correctly.

Suggested fix

Two non-mutually-exclusive options:

1. Loudly warn and refuse to serve when the weight loader skips named parameters for a hybrid-attention layer in a compressed-tensors NVFP4 path. Silent skip loading with only an INFO/WARNING at the line level is not enough signal for a correctness failure of this magnitude — it gets lost in startup noise. Suggest raising or at least an ERROR-level message that includes "model will produce incorrect output."

2. Auto-accept combined-name aliases when the quantization_config.ignore lists the split names. Since the split→combined rename is a known Qwen3-Next migration, vLLM could treat the presence of in_proj_qkv/in_proj_z in the ignore list as equivalent to in_proj_qkvz if the actual tensor has the combined name.

Option 1 is safer and more general. Option 2 fixes the common case automatically.

Also affected

Same bug surfaced for sglang in sgl-project/sglang#20973. The root cause is the quant authors' ignore-list, but the user-facing symptom (silent garbage output) is identical across inference engines — argues for the inference-engine-side fix.

Reference

Negative-finding gist with more context and the MoE kernel tuning trap that bit me while debugging this: https://gist.github.com/cghart/5374e7f749cb02e1ea96282893de64bd