Wan 2.2 VRAM Guide: What Actually Works on 8GB, 12GB, 16GB, and 24GB (2026)

You checked the VRAM requirements table. Your 12 GB card fits the Q4_K_M model at 10.5 GB. You load it up, hit generate — and it crashes with a CUDA OOM error before the first frame.

What happened? The VRAM table showed the model would fit. It did not show the VAE decode spike that pushes memory 3 GB over the limit during the final step.

VRAM behavior in Wan 2.2 is not flat. It varies significantly across the four stages of generation: model loading, text encoding, denoising, and VAE decoding. Each stage has a different memory profile, and the peak — not the average — determines whether your generation succeeds or crashes.

I profiled VRAM usage across 8 GB, 12 GB, 16 GB, and 24 GB GPUs through all four generation stages with different model sizes, quants, resolutions, and frame counts. This guide covers how Wan 2.2 actually uses memory, what settings reduce pressure at each stage, and when a workflow that technically fits will still fail in practice.

To understand why VRAM numbers on paper do not match real-world behavior, you need to see what happens at each stage of generation.

How Wan 2.2 Uses VRAM Through Each Stage

Wan 2.2 generation goes through four stages, each with a distinct VRAM footprint.

Stage 1: Model Loading

The model checkpoint is loaded from disk into VRAM. This is where you pay for your quant choice. The VAE and text encoder are also loaded here.

The load-stage trap: The numbers above look safe for many cards — 13.5 GB on a 16 GB card at Q4_K_M, for example. But this is only the starting point. VRAM usage grows from here.

Stage 2: Text Encoding

The text encoder processes your prompt and generates conditioning tensors. These tensors are small — typically 200–500 MB — and do not add significant VRAM pressure.

VRAM change: +200–500 MB above load stage.

Stage 3: Denoising

The diffusion model runs for N steps (typically 20–24) against the latent tensor. The latent itself grows with resolution and frame count:

• 480p (832×480), 81 frames: ~1.5 GB for the latent
• 720p (1280×720), 81 frames: ~3.5 GB for the latent
• 720p, 41 frames: ~1.8 GB for the latent
• 720p, 121 frames: ~5.2 GB for the latent

The latent plus intermediate tensors from the denoising steps add 2–6 GB on top of the loaded model, depending on resolution and frame count.

VRAM change: +2–6 GB above load+encode stage, depending on resolution and frames.

Stage 4: VAE Decode

This is where most OOM crashes happen. The VAE decodes the denoised latent back into pixel-space video. During this operation, the VAE needs:

• Space for the latent (same size as Stage 3)
• Space for the decoded pixel buffer (resolution × 3 channels × 81 frames)
• Intermediate tensors from the VAE forward pass

At 720p with 81 frames, the VAE decode step can require 4–8 GB of temporary VRAM on top of everything already loaded. The total during decode can exceed the model load by 30–50%.

VRAM change: +4–8 GB above denoising stage — the peak of the entire generation.

Putting It Together

What this table tells you: A 12 GB card at Q4_K_M fits at load time (13.5 GB fits with 1.5 GB of offloading). But during VAE decode, total VRAM needs hit ~20 GB — 8 GB over the card's capacity. That is why ComfyUI's built-in offloading is essential: it moves the text encoder and parts of the diffusion model to CPU during decode to free the 8 GB needed for the VAE spike.

Rule of thumb for VRAM budgeting: The number on the model card (e.g., "Q4_K_M = 10.5 GB") covers load only. Budget 40–60% more for the full generation cycle. A 10.5 GB model needs roughly 15–17 GB of total VRAM headroom during peak decode.

Knowing where the VRAM goes is only half the solution. Here are five techniques to reduce pressure, ordered from most effective to last resort.

5 VRAM Reduction Techniques (Ordered by Effectiveness)

1. Reduce Frame Count

Generating 41 frames (2.5 seconds) instead of 81 frames (5 seconds) cuts the latent size roughly in half. This reduces VRAM pressure during both denoising and VAE decode by 25–35%.

Expert pitfall for frame reduction: Reducing frames does not reduce model loading VRAM. If your OOM happens during model load (before generation starts), frame count will not help. You need a smaller quant or a smaller model.

2. Lower Output Resolution

Resolution affects VRAM non-linearly because it impacts both the latent size and the VAE decode buffer.

Dropping from 720p to 580p saves ~2 GB during peak decode — enough to keep a 12 GB card from OOM at Q4_K_M. Dropping to 480p saves another ~2 GB.

3. Enable VAE Tiled Decode

VAE tiled decode processes the VAE in tiles instead of all at once, trading speed for VRAM. It is the single most effective technique for preventing decode-stage OOM.

How to enable it in ComfyUI:

• ComfyUI settings: Settings → Memory Management → Enable VAE Tiled Decode
• Command line: python main.py --split-vae
• Threshold: Set the tile size to 256 or 512. Smaller tiles use less VRAM but take longer.

