Engineering notes
We ran an open video model on our own GPUs for a day.
Here is everything it costs and everything it cannot do.
LTX 2.5 is a 22-billion-parameter open-weights video model. We put it on a two-card workstation, measured every stage, and wrote down the results — including the several things we got wrong. No vendor benchmarks, no estimates. Every number below came off our own hardware on 1–2 September 2026.
The short version
10 seconds of video with synchronised audio, in about four minutes
On a single card, at 768×512. The audio is not dubbed on afterwards — video and sound are sampled as one latent, so they line up by construction. Our 2048×1152 clips were generated separately, without sound.
A missing pipeline stage cost us a day
The model samples twice, with an upscaler between the passes. We built a one-pass version. Soft output and frame-to-frame wobble were the same bug wearing two hats.
The bigger model was worse
We downloaded 92 GB of larger and higher-precision weights. They did not improve the output. The 17.4 GB four-bit checkpoint is still the one we use.
What it costs, measured
| Task | Time | Notes |
|---|---|---|
| First run of the day | 237.7 s | 231 s of that is loading ~34 GB of weights |
| Same clip once warm | 6.1 s | Quoting the cold number overstates cost 39× |
| 4 s clip, video + audio | 30 s | Audio adds almost nothing |
| 10 s clip, video + audio | ~240 s | 768×512, single card |
| 10 s clip at 2048×1152 | ~250 s | Two-pass, upscaled, no audio |
| Six 10 s clips → a 58.5 s film | 26.2 min | One card; a second card roughly halves it |
Hardware: one workstation, 2× NVIDIA RTX 5090 (32 GB each), ComfyUI 0.34.0, Windows. Only one card is used per generation — the runtime cannot split a single model across two GPUs, so the second card buys throughput, not capacity.
The single biggest win: tile the decode
Turning 97 frames of latent back into 1920×1088 pixels is where the time goes, not the diffusion. The 20 denoising steps take 9 seconds. Everything after that was the decode — and it was thrashing, not computing.
| Decoding 97 frames at 1920×1088 | Wall clock | Peak VRAM |
|---|---|---|
| Standard full-frame decode | 771 s | 32,046 MiB of 32,607 |
| Tiled decode | 40 s | 3,374 MiB |
19× faster on one tenth of the memory, for pixel-identical output. We verified that rather than assuming it: differencing the two videos frame by frame and pushing contrast eight stops gives a pure black image. No seams, no loss.
The tell for thrashing, worth remembering on any model: peak VRAM pinned one step below the card's limit while throughput collapses.
Which checkpoint wins
One prompt, five combinations of transformer and text encoder, same seed, same two-pass pipeline. We tested this because the assumption — bigger and higher-precision is better — is worth checking before it becomes a purchasing decision.
| Transformer | Text encoder | Wall | Peak VRAM | Result |
|---|---|---|---|---|
| distilled 4-bit (17.4 GB) | int8 | 203 s | 31.8 GB | Recommended |
| dev int8 (20.0 GB) | int8 | 234 s | 29.1 GB | Clearly worst — distorted, noisy |
| distilled bf16 (39.1 GB) | int8 | 300 s | 31.1 GB | No visible gain |
| distilled bf16 | bf16 (24.5 GB) | 213 s | 31.8 GB | No visible gain |
| distilled 4-bit | bf16 | 66 s | 27.6 GB | No visible gain |
The honest reading is narrower than we would like. The non-distilled “dev” model lost twice on two different subjects — that result is solid. Among the other four we could not separate quality: the same seed produces different compositions on different checkpoints, so apparent differences may be luck of the draw rather than fidelity. Settling that properly needs several seeds per combination.
What we can say: 92 GB of larger weights bought a negative result — two upgrade paths that looked obvious on paper and deliver nothing. That is worth knowing before building a workflow on either.
Audio works, and it is nearly free
The model generates sound natively. Video and audio are concatenated into a single latent and sampled together, then separated and decoded — so synchronisation is structural rather than something you fix in post.
| Clip | Generation | Audio | Level |
|---|---|---|---|
| 4 s, rain on stone | 30 s | FLAC 48 kHz stereo | mean −30.9 dB |
| 10 s, rain in a forest | ~240 s | FLAC 48 kHz stereo | mean −22.8 dB, peak −9.7 dB |
Audio level held flat across the whole ten seconds — −22.4, −23.0, −23.4, −22.7, −22.5 dB in successive two-second windows. It does not fade or drift.
The ceiling is 10 seconds per clip on this hardware. A 20-second attempt (481 frames) failed with a CUDA error during the decode. Longer pieces are assembled from 10-second shots, not generated in one pass.
What it does well, and what it does not
Production-ready today
3D product visualisation, motion graphics, isometric illustration, macro product photography, data-centre environments, abstract motion. Four stylised prompts at 2048×1152 worked on the first attempt.
Not there
Close-up talking humans. Skin, eyes and the mechanics of speech are where open video models still fail. Higher precision and higher resolution sharpen texture; they do not cross the uncanny valley.
The most useful thing we learned all day was about the brief, not the model. When a diffusion model attempts photorealism and falls short, the viewer has a lifetime of reference footage to compare against and it reads as broken. Ask it for a rendered look and there is nothing to fail against — the identical fidelity now reads as intentional. Two changes, a higher base resolution and prompts that name a render style, took the output from “looks like AI” to genuinely sharp. Nothing was bought.
For work that needs a person on screen, the practical answer is a hybrid: film or licence the presenter, generate the B-roll. B-roll is the highest-volume layer and the one you would otherwise pay per clip for.
Watch the tests
Every clip below was generated on the hardware described above. Nothing is a vendor demo. Sound on for the first two.
The finished film
The same prompt on five model configurations
Same seed, same pipeline. Only the transformer and text encoder change.
What it is good at
And what it is not
New: what the bigger model actually costs
The five-way test above says the higher-precision weights show no visible gain. Timing them puts a number on what they cost — and the number depends entirely on how you measure, which is worth showing rather than hiding.
We first timed one scene per configuration, each with the model loading cold. Then we rendered twelve scenes per configuration, where the model is already resident:
| Configuration | 1 scene, cold | 12 scenes, warm | Real cost vs 4-bit |
|---|---|---|---|
| distilled 4-bit + int8 encoder | 232.3 s | 245.4 s | baseline |
| distilled 4-bit + bf16 encoder | 408.5 s | 277.5 s | 1.13× slower |
| distilled bf16 + int8 encoder | 584.8 s | 375.1 s | 1.53× slower |
| distilled bf16 + bf16 encoder | 584.8 s | 474.8 s | 1.93× slower |
We published the cold numbers first, and they were wrong by up to 1.6×. A single cold scene charges the whole 39.1 GB model load to one clip. Across twelve scenes that cost amortises, and the honest steady-state penalty for the bigger weights is 1.5× to 1.9×, not 2.5×. We have corrected it here rather than quietly swapping the figure.
The conclusion survives the correction, and is the one worth acting on: the 39.1 GB model does not fit a 32 GB card, runs on the runtime's offload path, and is half again to twice as slow for output we cannot tell apart.
If you generate one clip at a time rather than in batches, the cold numbers are the ones you will actually feel — which is why both columns are here. Measure the workload you have, not the one that flatters the hardware.
What a film costs in GPU time
| Output | GPU time | At $0.76/card-hour | At $1.50/card-hour |
|---|---|---|---|
| One 10s clip with audio | 0.06 card-hours | $0.05 | $0.10 |
| A 2-minute story, 12 scenes | 0.77 card-hours | $0.59 | $1.16 |
| A 5-minute film, 30 scenes | 6.8 card-hours | $5.14 | $10.15 |
No per-clip fee, no per-character fee for the narration, no subscription. Every model in the chain is Apache-2.0 or MIT, so the output is yours to monetise. The only variable is how long the card is switched on.
New: it makes sound, but it does not speak
The model generates its own audio, and video and sound are sampled as a single latent — so they are synchronised by construction rather than dubbed afterwards. But it produces ambience: birdsong, rain, rustling leaves. It does not talk.
Narration is a second local model. We use Kokoro-82M, Apache-2.0, 360 MB, which produced 30 narration tracks in 3.5 seconds — 51× realtime. Speech is free next to video.
Two of the most popular open voice models are unusable commercially: F5-TTS is CC-BY-NC and XTTS-v2 is CPML. Checking the licence first cost one API call and saved a 7 GB download that could never have shipped. Read the licence before the benchmark.
Other measured limits: a clip caps at 10 seconds — a 20-second attempt crashed the decode — and generated audio gets quieter as resolution rises, from −22.8 dB at 768×512 to −41.8 dB at 2048×1152, so it needs normalising before it sits under speech.
The same film, four times, on four model configurations
The clip-level tests said the configurations were indistinguishable. That is easy to claim on a four-second clip, so we rendered a complete two-minute story four times — identical prompts, identical seeds, identical narration and mix. The only variable is the model.
They are equally good. The compositions differ — A and D frame the fox closer, B and C wider — because a different transformer follows a different sampling path from the same seed. But there is no quality gap. Nothing in the higher-precision versions is sharper, cleaner or more coherent.
Forty-eight clips, about three hours of GPU time, roughly $4.59 of compute at $0.76 per card-hour. The finding is worth more than the three hours: the smallest, fastest, cheapest configuration is the one to use, and the 92 GB of larger weights we downloaded to test this buys nothing at all.
Watch any two of them for thirty seconds and try to tell which is which. We cannot, and we knew which was which while cutting them.
Why we published this
Most model comparisons quote the vendor. We rent GPUs, so the only numbers worth anything to us are the ones our own hardware produces — including the unflattering ones. Four of the findings above are corrections to things we initially got wrong, and they are the most useful part of the page.
If you are sizing hardware for video generation, the summary is: a single 32 GB card generates a 22B model's video with audio at roughly 24× slower than realtime, the decode strategy matters more than the checkpoint, and the largest weights are not the best ones.