A 22B-Parameter Video Model Runs on an RTX 3080 with 10 GB of VRAM

The owner of an RTX 3080 with 10 GB of VRAM has run the 22-billion-parameter LTX-2.5 video model at home. That means 22 billion trainable numbers, or weights. The transformer alone, the main part of the model, takes up 39 GB, and the Gemma text encoder adds another 24.5 GB. On paper, this combination does not fit on a 10 GB card. In practice it runs, but it pays for that with system RAM, time and environment wrangling. The author describes all timings in the article as preliminary observations, not a reproducible benchmark.

How 65 GB of Weights Pass Through 10 GB of VRAM

The author builds vertical videos from 6–8 shots. Several models run one after another on a single computer:

• Gemma via llama.cpp helps with the script; • FLUX.2 [klein] draws frames with the same character face; • LTX-2.5 animates the frames; • Qwen3-TTS does the voiceover; • ACE-Step makes the music; • ffmpeg assembles the edit.

LTX takes a finished image and turns it into a short video shot. The author uses the distilled version, a simplified and faster variant. Generation runs in two stages. First come 8 denoising steps (gradually cleaning noise out of the image) at low resolution, about 1.4 s per step. Then a latent upscaler enlarges the result 2x. After that come 3 more steps at the full 576×1024 resolution, at 5 s per step.

Two flags from the Lightricks/LTX-2 repository make it all fit in memory:

• --quantization fp8-cast: the weights are stored in bf16 and cast to fp8 as they load onto the GPU. This needs half as much memory, and no separate fp8 checkpoint is required. • --offload cpu: the transformer blocks sit in system RAM and are fed to the GPU one at a time, as they are needed for computation. • The environment variable PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True eliminates out-of-memory errors caused by fragmentation on long shots.

The memory does not disappear; it moves. You need at least 32 GB of RAM, preferably 64 GB, and a swap file of 32 GB or more. The phrase "runs on 10 GB" without these caveats is misleading.

Two

Pitfalls: Safetensors on Windows and Memory That Doesn't Get Freed

The first run never reached generation. It ended with an access violation (a faulty memory access) while opening the weights, with no clear error message. In the author's environment, the cause turned out to be how safetensors reads large files on Windows. The library tried to map the entire file into memory and crashed on files larger than roughly 2 GB.

The author worked around this by replacing the safe_open function. Instead of the standard reader, a read-only np.memmap does the work. The file header is parsed manually, and tensors are returned as views over the mapped file. There is no separate copy of the weights in commit memory, the interface stays the same, and the LTX code did not need to change. The patch lives in site-packages, and a .pth file containing import ltx_sft_patch swaps in the module when the interpreter starts.

The second problem was unloading models. At first, each model lived in a persistent worker process: it did its job, an unload was called, and the card was handed to the next model. But with CPU offload, after such an unload some of the VRAM and pinned RAM stayed occupied, and the next model did not fit. Only terminating the entire process worked reliably. Now each model has its own process and its own venv, and for LTX a new process starts for every shot. Separate environments also solve a second problem: the models need incompatible versions of torch and diffusers.

Five Minutes per Shot, 25 Seconds of Compute

Restarting processes has a price. According to preliminary measurements, one shot takes about five minutes, while the denoising itself takes roughly 25 seconds, less than 10% of the time. The rest goes to reading and preparing about 65 GB of transformer and Gemma encoder weights. This repeats for every shot.

Takeaways for anyone building a similar pipeline:

• The bottleneck here is disk and RAM, not the GPU. Before buying a faster graphics card, it is worth measuring weight-loading speed and memory consumption. • A video of six shots takes about half an hour to assemble; a short one takes a few minutes. • The next optimization step is to keep the encoder and transformer in memory between shots. The author has not tested this yet. It would bring back the problem of freeing memory for other models.

The author also shares some tricks for getting usable motion:

• The starting frame should show the state before the action. If a door is already open and the prompt asks to open it, the model starts guessing at what is happening. • Hand contact with objects is split across two shots.

In the first, the hand reaches for the handle; after the cut, the door is already open. The moment where the fingers pass through the handle stays off-screen. • If the end of the motion matters, the last frame is passed as a second --image parameter.

• Lip sync (synchronizing lips with speech) needs a different setup: the full, non-distilled model, a distilled LoRA and the a2vid_two_stage audio branch. Only the video is taken from the output; the audio stays from the voiceover.

Bottom line: a 22-billion-parameter video model on a home card with 10 GB gives a workable result for short videos. Everything runs locally, with no cloud and no subscriptions. The limitations are known: a lot of RAM, a long weight-loading time for every shot, and separate environments for each model.