With tiled decode enabled at 256px tiles, peak VRAM during Stage 4 drops by 40–50% — from 20 GB to ~12 GB on a 720p, 81-frame, Q4_K_M workflow.

4. Offload Text Encoder to CPU

The UMT5 text encoder consumes 1.2–2 GB of VRAM depending on precision. Moving it to CPU saves that memory for the diffusion model and VAE.

In ComfyUI, this is controlled per-node. Find the CLIP text encoder node and set its device to "CPU." The text encoding step takes 2–5 seconds longer on CPU, but the VRAM savings are available for the entire generation.

5. Use the 5B Model Instead of 14B

The 5B model at FP16 uses ~10 GB VRAM at load and ~14 GB at peak. This fits on 12 GB cards comfortably and on 8 GB cards with offloading. The trade-off is lower output quality — the 5B model produces more deformations and less detail.

The 5B model is useful as a testing fallback: iterate prompts and settings on 5B, then switch to 14B for final generation.

Expert pitfall for combining techniques: Applying all five techniques at once rarely helps — the quality loss compounds faster than the VRAM savings add up. If you need all five techniques to fit a workflow, the workflow is wrong for your hardware. Pick the first three in the priority list, test, and only reach for resolution reduction or model switching if OOM persists.

Rule of thumb for technique priority: Use them in this order:

1. Reduce frame count (easiest, biggest impact)
2. Enable VAE tiled decode (near-zero quality loss)
3. Offload text encoder to CPU (small speed cost)
4. Lower resolution (visible quality loss)
5. Switch to a smaller quant or the 5B model (last resort)

These techniques apply differently depending on your GPU. Here is what each tier can actually sustain — and what it cannot.

What Each Tier Actually Sustains

8 GB — Technically Possible, Practically Limited

At 8 GB, Wan 2.2 runs but the experience is constrained.

What works reliably:

• 5B FP16 at 480p, 41 frames, with aggressive offloading
• 14B Q3_K_S GGUF at 480p, 41 frames, with VAE tiled decode and text encoder on CPU
• Expect 8–15 minute generation times

What does NOT work:

• 14B at any quant with 81 frames and 720p — the VAE decode spike alone exceeds total VRAM
• Any workflow without VAE tiled decode enabled
• Running both High Noise and Low Noise checkpoints simultaneously

The practical limit: 8 GB is usable for testing and very short clips. You will spend more time managing VRAM than generating. If this is your only GPU, prioritize 5B workflows and keep frame counts at 41 or below.

Realistic workflow for 8 GB:

1. Load: 5B FP16 (~10 GB with offloading → fits)
2. Text encoder on CPU
3. Generate at 480p, 41 frames, 20 steps
4. VAE tiled decode at 256px tiles
5. Generation time: 5–8 minutes per clip

12 GB — The Practical Minimum

12 GB is the first tier where Wan 2.2 becomes a usable tool rather than a technical exercise.

What works reliably:

• 14B Q4_K_S or Q4_K_M GGUF at 580p, 81 frames
• 5B FP16 at 720p, 81 frames (comfortable)
• VAE tiled decode recommended but not always required

What is tight:

• 14B Q4_K_M at 720p, 81 frames — needs VAE tiled decode and text encoder on CPU
• 14B Q6_K at any resolution — exceeds VRAM during decode
• FP8 14B — needs heavy offloading, slower than GGUF

The practical limit: 12 GB handles daily 14B generation at 580p or 5B at 720p. For maximum quality, use Q4_K_M GGUF, enable VAE tiled decode, and keep the text encoder on CPU. The generation times (4–8 minutes) fit into a natural work rhythm.

16 GB — Comfortable With Room to Experiment

16 GB is where VRAM management stops being the primary concern.

What works reliably:

• 14B Q8_0 GGUF or FP8 at 720p, 81 frames
• Dual model loading (High Noise + Low Noise at Q6_K) with VAE tiled decode
• LoRA integration (rank 64 adds ~1 GB)
• VAE decode without tiling at 720p

What is tight:

• 14B FP16 at 720p — needs system RAM offloading, ~28 GB peak during decode
• Dual model loading at Q8_0 — works but can OOM mid-batch
• 1080p generation — exceeds VRAM for most quants

The practical limit: 16 GB is the first tier where you can stop micro-managing VRAM settings. Set up Q8_0 at 720p with 81 frames, enable VAE tiled decode as insurance, and focus on prompt iteration instead.

24 GB — Headroom for Full Models

24 GB is the no-compromise tier — but even here, VAE decode can surprise you.

What works reliably:

• 14B FP16 at 720p, 81 frames — full model, no quantization
• 14B FP16 at 1080p — needs VAE tiled decode for the decode stage
• Dual model loading at FP16 (High Noise + Low Noise simultaneously)
• Multiple LoRAs (up to 4 at rank 64)
• Offloading not needed for most workflows

