LTX-2.5 on RTX 3090: 22B audio-video on Ampere via the official ComfyUI INT8 checkpoint

What You'll Build

Generate short clips with synchronised video and audio from LTX-2.5 — Lightricks' 22B-parameter audio-video DiT — on a 24 GB RTX 3090. The route this recipe takes is ComfyUI driving one of the vendor's official INT8 checkpoints, ltx-2.5-22b-distilled-transformer-comfy-int8-convrot.safetensors. Of the five first-party transformer files, the two bf16 builds are far too large for this card, the nvfp4 build is Blackwell-only, and the two INT8 builds — one for dev, one for distilled, byte-identical at 21,504,034,224 bytes each — are what is left. Either INT8 file fits identically; this recipe leads with distilled for speed, and the dev swap is a one-word change (see Results).

This is not an idiosyncratic choice. ComfyUI's own built-in LTX-2.5 template (video_ltx2_5_i2v.json) points its download URLs at exactly this pair — the distilled INT8 transformer and the INT8 text encoder — on hardware far above a 3090. On a 24 GB card it is the only option; upstream it is simply the default.

Hardware data: RTX 3090 (24GB VRAM, Ampere GA102, sm_86) · official INT8 distilled transformer at 20.027 GiB · See benchmark data

⚠️ This model was published days ago and /check/ltx-2-5/rtx-3090 currently returns verdict: unknown with zero benchmarks. Nothing below is a measurement made by this site. Every capacity figure is a byte count from the Hugging Face tree API with the arithmetic shown; the one timing figure is a single community report, attributed inline. If you run this pair, please contribute your numbers.

⚠️ Ampere cannot use two of the four official low-memory paths, and can use the other two. The distinction matters more here than on any other 24 GB card, so it is worth stating precisely.

• NVFP4 is out. The vendor's own optimization table says the NVFP4 policies "Requires Blackwell (SM ≥ 10)" (optimization.md). GA102 is sm_86. Independently, three separate ComfyUI users report the official ltx-2.5-22b-distilled-transformer-nvfp4.safetensors failing outright even on Blackwell hardware — see Troubleshooting.
• fp8-scaled-mm is out. It routes through torch._scaled_mm, and the LTX-2 README directs it at "On Hopper+ GPUs with native FP8 support, use --quantization fp8-scaled-mm for FP8 scaled matrix multiplication."
• fp8-cast is IN, and the flag name is misleading. installation.md says it "downcasts a bf16 checkpoint on the fly (any FP8-capable GPU)", which reads like a hardware gate. The source says otherwise: in fp8_cast.py the whole mechanism is Fp8CastLinear.forward, which upcasts the stored FP8 weight back to the input dtype and calls plain torch.nn.functional.linear. There is no torch._scaled_mm anywhere in that file. FP8 here is a storage format, not a compute path, so it needs no FP8 tensor cores. See the CLI section below.
• INT8 is IN, and it is the lead. GA102 has INT8 tensor cores, and the official *-comfy-int8-convrot checkpoints are ComfyUI-loadable today.

Variant pin. This recipe targets LTX-2.5, canonical repo Lightricks/LTX-2.5, which is a different and non-interchangeable file set from LTX-2.3. LTX-2.5 changed the text encoder from Gemma 3 to Gemma 4 and split the monolithic checkpoint into one file per component, so no VRAM figure from an LTX-2.3 recipe transfers. One deliberate exception is called out in step 4: the ComfyUI two-stage workflow really does load an LTX-2.3 upscaler.

ℹ️ Gated weights. Lightricks/LTX-2.5 carries gated: "auto" on the Hugging Face API, so anonymous downloads return 401/403. Accept the licence on the model page and run hf auth login with a Read token before the download step. The weights are under the LTX-2 Community License, not Apache-2.0.

Requirements

Why 24 GB is the floor, in bytes

The vendor's ComfyUI node repo still states the native requirement as "CUDA-compatible GPU with 32GB+ VRAM" (ComfyUI-LTXVideo README), and the bf16 file sizes say why: the bf16 transformer is 42.018 GB (39.132 GiB) and the bf16 Gemma 4 12B text encoder is 26.264 GB (24.460 GiB) — the encoder alone exceeds a 24 GiB 3090. The INT8 pair is what changes the answer:

Weights resident during sampling — transformer plus both VAEs — sum to 21,504,034,224 + 1,452,269,922 + 364,866,540 = 23,321,170,686 bytes, which is 21.72 GiB of the card's 24 GiB, leaving 2.28 GiB for activations, latents and the CUDA context. That margin is small, and it is the reason the decode-tiling advice in Troubleshooting is not optional.

The text encoder is excluded from that sum on purpose. At 14.317 GiB it would put the pair at 34.344 GiB, which does not fit anything with 24 GiB. ComfyUI encodes the prompt as its own stage and evicts the encoder before sampling, so the two are sequential, not simultaneous — which is also why the 64 GB system-RAM recommendation is real rather than decorative.

Installation

Every command block below is anchored to $COMFY. Set it once, in the shell you are going to use, and the blocks become order-independent and safe to copy-paste — no block depends on where a previous block left you. This matters more than it looks: the download steps write into ComfyUI's model directories, and a relative path evaluated from the wrong directory produces a tree that looks plausible, scans as empty, and gives you no error until a loader dropdown comes up blank.

1. Install ComfyUI

export COMFY="$HOME/ComfyUI"        # anywhere you like; every later block reads this

git clone https://github.com/comfyanonymous/ComfyUI "$COMFY"
cd "$COMFY"
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

On Ampere sm_86 the stock pip install torch wheel already carries sm_86 kernels — unlike Blackwell sm_120, no special --index-url is needed. On Python versions, two numbers circulate and they mean different things: the floor is 3.10 — both packages/ltx-core/pyproject.toml and packages/ltx-pipelines/pyproject.toml declare requires-python = ">=3.10" — while 3.12 is the model card's recommendation, alongside CUDA 12.7+ and PyTorch ~= 2.7. Install 3.12 if you are starting fresh; do not treat 3.10 or 3.11 as unsupported. ComfyUI's own requirements are looser still. The one version datapoint in the wild is from discussion #16, where a user reports the INT8 checkpoint loading on ComfyUI 0.32.0 — which is also comfyui_version.py on master today. The 3090 report cited under Results names no version.

2. Install the Lightricks ComfyUI nodes

cd "$COMFY/custom_nodes"
git clone https://github.com/Lightricks/ComfyUI-LTXVideo.git
pip install -r ComfyUI-LTXVideo/requirements.txt

This is what supplies the LTX-2.5 example workflows. As of the 2026-08-11 update the repository ships nine of them under example_workflows/2.5/, including LTX-2.5_T2V_I2V_Single_Stage_Distilled.json and LTX-2.5_T2V_I2V_Two_Stage_Distilled.json. Note that the repo's README has not been updated to list them — it still stops at the LTX-2.3 set — so browse the folder rather than the README.

3. Authenticate and download the checkpoints

pip install -U "huggingface_hub[cli]"
hf auth login          # accept the LTX-2.5 licence on the model page first

hf download Lightricks/LTX-2.5 \
    diffusion_models/ltx-2.5-22b-distilled-transformer-comfy-int8-convrot.safetensors \
    text_encoders/gemma4-12b-with-proj-ltx-2.5-comfy-int8-convrot.safetensors \
    vae/ltx-2.5-video-vae-conv-bf16.safetensors \
    vae/ltx-2.5-audio-vae-bf16.safetensors \
    --local-dir "$COMFY/models"

The workflow also wires up a second, separate Gemma model as a prompt enhancer, which lives in a different repository and is easy to miss:

# Prompt enhancer — a DIFFERENT repo, and not gated
hf download Comfy-Org/gemma-4 text_encoders/gemma4_e2b_it_bf16.safetensors \
    --local-dir "$COMFY/models"

--local-dir "$COMFY/models" is deliberate in both blocks: hf download keeps the repository's folder layout under the local dir, and the prefixes in these repos (diffusion_models/, text_encoders/, vae/) are already the directory names ComfyUI scans — so the five files land where ComfyUI will find them with no moving afterwards. The upscaler in step 4 is the exception and needs a fuller path, because it sits at the root of the LTX-2.3 repo with no prefix of its own.

Two deliberate substitutions against the vendor's own Quick Start, both driven by the 24 GB budget:

