Video regressions on 16 GB Vulkan: LTX-2.5 + MiniMax-H3 broken since master-864, Wan 2.2 broken by master-866 (graph segmentation / weight-budget behavior) — --auto-fit off only rescues Wan

[laurentvv]

TL;DR: Two distinct video regressions on 16 GB Vulkan, both with deterministic A/B repro (same command/seed, control run on old build passes):

1. LTX-2.5 + MiniMax-H3 break in the 841→864 window (memory-manager rework refactor: unify runner lifecycles and weight residency #1940/refactor: unify model source and weight lifecycle management #1956/refactor: split generation pipeline out of stable-diffusion.cpp #1957): graph now cut into 50+ segments, dies with vk::Queue::submit: ErrorOutOfDeviceMemory despite ~15 GB free VRAM — master-841 control passes with 2 segments.
2. Wan 2.2 T2V breaks in 864→866 (suspect feat: preserve explicit backend assignments during auto-fit #1967): DiT graph switches 1 segment → 42 segments, dies at step 5/8; --auto-fit off rescues it.

Image paths (Flux/SDXL/upscale) unaffected. We're pinning master-864 plus a parallel master-841 install meanwhile. Happy to bisect the 841→864 window or run any experiment.

---

Environment

• GPU: AMD Radeon RX 6950 XT 16 GB (RDNA2, Vulkan, proprietary driver, no matrix cores)
• OS: Windows x64
• Binaries: official release assets (sd-master-<sha>-bin-win-vulkan-x64.zip); the master-841 reference run used a parallel install from our archived binaries (--version verified 6b3edaa)
• Machine state for all runs: freshly booted or verified idle, 1.1–1.3/16 GB VRAM in use
• Models: Wan2.2-T2V-A14B-LowNoise-Q4_K_M.gguf + umt5-xxl-encoder-Q4_K_M.gguf + wan_2.1_vae.safetensors, LTX-2.5-Distilled-Q4_K_M.gguf, minimax_h3_ref2va_pruned-Q4_K_M.gguf

Summary

Three video paths break differently across recent builds on a 16 GB Vulkan setup — with two distinct regression windows:

	master-841 6b3edaa	master-864 ca37fad	master-866 42d6c0a
Wan 2.2 T2V 14B	❌ (#1946, fixed later)	✅	❌ (works with --auto-fit off)
LTX-2.5 (distilled, T2V & I2V)	✅	❌	❌ (identical failure)
MiniMax-H3 Ref2VA (turbo LoRA)	✅	❌	❌ (identical failure)
Flux / SDXL / ESRGAN upscale	✅/✅/✅	✅/✅/✅	✅/✅/✅

• LTX-2.5 and MiniMax-H3 broke in the 841→864 window (the memory-manager rework), not in 864→866. We had initially mislabeled master-864 as the last good build for these two — in fact all our LTX/H3 validations had been done on 6b3edaa and these paths were simply never re-tested after upgrading; the failures below are deterministic (identical computed refusals across builds and days, on freshly booted machines).
• Wan 2.2 broke in the 864→866 window (suspect: feat: preserve explicit backend assignments during auto-fit #1967), where the DiT graph switches from fully resident (1 segment) to a 42-segment cut that fails mid-sampling.

1. Wan 2.2 T2V A14B — fails at step 5/8 on master-866, works on master-864

Command (identical on both versions, seed fixed):

sd-cli.exe -M vid_gen \
  --diffusion-model Wan2.2-T2V-A14B-LowNoise-Q4_K_M.gguf \
  --t5xxl umt5-xxl-encoder-Q4_K_M.gguf \
  --vae wan_2.1_vae.safetensors \
  -p "a red fox walking through deep snow, winter forest, cinematic" \
  --cfg-scale 6.0 --steps 8 --sampling-method euler \
  -W 832 -H 480 --video-frames 17 --fps 24 \
  --diffusion-fa --temporal-tiling --vae-on-cpu --seed 42

master-864 (working): DiT weights resident (model manager prepared params backend buffers (9211.74 MB, 1095 tensors, 10 blocks, VRAM)); compute graph runs in 1 segment (Wan2.x-T2V-14B compute buffer size: 941.58 MB(VRAM) (peak across 1 segment)); sampling completes 8/8 (~264 s/it); VAE decode on CPU (--vae-on-cpu); webm written (2332 s total).

master-866 (failing): identical weight placement (same 9211.74 MB / 1095 tensors resident in VRAM), but the graph is now cut into 42 segments (compute buffer size: 787.47 MB(VRAM) (peak across 42 segments)), and generation dies at step 5/8 after 1390 s of sampling:

[WARN   ] model_manager.cpp:1767 - model manager cannot make enough memory available on Vulkan0: need 664.34 MB device / 1092.16 MB budget, available 631.30 MB device / 2366.17 MB budget
[ERROR  ] ggml_runner.cpp:877  - Wan2.x-T2V-14B segment 24/42 (wan.blocks.22) failed during weight preparation
[ERROR  ] diffusion_engine.cpp:2421 - diffusion model compute failed

The shape is reminiscent of #1946 (a few dozen MB short during weight preparation), but this is the new segmented path on a graph that master-864 kept fully resident.

Workaround (verified end-to-end on master-866): adding --auto-fit off restores the master-864 behavior — back to 1-segment resident compute (941.58 MB), sampling completes 8/8 (~272 s/it vs 264), webm written (2399 s total). Output is the same scene/trajectory with visible numerical divergence vs the master-864 run (middle-frame mean abs diff 14.8/255), as expected across different graph layouts.

2. LTX-2.5 — broken since master-864, with AND without --auto-fit off (no workaround found)

Recipe: explicit --backend diffusion=vulkan0,te=cpu,vae=cpu (all weights streamed from RAM: text encoder ~9.0 GB, DiT ~14.4 GB, VAE ~1.7 GB — 0 MB of weights in VRAM), 768×512, 33 frames, 8 steps with Lightricks distilled sigmas, euler_a, cfg 1.0. Last verified working on master-841; on both master-864 and master-866 it dies ~20 s in at the first workspace capacity check, with byte-identical numbers:

[WARN   ] model_manager.cpp:1767 - model manager cannot make enough memory available on Vulkan0: need 910.16 MB device / 398.16 MB budget, available 319.37 MB device / 668.90 MB budget
[ERROR  ] ggml_runner.cpp:877  - ltxav segment 1/1 (graph) failed during workspace capacity check
[ERROR  ] video.cpp:1684 - sampling failed after 21.24s

With --auto-fit off the budget becomes "unlimited" but available device stays ~317 MB → same failure at 19 s. Note the paradox: with ~15 GB of VRAM physically free and 0 MB of weights resident in VRAM, the manager still reports ~320 MB "available device".

I2V (65 frames, 832×480, init image) also fails on master-864 with vk::Queue::submit: ErrorOutOfDeviceMemory ~115 s into sampling; interestingly that run did not segment the graph at all, while the same command in 480×832 portrait did segment (50 segments) and still died at submit.

3. MiniMax-H3 Ref2VA — broken since master-864 (same signature as master-866)

Recipe: --backend diffusion=vulkan0,te=cpu,vae=cpu --offload-to-cpu --rng cpu --max-vram 10, turbo LoRA 8 steps, 22 frames, 864×480. On master-841 the graph-cut produced 2 segments and was stable. On both master-864 and master-866, after the CPU-side reference/audio conditioning completes (~15–20 min), the DiT reports 51 segments and dies at submit:

[VERBOSE] ggml_runner.cpp:857  - minimax_h3 using 51 segments
[ERROR   ] ggml_runner.cpp:651  - minimax_h3 graph execution failed on Vulkan0: vk::Queue::submit: ErrorOutOfDeviceMemory
[ERROR   ] video.cpp:1684 - sampling failed after 262.86s   (master-864)  /  358.87s  (master-866)

Control run (master-841, parallel install, same machine 24 h apart, exact same command/seed/assets): PASSES — minimax_h3 graph cut executing segment 1/2: minimax_h3.blocks.0..minimax_h3.blocks.37 + segment 2/2, 8 steps × 2 segments, webm 864×480 + PCM 32 kHz stereo written in 2279 s (historical timing). This isolates the regression to the build, not the environment.

What still works on master-866

• Flux schnell smoke (512×512, 4 steps, seed 42): clean image
• SDXL (monolithic checkpoint, 512×512, 20 steps): clean image
• ESRGAN upscale mode (4x-UltraSharp): fine

Current mitigation on our workstation (until fixes land)

Two side-by-side installs, same GPU/driver, same models directory (C:\Modeles_LLM\), only the binaries differ (sd-cli.exe --version verified before each run):

1. C:\SD\ = master-864 ca37fad (main install) — used for:
   • image paths: Flux schnell/dev, SDXL, ESRGAN upscale (-M upscale);
   • Wan 2.2 T2V and I2V (A14B LowNoise Q4_K_M): ≤ ~20 frames with --vae-on-cpu mandatory on 16 GB (resident GPU VAE decode of 17 frames requests 19.4 GB; 33 frames gets a clean 2.2 GB workspace refusal). Validated end-to-end at 17 frames.
2. C:\SD-6b3edaa\ = master-841 6b3edaa (parallel install, binaries restored from our archive into a separate directory, never mixed with the main install) — used for:
   • MiniMax-H3 Ref2VA production: re-validated 2026-09-15 with the exact turbo recipe (2-segment graph cut × 8 steps, webm 864×480 + PCM 32 kHz stereo in 2279 s);
   • LTX-2.5 production: last validated on this build (33-frame benchmark 2026-09-10, 65-frame I2V production chains 2026-09-12/13); not re-run since the A/B, same binary as the H3 control.

Coverage: every validated recipe on this workstation has a working binary again. What we lose meanwhile: the 841→864 memory-manager improvements (fix #1946 for Wan/Flux, streaming perf) on the LTX/H3 paths — which is why a fix in the 841→864 window would let us collapse back to a single install.

Suspects

• LTX-2.5 + MiniMax-H3 (window 841→864): the memory-manager rework — refactor: unify runner lifecycles and weight residency #1940 (unify runner lifecycles and weight residency) and related refactors (refactor: unify model source and weight lifecycle management #1956 model sources, refactor: split generation pipeline out of stable-diffusion.cpp #1957 generation pipeline split), possibly interacting with fix: guard GPU memory capacity and propagate encoding failures #1958 (memory capacity guards).
• Wan 2.2 T2V (window 864→866): feat: preserve explicit backend assignments during auto-fit #1967 (44dd137, preserve explicit backend assignments during auto-fit) is the only memory/auto-fit-related commit in ca37fad...42d6c0a (the others: attention regex fix: bound plain-text runs in parse_prompt_attention regex #1919, Wan2.2 S2V feat: add Wan2.2 S2V (audio+img-to-video) support #1925, video metadata feat: Add generation parameters into video metadata #1901, MSVC warnings fix: resolve MSVC narrowing conversion warnings #1969).

Happy to run any experiment that helps (bisect builds for the 841→864 window, extra logs, other flag combinations).