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 Ti. 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 Ti. On a 24 GB card it is the only option; upstream it is simply the default.
Hardware data: RTX 3090 Ti (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-ticurrently returnsverdict: unknownwith 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 was measured on a different, slower card and is attributed inline as such. If you run this pair, please contribute your numbers.
ℹ️ Why every capacity figure here is decided by the architecture, not by the SKU. The 3090 Ti and the 3090 are the same GA102 silicon at compute capability sm_86 with the same 24 GB of GDDR6X — NVIDIA's own RTX 3090 / 3090 Ti page lists both at 24 GB GDDR6X and both under Ampere. So everything decided by capacity (which checkpoints fit) or by compute capability (which quantization backends the card can run) is the same on both, and this page states those things about the 3090 Ti directly. What differs between the two cards is throughput, and that is handled under Results, where it is the only place it matters.
⚠️ 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.safetensorsfailing outright even on Blackwell hardware — see Troubleshooting.fp8-scaled-mmis out. It routes throughtorch._scaled_mm, and the LTX-2 README directs it at "On Hopper+ GPUs with native FP8 support, use--quantization fp8-scaled-mmfor FP8 scaled matrix multiplication."fp8-castis IN, and the flag name is misleading.installation.mdsays it "downcasts a bf16 checkpoint on the fly (any FP8-capable GPU)", which reads like a hardware gate. The source says otherwise: infp8_cast.pythe whole mechanism isFp8CastLinear.forward, which upcasts the stored FP8 weight back to the input dtype and calls plaintorch.nn.functional.linear. There is notorch._scaled_mmanywhere 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-convrotcheckpoints 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.5carriesgated: "auto"on the Hugging Face API, so anonymous downloads return 401/403. Accept the licence on the model page and runhf auth loginwith a Read token before the download step. The weights are under the LTX-2 Community License, not Apache-2.0.
Requirements
| Component | Minimum | This recipe |
|---|---|---|
| GPU | 24GB VRAM | RTX 3090 Ti (24GB, Ampere GA102, sm_86) — no run measured by this site; the budget below is derived from file byte counts (/contribute) |
| RAM | 32GB | 64GB recommended — the encoder and the transformer are swapped through host RAM, not co-resident |
| Storage | ~50GB | 21.504 GB INT8 transformer + 15.373 GB INT8 encoder + 10.279 GB prompt enhancer + 1.452 GB video VAE + 0.365 GB audio VAE = 48.973 GB; add the 0.996 GB upscaler for two-stage = 49.969 GB (byte counts from the Hugging Face tree API) |
| Software | ComfyUI 0.32.0+ | ComfyUI + ComfyUI-LTXVideo custom nodes; Python 3.10+ / CUDA 12.7+ for the optional CLI path |
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 Ti. The INT8 pair is what changes the answer:
| File | Bytes | Decimal GB | GiB |
|---|---|---|---|
ltx-2.5-22b-distilled-transformer-comfy-int8-convrot.safetensors (the dev INT8 build is the same size to the byte) | 21,504,034,224 | 21.504 | 20.027 |
gemma4-12b-with-proj-ltx-2.5-comfy-int8-convrot.safetensors | 15,372,971,786 | 15.373 | 14.317 |
ltx-2.5-video-vae-conv-bf16.safetensors | 1,452,269,922 | 1.452 | 1.353 |
ltx-2.5-audio-vae-bf16.safetensors | 364,866,540 | 0.365 | 0.34 |
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 non-Ti 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.safetensorsas "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.safetensorsis 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, theInput Parameterssubgraph exposes enhancement as itscondboolean input; at the instantiating node (id 5014) that input is unlinked, so its widget value governs, and the value istruein the single-stage and two-stage workflows alike. ComfyUI's built-invideo_ltx2_5_i2vtemplate reaches the same default through aPrimitiveBooleantitledBoolean (Enable Prompt Enhance)set toTrue. 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
condwidget on theInput Parametersnode tofalse, then bypassLoad CLIP - Text EnhancerinLoad Modelsand bothTextGenerateLTX2Promptnodes inInput Parameters(Positive prompt (t2v) enhancerandPositive 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-LTXVideoexample workflows — the files undercustom_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 inworkflow_templatesand 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 Modelssubgraph and you will find five loader nodes, every one of them active (mode=0), whose serialized defaults are partly wrong: the node titledLoad VAE - Videocarries the audio VAE filename, and bothCLIPLoadernodes carryViT-B-32.pt— a CLIP model that is neither of the two Gemma files this model uses. TheUNETLoadercarriesltx-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'sModel LinksMarkdownNote, which is correct and is the thing to follow.
Set each loader by hand:
| Loader node | Set it to |
|---|---|
UNETLoader (untitled) | ltx-2.5-22b-distilled-transformer-comfy-int8-convrot.safetensors |
Load CLIP - Text Encoder | gemma4-12b-with-proj-ltx-2.5-comfy-int8-convrot.safetensors |
Load CLIP - Text Enhancer | gemma4_e2b_it_bf16.safetensors (or bypass the node — see step 3) |
Load VAE - Video | ltx-2.5-video-vae-conv-bf16.safetensors |
Load VAE - Audio | ltx-2.5-audio-vae-bf16.safetensors |
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/--widthhelp text inargs.pystates. 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,DistilledPipelinecallsassert_resolution(..., is_two_stage=True), andutils/helpers.pysetsdivisor = 64 if is_two_stage else 32with the docstring "For two-stage pipelines, the resolution must be divisible by 64." The name is misleading:distilledis 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 raisesValueErrorhere. The frame-count rule is unchanged at8 * 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 Ti. 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, and no RTX 3090 Ti report for LTX-2.5 surfaced anywhere this round searched. All 19 discussions on the LTX-2.5 model page were enumerated and read message by message, and every issue and pull request on
Lightricks/LTX-2was searched — 208 issues and 65 pull requests are indexed there — with and without a space in the card's name; the 3090 Ti does not appear in either space as of 2026-08-12.reddit.comrefuses this tool's user agent, so Reddit was not searched and no claim here rests on its silence.The nearest datapoint is on the non-Ti RTX 3090, a slower card of the same architecture. Its owner 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; he names his card as a plain 3090, and nothing in the thread suggests a Ti). Read that ~2m30 as a pessimistic upper bound on the time, not an estimate for this card: per NVIDIA's RTX 3090 / 3090 Ti specifications the 3090 Ti carries 10,752 CUDA cores against the 3090's 10,496 and boosts to 1.86 GHz against 1.70 GHz (1.56 GHz base against 1.40 GHz), inside a 450 W board power against 350 W — the same architecture, slightly more of it, clocked meaningfully higher. A 3090 Ti should therefore land under that figure, by a margin nobody has measured and which this page does not guess at. The reporter also states neither checkpoint, resolution nor step count, so it is a single loose data point in both directions. A measured number 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, and that figure is a property of the files and the 24 GB capacity rather than of the SKU. Live data, when it exists, appears at /check/ltx-2-5/rtx-3090-ti.
-
Quality notes: this recipe leads with the distilled transformer, and that is a speed choice, not a fit choice.
devanddistilledare 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, swapdistilledfordevin the download command and in theUNETLoaderwidget — 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, anddevdoes 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 Ti is paired with a lot of system RAM and you care more about fidelity than wall-clock, thefp8-cast --offload cpuCLI route above runs the bf16 weights instead.
For the full benchmark data, see /check/ltx-2-5/rtx-3090-ti.
Troubleshooting
Decoding hangs forever on longer clips
Reported on a non-Ti RTX 3090, not on this card — but the mechanism is the 2.28 GiB of decode headroom derived above, which is a consequence of the 24 GB capacity and is identical on a 3090 Ti. 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, and neither mentions a 3090 Ti — the extra clock does not buy memory, so expect the same wall.
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 any sm_86 card — the 3090 Ti included — 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 his own hardware, which he gives as "RTX 3090 (sm_86), WSL2, 31 GiB RAM + 71 GiB swap", i.e. a non-Ti 3090, so the card is not this recipe's but the compute capability is the same one — 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; 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 — and on a non-Ti 3090 rather than on this page's card. It is cited here for the code path, not for a 2.5 measurement and not for a 3090 Ti measurement, and the code path is the same one today:
fuse_cast_fp8_weightstill gates on bareTRITON_AVAILABLEand_read_scalesstill opens the checkpoint withsafetensors.safe_open, both onmainas of 2026-08-12. The Ampere behaviour follows from the compute capability, which issm_86on both cards and has not changed.
Cannot allocate memory (12) before anything loads
Same PR and the same sm_86 architecture — the reporter's card is a non-Ti 3090 — 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. This one is decided by host RAM and swap rather than by the GPU, so it transfers to any machine regardless of card. 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.