• INT8 instead of bf16, for both the transformer and the encoder. The vendor's workflow notes list only the bf16 files, and the bf16 encoder does not fit this card.
• The convolutional video VAE, not the diffusion one. The workflow's own model-links note describes ltx-2.5-video-vae-conv-bf16.safetensors as "Lower memory & faster", against the diffusion decoder's better quality. On a card with 2.28 GiB of headroom, take the lighter decoder.

The enhancer is required by default, not optional — and here is how to turn it off if you want the 10.279 GB back. gemma4_e2b_it_bf16.safetensors is 10,278,774,160 bytes (10.279 GB, 9.573 GiB), and it is a genuine addition: a second language model, unrelated to the INT8 text encoder that actually conditions the diffusion. Prompt enhancement ships ON in every LTX-2.5 workflow checked, in both families. In the Lightricks pack, the Input Parameters subgraph exposes enhancement as its cond boolean input; at the instantiating node (id 5014) that input is unlinked, so its widget value governs, and the value is true in the single-stage and two-stage workflows alike. ComfyUI's built-in video_ltx2_5_i2v template reaches the same default through a PrimitiveBoolean titled Boolean (Enable Prompt Enhance) set to True. The pack's own Model Links note lists the Text Enhancer among the required downloads, which is the same conclusion from the documentation side. So budget for the file: without it the shipped graph will fail on a missing model.

The workflow's Inputs note does open "Everything here is optional.", and that is a statement about the inputs — the prompt, the image, the duration — not about whether the enhancer loads.

To turn it off and reclaim the space: set the cond widget on the Input Parameters node to false, then bypass Load CLIP - Text Enhancer in Load Models and both TextGenerateLTX2Prompt nodes in Input Parameters (Positive prompt (t2v) enhancer and Positive prompt + image enhancer). Write your own detailed prompts instead — the prompting guidance further down is written for exactly that. There is also a third route the same note describes: supplying an LTX API key enhances remotely, "which saves memory", but that is not a local path and is out of scope here.

4. Place the files, and read the upscaler line carefully

$COMFY/models/
├── diffusion_models/ltx-2.5-22b-distilled-transformer-comfy-int8-convrot.safetensors
├── text_encoders/gemma4-12b-with-proj-ltx-2.5-comfy-int8-convrot.safetensors
├── text_encoders/gemma4_e2b_it_bf16.safetensors                        # prompt enhancer
├── vae/ltx-2.5-video-vae-conv-bf16.safetensors
├── vae/ltx-2.5-audio-vae-bf16.safetensors
└── latent_upscale_models/ltx-2.3-spatial-upscaler-x2-1.1.safetensors   # two-stage only

Both Gemma files go in text_encoders/, which is what the workflow's own model-storage note shows — they are different models doing different jobs, not alternatives.

The single-stage workflow needs no upscaler; skip that last file if you only run single-stage. If you do run the two-stage workflow, the file it wants is ltx-2.3-spatial-upscaler-x2-1.1.safetensors from the LTX-2.3 repository — its LatentUpscaleModelLoader widget carries exactly that filename, its "Model Links" note links it to the LTX-2.3 repo, and its model-storage tree repeats it. The LTX-2.3 repo is not gated.

⚠️ Two workflow families ship LTX-2.5 templates, and they want different upscalers. Check which one you opened. This recipe documents the Lightricks ComfyUI-LTXVideo example workflows — the files under custom_nodes/ComfyUI-LTXVideo/example_workflows/2.5/ — and those load the 2.3 upscaler. ComfyUI's own built-in templates, the ones reachable from the Workflow → Browse Templates menu without installing anything, are maintained separately by Comfy-Org in workflow_templates and reference the 2.5 file, ltx-2.5-latent-spatial-upscaler-x2-bf16-1.0.safetensors. Both are real and each is correct for its own graph. (One more difference worth knowing if you switch: it loads the diffusion video VAE rather than the lighter conv one this recipe picks. Prompt enhancement is not a difference — both families ship it on.) They are also genuinely different files — 995,743,560 bytes for the 2.3 against 995,778,752 for the 2.5 — so they are not interchangeable by luck. If your upscaler node shows a filename that does not match the one you downloaded, you are in the other family; download that family's file rather than repointing the node.

# ONLY for the two-stage ComfyUI workflow — note: LTX-2.3 repo, not 2.5
hf download Lightricks/LTX-2.3 ltx-2.3-spatial-upscaler-x2-1.1.safetensors \
    --local-dir "$COMFY/models/latent_upscale_models"

Running

Start ComfyUI, then load custom_nodes/ComfyUI-LTXVideo/example_workflows/2.5/LTX-2.5_T2V_I2V_Single_Stage_Distilled.json:

cd "$COMFY"
source .venv/bin/activate
python main.py --listen 127.0.0.1

⚠️ Set all five loaders explicitly. The saved widget values in this workflow are not a usable starting point. Open the Load Models subgraph and you will find five loader nodes, every one of them active (mode=0), whose serialized defaults are partly wrong: the node titled Load VAE - Video carries the audio VAE filename, and both CLIPLoader nodes carry ViT-B-32.pt — a CLIP model that is neither of the two Gemma files this model uses. The UNETLoader carries ltx-2.5-22b-dev-transformer-bf16.safetensors, the 42.018 GB bf16 file, despite the workflow being named ...Distilled. None of that means you installed anything wrong; it means the defaults were saved in a state that does not match the workflow's own documentation. The authoritative list is the workflow's Model Links MarkdownNote, which is correct and is the thing to follow.

Set each loader by hand:

The two-stage workflow has the same five plus a LatentUpscaleModelLoader, making six.

Pointing UNETLoader at the INT8 file is a plain filename swap, not a node change: it is a ComfyUI core node and the convrot format is handled in core, so the INT8 checkpoint runs on the same code path the template already uses for bf16.

Then keep two constraints in mind — both are enforced by the model, not by preference:

• Frame count. The workflow's own note states "The frame count has to be 1 + a multiple of 8". The CLI expresses the same rule as num_frames = 8 * k + 1, which is why the vendor's example uses --num-frames 121.
• Resolution. Keep width and height multiples of 32. That is the model's spatial grid, and it is what the --height / --width help text in args.py states. The CLI section below is stricter — 64, not 32 — because the pipeline it runs is internally two-stage; if you go that route, read the note beside the command.

Start at 5 seconds and a modest resolution. The distilled model runs 8 sampling steps, and output lands in $COMFY/output/.

Optional: the ltx-pipelines CLI on Ampere

The vendor CLI also runs on this card, and it is worth knowing why, because the flag names suggest it does not. --quantization fp8-cast is storage-only quantization: Fp8CastLinear.forward upcasts each stored FP8 weight back to the activation dtype and calls torch.nn.functional.linear, so no FP8 GEMM is ever issued and no FP8 tensor cores are needed. The README's own guidance is consistent with that reading — "Fp8-cast should be used with bf16 checkpoints, it shall downcast them on the fly." Paired with --offload cpu — which installation.md glosses as holding the weights in system RAM, and which the CLI's own --offload help text in args.py describes more precisely as pinning them in CPU RAM and streaming them to the GPU per layer — this is the vendor's documented low-memory route:

This is a second codebase, not something the ComfyUI install above provides. Clone it and let uv build its environment, keeping it outside the $COMFY tree:

export LTX="$HOME/LTX-2"        # keep this outside the $COMFY tree
git clone https://github.com/Lightricks/LTX-2.git "$LTX"
cd "$LTX"
uv sync

Plain uv sync is enough here. The README's uv sync --extra natten buys a faster neighbourhood-attention backend for the diffusion video VAE, and this command runs the convolutional one — the decoder kind is chosen from the VAE file's own metadata, so with ltx-2.5-video-vae-conv-bf16.safetensors the extra is never exercised.

cd "$LTX"
PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True uv run python -m ltx_pipelines.distilled \
    --transformer-path       "$COMFY/models/diffusion_models/ltx-2.5-22b-distilled-transformer-bf16.safetensors" \
    --text-encoder-path      "$COMFY/models/text_encoders/gemma4-12b-with-proj-ltx-2.5-bf16.safetensors" \
    --video-vae-path         "$COMFY/models/vae/ltx-2.5-video-vae-conv-bf16.safetensors" \
    --audio-vae-path         "$COMFY/models/vae/ltx-2.5-audio-vae-bf16.safetensors" \
    --spatial-upsampler-path "$COMFY/models/latent_upscale_models/ltx-2.5-latent-spatial-upscaler-x2-bf16-1.0.safetensors" \
    --quantization fp8-cast --offload cpu \
    --num-frames 121 --seed 42 \
    --output-path output.mp4 \
    --prompt "A medium close-up of a woman in a workshop, speaking directly to camera, warm afternoon light, static shot"

