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

A public bug report in InvokeAI issue #9831 documents that Wan 2.2 T2V A14B at 1280×720 exhausts memory on a 24 GB RTX 4090 because InvokeAI reserves only 3 GB of working memory for attention activations by default, causing a torch.OutOfMemoryError in the first transformer block. The reporter found that raising device_working_mem_gb to 10 in invokeai.yaml, with partial loading enabled and PyTorch SDPA attention, let the 720p, 81-frame job complete. The issue notes the A14B model loads two 14B experts totaling 27B parameters, and Wan's official README states its own 720p single-GPU command needs at least 80 GB of VRAM.

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. From InvokeAI issue 9831 https://github.com/invoke-ai/InvokeAI/issues/9831 opened 2026-10-12, open, labelled bug, no comments when read on 2026-10-28 : main at 8111b5067e 7.0.0-alpha.1 , Python 3.12, torch 2.13.0+cu130. Wan2.2-T2V-A14B-Diffusers components and the Lightning 4-step LoRAs V1.1, high and low . invokeai.yaml . 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: What to check enable partial loading: true , device working mem gb: 3 , or neither line set . Two experts, one at a time. The official Wan2.2 README https://github.com/Wan-Video/Wan2.2 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: 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. 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. InvokeAI's Low-VRAM mode docs https://invoke.ai/configuration/low-vram-mode/ 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 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. max cache vram gb , the docs say to keep it at or below your VRAM minus reserve vram gb . 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. enable partial loading is true or absent 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 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. 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. 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 https://cloudgpu.app/pricing?utm source=devto&utm medium=article&utm campaign=202611 seg01 comfyui&utm content=wan22 oom 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: 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.