A local AI video generator runs on less hardware than most guides claim, takes longer than you expect, and the thing that ruins your first evening is usually not your GPU. Every list of the best local video models will tell you which model to pick. Almost none of them tell you what happens after you have picked one, which is where people actually give up.
I build SimpliGen, so I have both the telemetry and the support threads. Here is what they say.
What do you actually need?
An NVIDIA card, and more system RAM than you think. Video is far heavier than images, and the requirement that catches people out is not the graphics card, it is the 32 gigabytes of system RAM that stops the machine falling over on long runs.
Here is the honest tier list, the same one in our docs:
| Your NVIDIA GPU | Images | Video |
|---|---|---|
| 4 to 6 GB VRAM | Most image presets work | Not realistic, use cloud |
| 8 GB VRAM | Everything | Lightweight and low-VRAM video presets only, at lower resolutions |
| 12 GB VRAM | Everything | Most video presets at moderate settings |
| 16 GB+ VRAM | Everything | Everything, including the heavier video models |
Alongside that: 16 GB of system RAM minimum and 32 GB recommended for video, and real disk space, because a single video model can be 10 to 30 GB.
Why does every guide quote a different VRAM number?
Because they are quoting different builds of the same model and calling them all by one name. There are three numbers in circulation for any given video model, they are all correct, and a listicle that gives you one of them has told you nothing.
Take Wan 2.2. The lists mostly say 12 to 16 GB. Wan's own repository says its reference command for the TI2V-5B model "can run on a GPU with at least 24GB VRAM (e.g, RTX 4090 GPU)", and that the 14B models need "at least 80GB VRAM". Meanwhile our quantized video packs start at the 8 GB tier, and one of our users happily runs an LTX preset we list at 16 GB on a 12 GB card.
Those three numbers are not in conflict. The model authors are describing their full-precision reference build, the listicles are describing something in the middle, and most people are actually running a quantized build that the model authors never benchmarked. So treat any single VRAM number with suspicion, including mine. Ask which build it refers to, then look at what your card can actually load.
How long does a clip take?
Longer than a cloud tool, and the honest figure is minutes per second of footage. In late August, a 15 second text to video on an RTX 4090 averaged 26.6 minutes across about 300 real runs, and a 5 second clip on the same card lands nearer 3 minutes.
Two caveats on that number. It is a late-August measurement and local video speeds moved a lot in mid-August, so it will drift again. And it is one card running our presets: a different model, a different build or a different resolution changes it completely, which is the same problem as the VRAM numbers above.
For calibration on the other end of the scale, Wan's repository reports that TI2V-5B "can generate a 5-second 720P video in under 9 minutes on a single consumer-grade GPU", and LTX-Video publishes distilled variants built for speed, with the 13B distilled model generating "HD videos in 10 seconds" on an H100, which is a data centre card rather than anything in your desk.
Why is your first clip so much slower than the rest?
Because you are paying to load the model, not to generate. This is the single most common false alarm I see, and it looks exactly like a broken GPU.
Someone came to me with a 4090 and a 5 second clip that took 24 minutes, ready to blame the card. Their logs showed the render itself took 3.5 minutes. The other 20 were spent reading the model off disk at 29 megabytes a second, because the models sat on a slow drive and Windows Defender was scanning each file as it loaded. Excluding that folder and moving it to a fast SSD fixed it completely.
If you are coming from a cloud tool, this is the part that will catch you out. Up there the model is already loaded and you never pay for it. Here you pay it on the first run of every session.
The test takes two minutes. Run the same generation twice without closing the app. If the second one is fast, nothing was ever wrong with your GPU, and your problem is disk speed or a scanner sitting in front of it. Both fixes are here.
Why do long runs die near the end?
Because Windows runs out of committed memory, not because your GPU runs out of VRAM. Long video runs get most of the way through and then die, sometimes taking the whole machine down with them, and everyone including me assumed VRAM first.
It usually is not VRAM. Windows tracks a commit limit, which is the total memory it is willing to promise to every running program, and that limit is your RAM plus your page file rather than your RAM alone. The first machine I saw this on was a 4090 with 32 gigabytes of RAM, so it is not a question of owning a weak card.
The cruel part is that the obvious fix makes it worse. Lowering the VRAM profile or turning on low memory mode pushes more of the model into ordinary system memory, which is exactly the thing that is running out. That is the tell: if reducing your VRAM settings does not help or makes things worse, stop looking at the GPU and raise the page file instead.
Which model should you run?
Pick by the job, not by the leaderboard. For general text to video and image to video, Wan 2.2 is the current default and its repository documents T2V, I2V, speech to video and character animation variants; for speed, the LTX line publishes distilled builds specifically designed to trade a little quality for a lot of time.
SimpliGen ships presets for both, plus MiniMax H3 for image and video, WAN 2.2 Animate for character animation, and LTX 2.3 and 2.5 including lip-sync. The reason to care about the preset rather than the model name is everything above: a preset is a specific build at a specific resolution with settings that have been tested to fit a stated VRAM tier, which is the information the model name alone never carries.
Is running it locally actually cheaper?
Locally, yes, once you own the hardware, because there is no per-generation cost and no quota. What you pay instead is time, electricity and the occasional evening spent on the two problems above.
SimpliGen itself is a one-time licence, not a subscription. Local generation on your own GPU costs nothing per clip. Cloud credits exist for when your card cannot do the job, they are optional, and what a cloud generation costs comes down to resolution, duration and steps, so a long high-resolution clip costs more than a short one. Keeping clips short while you dial in the look is the cheapest habit in either mode.
What if you are on AMD, a Mac or Linux?
Then SimpliGen is not your answer and I would rather say so now. Local generation here needs an NVIDIA RTX 20-series card or newer, AMD and Intel GPUs are not supported, and the installer is a Windows executable.
ComfyUI supports AMD, Intel Arc and Apple silicon alongside NVIDIA and runs on Windows, Linux and macOS, so on non-NVIDIA hardware the open source route is also the more capable one. It will ask more of you in setup, and everything above about load times, VRAM builds and the page file still applies.
What should you do next?
Before you buy anything or blame anything, run one generation twice in a row and watch the difference. That single test separates a slow disk from a slow card, and it is free.
After that, check your page file if long runs are crashing, and check your GPU against the tier list before you decide whether local video is realistic on your machine at all. If it is not, cloud generation on the same presets will get you there without new hardware.