⚠️ Resolution here must be divisible by 64, not 32. The command above passes no --width / --height, so it runs as printed — but the moment you add them, DistilledPipeline calls assert_resolution(..., is_two_stage=True), and utils/helpers.py sets divisor = 64 if is_two_stage else 32 with the docstring "For two-stage pipelines, the resolution must be divisible by 64." The name is misleading: distilled is a two-stage pipeline internally — it generates at half resolution and upsamples — so the stricter rule applies even though nothing in the command says "two-stage". A value like 1376×768 satisfies the /32 rule quoted in the ComfyUI section above and raises ValueError here. The frame-count rule is unchanged at 8 * k + 1.

This block reuses $COMFY so both paths share one model tree, but note that three of its five files are not the ones step 3 downloaded: the CLI runs bf16 weights, so the bf16 transformer, the bf16 text encoder and the 2.5 spatial upscaler are a separate hf download Lightricks/LTX-2.5 … --local-dir "$COMFY/models" before this command will run. The two VAEs carry over unchanged.

Three things make this the secondary path rather than the lead on a 3090. It needs the 42.018 GB bf16 transformer and the 26.264 GB bf16 encoder on disk — 71.095 GB for the full CLI set, against 48.973 GB for the ComfyUI set. It leans hard on host RAM and swap. And it carries an open Ampere defect described in Troubleshooting. The INT8 route asks less of the machine on every axis except output quality.

The *-comfy-int8-convrot checkpoints cannot be substituted into this command: QuantizationKind in quantization_factory.py defines exactly four backends — fp8-cast, fp8-scaled-mm, nvfp4-cast, nvfp4-prequant — and there is no INT8 policy anywhere in ltx-core. Those files are for ComfyUI, which is what the comfy in their filename says.

Results

