Wan 2.2 on an 8GB GPU? Real Tests Show RAM Matters as Much as VRAM
I measured three Wan 2.2 image-to-video renders and watched where the memory actually went. The answer to "will it run on my card?" is mostly about system RAM.
The setup
| Part | What I used |
|---|---|
| GPU | NVIDIA RTX 5070, 12GB GDDR7, PCIe 5.0 x16 |
| System RAM | 64GB DDR5-6000 (2 × 32GB, dual channel) |
| Model | Wan 2.2 I2V A14B, fp8 (high-noise + low-noise experts) |
| Steps | 12 + 12 (lightx2v speed-up LoRA) |
| Software | ComfyUI 0.37 with dynamic VRAM loading, run through Loomance (Stable Scene workflow) |
| Post-processing | RIFE frame interpolation on, final upscale off, 24 FPS |
All three renders ran back to back in the same session, so the models were already in memory. The first render after launching is much slower, more on that below.
Render times
| Resolution | Frames | Total time | High-noise step | Low-noise step |
|---|---|---|---|---|
| 832×480 | 49 | 8 min 28 s | ~29 s | ~10 s |
| 832×480 | 81 | 17 min 30 s | ~56 s | ~22 s |
| 1024×576 | 49 | 14 min 0 s | ~49 s | ~19 s |
Times are ComfyUI's own "Prompt executed in" figures. In every run, the high-noise stage took about two thirds of the total time, with each step roughly 2.6–2.8 times slower than in the low-noise stage.
Where the memory went
Model sizes, straight from the ComfyUI log:
| Component | Size |
|---|---|
| Wan 2.2 high-noise expert (fp8) | 13.9 GB |
| Wan 2.2 low-noise expert (fp8) | 13.6 GB |
| UMT5-XXL text encoder (fp8) | 6.4 GB |
| VAE + RIFE interpolation | 0.25 GB |
| Total | ~34 GB |
And what Windows Task Manager showed in the middle of each render:
| Render | Dedicated VRAM | Shared GPU memory | System RAM in use |
|---|---|---|---|
| 832×480 · 49 | ~9.0 / 12 GB | 14.8 GB | 32.2 / 63 GB |
| 832×480 · 81 | 8.0 / 12 GB | 13.7 GB | 29.3 / 63 GB |
| 1024×576 · 49 | 8.3 / 12 GB | 11.8 GB | 28.4 / 63 GB |
Committed memory (everything Windows had promised to running programs) was about 40GB during rendering, and the GPU sat at 100% utilisation the whole time.
What this means
1. VRAM is not the hard limit you'd expect
34GB of models cannot fit in a 12GB card, and they don't have to. Recent ComfyUI versions load weights dynamically: the card holds what it needs for the current step and the rest stays in system RAM. In my runs the GPU used 8–9GB regardless of resolution or clip length. Bigger jobs didn't run out of VRAM, they just took longer.
2. RAM decides whether it runs well
If ~25GB of model weights live in system RAM and Windows commits ~40GB in total, the amount of RAM becomes the real limit:
- 64GB: comfortable. Everything fits, with room left for the file cache that makes reloading models fast.
- 32GB: borderline. 40GB committed doesn't fit in 32GB, so Windows will likely page part of it to disk. Expect it to work at 480p, but slower, and noticeably slower on the first render. (Reasoned, not measured.)
- 16GB: not recommended for the fp8 models.
3. For 8GB cards, the connection matters more than the GPU
Because the model is streamed from RAM to the GPU during every step, the speed of that path matters. My test machine has PCIe 5.0 x16 and DDR5-6000. Many 8GB cards use an x8 link (for example, the RTX 4060 runs at PCIe 4.0 x8, roughly a quarter of the bandwidth of PCIe 5.0 x16), and many PCs still use DDR4. On those systems, expect noticeably longer times than in the table above, even at the same resolution.
4. Longer clips cost more than you'd think
Going from 49 to 81 frames is 1.65× more frames but took 2.07× longer. Going from 832×480 to 1024×576 is 1.48× more pixels and took 1.66× longer. More frames and more pixels both mean bigger intermediate data, and the cost grows faster than the clip.
Meanwhile, interpolating 80 in-between frames with RIFE took about 10 seconds. That's the cheapest way to get a smooth, longer-looking clip.
5. The first render after launch is much slower
My first attempt in this session ran at 88–104 seconds per high-noise step (I cancelled it), versus ~29 seconds once things were warm. On the first run, ComfyUI loads ~14GB per model from disk and sets up about 26GB of pinned RAM, and the CPU sat near 100% while that happened. If your first render feels painfully slow, wait for the second one before judging your hardware.
Practical settings for 8GB and 12GB cards
- Start at 832×480 with 49 frames. Wan 2.2 was trained around 480p, and this was the fastest setting I tested (8.5 minutes on 12GB).
- Prefer two short clips over one long one. Two 49-frame clips took about as long as one 81-frame clip, and each can be redone separately.
- Turn frame interpolation on. It doubles the frame count for almost no cost.
- Upscale at the end if you need a bigger video, but remember upscaling can't add detail the model never generated. See the 12GB test for a side-by-side.
- If you're buying parts for this, prioritise RAM. Going from 32GB to 64GB is usually cheaper than a bigger GPU and removes the main bottleneck.
- Close other heavy apps. Browsers with many tabs and games eat into exactly the RAM Wan 2.2 needs.
How Loomance fits in
All renders here were made with Loomance, a free desktop app I built that installs ComfyUI and the Wan 2.2 models for you and runs these workflows from a simple window, including a render queue for overnight batches. Your images stay on your PC. If you prefer wiring nodes yourself, the official ComfyUI Wan 2.2 image-to-video template with the lightx2v LoRA is the same basic setup. For a side-by-side of both approaches, see Loomance vs ComfyUI.
Tools and sources
- Wan 2.2, the open-source video model by Alibaba's Wan team (Apache 2.0)
- ComfyUI, the open-source engine used for every render
- Wan 2.2 on a 12GB GPU: real render times and RAM use, the earlier test on the same PC
Frequently asked questions
Try Wan 2.2 on your own GPU
Loomance is free to use (ad-supported) and renders locally on your NVIDIA GPU. It sets up ComfyUI and the models for you. No node graphs, no cloud uploads.
Download free