feat(MODEL-MM-QWEN4-EXP): W1 — resolve and validate the qwen4_exp config, register the arch, and refuse by name

[localai-bot]

Qwen/Qwen3.8-Flash-Next declares Qwen4ExpForConditionalGeneration /
model_type: qwen4_exp, an architecture vLLM implements at no revision. This makes
it RESOLVE, and makes its config parse and VALIDATE. It does not make it load and it
does not make it forward: both refuse by name, and so does the KV-cache spec.

This body was rewritten after a fresh review failed the change and a different
implementer repaired it. The original body argued for a defect. It said
partial_rotary_factor had to be read locally with "upstream's inherited default of
0.25", because Qwen4ExpTextConfig subclasses Qwen3_5MoeTextConfig, and that using
the shared reader's value "would make us REFUSE a config upstream ACCEPTS". Every
clause was false at the lane pin. The generated class is
class Qwen4ExpTextConfig(PreTrainedConfig) — no Qwen3.5 base;
partial_rotary_factor occurs exactly twice in the file, both inside the guard, read
from rope_parameters with default 1.0; and 0.25 does not appear at all. The
error came from reading the modular file and assuming its inheritance survives into
the executed, flattened class. It does not.

The consequence was the opposite of what the original body claimed: the local read
produced false ACCEPTs, not a false refusal. A config with no partial_rotary_factor,
or with it only inside rope_parameters at 1.0, is refused upstream at
rotary_dim = 256 > indexer_head_dim = 128; we accepted it and handed W4 a 64-of-256
rotary slice, on a row that has no reachable token gate to catch it. The repair uses
config.rotary_dim from the shared reader, and the "REGRESSION GUARD" case that
pinned the wrong answer was deleted and inverted.

The config layer is the last place any of this is checkable, so the acceptance
criterion is a refusal-set diff rather than a fixture round-trip. ## The refusal boundary in the spec now maps each of the 15 upstream validate_architecture
rejections to the local line implementing it, with two-direction probe evidence: 39
configs written once and fed to both a running transformers 5.16.0 and to our
production hook from the same bytes. The four divergences that remain are ours refusing
what upstream accepts, each tabulated, plus one recorded false ACCEPT reachable only
through a rope_parameters.rope_dim key that no transformers path writes or reads.

The review found more than F1, and the pattern is worth stating: the tests named
guarantees they did not measure. Gutting the production parse_config hook to
(void)config; left all 151 assertions green, because the test called the hook and
then returned the direct call. Deleting the forward's refusal, or the entire GGUF
arm, left the gate green. Thirteen of twenty-two refusals could be deleted at once
with nothing red. All of that is now load-bearing: 12 cases, 41 subcases, 294
assertions, and 13 mutations that were green and are red.

Four upstream refusals were missing and are added: eos_token_id required when PLE is
enabled — which the published GGUF stores as a first-class key at 248044, and which
feeds the n-gram segment boundary; output_gate_type falling back to hidden_act;
ple_embed_dim <= 0, absent so -2560 % 16 == 0 was accepted; and the four PLE
fields that defaulted to 0 rather than upstream's 3 / 8 / 20000000 / 128, which made
us refuse a config upstream accepts and would have sized a hashed table from zero.
block_topk() and head_dim_per_ngram() divided by zero on a legally-parsed config
with QSA or PLE absent; both now refuse by name, so W2 and W4 get a message instead of
SIGFPE.

Two design points the review examined and cleared. Qwen4ExpLayerKind has no
kFullAttention enumerator at all, so the checkpoint's spelling for the twelve layers
that actually run the QSA indexer is unrepresentable rather than merely unused; the
test asserts the stronger property that the rewritten published list and the list
synthesized from full_attention_interval are equal, so if either path is wrong the
other says so. And the forward refuses before opening the type-erased handle: while
load_weights refuses unconditionally nothing can produce a loaded Qwen4-Exp, so a
downcast placed first would turn every reach into a type-mismatch report and leave the
advertised refusal dead. The test pins both directions.

ple_layer_ids is stored already converted to 0-based. It is one-indexed in the
checkpoint and upstream says so in terms, its validator resolves layer_types[id - 1],
and every PLE tensor in the released weights sits under ...layers.1.ple. — as does
qwen4exp.ple.layers = [1] in the published GGUF, which is a third independent
confirmation.

Nothing here is reachable. No forward, no loader, no token and no speed number, and
the speed axis does not open until G4. Row MODEL-MM-QWEN4-EXP owns the wiring and
#1978 tracks it.

Tracked by #1981, under #1978.

Gates: test_qwen4_exp_scaffold 12 cases / 294 assertions; test_model_registry
24/958; test_model_loader_gguf 6/18; check-supported-models ok at 42
architectures; check-runner-routing-consistency classifies qwen4_exp REFUSE;
check-windows-portability ok. agent-preflight.sh reports one FAIL,
test_cpu_x86_llamacpp_floor, at load average 90 with concurrent builds on the box —
the known #618 load flake, which touches no path this change reaches.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: Claude:claude-opus-5 [Claude Code]