Quantized Wan2.2 A14B + CFG + 81 frames produces fully black videos (frame-count-dependent; bf16 unaffected)

[lBroth]

What happens

Any quantized Wan2.2 I2V-A14B conversion (4-bit, 8-bit, or mixed) generating with CFG on (guide_scale > 1) at 81 frames produces a fully black video: every frame has mean luma 0.0, flicker 0.0. Generation "succeeds" mechanically (correct duration, no error, normal wall-clock).

Repro matrix (M5 Pro 48GB, macOS 26.5.1, mlx 0.31.2, mlx-video @ 87db56a, seed 42, 832x480, I2V from a real keyframe)

weights	guide_scale	frames	steps	result
Q4 (convert.py --quantize)	3.5,3.5	81	20	BLACK
Q8 uniform	3.5,3.5	81	6	BLACK
Q8 uniform	3.5,3.5	17	20	OK (luma 76)
mixed high@4/low@8	3.5,3.5	17	6	OK (luma 75)
mixed high@4/low@8	3.5,3.5	81	20	BLACK
Q4	1 (CFG off)	81	20	OK
bf16	3.5,3.5	81	20	OK (luma 76)

The discriminating axis is frame count, not steps: 81f is black even at 6 steps, 17f is fine even at 20 steps. CFG-off is always fine. bf16 is always fine.

So the failing combination is exactly: quantized weights × CFG batch (B=2) × large seq_len (81f at 832x480 ≈ 32.8K tokens). Suspect: numeric blowup (NaN/Inf) in the quantized path when the CFG-doubled batch meets the long sequence.

Why the happy path never hit it

Lightning-LoRA workflows run guide_scale=1 (CFG off) and never touch the broken branch; short test clips don't reach the failing seq_len. The black-clip reports that DO exist elsewhere look like the same family — kijai/ComfyUI-WanVideoWrapper#1555 / kijai/ComfyUI-WanVideoWrapper#1761 (M1 Ultra, all-black 81f outputs after 39h runs, undiagnosed) and thu-ml/SageAttention#221 (FP8 Wan + int8 attention → black output, on CUDA) — suggesting a quantization × CFG × length interaction rather than anything Mac-specific.

Repro

# converted with: python -m mlx_video.models.wan_2.convert --checkpoint-dir <Wan2.2-I2V-A14B src> --quantize --bits 4
python -m mlx_video.models.wan_2.generate \
  --model-dir <Q4 dir> --image keyframe.png \
  --prompt "the camera pans right, revealing a glowing neon shop sign, cinematic night street" \
  --width 832 --height 480 --num-frames 81 --steps 20 --guide-scale 3.5,3.5 \
  --seed 42 --tiling aggressive --output-path black.mp4     # -> fully black
# same command with --num-frames 17  -> real video
# same command with --guide-scale 1  -> real video

Evidence clips (measured, seed 42)

• quantized + CFG + 81f → black (8KB mp4 — it really is all black)
• control: 81f + 6 steps CFG → black vs 17f + 20 steps CFG → alive — the frames-not-steps isolation
• control: CFG off at 81f → alive

Environment

M5 Pro MacBook 48GB, macOS 26.5.1, mlx 0.31.2, python 3.12, mlx-video main (87db56a).

Disclosure

I'm not a professional ML engineer; this investigation was done with heavy AI assistance (Claude — Fable 5). Every row of the matrix is a real measured clip on my machine and I'm happy to run any diagnostic you'd find useful. Related: #41 adds a memory_mode=relay that makes bf16 A14B fit 48GB — currently the only way to get working CFG on this model class within that budget.

[lBroth]

⚠️ Heads-up for anyone reading: the comment above from a throwaway account linking a release_fix_2.1.1.zip is the classic GitHub malware-spam pattern (fake "fix" archive posted seconds after the issue opened). Don't download it — there is no fix zip for this. Reported to GitHub.

[Blaizzy]

Thanks a lot @lBroth!

I will get to this during the week 👌🏽

[lBroth]

Gentle nudge on this, zero rush. Nothing has landed on main since the
report, so the repro stands exactly as filed. If it helps, the relay PR
(#41) sidesteps the quantized path entirely (A14B bf16 on 48GB) and
still applies cleanly to current main. Happy to re-run anything on my
side whenever you get to it.