FervorCreative AI
Live Latest 13.09.26 · morning 63 tools tracked 100 workflows indexed 143 topics Hot: MiniMax H3, ComfyUI, LTX-2.5

Analysis September 13, 2026 tool 10 min read

For local video the number that decides everything is whether the whole model fits on the card, which means a less faithful file that stays resident beats a more faithful one that has to be shuffled.

LTX-2.5ComfyUILightricksConvRotvideo-genlocal-creative-aiopen-weightslicensing-provenance

LTX 2.5 Now Renders Ten Real Seconds on a 24 GB Card, and the File That Does It Advertises Its Own Weakness

A 39 GiB video transformer squeezed into 11.66, why the speedup comes from residency rather than arithmetic, and how to run it tonight.

Halfway down the model card for a brand new quantization of LTX 2.5, past the size and the speed, there is a sentence that most people would have left out. The file is 1.90x less faithful than Lightricks' own INT8 build. Not a caveat in a footnote. A number, in the summary, in bold, put there by the person who made the file, with the measurement that produced it printed in the table above.

That is an unusual way to sell something. It is also the most useful line on the page, because it turns a download decision into an actual choice rather than a guess.

The file is JoaoZaokk/LTX-2.5-22B-distilled-W4A8-ConvRot, published on September 13. It takes the 22B distilled transformer from Lightricks' LTX 2.5, all 39.13 GiB of BF16, and re-encodes 1440 Linear layers into ComfyUI's asym_w4a8_int8 format: four-bit weights, an eight-bit activation path. What comes out is 11.66 GiB.

Which means a real ten-second video, on one consumer card, without the model leaving the GPU.

Why ten seconds is the number that matters

LTX 2.5 is not a short-clip model. Lightricks built it around native multishot, where one generation produces several connected shots that hold character, lighting and voice across the cuts, and a custom Gemma 4 12B text encoder that reads a complicated prompt as direction rather than as a bag of nouns. On fal, the Fast endpoints run up to 20 seconds and up to 4K. The whole design assumes you have room to tell a small story.

Run it locally at BF16 on a 24 GB card and you get almost none of that. The author documents four attempts at the reference arm, and three of them fail:

BF16, no splitting,        49 frames  -> CUDA out of memory
BF16, 6 GiB from cuda:1,   49 frames  -> works, 717.8 s
BF16, 6 GiB from cuda:1,  249 frames  -> Windows fatal exception, process dead
BF16, 40 GB on cpu,       249 frames  -> works, 780.7 s

Read the third line twice. Forty-nine frames survived being split across two cards. Two hundred and forty-nine frames killed the process. The frame count alone is not the problem, and neither is the model size alone; it is the combination of a 39 GiB model spread across devices and a long latent that falls over.

The W4A8 build renders the same 249 frames with no splitting at all, in 400.9 seconds. Same card. Same prompt, seed, sigmas, encoder and VAE. Just under seven minutes for 9.96 seconds of video at 512×512.

The speedup is about where the weights sit, not how fast the math is

Here is the part I did not expect, and the part that changes how I read every quantization card now.

The obvious story about four-bit weights is arithmetic: smaller numbers, faster multiplies, done. That story is mostly wrong here. The three arms in the measurement look like this:

arm GiB 249 frames s/frame MAE vs BF16 PSNR vs BF16
BF16 original 39.13 780.7 s 3.14 reference reference
Lightricks' comfy-int8-convrot 20.03 481.5 s 1.93 4.10 29.71 dB
this W4A8 file 11.66 400.9 s 1.61 7.81 25.39 dB

The W4A8 build is 1.95x faster than BF16 and only about 1.2x faster than the INT8 one, despite carrying half the bits. If the gain were arithmetic, that gap would be much wider.

The card names the real reason: at 11.66 GiB the model is resident on a 24 GB card and needs no block splitting, and both other arms have to move weights every step. Every step, the INT8 and BF16 arms pay to shuttle tensors across the PCIe bus or in and out of system RAM. The W4A8 arm does not, because there is nothing to shuttle.

That reframes the whole exercise. You are not buying faster multiplication. You are buying the right to stop moving data, and the threshold where that kicks in is not a smooth curve. It is a cliff located at your card's VRAM. A file at 25 GiB on a 24 GB card and a file at 11 GiB on the same card are not 2x apart in practice; they are on opposite sides of a wall.

Which is why "3.36x lighter" is the wrong headline and "fits" is the right one.

Two videos, both good, one of them yours

