LTX-2.5 makes the decoder a diffusion model, and deletes your upscaler

Lightricks released LTX-2.5 on August 11, 2026, and the interesting change is not the transformer but the decoder: the VAE decoder is itself a diffusion model that performs a final denoising step in pixel space ^[1][2]. Most open-weights video models still treat the decoder as a fixed, deterministic latent-to-pixel map and recover lost detail with a separate super-resolution stage; LTX-2.5 folds that recovery into decode ^[3][13].

The reason the stage exists at all is compression. Latent diffusion compresses video before denoising, and high-frequency content such as readable text, fine textures and fast-moving edges gets smoothed out on the way back to pixels ^[4]. The usual fixes are a lighter compression ratio or a bolt-on upscaler ^[5]. LTX-2.5 goes the other way: a spatiotemporal ratio of 32x32x8, described as 1:192 overall, with the decoder trained on pixel-space losses so it learns to reconstruct what the latent cannot carry ^[6][7]. Those two figures only reconcile if the latent is fat in channels: 32x32x8 collapses 8,192 positions, so 1:192 against three-channel pixels implies roughly 128 latent channels ^[18].

For a deployment stack, this is a swap, not a subtraction. The decoder is a separate diffusion model with its own pipeline, LTX2VideoDiffusionDecodePipeline in the Diffusers integration, documented in the Hugging Face model card ^[8]. You still load and schedule two models; the difference is that the second one is matched to this latent space rather than being a generic upscaler, and it sits inside the request instead of after it. Weights for the Gemma 4 12B text encoder are separated from the transformer and VAE, so an encoder swap or a transformer-only fine-tune does not disturb the rest ^[9][10].

The latency picture is less settled than the headline number suggests. LTX's own benchmarks report a 10-second 720p clip in 6.8 seconds on two NVIDIA GB200 GPUs ^[16], which is about 13.6 GPU-seconds of accelerator time per 10 seconds of output ^[19] and roughly 1.5x faster than real time on that hardware ^[20]. The source material does not break out how much of that 6.8 seconds is decode, which is exactly the number you need to size a queue. Nor is a pair of GB200s a commodity assumption.

Content dependence compounds this. Diffusion Fidelity Rendering allocates compute unevenly, generating high-fidelity keyframes at a frequency that adapts to scene complexity, with more spend on readable signs, reflective surfaces and fast-moving faces and less on static backgrounds, operating inside the 8x temporally compressed latent space during generation rather than as post-processing ^[11][12]. Adaptive compute means per-request latency tracks prompt content, so plan against tail percentiles rather than a mean.

Quality claims are single-sourced. On LTX's 98-prompt suite the model scores 0.28 on artifacts where lower is cleaner, against 0.45 for Flux 3 and 1.20 for Veo 3.1 ^[17]: about 38 percent below Flux 3 and about 77 percent below Veo 3.1, on the vendor's own metric and prompts ^[21][22]. Separately, native multi-shot generation produces connected cuts in a single request while holding lighting, character identity, environment and visual style across the cuts ^[14][15], which removes a second assembly step for anyone currently stitching independent clips.

What to watch: whether Lightricks or third parties publish the decode share of end-to-end latency, whether the diffusion decoder runs acceptably on hardware smaller than paired GB200s, and whether that artifact gap survives measurement on a suite nobody at Lightricks chose.