test_qwen27_dense_forward and test_qwen27_dense_forward_glue_fuse_off fail deterministically on origin/main. Both throw rather than assert:
test_qwen27_dense_forward.cpp:280: ERROR: test case THREW exception:
vt: qwen3_5 dense: 'layer.linear_attn.in_proj_qkv.weight_scale_inv' is present, which is the
block-wise (fine-grained) FP8 scale, but the checkpoint's quantization_config declares no
weight_block_size. The tensors and the config disagree and there is no block geometry to read
the scale with; refusing rather than guessing 128x128
at src/vllm/model_executor/models/qwen3_5_dense_weights.cpp:428
The refusal itself is correct and was landed deliberately — 09597106e feat(MODEL-FP8-BLOCK-WEIGHT): a block-wise FP8 checkpoint now LOADS, and says by name that it cannot run yet (#1189) (#1228). What is wrong is that an existing test fixture builds a checkpoint carrying weight_scale_inv without weight_block_size, so the new refusal fires on it. Either the fixture predates the invariant and must declare a block size, or the refusal is stricter than the loader's own contract.
Why this is main and not a branch
Observed while gating an unrelated PR (#1200, the Gemma-4 arm-existence guard). Both are byte-identical to main:
git diff origin/main HEAD -- tests/vllm/models/test_qwen27_dense_forward.cpp -> empty
git diff origin/main HEAD -- src/vllm/model_executor/models/qwen3_5_dense_weights.cpp -> empty
and that PR changes only fused_ops.{h,cpp}, gemma4_moe.cpp, two of its own tests and two records — nothing on the qwen3.5 dense path.
It is also not the box: it reproduces when the two tests are run alone (0% tests passed, 2 tests failed out of 2), unlike the known load-sensitive suites.
One thing worth noting about how it presents
The doctest summary reads assertions: 563 | 563 passed | 0 failed while the case threw. Reading only the assertions line would report this as green — the failure is visible only in Status: and the test-case count. That is a known reporting trap in this repo and it is worth knowing that this particular failure wears it.
What would close it
Either the fixture declares a weight_block_size consistent with the weight_scale_inv it carries, or the refusal narrows to the case it is actually aimed at. The first is likelier — the refusal's message is specific and its reasoning ("refusing rather than guessing 128x128") is sound.
Owning row: MODEL-FP8-BLOCK-WEIGHT (#1189) as the change that introduced the refusal.
test_qwen27_dense_forwardandtest_qwen27_dense_forward_glue_fuse_offfail deterministically onorigin/main. Both throw rather than assert:The refusal itself is correct and was landed deliberately —
09597106e feat(MODEL-FP8-BLOCK-WEIGHT): a block-wise FP8 checkpoint now LOADS, and says by name that it cannot run yet (#1189) (#1228). What is wrong is that an existing test fixture builds a checkpoint carryingweight_scale_invwithoutweight_block_size, so the new refusal fires on it. Either the fixture predates the invariant and must declare a block size, or the refusal is stricter than the loader's own contract.Why this is
mainand not a branchObserved while gating an unrelated PR (#1200, the Gemma-4 arm-existence guard). Both are byte-identical to
main:and that PR changes only
fused_ops.{h,cpp},gemma4_moe.cpp, two of its own tests and two records — nothing on the qwen3.5 dense path.It is also not the box: it reproduces when the two tests are run alone (
0% tests passed, 2 tests failed out of 2), unlike the known load-sensitive suites.One thing worth noting about how it presents
The doctest summary reads
assertions: 563 | 563 passed | 0 failedwhile the case threw. Reading only the assertions line would report this as green — the failure is visible only inStatus:and the test-case count. That is a known reporting trap in this repo and it is worth knowing that this particular failure wears it.What would close it
Either the fixture declares a
weight_block_sizeconsistent with theweight_scale_invit carries, or the refusal narrows to the case it is actually aimed at. The first is likelier — the refusal's message is specific and its reasoning ("refusing rather than guessing 128x128") is sound.Owning row:
MODEL-FP8-BLOCK-WEIGHT(#1189) as the change that introduced the refusal.