fix(wan): pair Wan 2.2 A14B GGUF experts by wiring, not just filename

[Pfannkuchensack]

Summary

fix — Wan 2.2 A14B GGUF expert pairs failed to load whenever the expert
couldn't be read from the filename:

ValueError: A Wan A14B GGUF expert pair must contain one high and one low expert.

...even with a correct high GGUF and low GGUF wired to the two transformer
slots.

Why: the expert field on Main_GGUF_Wan_Config is a filename heuristic,
but the loader treated it as authoritative and hard-required {"high", "low"}.
The heuristic only recognised the canonical high_noise / low_noise form
(plus hyphenated/concatenated variants). Community finetunes frequently tag the
expert with a bare marker instead — e.g. DasiwaWAN22I2V14BTastysinV8_q5High.gguf
— so both files probed to expert='none' and every such pair was rejected.

How:

1. _detect_wan_gguf_expert() now also accepts a bare high / low marker.
   It's matched as a whole word on separator or camelCase boundaries
   ([A-Z]+(?![a-z])|[A-Z][a-z]*|[a-z]+|\d+), so _q5High resolves while
   Flowstate, slowmotion and highres don't produce false positives. A
   name carrying both markers stays ambiguous ('none').

2. WanModelLoaderInvocation treats the wiring as the stronger signal, since
   the tag is only ever a guess. New pairing rules:

   main slot	low-noise slot	result
   tagged, complementary	tagged, complementary	as before, incl. auto-swap if reversed
   tagged	untagged	untagged file inferred as the complement
   untagged	tagged	untagged file inferred as the complement
   untagged	untagged	wiring is taken as-is (main = high), logs a warning
   same expert	same expert	error, now naming which expert both claim

Fix 2 means installs already recorded with expert='none' work without a
re-probe. Fix 1 means a fresh install of such a file gets tagged correctly.

Out of scope, noted for a follow-up: the Wan LoRA probe in
configs/lora.py duplicates the old heuristic, so a bare-marker LoRA still
falls back to expert-agnostic (applied to both experts). That's a silent
quality issue rather than a crash, and LoRA filenames carry a higher
false-positive risk, so it's left alone here.

Related Issues / Discussions

QA Instructions

Requires a Wan 2.2 A14B GGUF expert pair whose filenames tag the expert with a
bare marker rather than high_noise / low_noise.

1. Install both GGUFs. In the model manager they probe as
   base=wan, type=main, format=gguf_quantized, variant=*_a14b.
2. Build a Wan 2.2 graph: high GGUF → Transformer, low GGUF →
   Transformer (Low Noise), plus a standalone Wan VAE and UMT5-XXL encoder.
3. Invoke. Before this PR it fails at wan_model_loader with the error above;
   now it runs.
4. Freshly re-scanning/re-installing the two files tags them high / low, and
   the "neither GGUF filename identifies its expert" warning disappears.
5. Negative check: wiring two GGUFs that both probe as the same expert still
   errors, now stating which one.

Automated:

uv run --extra cuda --extra test pytest \
  tests/app/invocations/test_wan_model_loader.py \
  tests/backend/model_manager/configs/test_wan_gguf_config.py --no-cov

79 passed. Added coverage for the bare-marker filenames, the false-positive
candidates (slowmotion / Flowstate / highres), the both-markers case, and
all five untagged wiring combinations. The previously-expected
(high, none) -> reject case is now (low, low) -> reject, matching the new
conflict-only rule.

Merge Plan

Nothing special — backend only, no DB schema or redux changes. Existing model
records keep working unchanged.

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• ❗Changes to a redux slice have a corresponding migration — n/a
• Documentation added / updated (if applicable) — n/a
• Updated What's New copy (if doing a release after this PR)

[lstein]

Adversarial review at 0d51582277, plus an independent fresh-context pass that was told to assume the change is broken. Everything below is verified against the code — regex results reproduced by execution, loader combinations traced through invoke(). 79 passed reproduces locally.

Verdict: the pairing truth table is correct in isolation — all 9 (main, low) tag combinations resolve to a defensible assignment, and the and → or swap condition is right. The defects are all at the seams with code the PR didn't touch, and two of them are user-visible regressions.

Blockers

1. False-positive low tags silently remove a model from the main model picker

configs/main.py:1855-1886 → services/api/types.ts:644 / MainModelPicker.tsx:26-38

The frontend filters every Wan GGUF main with expert === 'low' out of the main model dropdown, and lists only those in the low-noise picker — with no variant gate. Verified flips introduced by the new bare-word branch (old → new):

