Wan 2.2 on an 8GB GPU? What Real Tests Show About VRAM and RAM

I measured Wan 2.2 image-to-video renders and watched where the memory actually went. Then readers asked two good questions, so I tested again: with the driver fallback switched off, and with the PC limited to 16GB of RAM.

Published 19 October 2026 · Updated 19 October 2026 · By Vismantas Šleinota · Measured on RTX 5070 12GB, 64GB DDR5-6000 (also limited to 16GB)

The setup

The first 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

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:

And what Windows Task Manager showed in the middle of each render:

Committed memory (everything Windows had promised to running programs) was about 40GB during rendering, and the GPU sat at 100% utilisation the whole time. Those numbers made RAM look like the limit. The next two tests show it wasn't.

Follow-up 1: is the shared memory just the driver spilling over?

A reader on r/comfyui asked a fair question: maybe ComfyUI just treats dedicated VRAM and shared GPU memory as one pool, and the NVIDIA driver quietly spills into system RAM. To check, I set NVIDIA Control Panel → Manage 3D settings → CUDA – Sysmem Fallback Policy to Prefer No Sysmem Fallback, which stops the driver from doing that, and reran the 81-frame render twice.

No difference. Dedicated VRAM never filled up, and the ComfyUI log says what is happening: Enabled pinned memory 25851 and DynamicVRAM support detected and enabled. The shared memory is pinned system RAM that ComfyUI reserves on purpose and streams to the GPU, not driver overflow.

Follow-up 2: the same PC limited to 16GB of RAM

Another reader asked about 16GB of RAM. My first answer was "expect it to be a lot slower, or run out of memory". Instead of guessing, I limited Windows to 16GB (msconfig → Boot → Advanced options → Maximum memory = 16384), rebooted, and ran the same render twice with the driver back on its default setting. Windows and background apps were already using 7GB before Loomance started.

* The 64GB runs are the two from Follow-up 1, done earlier the same evening. The original Driver Default run in the first table took 17 min 30 s.

Same speed in both runs, no errors. ComfyUI simply pinned less RAM and read more of the model straight from the SSD, which shows up as the extra disk activity. The big RAM numbers with 64GB were ComfyUI using memory because it was there, not because it needed it.

The catch: the models were on a PCIe 5.0 NVMe SSD. ComfyUI's log marks this as fast_disk=True. On a SATA SSD or a hard drive, streaming from disk will be slower, and I haven't tested that yet.

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. High RAM use is not the same as needing that much RAM

With 64GB, ComfyUI pinned ~26GB and Windows showed ~40GB committed. With 16GB, it pinned 5.8GB and ran at the same speed. Recent ComfyUI adapts to whatever RAM it finds and streams the rest from disk:

• 64GB: works, with plenty of headroom for other apps.
• 32GB: should work fine. Not measured separately, but it sits between two configurations that ran at the same speed.
• 16GB: worked at full speed in my test, with the models on a fast NVMe SSD. Close other heavy apps, since Windows alone took 7GB.

3. For 8GB cards, the connection matters more than the GPU

Because the model is streamed to the GPU during every step, the speed of that path probably 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 longer times than in the tables above, even at the same resolution. (Reasoned, not measured.)

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.
• Keep the models on an NVMe SSD. With less RAM, ComfyUI reads more of the model from disk during rendering, so a fast drive is what made 16GB work in my test.
• Don't buy RAM just because Task Manager looks full. ComfyUI fills free RAM because it can. In my test, 16GB rendered as fast as 64GB.
• 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