Skip to content

test_qwen27_dense_forward{,_glue_fuse_off} are RED on main: #1228's block-FP8 refusal fires on a fixture it did not update #1240

Description

@localai-bot

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions