Untested: the LTX-2.5 family decodes with the conv VAE and never uses LTX2VideoDiffusionDecodePipeline

[dkackman]

tool/endpoint: templates/ltx2/two-stage (and the rest of the family) — video decode path

repro: get_workflow(name="templates/ltx2/two-stage") builds on LTX2Pipeline and
LTX2LatentUpsamplePipeline. Grepping the family turns up no reference anywhere to
LTX2VideoDiffusionDecodePipeline.

expected/actual: not a bug — an untested option. The Lightricks/LTX-2.5-Diffusers card
lists LTX2VideoDiffusionDecodePipeline as an alternative decoder alongside the convolutional
one, and upstream's own docs treat the diffusion VAE decode as the production path rather than a
niche alternative.

why it is attractive here specifically: it changes only the decode. No sigma schedule, no
resolution, no LoRA, no prompt — which makes it the cheapest thing in this family to A/B, and the
result is directly comparable on the same latents.

Relevant upstream detail for this box: the DiffVAE neighborhood-attention backend ladder puts
NATTEN as "the fastest production path on non-B200 GPUs (Hopper/Ampere/Ada)", and lem is an
RTX 3090 (Ampere, confirmed via get_memory). Their warm-runtime figures show the backend choice
is not a detail: chunked_eager runs roughly 2-2.5x slower than combined_compile.

the honest caveat. Those backend names are ltx_pipelines flags, and dw runs diffusers.
So the upstream numbers do not transfer directly; what transfers is the question — is diffusion
decode worth its cost over conv decode on our clips? This is an experiment to run, not a
settled win, and it should be recorded as a timing comparison either way.

adjacent, unverified: LTX-2 1.3.0 (2026-08-25) added keyframe-aware diffusion-VAE decoding —
"sharpens detail at the frames a generator anchored on", via VideoDecoder.decode_video(..., keyframes=)". That would bear directly on templates/ltx2/keyframes. It is an ltx_pipelines`
API and whether diffusers exposes an equivalent is unconfirmed — worth checking while in
this code.

related: #151, #152. Full LTX-2.5 write-up on #151, including what was ruled out (NVFP4 and
FP8 are both unusable on a 3090; SDNQ uint4 already goes further).

[dkackman]

Built and deployed as templates/ltx2/diffusion-decode (ec36be1). Worked as model opus via provider anthropic.

You framed this as an experiment rather than a fix, so what I shipped is the experiment made runnable — not an adoption, and not a claim about the result.

It is reachable from diffusers, confirmed rather than assumed. LTX2VideoDiffusionDecodePipeline is exported, diffusion_decoder is in Lightricks/LTX-2.5-Diffusers's model_index.json (a LTX2VideoDiffusionDecoderModel beside the conv vae), and its __call__ takes (latents, generator, output_type, return_dict, denormalize). So it is a template, not engine work.

The template is text-to-video, argument for argument, with one thing changed: the generation step stops at output_type: "latent", and a second step decodes. Same prompt, same seed, same eight distilled sigmas, same canvas — the denoise is deterministic, so running this and text-to-video gives two clips comparable frame for frame and minute for minute. That is what makes it an A/B rather than two renders.

denormalize: false, because LTX2Pipeline already applies the latent statistics on its way out of the output_type == "latent" branch. Decoding denormalized latents a second time is the mistake that argument exists to prevent, and the test pins it against the pipeline's own source.

Two limits, both in the description and neither avoidable here:

• It is silent. At output_type: "latent" the soundtrack comes back as audio latents, and this decoder is video-only. The comparison is about the picture. There is no exposed audio-decode path to pair with it.
• The decoder is a second model on top of the 22B transformer, so the generation step carries release_pipeline: true. On a 24 GB card that is not optional.

It has never been run. I have no CUDA here and this is a 22B model, so what I could verify is static and that is what I pinned (tests/test_ltx2_diffusion_decode.py): every argument against the real __call__ signatures, denormalize: false against the branch that denormalizes, previous_result:latents.frames against the output field that carries them, that only the decode differs from the baseline, and that no cost is claimed. The tester's first run is the experiment, and it may well fail on something static checks cannot see — memory at decode being the likeliest.

On your adjacent question — keyframe-aware diffusion-VAE decoding from LTX-2 1.3.0: diffusers exposes no equivalent. LTX2VideoDiffusionDecodePipeline.__call__ takes no keyframes and neither does LTX2VideoDiffusionDecoderModel.decode. That is an ltx_pipelines API and it has not crossed over, so templates/ltx2/keyframes cannot benefit today. Recorded so it is not re-investigated.

Also as expected: the NATTEN/combined_compile backend ladder is ltx_pipelines flags with no diffusers equivalent, so their 2–2.5x figures do not transfer. What transfers is the question, which is now answerable.

Deploy: develop 86207aa, pushed; lem pulled and dw.serve restarted at 14:47 UTC, healthy. POST /api/validate on the new template returns valid: true.

Regression case proposal — hold this one until it has actually run. If the first run works, regression-suite-model-specific.md:

run_workflow("templates/ltx2/diffusion-decode") on defaults, then run_workflow("templates/ltx2/text-to-video") on defaults.

Expected: both complete at the same seed and canvas; record both wall clocks and have the user compare the two clips. The comparison is the result this issue asked for, so it belongs back on this issue whichever way it comes out — including "the diffusion decode is not worth it", which is a perfectly good answer and would make the template a documented negative rather than a mistake.