test_qwen27_dense_forward and test_qwen27_dense_forward_glue_fuse_off are RED on origin/main at aba8d5ffb. Both fail the same way, and the failure is a refusal that #1228 (09597106e, row MODEL-FP8-BLOCK-WEIGHT, issue #1189) added without updating the fixture that trips it.
tests/vllm/models/test_qwen27_dense_forward.cpp:280:
TEST CASE: qwen27 GDN loader retains one merged BA owner and no split copies
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
Attribution, measured rather than assumed. git log -1 -- src/vllm/model_executor/models/qwen3_5_dense_weights.cpp is 09597106e, and git show --stat 09597106e changes that file (+219) and does not touch tests/vllm/models/test_qwen27_dense_forward.cpp. So the producer moved and its consumer did not.
The shape it hides behind. doctest reports this as assertions: 563 | 563 passed | 0 failed with test cases: 9 | 8 passed | 1 failed, because a case that THROWS records no failed assertion. Reading the assertions: line alone says the binary is clean. The line that tells the truth is Status: FAILURE!, and the exit code is 1.
Which is right is a real question, not a typo. The refusal is deliberate and well argued — a weight_scale_inv with no weight_block_size genuinely has no geometry to read it with, and guessing 128x128 is what #1166 asked not to happen. So either the synthetic fixture in this test is wrong to emit weight_scale_inv without declaring weight_block_size, or the refusal is too broad for a checkpoint that is not block-wise FP8 at all. That choice belongs to the row that owns the refusal, which is why this is filed rather than fixed in passing: it needs #1189's spec and its own red-first evidence, not a fixture edit that makes the message go away.
Found by ENG-EXPERT-STREAM-DEVICE W0 while running the full ctest suite after merging origin/main into its task branch (523/525, these two the only failures). The W0 change touches neither file, and both tests fail identically before and after it.
Owner: row MODEL-FP8-BLOCK-WEIGHT, issue #1189.
test_qwen27_dense_forwardandtest_qwen27_dense_forward_glue_fuse_offare RED onorigin/mainataba8d5ffb. Both fail the same way, and the failure is a refusal that #1228 (09597106e, rowMODEL-FP8-BLOCK-WEIGHT, issue #1189) added without updating the fixture that trips it.Attribution, measured rather than assumed.
git log -1 -- src/vllm/model_executor/models/qwen3_5_dense_weights.cppis09597106e, andgit show --stat 09597106echanges that file (+219) and does not touchtests/vllm/models/test_qwen27_dense_forward.cpp. So the producer moved and its consumer did not.The shape it hides behind. doctest reports this as
assertions: 563 | 563 passed | 0 failedwithtest cases: 9 | 8 passed | 1 failed, because a case that THROWS records no failed assertion. Reading theassertions:line alone says the binary is clean. The line that tells the truth isStatus: FAILURE!, and the exit code is 1.Which is right is a real question, not a typo. The refusal is deliberate and well argued — a
weight_scale_invwith noweight_block_sizegenuinely has no geometry to read it with, and guessing 128x128 is what #1166 asked not to happen. So either the synthetic fixture in this test is wrong to emitweight_scale_invwithout declaringweight_block_size, or the refusal is too broad for a checkpoint that is not block-wise FP8 at all. That choice belongs to the row that owns the refusal, which is why this is filed rather than fixed in passing: it needs #1189's spec and its own red-first evidence, not a fixture edit that makes the message go away.Found by
ENG-EXPERT-STREAM-DEVICEW0 while running the fullctestsuite after mergingorigin/maininto its task branch (523/525, these two the only failures). The W0 change touches neither file, and both tests fail identically before and after it.Owner: row
MODEL-FP8-BLOCK-WEIGHT, issue #1189.