• Speed: no first-party figure exists for this pair. One community report, from a user with matching hardware, describes the ComfyUI image-to-video route as "works great and fast for 5sec vids (like 2mn30 or so without Sage Attention), I have a 3090, 128Gb RAM" (Lightricks/LTX-2.5 discussion #15, 2026-08-12, community member, not a Lightricks employee). Treat it as a single data point, not a benchmark: the reporter does not state which transformer checkpoint, resolution or step count produced it. Measured numbers for this pair would be genuinely new — please contribute one.
• VRAM usage: not measured. The derived weight residency during sampling is 21.72 GiB of 24 GiB, from the byte counts tabulated above. Live data, when it exists, appears at /check/ltx-2-5/rtx-3090.
• Quality notes: this recipe leads with the distilled transformer, and that is a speed choice, not a fit choice. dev and distilled are symmetrical in every respect that matters to a 24 GB card: both bf16 files are 42,018,190,584 bytes, and both have an official INT8 build, byte-identical at 21,504,034,224 bytes each. So if you want the full model's quality, swap distilled for dev in the download command and in the UNETLoader widget — the memory budget above does not move by a single byte. What you give up is step count: the distilled model runs the 8-step schedule the shipped workflows are built around, and dev does not. The asymmetry in the file list is elsewhere — nvfp4 is distilled-only, and it is Blackwell-only besides, so it is irrelevant here either way. Separately, INT8 is a real quality trade against bf16; if your 3090 is paired with a lot of system RAM and you care more about fidelity than wall-clock, the fp8-cast --offload cpu CLI route above runs the bf16 weights instead.

For the full benchmark data, see /check/ltx-2-5/rtx-3090.

Troubleshooting

Decoding hangs forever on longer clips

Reported on this exact card. A 3090 owner who gets clean 5-second clips describes 10-second generation at medium resolution getting "stuck forever in the decoding phase just before the video appears", with the console otherwise identical to a successful run (discussion #15). The reply that resolved it: "Go into the subgraph and change the VAE Decode (Tiled) node's tile size from 768 to 512." Both speakers are community members.

This is the 2.28 GiB of headroom asserting itself, and the vendor anticipated it — the workflow's Decode note reads "Make sure to adjust the number of tiles and overlap to fit your hardware." and publishes a settings ladder whose smallest rung is exactly 512 / 64 / 128 / 32. On a 24 GB card, start at 512 and only move up if a run completes with room to spare.

The official NVFP4 checkpoint fails

Do not download ltx-2.5-22b-distilled-transformer-nvfp4.safetensors for this card. Beyond the vendor's own SM ≥ 10 requirement, it is failing in practice: a user reports RuntimeError: mat1 and mat2 shapes cannot be multiplied (3520x4096 and 2048x4096) on ComfyUI 0.32.0 with an RTX 5090, and two further users confirm the same failure (discussion #16). The same reporter notes that "The official ltx-2.5-22b-distilled-transformer-comfy-int8-convrot.safetensors" — the file this recipe uses — "checkpoint works with the same template."

--quantization fp8-cast crashes when a LoRA is fused, on Ampere only

This one is specific to sm_86 and is still open upstream. Fusing a LoRA into fp8-cast weights routes through a Triton kernel that casts to float8_e4m3fn; Triton supports that dtype only from Ada sm_89 onward, so on a 3090 it raises "type fp8e4nv not supported in this architecture." A deterministic bf16 fallback already exists in fuse_cast_fp8_weight, but the gate in front of it tests only whether Triton is installed, not whether the GPU can compile the kernel — so the fallback is unreachable. PR #253 documents the failure and proposes the capability check; it is a community contribution, unmerged as of 2026-08-12, and the bare TRITON_AVAILABLE gate is still what fp8_cast.py ships on main.

The practical consequence is a routing rule, not a blocker. Plain inference never touches that kernel — the inference path passes with_stochastic_rounding=False and takes a straight weight.to(dtype) upcast. So on Ampere, run ltx_pipelines.distilled against the distilled transformer, which needs no LoRA fusion, and avoid the two-stage pipelines that fuse the distilled LoRA into fp8-cast weights. The same PR's author reports doing precisely this on "RTX 3090 (sm_86), WSL2, 31 GiB RAM + 71 GiB swap" with --offload cpu and --quantization fp8-cast: on the distilled pipeline, "shots render end-to-end" — while the LoRA-fusing path needed the patch.

Scope note on the two PR-sourced entries. PR #253 was filed on 2026-07-11, a month before LTX-2.5 shipped, and its author was running the previous generation's monolithic checkpoint — his figure is a 46 GB file, not LTX-2.5's 42.018 GB transformer. It is cited here for the code path, not for a 2.5 measurement, and the code path is the same one today: fuse_cast_fp8_weight still gates on bare TRITON_AVAILABLE and _read_scales still opens the checkpoint with safetensors.safe_open, both on main as of 2026-08-12. The Ampere behaviour follows from the compute capability, which has not changed.

Cannot allocate memory (12) before anything loads

Same PR, same card, and worth knowing before you spend an hour on it. --quantization fp8-cast calls _read_scales, which opens the whole checkpoint with safetensors.safe_open purely to enumerate key names — a 42.018 GB file needs a mapping that large, and on hosts where RAM plus swap is smaller than the checkpoint the call fails during argument parsing, before a single weight is read. A bf16 checkpoint has no *_scale tensors, so the mapping buys nothing. Reported on WSL2; add swap, or use the ComfyUI INT8 route, which never runs this code.

There is no working GGUF path yet

If you came here expecting the GGUF route our LTX-2.3 recipes use, it is not available for LTX-2.5 as of 2026-08-12. QuantStack/LTX-2.5-GGUF, the account that published the LTX-2.3 GGUFs, holds only a .gitattributes file. Two GGUF sets do exist under Abiray, uploaded within the last day; both have zero downloads, the dev-transformer repo's entire README body reads "Currently testing", and the distilled repo's card does not claim its files work — it asks the reader to "Ensure your inference engine (such as llama.cpp or compatible ComfyUI GGUF loader nodes) supports the LTX-2.5 DiT architecture." On the other side, the ComfyUI-GGUF README lists no LTX model among its supported pre-quantized sets. Nobody on either side of that handshake asserts it closes. Use the official INT8 checkpoint until that changes.