You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 #1976
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
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).
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:
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.
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):
C:\SD\ = master-864 ca37fad (main install) — used for:
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.
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.
Environment
sd-master-<sha>-bin-win-vulkan-x64.zip); the master-841 reference run used a parallel install from our archived binaries (--versionverified6b3edaa)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.ggufSummary
Three video paths break differently across recent builds on a 16 GB Vulkan setup — with two distinct regression windows:
6b3edaaca37fad42d6c0a--auto-fit off)6b3edaaand 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).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):
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: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 offrestores 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:With
--auto-fit offthe 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: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
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 --versionverified before each run):C:\SD\= master-864ca37fad(main install) — used for:-M upscale);--vae-on-cpumandatory 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.C:\SD-6b3edaa\= master-8416b3edaa(parallel install, binaries restored from our archive into a separate directory, never mixed with the main install) — used for: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
44dd137, preserve explicit backend assignments during auto-fit) is the only memory/auto-fit-related commit inca37fad...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).