LTX-2.5 VRAM & Cost Calculator

Two numbers decide whether you self-host LTX-2.5: how much VRAM your generation needs, and what a finished second of video costs you. This guide turns both into arithmetic you can do before you download the weights.

The VRAM side is built from the documented compression ratios of the LTX-2 Video VAE and the published parameter counts. The cost side is built from the documented per-second billing model of the LTX API. Where a number depends on your own hardware or your own GPU rental contract, this guide gives you the formula rather than inventing a figure.

Prerequisites. Per the open-source documentation, the codebase is pure PyTorch, tested on CUDA 12.7 or newer with CUDA 13 or newer recommended, targeting NVIDIA GPUs with 80GB or more of VRAM, with distilled variants supported on 32GB when quantization is enabled. At bf16 the transformer and text encoder alone come to roughly 68 GB, so budget on the order of 70 GB of disk for the full bf16 component set, and considerably less if you pull quantized checkpoints. If those requirements exclude your hardware, the hosted API runs the same model family on managed GPUs, priced at ltx.io/model/api/pricing.

What consumes VRAM in a generation?

VRAM during an LTX-2.5 generation goes to four places, and they peak at different moments. Knowing which one is your bottleneck determines which lever will actually help.

• Transformer weights. The LTX-2.5 transformer checkpoints are 22B-parameter files. At bf16, two bytes per parameter, that is roughly 44 GB of weights before anything else loads. Casting to FP8 roughly halves it, and the NVFP4 checkpoint is smaller again.
• Text encoder. LTX-2.5 uses a custom Gemma 4 12B encoder, fine-tuned for LTX and shipped with the model. At bf16 that is roughly 24 GB, and it is required by every pipeline. Loading checks the encoder version against the one the checkpoint was trained with, so Google's stock Gemma 4 release is not a substitute.
• Latents and activations. This is the part that scales with what you asked for, and the part the calculator below computes.
• VAE decode. Decode is a separate peak at the end of the run. The ltx-core documentation states the diffusion video decoder delivers improved quality at the cost of longer decode time and more VRAM than the convolutional decoder.

How to calculate your latent size