stem	old	new
Wan2.2_TI2V_5B_LowVRAM_Q4	none	low
wan22_ti2v_5b_low_denoise_q4	none	low
Wan2.2-A14B-LOWRes-Q4	none	low
Wan2.2-I2V-A14B-Low-Light-v3-q5	none	low
Wan2.2-A14B-Low-Step-Lightning-Q4	none	low

The TI2V-5B rows are the bad ones: a single-expert model becomes selectable only in the "Transformer (Low Noise)" slot, where wan_model_loader.py:151-154 explicitly ignores it. The model installs, probes fine, and is unreachable from the linear UI — with no error anywhere.

There is no user-facing correction path either: expert is absent from ModelRecordChanges (model_records_base.py:87-153), so it can't be set at install time (_probe passes config.model_dump(), model_install_default.py:1151-1154; pydantic drops extras) and can't be PATCHed afterwards, and /scan_folder only reports is_installed — there's no re-probe. The only remedy is renaming the file on disk and delete + reinstall, which mints a new model key and breaks saved workflows and metadata that reference the old one.

Cheap fix: variant is already computed at main.py:1932, two lines above the expert probe. Skipping the heuristic (or at least the bare-word branch) for TI2V_5B eliminates the entire single-expert false-positive class for free.

2. A single tag silently inverts the explicit wiring

wan_model_loader.py:192

(low, none) and (none, high) both swap with zero warning, while (none, none) — where the loader is less certain — gets one. Trigger: main slot = Wan2.2-I2V-A14B-Low-Light-v3-q5-part1.gguf (really the high expert, falsely tagged low per finding 1), low slot = its untagged partner. The two experts are inverted, the run completes, and the output is silently wrong. The old code raised a clear error here.

The commit message says "which slot the user picked is a stronger signal than the filename", but for the mixed cases the code lets the tag win. That was defensible when the old and required both tags to agree before swapping; it is weaker now that a single bare word can set the tag. Minimum ask: log a warning naming which file was moved, so a bad tag is diagnosable from the log.

Should fix

3. The unpaired branch still treats the tag as authoritative. wan_model_loader.py:200-201 hard-rejects expert != "high", so Finetune_q5.gguf on its own is a fatal error while the paired path now infers it — the PR's own premise ("'none' is common on community finetunes") applies identically here. It also contradicts readiness.ts:403-415, which promises the unpaired case runs high-only: readiness passes, the user hits Invoke, and the graph dies at the loader. Pinned in place by the ["low", "none"] parametrize at test_wan_model_loader.py:161.

4. The relaxation is mostly unreachable from the linear UI. The low-noise picker lists only expert === 'low' (types.ts:644, modelsByType.ts:129), so 4 of the 5 newly-supported combinations — including the motivating (none, none) — can only be produced from the workflow editor. Combined with finding 3, a pre-PR install of the exact pair described in the PR body still fails end-to-end in the linear UI: the partner can't be selected, and unpaired hard-errors. So "Fix 2 means installs already recorded with expert='none' work without a re-probe" holds only for node-editor/API users; for everyone else it's the heuristic half of the PR plus a delete + reinstall that delivers the fix.

5. The same model wired to both slots is now silently accepted (it used to fail {none, none} != {high, low}). _ExpertSwapper.get() (wan_denoise.py:194-240) keys on the label, not on model identity, so every boundary crossing does full_unload_from_vram() + empty_cache() + a full reload of the same ~9 GB model — and the "only the high-noise expert will run" warning never fires. A key comparison in the loader guards it in one line.

Minor

• The docstring's false-positive guarantee holds only for the lowercase spelling: Wan2.2-A14B-HighRes-Fix-Q4 → high, Wan2_2_A14B_HIGHQuality_Q4 → high, Wan2.2-A14B-LOWRes-Q4 → low ([A-Z]+(?![a-z]) backtracks, splitting LOWRes into LOW/Res). The tests assert only the lowercase forms.
• configs/lora.py:1144-1146 says it "mirrors the GGUF transformer probe's heuristic" — no longer true. Deferring the LoRA fix is fine and clearly stated in the PR body, but the comment should say so; the lightx2v ..._HIGH_fp16 Lightning LoRAs are exactly the case wan_denoise.py:583-589 warns about.
• Undocumented behaviour change: a name carrying both canonical markers flips high → none (Wan2.2-A14B-HighNoise-LowNoise-merged). Only affects newly probed models, so stored records are safe, but the commit message presents this as preserved behaviour rather than a change.
• Pre-existing, not introduced here: InitialStateMainModelPicker.tsx:19 uses unfiltered useMainModels(), so a low-tagged GGUF is still offered as a main model there. Broader tagging widens the exposure.

Tests