What is tight:

• 14B FP16 at 1080p with 121+ frames — VAE decode peak exceeds 24 GB
• Running Animate 14B alongside I2V 14B — two 28 GB models fight for the same 24 GB

The practical limit: 24 GB eliminates VRAM as a constraint for standard Wan 2.2 workflows. The only remaining VRAM considerations are extended frame counts (121+), 1080p resolution, or multi-model workflows.

Expert pitfall for 24 GB: The 24 GB card's headroom makes it easy to forget about VAE decode pressure. A workflow that runs 20 times successfully can OOM on the 21st if the VAE decode happens to coincide with a memory allocation from another process. Enable VAE tiled decode as a safety net even on 24 GB — the speed cost is negligible and it prevents intermittent crashes.

The tier recommendations above are based on my testing. To measure VRAM on your specific hardware, here is how to profile it yourself.

How to Profile Your Own VRAM Usage

If you want to measure exactly how much VRAM Wan 2.2 is using on your GPU, use these methods.

NVIDIA GPUs: Open a terminal and run nvidia-smi -l 1 to watch VRAM usage update every second. Run this alongside your generation to see the peak at each stage. The peak during VAE decode is your true VRAM requirement.

ComfyUI console output: ComfyUI prints VRAM usage at key points if you start it with --verbose. Look for lines containing "memory," "VRAM," or "cuda" in the console output.

Custom nodes for profiling: The ComfyUI-VideoHelperSuite and ComfyUI-SaveVRAM custom nodes can log VRAM usage to the console or to a file during generation. These are useful for identifying which stage causes OOM.

Rule of thumb for profiling: Profile once per workflow configuration, not per generation. The VRAM profile of Q4_K_M at 720p with 81 frames is the same every time. Only re-profile if you change the model, quant, resolution, or frame count. Profiling every generation wastes time without revealing new information.

Profiling reveals the specific numbers. Here are the questions those numbers answer most often.

Frequently Asked Questions

Why does my generation fail at 90% when the model loaded fine? The VAE decode stage at the end of generation requires 4–8 GB of temporary VRAM on top of everything already loaded. If your VRAM is full from the model, latent, and intermediate tensors, the VAE decode has no room to work. Enable VAE tiled decode or reduce resolution/frame count.

Does system RAM help with VRAM limitations? Yes — but only through explicit offloading. ComfyUI can move the text encoder, VAE, or parts of the diffusion model to system RAM when VRAM is full. This trading speed for memory. System RAM does not automatically extend your VRAM — you must configure what gets offloaded and when.

How much VRAM does a LoRA add? A rank 64 LoRA adds approximately 1 GB of VRAM during generation. A rank 128 LoRA adds approximately 1.8 GB. The LoRA is loaded alongside the base model and stays in VRAM throughout generation. If you are close to your VRAM limit, add LoRAs one at a time and test.

Does changing the sampler or scheduler affect VRAM? Minimally. Samplers and schedulers change the math inside each denoising step but do not meaningfully change the memory footprint. Step count also has negligible VRAM impact — 20 steps use the same VRAM as 4 steps. The VRAM cost is per-step intermediate tensors, not cumulative across steps.

Can I use shared GPU memory (Windows) to extend VRAM? Windows shared GPU memory lets the GPU borrow system RAM when VRAM is full, but the performance cost is severe — bandwidth drops from ~900 GB/s (GDDR6X) to ~50 GB/s (system RAM over PCIe). Wan 2.2 becomes unusably slow when it hits shared memory. Avoid relying on it.

What is the cheapest GPU that can run 14B at 720p? A used 12 GB RTX 3080 at Q4_K_M GGUF with VAE tiled decode enabled. This combination costs approximately $300–400 on the used market and produces acceptable generation times (4–8 minutes).

The pattern across all these answers is the same: VRAM is dynamic, not static. Here is the short version.

Summary

VRAM in Wan 2.2 is not a single number — it is a profile that changes across the four generation stages. The peak during VAE decode is what determines whether a generation succeeds, not the model file size at load.

• 8 GB: Technically possible with 5B model or 14B Q3 at 480p and 41 frames. Practical for testing only.
• 12 GB: The minimum for daily use. 14B Q4_K_M at 580p with VAE tiled decode is the sweet spot.
• 16 GB: Comfortable. Q8_0 at 720p runs without constant VRAM management.
• 24 GB: Headroom for full FP16 models, but VAE decode can still surprise you.

The most effective VRAM reduction technique is not quantization — it is VAE tiled decode combined with frame count reduction. These two changes together can cut peak VRAM usage by 40–50% with minimal quality impact.

Next step: If you are setting up Wan 2.2 on a specific GPU, check the Wan 2.2 Requirements Guide for hardware-specific recommendations. For help with OOM errors during specific workflows, the Wan 2.2 ComfyUI Workflow Guide covers troubleshooting steps for each generation stage.