The fidelity number needs the same care. MAE 7.81 against 4.10 is the mean absolute per-pixel difference from BF16, on the 0 to 255 scale, averaged over all 249 frames. The spread is tight (7.16 to 8.84 for this build, 3.61 to 4.61 for Lightricks'), so the ordering is not one bad frame dragging an average around.

What that looks like on screen is more interesting than the number. The card's contact sheet shows frames 1, 63, 125, 187 and 249 across all three arms. The INT8 row tracks the BF16 row closely: same thin white lighthouse, same rock, same framing. The W4A8 row is a different composition, a larger brick-coloured tower, closer to camera, with dark smoke where the original has a light beam.

Not a broken video. A different video. Coherent motion across the full ten seconds, and it would pass unremarked if you had never seen the reference.

So the choice splits cleanly by what you are doing:

You are exploring, and the clip is the first thing you have seen of an idea. Take the W4A8. Composition drift is irrelevant when there is no reference to drift from, and you get your ten seconds three minutes sooner.

You are iterating on a shot you already approved, or matching something you generated last week, or you have a client who noticed the tower. Take Lightricks' INT8 and pay the 8.4 GiB and the 20% more time. The file that tracks the original is worth what it costs.

I would not have been able to make that call from a compression ratio. I could make it in about ten seconds from the table.

Put this into practice

The whole thing is one download and a handful of settings. Budget an hour, most of it waiting on the network.

1. Get the transformer. Download ltx-2.5-22b-distilled-transformer-w4a8.safetensors (12,520,267,816 bytes) from the model repository into ComfyUI/models/diffusion_models/.

2. Match the text encoder the measurement used. That is gemma4-12b-with-proj-ltx-2.5-comfy-int8-convrot. All three arms in the benchmark held the encoder fixed at that INT8 build so the transformer stayed the only variable. If you swap in a BF16 encoder you are running a different experiment, and the numbers above stop describing your setup.

3. Launch ComfyUI with --disable-dynamic-vram. This is the flag that keeps the resident-model behaviour the whole result depends on. Skip it and you may hand back the speedup to a memory manager trying to be helpful.

4. Set the generation parameters exactly.

frames      249          (must satisfy 8n+1)
fps         25
resolution  512 x 512
steps       3
cfg         1.0
sampler     euler
sigmas      0.909375, 0.725, 0.421875, 0.0

The 8n+1 constraint is the one that will bite you first. LTX rejects 250 frames. 249 is the legal neighbour, and it lands at 9.96 seconds rather than a round ten. Enter the sigmas manually; three steps with an automatic schedule is not the same thing.

5. Queue it and expect roughly 400 seconds on a 3090. Slower card, longer wait, same memory behaviour, which is the part that decides whether it runs at all.

On whether this is worth it against just paying. fal's published rates for the LTX 2.5 Fast endpoints are $0.09/s at 720p and $0.13/s at 1080p, with native audio included, so a ten-second 1080p clip is about $1.30 and arrives in well under a minute. Local costs you nothing per clip and takes seven minutes at a quarter of that resolution. If you are generating a handful of finals, pay. If you are burning fifty variations to find a shot, or working offline, or feeding a LoRA experiment, the arithmetic flips fast. Be honest with yourself about which one you are actually doing.

On the license, because it is not the usual one. LTX 2.5 ships under the LTX-2.x Community License, not an OSI-approved open-source license. fal's own summary of it says commercial use is permitted, that organisations with annual revenue of at least $10 million need a paid license from Lightricks first, and that the agreement carries use restrictions including not training competing models. The license text shipped with the quantized weights is broader than that summary: Attachment A restricts using the model or its outputs to commercially train other machine learning models, not only competing ones, which is a live question if you were planning to distill it or generate a training set with it. The derivative is distributed under those same terms, with the full agreement and a statement of changes beside the weights as Section 3.3 requires. Read it before you build a business on it, and treat that paragraph as a pointer, not legal advice.

Honest limitations

The measurement is one prompt, one seed, 512×512, 25 fps, three steps, one RTX 3090. Three arms, not a sweep. Everything above is a well-controlled single comparison, and single comparisons have been wrong before on exactly this bench: the same author published a timing result in August, re-measured it over three seeds two weeks later, and watched the sign invert.

MAE and PSNR are pixel metrics. They say this build lands further from the reference. They do not say a viewer prefers the reference, and no perceptual metric was run. Judge the contact sheet yourself before you decide the drift matters.

The audio branch was never decoded. LTX 2.5 generates audio alongside video and the graph concatenates both latents; only the video half was decoded in this measurement. Nothing on the card describes what four-bit weights do to the sound. If audio is why you picked LTX in the first place, you are in unmeasured territory.

There is no per-layer error analysis for this checkpoint. The bench's other builds carry a calibration record with an err_w4a8 distribution you can compare against a known breaking threshold; this one predates that record and its sidecar has no source identity hash. So the usual "check before you convert" test does not apply here, and you are trusting a render rather than a statistic.

And 512×512 is not a finishing resolution. Nothing in this measurement tells you how the build behaves at 1080p, where the latent is four times larger and residency stops being free.

What I would watch next

The thing I keep turning over is the metric switch. On this same bench, image models get judged by latent divergence, the distance between the quantized model's latent and the reference's. For this video build the author reached for MAE and PSNR instead, and a companion release the same weekend showed why that was the right instinct: a Wan 2.2 build scoring a comfortable 0.3847 divergence turned out to be the blurry one, because blur is a small latent change. Softening moves you less far from the reference than staying sharp and landing somewhere slightly different does. The metric rewards mush, and says nothing while it does it.

Which suggests the useful question for anyone shipping quantized creative models is not "how small did you get it" but "what did you measure it with, and does that measurement punish the failure mode your format actually has." Pixel metrics catch blur. Divergence does not. Neither catches a plausible, well-composed, wrong picture.

If you run this build at 1080p, or decode the audio branch, I would like to know what came out. Those are the two holes in the map, and they are the kind that only get filled by somebody having a Sunday afternoon and a spare card.

Medium metadata

Suggested kicker: Local video generation

Primary sources: