How much VRAM do open image and video models need?

How to read these numbers

Every figure here comes from the model developer's own card, README or blog, with the setup it assumes. A VRAM number without its setup is close to meaningless: the Wan 2.2 80GB figure already has model offloading switched on, and HunyuanVideo's 14GB minimum was measured with offloading too. Turn those off and you need more; add quantisation and you may need less.

Where a developer gives no figure, we say so instead of estimating. Figures from tools rather than model developers (ComfyUI, community engines) are labelled as such.

Developer VRAM figures, model by model

What fits on 8, 12, 16, 24, 48 and 80GB

Each tier includes everything from the tiers below it. The middle column is strictly what the model developer says; the right-hand column is what tool docs or community engines report, which is worth trying but isn't the developer's claim.

The 80GB row is where most video models land at full precision. Wan's README documents multi-GPU inference (FSDP plus DeepSpeed Ulysses, 8-GPU example) for anyone splitting the A14B models across smaller cards, and LongCat-Video and MiniMax H3 ship multi-GPU commands too.

What quantisation changes

Quantisation stores weights in fewer bits. Halving the bits roughly halves the memory those weights take; activations, the text encoder and the VAE still need their own room. Quality can drop, and how much depends on the model and the method, so compare outputs before committing.

fp8

• BFL publishes official FP8 and NVFP4 versions of every FLUX.2 [klein] variant and says FP8 uses up to 40% less VRAM and NVFP4 up to 55% less, measured on RTX 5080/5090 at 1024×1024.
• HunyuanVideo 1.5 added FP8 GEMM inference for the transformer in December 2025 (needs sgl-kernel).
• Lightricks' LTX-2 code offers --quantization fp8-cast --offload {cpu, disk} for constrained GPUs, which downcasts bf16 checkpoints on the fly.
• Diffusers' layerwise casting stores weights in float8_e4m3fn and upcasts per layer for compute, skipping normalisation and modulation layers because fp8 there can degrade quality.
• musubi-tuner's --fp8 for Wan "can significantly reduce memory consumption but may impact output quality"; --fp8_scaled trades a little memory back for better quality.

GGUF

GGUF is the llama.cpp file format, brought to image and video models by the community ComfyUI-GGUF nodes. Its README says transformer models such as Flux "seem less affected by quantization", which allows much lower bits-per-weight quants on low-end GPUs. Diffusers can also load GGUF files with from_single_file. Model developers rarely publish GGUF files themselves, so these are community conversions: check who made them.

int8 and 4-bit

Lightricks publishes int8 LTX-2.5 checkpoints for ComfyUI and an NVFP4 distilled checkpoint (its ltx-pipelines path needs a Blackwell GPU). Diffusers supports bitsandbytes 4-bit and 8-bit, torchao, quanto and GGUF backends through one PipelineQuantizationConfig, and recommends quantising the most compute-heavy component (the transformer) first, then large text encoders.

What offloading changes

Offloading keeps weights in system RAM and moves them to the GPU when needed. It trades speed for memory, and it shifts the requirement to system RAM, which matters for 14B video models.

• Model offload (enable_model_cpu_offload() in Diffusers) keeps one whole component on the GPU at a time. Faster than the alternatives, smaller savings. This is what most model cards show.
• Sequential offload (enable_sequential_cpu_offload()) moves submodules one by one. Diffusers' docs call it "extremely slow" and often impractical.
• Group offload moves blocks of layers and sits between the two. With CUDA streams, Diffusers says you need about twice the model size in CPU memory.
• Model-specific flags: Wan's --offload_model True, --convert_model_dtype and --t5_cpu (which runs the T5 text encoder on CPU); musubi-tuner's --blocks_to_swap (up to 39 blocks for Wan 14B) and --fp8_t5 for GPUs under about 16GB.
• VAE tiling cuts decode memory for large images and video. HunyuanVideo 1.5's Diffusers example turns it on with vae.enable_tiling(), and DiffSynth-Studio's Wan pipeline tiles the VAE by default.

LoRA training VRAM requirements

Training needs more memory than inference for the same model: gradients, optimiser state and activations for every frame. Developer-published training figures are rare; trainer docs are where the numbers are.

DiffSynth-Studio's training docs list the standard levers: gradient checkpointing (and offloading it to RAM for video), fp8 storage for frozen components such as the text encoder and VAE, and the option to run the transformer in fp8 during LoRA training.

Models with no official VRAM figure

These developers publish no VRAM requirement: Z-Image (base), Qwen-Image-2512, Qwen-Image-2.1, Qwen-Image-Edit-2511, FLUX.1 [schnell], HiDream-O1-Image, SDXL, LongCat-Video, LTX-2.3, LTX-2.5 and MiniMax H3. Numbers you see for these elsewhere are community measurements, which vary with resolution, frame count, attention backend and offloading settings. Measure on your own setup with torch.cuda.max_memory_allocated(), as Diffusers' memory guide does in its examples.

If you'd rather not run the GPU

The hardware requirements page keeps these figures for every catalogued model, linked to the source. Windpaint runs Z-Image Turbo and FLUX.2 [klein] 4B on its own GPUs behind an API with per-image pricing, so you don't need any of the above to use those two.