DEV Community

Cover image for Wan 2.2 A14B at 720p on a 24 GB GPU: why it runs out of memory and what to change
CloudGPU
CloudGPU

Posted on

Wan 2.2 A14B at 720p on a 24 GB GPU: why it runs out of memory and what to change

#ai #video #machinelearning #gpu

If you try Wan 2.2 T2V A14B at 1280×720 on a 24 GB card and get torch.OutOfMemoryError, you are not alone. A public bug report, reported in InvokeAI issue #9831 (2026-10-12) on an RTX 4090 24GB, lays out exactly when it fails, why, and which setting got it running. This post walks through that report and the official docs, step by step.

Everything below is quoted from the issue or from official documentation. We have not reproduced the runs ourselves.

1. The symptom and the conditions it was reported under

From InvokeAI issue #9831 (opened 2026-10-12, open, labelled bug, no comments when read on 2026-10-28):

  • Machine: Windows 10, RTX 4090 with 24 GB VRAM, manual development checkout of InvokeAI main at 8111b5067e (7.0.0-alpha.1), Python 3.12, torch 2.13.0+cu130.
  • Model: Wan 2.2 T2V A14B, GGUF Q4_K_M, both experts (High Noise and Low Noise), plus the Wan2.2-T2V-A14B-Diffusers components and the Lightning 4-step LoRAs (V1.1, high and low).
  • Job: 1280×720, 81 frames, 4 steps, guidance 1.0, default invokeai.yaml.
  • Error: torch.OutOfMemoryError in diffusers/models/transformers/transformer_wan.py:502.

The issue's results table (settings and outcome as reported; we list the memory outcome only):

enable_partial_loading device_working_mem_gb Attention Memory outcome reported in #9831
true (default) 3 (default) PyTorch SDPA OOM in the first transformer block, also at 832×480
false 3 PyTorch SDPA Completed, but VRAM full; overflowed into shared system memory
true 10 PyTorch SDPA Completed (the issue's workaround for 24 GB)
true 10 SageAttention Completed, but overflowed (about 1.2 GB more held than SDPA)
false 3 SageAttention Completed, but overflowed into shared system memory

Two details matter when you compare this with your own machine:

  • The run with partial loading off did not really "fit". The issue says the card still overflowed and Windows moved memory to shared system memory instead of raising an OOM.
  • This is a Windows machine on a 7.0.0 alpha development build. Linux, or a release build, may behave differently; the issue does not test them.

What to check

  • Your error matches: torch.OutOfMemoryError in the Wan transformer, at the first denoise block.
  • Your invokeai.yaml still has the defaults (enable_partial_loading: true, device_working_mem_gb: 3, or neither line set).
  • On Windows, watch "Shared GPU memory" in Task Manager. If it climbs during generation, you are in the spill case, not the OOM case.

2. Why 24 GB is not enough here

Two experts, one at a time. The official Wan2.2 README (read 2026-10-28) describes the A14B models as a two-expert design: "a high-noise expert for the early stages, focusing on overall layout; and a low-noise expert for the later stages, refining video details. Each expert model has about 14B parameters, resulting in a total of 27B parameters but only 14B active parameters per step". So you download and load two diffusion models, but each denoise step uses one.

The official script's own guidance. For its single-GPU 1280*720 A14B command (with --offload_model True --convert_model_dtype), the README says: "This command can run on a GPU with at least 80GB VRAM." That statement is about the Wan repo's generate.py, not about InvokeAI or GGUF weights, but it tells you 720p A14B is not a small job.

What the issue found inside InvokeAI. According to #9831:

  • Wan denoise has no working-memory estimate. _get_wan_transformer_working_mem_bytes returns None unless wan_memory_optimization is on, so the expert is loaded with the floor, device_working_mem_gb (3 GB), as its working memory.
  • At 720p with 81 frames the transformer sees 75,600 tokens, "and the activations need far more than 3 GB."
  • With partial loading on, the cache frees only 2,003 MB of the 10.8 GB UMT5 text encoder before loading the 9.2 GB expert, so the first block runs out of memory with 21.3 GiB allocated.

In short: model weights plus text encoder plus the attention activations for 75,600 tokens do not fit in 24 GB, and InvokeAI reserves only 3 GB for the activations by default.

What to check

  • The InvokeAI log around model loading: is the text encoder still partly in VRAM when the expert loads?
  • Your resolution and frame count. The 75,600-token figure is for 1280×720 with 81 frames only.

3. Local settings to change

3a. Raise the working memory

InvokeAI's Low-VRAM mode docs (read 2026-10-28): "Invoke reserves 3GB VRAM as working memory by default", and you can raise it in invokeai.yaml to prevent OOMs (the docs' example sets 4).

The issue's workaround for this exact case on 24 GB is 10:

# invokeai.yaml — workaround reported in InvokeAI issue #9831 for 24 GB
device_working_mem_gb: 10
Enter fullscreen mode Exit fullscreen mode

With that, partial loading on and SDPA, the issue reports the 720p, 81-frame job completing. Invoke needs a restart after you edit the file.

What to check

  • The OOM is gone and Task Manager's shared GPU memory stays flat during denoise.
  • If you also set max_cache_vram_gb, the docs say to keep it at or below your VRAM minus device_working_mem_gb minus reserve_vram_gb.