Latent size is fully determined by three documented compression facts, so you can compute it exactly rather than guessing. The Video VAE encoder maps pixels shaped [B, 3, F, H, W] to latents shaped [B, 128, F', H/32, W/32], where F' = 1 + (F-1)/8. Spatial compression is 32x in each dimension, temporal compression is 8x, and the latent has 128 channels.

That gives you a three-step calculation.

1. Pick a valid frame count. It must satisfy (F-1) % 8 == 0. Valid values include 9, 17, 25, 33, 41, 49, 57, 65, 73, 81, 89, 97 and 121. The documented quick start uses --num-frames 121.
2. Compute latent elements. Multiply 128 x F' x (H/32) x (W/32), where F' = 1 + (F-1)/8.
3. Multiply by bytes per element. Two bytes at bf16, one byte at FP8.

Worked example, 121 frames at 1280x720. F' = 1 + 120/8 = 16 latent frames. The spatial grid is 1280/32 = 40 wide; 720 is not a multiple of 32, so in practice the height pads up to the next multiple, 736, giving 23 (this padding is an inference from the divisible-by-32 rule rather than a documented step, but it matches LTX generating 1080p as 1088). Latent elements are 128 x 16 x 23 x 40 = 1,884,160, about 3.8 MB for a single latent tensor at bf16.

Worked example, 121 frames at 1920x1080. F' is still 16. The spatial grid is 34 by 60 after padding to 1088. Latent elements are 128 x 16 x 34 x 60 = 4,177,920, about 8.4 MB at bf16.

The headline from those two examples is the one most VRAM guides get wrong: the latent tensor itself is tiny. What scales is everything the transformer builds on top of it. The latents are patchified into sequence format [B, seq_len, dim] before the transformer sees them, and attention activations scale with sequence length, which is what makes the jump from 720p to 1080p expensive. Use the latent element count as your relative cost index between configurations: the 1080p example carries 2.2x the tokens of the 720p one, so expect activation memory and step time to scale in that direction.

What are your levers when it does not fit?

Levers fall into four documented groups, worth trying in this order because the earlier ones cost you less.

• Reduce the workload first. Drop to the next valid frame count down, or generate at a lower resolution and upsample. The two-stage pipelines exist precisely to do this: generate at lower resolution, then apply 2x spatial upsampling. This costs nothing structurally and it is the only lever that reduces both memory and time.
• Quantize. Use --quantization fp8-cast with bf16 checkpoints to downcast on the fly. On Hopper and newer GPUs with native FP8 support, use --quantization fp8-scaled-mm with FP8 checkpoints. ltx-core also provides blockwise FP8, FP6 and NVFP4 linear policies. Read quantization formats before choosing.
• Offload. Add --offload cpu or --offload disk. This moves weights off the GPU between uses and trades wall-clock time for headroom.
• Stream transformer blocks. ltx-core's block streaming module runs the full model on machines that cannot hold all its weights at once, streaming transformer blocks through a small rolling set of GPU buffers. With cpu_slots_count omitted or at least the block count, all blocks pre-load into pinned CPU buffers: fast, but more CPU memory. Setting it below the block count switches to disk streaming, which reads blocks from the safetensors file on demand on a background thread: slower, but the lowest CPU memory of any option.

Two smaller levers are worth knowing. The convolutional video VAE decoder is lighter than the diffusion decoder and needs no extra dependencies, so switching decoders reclaims the decode-time peak. And LoRA adapters load onto the CPU by default and transfer to the GPU sequentially during fusion, which keeps peak GPU memory low; overriding lora_load_device to the CUDA device is faster but uses more GPU memory. The LoRA adapters guide covers loading in full.

Reading a CUDA out of memory error

The timing of the failure points at the lever.

If it happens before any step completes, you are weight-bound: the transformer and text encoder do not fit, so quantization, offloading or block streaming are your levers.

If it happens partway through the denoising loop, you are activation-bound: reduce resolution or frame count.

If it happens at the very end after the steps finish, you are decode-bound: switch from the diffusion decoder to the convolutional decoder.

One documented failure mode looks like an out-of-memory error but is not. The natten extra pins natten==0.21.7+torch2130cu132 with torch==2.13.0. Older PyTorch and NVIDIA stacks can produce an illegal memory access inside NATTEN TokPerm on large volumes when using the diffusion decoder. The documented fix is upgrading CUDA, PyTorch and natten to those pins, not reducing your workload.

What does a generation actually cost?

Cost has three shapes depending on how you run LTX-2.5, and they are not comparable until you normalize all three to cost per second of finished video.

Hosted API. The LTX API charges per second of video generated, measured in cents, with each SKU combining endpoint, model, resolution and output type — for example text-to-video-ltx-2-5-pro-1920X1080. Each SKU maps to an array of price entries with effective dates, so the rate that applies is the most recent effective entry, not the first listed, and the total is rounded to the nearest cent. As of September 2026 the live endpoint prices text-to-video-ltx-2-5-fast-1920X1080 at 13 cents per second and text-to-video-ltx-2-5-pro-1920X1080 at 17 cents; the legacy text-to-video-ltx-2-3-fast-1920X1080 SKU is 6 cents. Higher resolutions and the pro tier cost more per second than fast. Read current prices from the unauthenticated endpoint rather than any article:

curl --location 'https://api.ltx.video/pricing'

One billing detail matters for budgeting: prepaid organizations have their balance reserved before generation starts and are charged only on success, so failed jobs do not consume credits.

Rented GPUs. Cost per second of output equals your hourly GPU rate divided by 3600, multiplied by the seconds of GPU time each second of output consumes. LTX does not publish third-party rental rates, so substitute your provider's. The second term is what your speed benchmark produces, which is why memory optimization and cost optimization are the same exercise: every lever that lets you fit a larger batch or skip an offload improves the denominator.

Owned GPUs. Cost per second of output equals amortized hardware cost per hour, plus power, divided by 3600, multiplied by GPU seconds per output second. The structural advantage of owning is that this number falls as utilization rises, approaching the cost of electricity at high volume. That is the economic argument behind private deployment, and it only works if your GPUs are actually busy.

Where the break-even sits

Break-even between the hosted API and self-hosting is a utilization question, not a preference. Using the September 2026 rate of 13 cents per second for LTX-2.5 fast at 1920x1080, a thousand seconds of generated video costs roughly $130 on that tier. Set that against your own hourly GPU cost and the throughput you measured, and the crossover point falls out. Below it, the API is cheaper and needs no hardware. Above it, self-hosting wins and keeps winning, because marginal cost per generation on hardware you already own is power rather than price per second.

Three factors push the crossover in favor of self-hosting beyond raw arithmetic. Assets never leave your machine, which matters when IP sensitivity is the constraint. You are not exposed to queue time, since the API request flow includes authentication, SKU lookup, balance reservation and a job queue before a worker picks up the job. And you can use the full set of open-source levers above, several of which have no equivalent on a managed service. The factors pushing the other way are equally real: no capital outlay, no CUDA version management, and no responsibility for keeping a local install running.

Summary

LTX-2.5 targets NVIDIA GPUs with 80GB or more of VRAM, with distilled variants supported on 32GB when quantization is enabled; at bf16 the transformer (~44 GB) and encoder (~24 GB) dominate the download, so plan for roughly 70 GB of disk or less with quantized checkpoints. Latent memory is computable exactly: the Video VAE compresses 32x spatially and 8x temporally to a 128-channel latent, so latent elements equal 128 x (1 + (F-1)/8) x (H/32) x (W/32), and frame counts must satisfy (F-1) % 8 == 0. When a generation does not fit, reduce the workload first, then quantize, then offload, then stream transformer blocks. The API bills per second in cents, with LTX-2.5 fast at 1920x1080 running 13 cents as of September 2026 and live prices at the unauthenticated pricing endpoint. Self-hosting beats the API above a utilization crossover you can calculate from your own GPU rate and measured throughput.

Run the numbers for your own resolution and clip length before committing to hardware. The open-source repository has the full component list and CLI flags, and the hardware guide covers GPU selection by use case.