79 passed reproduced. The 5 new loader rows are load-bearing (all raise under the old code), and ("low", "none") specifically pins the and → or change. 4 of the 9 new heuristic rows pass under the old implementation too — fine as regression guards, but they only guard the all-lowercase spelling, so the actual new false-positive class (CamelCase / hyphenated Low-*, LOW*) is untested. No coverage was deleted. Untested new behaviour: the (none, none) warning, the absence of a warning on the two inversion paths, and same-model-both-slots.

Attacks that found nothing

Truth-table correctness given accurate tags (all 9 combinations right; the chained ==/!= is correct Python and doesn't misfire on ("none", "none")); lowercase substring false positives (slowmotion, flowstate, lowvram, lowrank, lowmem, highres, glow, yellow, below, allow — all none); all 10 Wan GGUF starter models and every Wan filename in tests/ resolve identically old vs new; validation ordering in the pair branch (base/type, format and variant checks all precede the expert logic); metadata-recall paths; regex backtracking (linear, no ReDoS); and a false tag on a TI2V-5B is inert on the backend (main_variant isn't in the A14B tuple at line 200) — the damage there is frontend-only, which is finding 1.

[lstein]

Follow-up to my review above, with a scoping suggestion now that I've checked this against #9503.

The core idea here is right, and it's better than what I did in #9503.

#9503 treats the expert tag as authoritative: it requires a {high, low} pair and treats 'none' as fatal. That makes the filename heuristic safety-critical, which is exactly the wrong place to put weight — the tag can't be set or corrected through any API, so a bad guess is only fixable by renaming the file and re-importing. My own PR body admits this and says "the durable fix is to make it non-load-bearing."

That's what this PR does. Wiring is explicit user intent; the tag should be advisory. I'd like to build on it rather than around it.

The problem is that we're both rewriting the same two hunks. All four files here are also touched by #9503, and git merge-tree gives content conflicts in both of the ones that matter — wan_model_loader.py and configs/main.py.

Suggestion: drop the heuristic change from this PR and keep only the pairing semantics.

Two reasons.

It removes the configs/main.py conflict entirely. #9503 replaces _detect_wan_gguf_expert wholesale with a shared _detect_wan_expert used by the checkpoint probe, the GGUF probe, and the Wan LoRA probe. If this PR doesn't touch that function, the two stop overlapping there and only one small hunk in wan_model_loader.py needs merging.

The replacement scores better on the cases you're targeting. I ran both functions over a shared set. Five divergences, and they all go the same way:

filename	this PR	#9503	correct
Torstens_Wan2.2-14B_i2v_Low-VRAM_WF_V2 (real)	low	none	none
Wan2.2-A14B-LOWRes-Q4	low	none	none
wan2.2_a14b_4step_low_cfg_merge	low	none	none
Wan2.2_TI2V_5B_LowVRAM_Q4	low	none	none
Extream Low Angle HIGH - Wan2.2	none	high	high

The first four are the blocker-1 false positives from my review — the difference is a short disqualifier list (vram, cfg, res, steps, angle, …) that only counts when it follows the marker, plus a structural pin that forces expert='none' for TI2V-5B since it's single-transformer. Your camelCase word-splitting idea is good and #9503 does the same thing; it just also needs those two guards.

Your bare-marker cases all still pass under the replacement, including DasiwaWAN22I2V14BTastysinV8_q5High and the slowmotion / Flowstate / highres substring traps.

For the record, one case neither of us gets right — Mabrle_wan2.2_low_high_noise and ..._t2v_low_high_noise_14B are real HF repos serving both experts in one file, and both implementations return 'high' instead of 'none'. I'll fix that in #9503.

One thing to fix even after narrowing. The unpaired branch still hard-rejects an untagged main:

if main_variant in (T2V_A14B, I2V_A14B) and primary_expert != "high":
    raise ValueError("An unpaired Wan A14B GGUF model must be the high-noise expert.")

That's inconsistent with the new rule in the paired path. The same untagged file is now welcome when a second slot is filled and rejected when it isn't. Since "wiring is intent" applies just as well to a single wired transformer, I think this should degrade to the existing "only the high-noise expert will run" warning rather than raising. That would also fix a readiness/backend disagreement on my side: readiness.ts tells the user the low-noise partner is optional, which is only true today when expert == 'high'.

Blockers 2 and 5 from my review (the silent wiring inversion off one tag, and the same model in both slots) still stand as written.

Sequencing. If you narrow this, I'm happy for it to land first — it's small and nearly done — and I'll rebase #9503 on top and extend wiring-first to the checkpoint path. No need for you to wait on me.

[lstein]

All good.