# Wan 2.2 5B text-to-video on rented GPUs: where the time goes when you move it

> An 18 GB Wan 2.2 text-to-video setup, built once and restored on a 3090, a 4090, a 5090 and an A5000. Download, dependency install and render times side by side, and what held up the slowest run.

Published: 2026-10-13 · Field reports
Canonical page: https://renest.ai/blog/wan22-video-on-rented-gpus

**Short answer:** it came back and rendered a video on all four cards, in between three and a half and nine and a half minutes from pasting the command. The render itself was 48 to 124 seconds and was never the longest stage; the wait came from downloading the files and installing the packages, and it varied a lot from machine to machine.

## The setup

Wan 2.2 TI2V 5B is a text-to-video model people run in ComfyUI on a single consumer card. The setup is big: the fp16 model, the UMT5 text encoder, the VAE and the workflow come to 18.1 GB. We built it once on a RunPod A5000 and ran the workflow (139 seconds to render the first video). Packing it into a nest took 64 seconds.

Then we restored it on other machines, one at a time.

## What each card did

| Card | Download | Installing packages | Render | Start to finished video |
|---|---|---|---|---|
| RTX 4090 (a second run) | 68 s | 26 s | 57 s | 3 min 1 s |
| RTX 4090 | 140 s | 55 s | 66 s | 5 min 6 s |
| RTX 3090 | 140 s | 23 s | 124 s | 5 min 37 s |
| RTX A5000 | 165 s | 18 s | 118 s | 5 min 49 s |
| RTX 5090 | 100 s | 382 s | 48 s | 9 min 32 s |

The download is the biggest block on most rows, and it ranged from 68 to 165 seconds across the rows. The 5090 is the one to look at: the card with the fastest render took the longest, because installing the Python packages on that machine took 6 minutes 22 seconds, against 18 to 55 seconds elsewhere. We reran that cell and noted that the platform's download speed on that machine was slow. We didn't establish more than that.

The two 4090 rows are the same card on different machines and days: 3 minutes against 5 minutes.

## What the download speed really was

On the A5000 row we also tried a quick speed test before restoring: one connection pulling a 20 MB sample of one of the files from our storage. It got about 20.5 MB/s. The restore itself opens several connections at once for big files, and it brought the whole 18.1 GB down in 165 seconds, about 110 MB/s: more than five times what the single-connection test suggested. If you time a download with one connection and decide a machine is slow, you may be wrong.

## Did the video look the same?

We didn't compute a similarity number: Wan's output is a video, and our comparison is for still images. We did look at frames. Here are four frames, 0.7 seconds apart, from the video the A5000 made when we built the setup (top) and from the video the 4090 made after the restore (bottom).

![Two rows of four video frames each: a man in a dark jacket playing an acoustic guitar in front of a microphone on a metro platform, with a train blurring past and two seated musicians behind him. The top row is labelled original, the bottom row restored.](/blog/wan22-original-vs-restored-frames.jpg)

It is the same scene in both: the platform, the passing train, the man with the guitar and the same slow move towards him. The two people sitting behind him are posed a little differently from one row to the other. That is as far as we looked. We kept the videos. What the table says is that the files and dependencies came back, checked, and the workflow ran and produced a video on each card.

## What we'd tell someone moving a video setup

- **Budget the packages, not just the model.** The model files are the part you expect to wait for. On the slowest row the wait was dependencies.
- **Don't judge the download from a single-connection test.** A single connection measured about 20 MB/s on the A5000; the restore, using several, moved 18.1 GB in 165 seconds.

## What this doesn't say

Five single runs on RunPod machines in early October. Times will move with the connection. This is the Wan 2.2 TI2V 5B setup with the fp16 weights; the larger Wan models are a different size problem. Most of these ran on version 0.1.18 of the tool.