If you generate AI video locally, you will meet the “out of memory” error sooner or later. Graphics card memory, VRAM, is the main limit on what you can make. The good news is that you can usually do much more with your card than the first error suggests, as long as you understand how resolution, clip length and memory interact.
Why video eats memory
A video model has to hold three big things in VRAM at once:
- The model weights: often many gigabytes.
- The working data: the compressed representation of every frame being generated, plus the intermediate calculations the model makes about how frames relate to each other.
- Helper models: the text encoder and VAE, which may be loaded at the same time or swapped in and out.
The working data grows with both resolution and frame count. Doubling the width and height roughly quadruples the pixels. Doubling the frames doubles them again. Because many models relate every part of the clip to every other part, memory and time can grow faster than the raw pixel count.
The three-way trade-off
With a fixed amount of VRAM, you are always balancing:
- Resolution: sharpness and detail.
- Clip length: number of frames.
- Model size and precision: quality and prompt understanding.
Push one up and you usually have to bring another down. Understanding which matters most for each shot is the key skill.
Practical techniques
Generate smaller, upscale later
The single most effective technique. Generate at a moderate resolution, such as around 480p to 720p, then use a video upscaler to reach 1080p or 4K. Upscalers need far less memory than generation and often give a cleaner final result. See AI Video Upscalers and Frame Interpolation.
Generate fewer frames, interpolate later
Generate at a lower frame rate or fewer frames, then use frame interpolation to smooth motion. This works well for slow and moderate movement.
Use shorter clips and extend
Several short clips, edited together or extended from the last frame, are more reliable than one long clip, and each needs less memory.
Quantisation
Quantised models store weights with fewer bits, for example 8-bit instead of 16-bit, or even less. Memory use drops a lot, and quality usually drops only a little. Many popular models have trusted quantised versions. Start with the highest precision that fits, and go lower only if needed.
Offloading
Offloading moves parts of the model to system RAM when they are not in use. It lets large models run on smaller cards, at the cost of speed. Plenty of fast system RAM helps a lot here.
Tiled decoding
The VAE decode step can spike memory at the very end of generation, causing a crash after minutes of work. Tiled VAE decoding processes the frames in smaller pieces and avoids that spike. Many workflows include a tiled decode node for this reason.
Attention optimisations
Memory-efficient attention methods, often enabled automatically or through a setting, reduce the memory needed for the model’s core calculations. Keep your software updated to benefit from them.
Free up VRAM
Close browsers with many tabs, games and other GPU apps. Use a second, lighter display adapter for your monitor if possible. Every gigabyte counts.
A rough planning table
Exact numbers vary by model and settings, but this table shows the kind of decisions people make:
| VRAM | Typical approach |
|---|---|
| 8 GB | Small or heavily quantised model, low resolution, short clips, offloading, upscale afterwards |
| 12 GB | Quantised mid-size models around 480p, short clips, tiled decode |
| 16 GB | Quantised larger models around 480p–720p, moderate lengths |
| 24 GB | Most models at 720p, longer clips, higher precision, LoRA training for some models |
| 32 GB+ | Higher resolutions and full-precision large models |
Diagnosing memory errors
- Crash at the very start: the model itself does not fit; use a quantised version or offloading.
- Crash during sampling: resolution or frame count is too high; lower one of them.
- Crash at the end: VAE decode spike; enable tiled decoding.
- Works once, fails the second time: memory is not freed between runs; restart ComfyUI or use a node that unloads models.
Speed versus memory
Many memory-saving tricks cost speed. Offloading and heavy tiling can make generation several times slower. A good approach is to use aggressive memory saving only for final renders, and draft at lower resolution where the model fits comfortably. Fast drafts mean more experiments, which usually improves results more than any single setting. Save the slow, high-quality settings for the few shots you will actually keep.
When to rent instead
If you spend more time fighting memory errors than creating, rent a high-VRAM GPU for the shots that need it. A few hours on a large card can be cheaper than a hardware upgrade, and you keep your local machine for drafts. See Renting a Cloud GPU for AI Video.
A worked example
Suppose you have a 12 GB card and want a 5-second shot at 1080p. Asking for that directly fails with an out-of-memory error. Instead:
- Load a quantised version of the model.
- Generate at the model’s lower native resolution, around 480p, at its default frame count.
- Enable tiled VAE decoding to avoid the crash at the end.
- Pick the best of four seeds at that size.
- Interpolate to 24 fps if the motion looks choppy.
- Upscale the chosen clip to 1080p in a separate step.
The final shot is 1080p, smooth and stable, made on a card that could never generate 1080p directly. This pattern, small generation plus separate finishing, is how most people with consumer hardware work.
Frequently asked questions
Does more system RAM help?
Yes, when you use offloading. It cannot fully replace VRAM, but it lets bigger models run. 64 GB is a comfortable amount for heavy offloading.
Is quantisation visible in the output?
At 8-bit, usually barely. At very low precision, detail and prompt adherence can suffer.
What resolution should I generate at?
The model’s recommended native resolution, then upscale. Generating far above it often causes repeated objects and odd compositions.
