22B-Parameter LTX-2.5 Runs on a 10 GB RTX 3080, but Takes 5 Minutes per Shot

A Habr author has run the 22-billion-parameter LTX-2.5 video model locally on an RTX 3080 with 10 GB of memory. The transformer alone weighs 39 GB, and the Gemma text encoder takes another 24.5 GB. The model runs under Windows and is built into a pipeline for vertical videos made of 6–8 shots. But the small amount of video memory came at a price: system RAM, load time and fiddly environment setup.

The author's task is practical, and a whole chain of models runs one after another on a single computer. Gemma, via llama.cpp, helps with the script, FLUX.2 [klein] draws frames with a consistent face for the character, and LTX-2.5 animates those frames. Qwen3-TTS then produces the voice, ACE-Step the music, and ffmpeg handles the editing. LTX receives a finished image and turns it into a short video shot.

How 39 GB of weights pass through 10 GB of VRAM

The author uses the distilled version of LTX-2.5, which builds video in two stages. First come 8 denoising steps at low resolution (about 1.4 s per step). Then a latent upscaler enlarges the result by a factor of two, and 3 more steps run at the full 576×1024 resolution (about 5 s per step). The author calls these timings preliminary observations, not a reproducible benchmark.

In the standard Lightricks/LTX-2 pipeline, two flags are enough for this. The `--quantization fp8-cast` parameter stores weights in bf16 and casts them to fp8 when loading onto the GPU: it needs half the memory, and no separate fp8 checkpoint is required. The `--offload cpu` parameter enables streaming mode: transformer blocks sit in system RAM and are fed to the GPU one at a time. Long shots also needed the variable `PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True`; without it, memory fragmentation caused OOM errors.

The memory does not disappear, though. It moves from the GPU to RAM. By the author's estimate, this setup needs at least 32 GB of RAM (64 GB is better) and a swap file of 32 GB or more. So the phrase "runs on 10 GB" does not adequately describe the requirements.

Two pitfalls: safetensors on

Windows and unloading that does not unload

The first run ended in an access violation when opening the weights, with no clear error message. In the author's environment, the safetensors library tried to map files larger than roughly 2 GB into memory in one piece and crashed. The workaround is to replace safe_open: the file header is parsed manually, and tensors are returned as views over a read-only np.memmap. The interface stays the same, so the LTX pipeline notices nothing, and no separate copy of the weights consumes commit memory. The patch hooks in without editing third-party code: the file sits in site-packages, and a .pth file containing `import ltx_sft_patch` swaps the module in when the interpreter starts.

The second problem appeared when the models worked together. Originally each lived in a persistent worker process and was unloaded with an unload call after use. With CPU offload, some VRAM and pinned RAM stayed occupied afterward, and the next model did not fit. The reliable fix was to terminate the process entirely. Now each model runs in its own process and its own venv, and LTX gets a separate process for every shot. A side benefit: the models need incompatible versions of torch and diffusers, and isolated environments keep them from interfering with each other.

Where the time actually goes

Restarts have a cost. By preliminary measurements, one shot takes about five minutes, and denoising itself takes about 25 seconds. That matches the step arithmetic: 8 times 1.4 s plus 3 times 5 s gives about 26 seconds. The remaining time goes to reading and preparing roughly 65 GB of transformer and Gemma encoder weights, and it happens anew for every shot.

The takeaway for anyone building a similar pipeline: before buying a faster GPU, measure weight-loading speed and memory usage. A video of 6 shots takes about half an hour to assemble; a short one takes a few minutes. The author sees the next step as keeping the encoder and transformer in memory between shots, but that option has yet to be tested.

Separately, the author shares tricks for working around the model's weaknesses. The starting frame should show the state before the action: if a door is already open and the prompt asks the model to open it, the model has to invent what happens. Hand contact with objects is better split across two shots: in the first, the hand reaches out; after the cut, the door is already open, and the questionable moment stays off-screen.

If the end of the motion matters, the final frame can be passed as a second `--image`. Lip sync needs a different setup: the full, non-distilled model, a distilled LoRA and the a2vid_two_stage audio branch, and only the video is taken from the result, while the sound stays from the voice-over.

Bottom line: a 22B model on a home card with 10 GB turned out to be a workable option for short videos. Everything runs locally, with no cloud and no subscriptions, but at the cost of a large amount of RAM, long load times and manual environment setup.