{"slug": "wan-2-2-a14b-at-720p-on-a-24-gb-gpu-why-it-runs-out-of-memory-and-what-to-change", "title": "Wan 2.2 A14B at 720p on a 24 GB GPU: why it runs out of memory and what to change", "summary": "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.", "body_md": "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.\n\nEverything below is quoted from the issue or from official documentation. We have not reproduced the runs ourselves.\n\nFrom [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):\n\n`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`.\nThe issue's results table (settings and outcome as reported; we list the memory outcome only):\n\n| `enable_partial_loading` | `device_working_mem_gb` | Attention | Memory outcome reported in #9831 | \n|---|---|---|---|\n| true (default) | 3 (default) | PyTorch SDPA | OOM in the first transformer block, also at 832×480 | \n| false | 3 | PyTorch SDPA | Completed, but VRAM full; overflowed into shared system memory | \n| true | 10 | PyTorch SDPA | Completed (the issue's workaround for 24 GB) | \n| true | 10 | SageAttention | Completed, but overflowed (about 1.2 GB more held than SDPA) | \n| false | 3 | SageAttention | Completed, but overflowed into shared system memory | \n\nTwo details matter when you compare this with your own machine:\n\n**What to check**\n\n`enable_partial_loading: true`, `device_working_mem_gb: 3`, or neither line set).\n**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.\n\n**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.\n\n**What the issue found inside InvokeAI.** According to #9831:\n\n`_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.\nIn 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.\n\nInvokeAI'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).\n\nThe issue's workaround for this exact case on 24 GB is 10:\n\n```\n# invokeai.yaml — workaround reported in InvokeAI issue #9831 for 24 GB\ndevice_working_mem_gb: 10\n```\n\nWith that, partial loading on and SDPA, the issue reports the 720p, 81-frame job completing. Invoke needs a restart after you edit the file.\n\n`max_cache_vram_gb`, the docs say to keep it at or below your VRAM minus `reserve_vram_gb`.\nThe 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.\n\nThe 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.\n\n`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.\n\nThe 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.\n\n```\nwan_memory_optimization: true\n```\n\nThe 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.\n\nThe 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.\n\nThe 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.\n\nIf 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.\"\n\nOn 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.\n\nIf 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:\n\n| Card on /pricing | VRAM (as shown on /pricing) | \n|---|---|\n| RTX 5090 32G | 32 GB | \n| RTX 4090 48G | 48 GB | \n| A100 80G | 80 GB | \n\nTo be clear about what this does and does not mean:\n\n**Why does Wan 2.2 A14B run out of memory at 720p on a 24 GB GPU in InvokeAI?**\n\nAccording 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.\n\n**What setting fixed it in the issue?**\n\n`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).\n\n**Does turning off partial loading help?**\n\nNot 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.\n\n**Does lowering the resolution to 832×480 avoid the OOM?**\n\nNot on its own. The issue reports an OOM at 832×480 with default settings too; with `device_working_mem_gb: 10` it fit.\n\n**What does the official Wan2.2 README say about VRAM for A14B at 720p?**\n\nFor 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.", "url": "https://wpnews.pro/news/wan-2-2-a14b-at-720p-on-a-24-gb-gpu-why-it-runs-out-of-memory-and-what-to-change", "canonical_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_at": "2026-10-29 02:37:10+00:00", "updated_at": "2026-10-29 02:41:12.600416+00:00", "lang": "en", "topics": ["generative-ai", "ai-tools", "ai-infrastructure", "ai-products"], "entities": ["InvokeAI", "Wan 2.2", "Wan-Video", "NVIDIA", "RTX 4090", "PyTorch", "SageAttention", "Diffusers"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/wan-2-2-a14b-at-720p-on-a-24-gb-gpu-why-it-runs-out-of-memory-and-what-to-change", "markdown": "https://wpnews.pro/news/wan-2-2-a14b-at-720p-on-a-24-gb-gpu-why-it-runs-out-of-memory-and-what-to-change.md", "text": "https://wpnews.pro/news/wan-2-2-a14b-at-720p-on-a-24-gb-gpu-why-it-runs-out-of-memory-and-what-to-change.txt", "jsonld": "https://wpnews.pro/news/wan-2-2-a14b-at-720p-on-a-24-gb-gpu-why-it-runs-out-of-memory-and-what-to-change.jsonld"}}