3b. Keep partial loading on, and turn off the Windows sysmem fallback

The docs say Low-VRAM mode is enabled by default via enable_partial_loading: true. In the issue, turning it off did not prevent the overflow: the encoder was unloaded, but the run spilled into shared memory.

The same docs ask Windows users to disable the Nvidia sysmem fallback: NVIDIA Control Panel → 3D Settings → Manage 3D Settings → "CUDA - Sysmem Fallback Policy" → "Prefer No Sysmem Fallback". With it disabled, an overflow shows up as an OOM you can act on instead of silently spilling into shared system memory.

What to check

  • enable_partial_loading is true (or absent) in invokeai.yaml.
  • On Windows, the NVIDIA Control Panel setting reads "Prefer No Sysmem Fallback".

3c. Try wan_memory_optimization (opt-in)

From the same docs page: setting wan_memory_optimization: true makes partial-load Wan transformer weights "target about 2 GiB resident and stream remaining layers from RAM". It "reduces peak VRAM during both denoise and decode, but generation can be substantially slower and requires enough system RAM for offloaded weights." The docs also note same-seed output may differ slightly from the baseline path.

The issue explains that this flag is also what turns on Wan's working-memory estimate. It does not report a run with the flag on, so we have no figures for it.

wan_memory_optimization: true
Enter fullscreen mode Exit fullscreen mode

What to check

  • Free system RAM during generation; the docs say offloaded weights need it.
  • Compare a short test clip against your baseline before committing to long runs.

3d. Lower the resolution, and treat frame count with care

The issue's only other resolution is 832×480. With default settings it also ran out of memory. With partial loading on and device_working_mem_gb: 10, it fit with both attention backends.

The issue tests 81 frames only. Fewer frames means a shorter clip, but the issue gives no figures for it, so try it on your own setup rather than relying on a number from us.

What to check

  • At 832×480, the default settings still fail in the issue. Raise device_working_mem_gb as well; do not rely on resolution alone.

3e. Quantization, and the official script's flags

The issue already used GGUF Q4_K_M weights for both experts and still ran out of memory at default settings. Lower-bit weights alone did not fix it there; working memory did.

If you use the Wan repo's own generate.py instead of InvokeAI, the README says: "If you encounter OOM (Out-of-Memory) issues, you can use the --offload_model True, --convert_model_dtype and --t5_cpu options to reduce GPU memory usage."

On attention, these are figures reported in InvokeAI issue #9831 (one RTX 4090 24GB on Windows), not measured by us and not a claim about CloudGPU cards: the issue reports SageAttention held about 1.2 GB more than SDPA at 75,600 tokens, which pushed that card over the edge at 720p. At 832×480, the issue reports both backends fit.

What to check

  • If you switched to SageAttention and shared GPU memory now climbs at 720p, switch back to SDPA and compare.
  • The Wan2.2 model weights are licensed Apache-2.0 (per the README and the model card); check the license of any community GGUF build you download separately.

4. If local settings are still not enough: run the same workflow on a card with more VRAM

If the slower settings are not an option for you, the other route is more VRAM. On CloudGPU you can rent a card with more VRAM, billed per minute, and set up the same InvokeAI workflow on it. Cards listed on /pricing when we read it on 2026-10-28 include:

Card on /pricing VRAM (as shown on /pricing)
RTX 5090 32G 32 GB
RTX 4090 48G 48 GB
A100 80G 80 GB

To be clear about what this does and does not mean:

  • We have not tested Wan 2.2 A14B, InvokeAI or this workflow on any of these cards. The only difference we can state is more VRAM than a 24 GB card.
  • VRAM need depends on model, precision and workflow. See How much VRAM do I need to run an LLM?
  • Billing is per minute, rounded up, with a 1-minute minimum, and stops when you destroy the instance (terms). Rates per card are on /pricing.

What to check

  • Before renting, compare the VRAM column above with what your settings needed locally (the InvokeAI log and Task Manager tell you where it ran out).
  • Destroy the instance when the job is done, so billing stops.

FAQ

Why does Wan 2.2 A14B run out of memory at 720p on a 24 GB GPU in InvokeAI?
According to InvokeAI issue #9831, Wan denoise has no working-memory estimate unless wan_memory_optimization is on, so InvokeAI reserves only the default 3 GB for activations. At 1280×720 with 81 frames the transformer sees 75,600 tokens, and the activations need far more than that.

What setting fixed it in the issue?
device_working_mem_gb: 10 in invokeai.yaml, with partial loading left on. The issue reports the 720p, 81-frame job then completed on an RTX 4090 24GB (Windows 10, InvokeAI 7.0.0-alpha.1).

Does turning off partial loading help?
Not in the issue. With enable_partial_loading: false the card still overflowed, and Windows moved memory to shared system memory instead of raising an OOM.

Does lowering the resolution to 832×480 avoid the OOM?
Not on its own. The issue reports an OOM at 832×480 with default settings too; with device_working_mem_gb: 10 it fit.

What does the official Wan2.2 README say about VRAM for A14B at 720p?
For its own single-GPU generate.py command at 1280*720, it says the command "can run on a GPU with at least 80GB VRAM", and suggests --offload_model True, --convert_model_dtype and --t5_cpu for OOM issues.

Sources

Top comments (0)