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

> Source: <https://dev.to/cloudgpu_app/wan-22-a14b-at-720p-on-a-24-gb-gpu-why-it-runs-out-of-memory-and-what-to-change-8nc>
> Published: 2026-10-29 02:37:10+00:00

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.