LTX-2.5 on RTX 5070 Ti: 22B audio-video in 16 GB, and the decode trap three owners hit

What You'll Build

Generate clips with synchronised video and audio from LTX-2.5 — Lightricks' 22B-parameter audio-video DiT — on a 16 GB RTX 5070 Ti, using ComfyUI's own shipped LTX-2.5 template with one node swapped: the diffusion-model loader becomes Unet Loader (GGUF), pointed at a community Q3_K_M quantisation of the distilled transformer. The official ComfyUI checkpoint for this model is a 20.027 GiB INT8 file — it is what our 24 GB anchors run. It is not out of reach here, and this card is the one card in the catalogue with public evidence about that; see the INT8 question below. The GGUF rung is what this recipe leads with, because it is the one an instrumented 16 GB card has actually been measured on.

Hardware data: RTX 5070 Ti (16GB VRAM, 256-bit GDDR7, Blackwell) · 13.354 GiB of resident weights on the lead rung — derived from file sizes, not measured on this card · See benchmark data

⚠️ Nothing on this page was measured by us on an RTX 5070 Ti. /check/ltx-2-5/rtx-5070-ti returns verdict: unknown with zero benchmarks (re-checked 2026-08-13). Every VRAM figure below is arithmetic over file byte counts read from the Hugging Face tree API. Community timings from owners of this card do exist and are reported below with their author and their configuration attached — but they are self-reported wall-clock on a different install path from the one documented here, and they are not a substitute for an instrumented run. If you run this pair, contribute your numbers.

This is the best-evidenced 16 GB card on this site for LTX-2.5, and every scrap of that evidence is about the same thing: the video decoder. Three owners of this exact card reported publicly within 36 hours of the model's release. All three hit a decode-stage stall or OOM. All three fixed it. Working independently, they landed on the same two levers this recipe already pulls — which video VAE you load, and how finely VAEDecodeTiled cuts the clip up — though they chose different values on the second. One of them then published before-and-after times showing the same jobs running between 2× and 10× faster on the VAE swap alone. If you read one section of this page, read Decoding hangs, stalls, or OOMs.

ℹ️ The one card in this catalogue that we have instrumented is a different one, and here is exactly what transfers. Our RTX 5060 Ti page is backed by fifteen measured runs on the operator's own card. That card is also 16 GB and also Blackwell, so the install path, the file set, the workflow and the fit arithmetic carry over intact. What does not carry over is every number describing how that card behaved: peaks, timings, throughput. Those belong to the RTX 5060 Ti and are labelled as such wherever they appear below. A same-capacity, same-architecture sibling is the strongest prior you can have without a measurement, and it is still not a measurement.

The finding you should drive this card by, and it is a property of the pipeline rather than of the silicon: on the one 16 GB card where this has been instrumented, peak VRAM was not governed by resolution or clip length. It was governed by whether the prompt changed — and the mechanism says the same should hold here.

ComfyUI runs prompt encoding as its own stage. The LTX text encoder is a 14.317 GiB file; it enters VRAM, produces the conditioning, and is evicted before sampling begins. Change the prompt and it comes back — on top of the transformer ComfyUI keeps resident between jobs. Nothing else in the graph moves that much memory in one step. On the measured RTX 5060 Ti, prompt-change runs averaged 871 MiB above cached-prompt runs and the cleanest matched pair differed by 1316 MiB, with peak showing negative correlation against output size across the session.

The mechanism is in the graph, not in the card, and community reports on other cards describe the same shape — in the RTX 5070 Ti timing thread below, an RTX 4070 owner volunteers that "changing prompts seems to very expensive operation though and sometimes trigger full model reload". Operationally: fix the prompt first, then tune size and duration. "Start small and work up" is the wrong instinct on a 16 GB card running this model.

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. No VRAM figure from an LTX-2.3 recipe transfers, and no LTX-2.3 GGUF will load here. This card already carries its own published LTX-2.3 recipe, which uses a different runtime, a different node set and a different fit strategy — see Troubleshooting if you are arriving from it.

ℹ️ Gated weights. Lightricks/LTX-2.5 carries gated: "auto", so an unauthenticated request to any file under it returns 401 (re-verified 2026-08-13 against the transformer, the text encoder, the conv video VAE and the spatial upscaler). 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. Ungated third-party copies exist for all four gated first-party files — see the download step.

Requirements

Why 16 GB works, in bytes

The official ComfyUI path loads a 20.027 GiB INT8 transformer (ltx-2.5-22b-distilled-transformer-comfy-int8-convrot.safetensors, 21,504,034,224 B). That is what ComfyUI's shipped template points at by default. A GGUF quantisation of the same distilled transformer replaces it, and the rest of the graph is unchanged.

Resident weights during the graph, using the lead rung:

Against a nominal 16 GiB that leaves 2.646 GiB for activations, latents, CUDA context and whatever the desktop is holding. The three non-transformer files sum to 2.620 GiB and are fixed — they are the same on every rung, which is what makes the ladder below a straight comparison of transformer files.

That total is also where the frontmatter's min_vram_gb: 16 comes from, and it is a floor rather than a peak: 13.354 GiB of weights alone overruns a 12 GB card before a single activation is allocated, and 16 GB is the next capacity real hardware ships in. Nominal 16 GiB is itself a yardstick, not a reading — what this particular card reports as usable has not been measured here. The instrumented RTX 5060 Ti reports 16311 MiB, which is that card's number and not necessarily yours.

The 14.317 GiB text encoder is excluded from that sum on purpose. Adding it gives 27.671 GiB, which fits nothing here. It is a sequential stage, not a resident one — which is also why a prompt change is the expensive operation on this card, and why the system-RAM requirement is real rather than decorative.

The rung ladder

The inclusion rule, stated so you can see what is missing: every distilled-transformer file from the seven community publishers below that fits a nominal 16 GiB card once the 2.620 GiB of fixed companions are added, plus the first-party pair for scale. Byte counts are from each repo's tree API, read 2026-08-13; the totals below sum unrounded bytes and round once. Enumerating those seven repos gives 18 files that fit and 26 that do not, and all 18 are here. The 26 that are not run from realrebelai's Q4_K_M at 16.670 GiB resident up to its Q8_0 at 24.629, and they include Q4-class builds as well as Q5, Q6 and Q8 — vantagewithai's Q4_0 at 16.815 misses by less than tsolful's row below. None of them changes a verdict, which is why they are cut. This is a claim about those seven repos on that date and nothing wider; the dev-variant transformers, the LoRAs and the text encoders are out of scope by construction.

Where a row names two publishers, the two counts are given in that order: Abiray's build is 64 bytes larger than vantagewithai's on each of those rungs, which changes no GiB figure and no verdict but is worth printing rather than averaging away.

Four things in that table are worth stopping on.

A quant name is not a file size, and the spread is larger than any single companion. Q3_K_M is 10.734 GiB from realrebelai and 12.036 GiB from the other two, at an identical 4349-tensor count. Q2_K is 8.228 GiB from realrebelai and 11.292 GiB from vantagewithai — a 3.064 GiB spread under one name. Which tensors stay at higher precision is the publisher's choice, so on a card this tight the publisher is part of the rung, not a detail.

The publisher's recommended rung does not fit. realrebelai's README marks Q4_K_M as **Recommended**, and at 14.050 GiB plus companions it lands 0.670 GiB past a nominal 16 GiB. A recommendation written for the model is not a recommendation for your card.

Q4_K_S is a near-miss, not a no. It leaves 0.478 GiB after weights. Note the unit before you argue with the arithmetic: the gap between Q3_K_M and Q4_K_S is 2,328,100,864 B, which is 2.168 GiB — 2220 MiB, not 2168. On the RTX 5060 Ti, where this has actually been instrumented, adding that delta to the roomiest of fifteen observed peaks lands 64 MiB past the capacity that card reports. So Q4_K_S deserves one deliberate attempt on a fresh start with a cached prompt; it does not deserve a workflow built around it.

The one rung that fits at Q4 is not therefore the best rung, and the reason is invisible from the file listing. joeygambino published a seventh-publisher set on 2026-08-13 that undercuts every other build by roughly 0.9 GB at each nominal level, and its Q4_K_M is the only Q4_K_M in the table that fits a 16 GiB card. Reading the tensor directories of both files over HTTP Range rather than either README: each carries the same 4349 tensors, the same ltxv architecture and the same 2199-character config blob, and each contains 620 tensors with gate in the name — 310 weights and 310 biases. In realrebelai's build not one of them is quantised (304 of the weights F16, 6 F32; all 310 biases F32). In joeygambino's, the 304 to_gate_logits weight matrices are quantised — Q4_K in the Q4_K_M build, Q3_K in the Q3_K_M — and the biases sit at F16. The tensor census says it plainly: realrebelai's Q3_K_M holds 1072 Q3_K tensors, joeygambino's holds 1376, and the difference of exactly 304 is those gates.

Those are the tensors realrebelai deliberately protects, and its README gives the reason — "Quantize them and video still looks fine while audio desyncs or degrades", which is a failure you ship without noticing on a model whose selling point is synchronised audio. joeygambino's README is not wrong about any of this; it is simply about something else. It says its size advantage comes from writing unquantised tensors at half precision — "Same weights, half the bytes, no quality argument involved." — and my parse confirms that (2605 F16 there against 2603 F32 plus 306 F16 here), and it correctly states that 304 gate-logit biases stay F16 "like every other bias". It never mentions the gate-logit weights. So a reader who checks the README against the header and stops at the word gate will conclude the two builds treat the gates alike. They do not. No side-by-side of the two has been published, so this is a difference in approach with a stated risk attached, not a measured defect — but it is why the lead stays where it is, and why a smaller file under the same quant name is not automatically a better one.

Why not just run the official INT8 and let ComfyUI offload?

It is the obvious alternative, and on this card — uniquely among the 16 GB cards this site covers — it is not a hypothetical. ComfyUI streams a model larger than VRAM rather than refusing it, so the 20.027 GiB INT8 file is not a hard no; it is a cost, and here somebody has paid it in public.

On 2026-08-12 a Reddit user, desktop4070, published a generation-time grid under the title "LTX 2.5 gen times on an RTX 5070 Ti" (thread). His configuration is stated in an earlier thread of his own: an RTX 5070 Ti 16GB with 64GB DDR5 on Windows 11, launched with --reserve-vram 2, "Using the default LTX 2.5: Text to Video template on ComfyUI" and all of the models that template recommends — i.e. the INT8 checkpoint, not a GGUF. Asked in the grid thread itself whether the times were with SageAttention, he answers "Raw, no sage attention." A sample of his figures, in his own units of ResolutionSelector megapixels against clip duration:

Read those as an existence proof, not as this recipe's numbers, for four separate reasons. They are on the INT8 path rather than the Q3_K_M GGUF documented below. They come with 64GB of system RAM and a --reserve-vram 2 launch flag. They are self-reported wall-clock rather than an instrumented trace, and the author flags his own contamination — "I was browsing reddit for some of these gens, so I'm guessing I was probably hitting my VRAM limit for some of these." And his fps is not stated, so a seconds-per-megapixel-frame constant cannot be derived from them at all. No such constant is computed on this page, deliberately: putting his numbers on the same axis as the RTX 5060 Ti's instrumented constant would produce a comparison that looks rigorous and is not.

What his grid does establish, and it is worth a lot: the stock INT8 template completes on this card once the decoder is set up correctly — reaching 2.0 MP at 15 seconds on one axis and 50-second clips at 0.6 MP on the other. Not both at once — in the companion thread he says outright that he had not tried 2.0 MP together with a 20-second clip. The correctly is the whole story and it is the next section. Note also that a reply on his grid is another user pointing out that "to anyone using the official comfyui template, make sure to disable the prompt enhancer. it adds an additional 1-2min" — which is one of the six deltas this recipe already applies.

This recipe still leads with the GGUF rung, for three reasons that have nothing to do with his result: 10.734 GiB of resident transformer is a deterministic fit rather than a streaming bet, it is the rung our own instrumented 16 GB card ran fifteen times with zero OOM, and it does not assume 64GB of host RAM. If you have the RAM and want the INT8 quality, his post is your evidence that the road exists.

Where this card sits in the 16 GB tier, and why that changes nothing

The RTX 5070 Ti is the middle of three 16 GB Blackwell cards this site documents for LTX-2.5, and the spread between them is wide. From NVIDIA's own spec tables: this card is 16 GB GDDR7 on a 256-bit interface, 8960 CUDA cores, 1406 AI TOPS; the RTX 5080 is 16 GB GDDR7, 256-bit, 10752 cores, 1801 AI TOPS; the RTX 5060 Ti — the card this model has been instrumented on — is 16 GB GDDR7 on a 128-bit interface, 4608 cores, 759 AI TOPS. Same architecture, same memory generation, same capacity; this card has the 5080's bus width and roughly twice the 5060 Ti's compute.

None of that moves a single verdict in the ladder above. Every one of them is a capacity verdict, and bus width is not capacity. Q4_K_M does not become loadable, the first-party nvfp4 file does not shrink, and the INT8 checkpoint is still 20.027 GiB on disk. The lead rung is the same rung, for the same reason. If you came here from the cheaper card hoping the step up opens a quantisation tier, it does not — and that is the thesis of this whole tier rather than a disappointment specific to you.

Where it should show up is throughput, and the reason is specific to this install. ComfyUI-GGUF does not hand quantised weights to the tensor cores. Its op class is documented in one line — ops.py declares GGMLOps as "Dequantize weights on the fly before doing the compute" — and the linear layer is exactly that:

def forward_ggml_cast_weights(self, input):
    weight, bias = self.cast_bias_weight(input)
    return torch.nn.functional.linear(input, weight, bias)

cast_bias_weight calls get_weight, which calls dequantize_tensor, and the result is an ordinary dense tensor fed to plain torch.nn.functional.linear. Every forward pass therefore reads the packed weights out of VRAM and materialises an unpacked copy before any maths happens — a traffic pattern a native INT8 or NVFP4 path does not have, because those feed the quantised bytes to the tensor cores directly. A GGUF graph is unusually memory-bound, so a wider memory interface has more to work with here than it would on the INT8 path our 24 GB anchors document.

That is a mechanism, not a measurement, and no ratio appears on this page. NVIDIA publishes no memory-bandwidth figure for any of these three cards on its own product pages — the spec tables stop at interface width — so a bandwidth ratio would have to come from somewhere that is not the manufacturer. The core and TOPS figures move together with the bus anyway, so no single factor would describe the difference honestly. The instrumented throughput constant from the RTX 5060 Ti session is a property of that card and is deliberately not rescaled here; rescaling a measurement by a spec-sheet ratio produces a number that looks measured and is not. If you time this pair on the GGUF path, contribute the result and the two pages become the comparison neither of them can be alone.

The non-GGUF routes, and why none of them leads

Worth checking rather than assuming, because this card is Blackwell and the natural hope is that a Blackwell-native format opens up. It does not, and the reason is capacity in every case.

First-party nvfp4: no, on capacity. ltx-2.5-22b-distilled-transformer-nvfp4.safetensors is 18,721,732,720 B = 17.436 GiB, over 16 GB before a single companion file. It also shipped broken: in Lightricks/LTX-2.5 discussion #16 three users report it failing in ComfyUI's own template with RuntimeError: mat1 and mat2 shapes cannot be multiplied, and Lightricks' art-alex replied "We fixed the issue." the same day. Fixed or not, it does not fit as a resident load.

Community nvfp4 rebuilds: two of them, and this card can genuinely use the format. DmitryDB publishes a 13,572,563,959 B (12.640 GiB) nvfp4 distilled transformer written, per its README, in "the stock Comfy NVFP4 wire format", plus a matching nvfp4 text encoder at 11,197,310,236 B (10.428 GiB). joeygambino publishes a second at 12,499,335,336 B (11.641 GiB), which is 0.999 GiB lighter — 14.261 GiB resident against 15.260, so 1.739 GiB of headroom instead of 0.740.

The gate is worth reading in the source rather than inferring, because it is short and unambiguous. ComfyUI's comfy/model_management.py::supports_nvfp4_compute returns False for any non-NVIDIA device and then for any device whose torch.cuda.get_device_properties(device).major is below 10. Consumer Blackwell reports major 12, so this card clears it — and so does every card in this tier, because NVIDIA lists the RTX 5060 Ti and RTX 5080 under the same architecture on the pages linked above. So the NVFP4 route is not a reason to prefer this card over a cheaper 16 GB Blackwell one; a 12.640 GiB file fits, or does not fit, a 16 GB card identically on all three. The cards this route genuinely leaves behind are the 16 GB Ada parts, which sit under the same line. The publisher's own table says it in product terms: "Smallest transformer route; supported fallback on RTX 4090 and native acceleration on supported Blackwell hardware."

If you try one, try joeygambino's. On the two axes this page cares about it is the better of the pair on both. Headroom: 1.739 GiB against 0.740, and on the RTX 5060 Ti — the one 16 GB card this model has been instrumented on — observed peaks consumed between roughly 0.5 and 2.2 GiB on top of a comparable weight sum, a range that swallows DmitryDB's margin whole and leaves joeygambino's intact. Provenance: its README says "comfy-w4a4 and comfy-nvfp4 were built and tested on a Blackwell card." — this card's own architecture — whereas DmitryDB's validation is loader-level and on an Ada card, a stock-ComfyUI load and projection smoke test on an RTX 4090, with the README stating plainly that "A prompt-to-decoded-video/audio perceptual A/B has not yet been completed."

Neither is the lead, and both are still second. Both are community conversions — DmitryDB's card says so itself: "These are community conversions, not official Lightricks or ComfyOrg releases." — neither has a published end-to-end run on this card, and NVFP4 has no fallback story if it misbehaves, whereas the GGUF rung has fifteen instrumented runs behind it on a sibling. Try it second, not first.

INT4 / W4A8: real support, thin provenance. ComfyUI core registers asym_w4a8_int8 as a first-class quantisation format — comfy/quant_ops.py maps it to AsymW4A8Int8Layout, and comfy-kitchen, which provides the kernels, is pinned in ComfyUI's own requirements.txt. Three publishers ship LTX-2.5 in that format. Winnougan's at 12,520,292,200 B and joeygambino's at 12,520,362,840 B are the same format at effectively the same size — 70,640 B apart, built independently, and joeygambino's README says as much, calling its own "a mirror, not a first." Both fit, at 14.280 GiB resident. tsolful's W4A8 Mixed is the third and lands 0.974 GiB over a nominal 16 GiB. Against all of it: no end-to-end run of any of the three has been reported in the surfaces listed at the end of this page, and Winnougan's model card lists six files where the repo contains three. joeygambino also ships a W4A4 build at 10.465 GiB — the roomiest non-GGUF route here — and a two-tier mix4x8 that restores part of the INT8 precision over a W4A8 floor. Treat the family as experiments rather than an install path, but it is a larger and better-documented family than this page previously implied.

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.

1. Get ComfyUI new enough

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

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

LTX-2.5's audio-video nodes are in core (comfy_extras/nodes_lt.py), not in a custom pack. Support landed in commit 57ce8e1a — "Add support for LTX 2.5 (#15499)", 2026-08-11 — and was first tagged v0.32.0. Do not stop at that tag, but be clear about why. The commit usually cited here, bd34f338 "Fix float64 device in ltx diffusion decoder" (#15516), landed the next day and touches exactly one file — comfy/ldm/lightricks/vae/na_diffusion_decoder.py, read from the commit's own patch. That is the diffusion decoder, which this recipe does not install; it matters only if you take the diffusion VAE against the advice below. The real reason to be current is the template package: the tiled-decode defaults that answer this card's one known failure ship in comfyui-workflow-templates 0.11.40, which current ComfyUI pins. See the decode section.

A quick negative test for a build that is too old: if comfy/text_encoders/lt.py defines LTXAVGemmaTokenizer but has no ltxav_gemma4_tokenizer, you are on an LTX-2-era build and it cannot load 2.5 no matter what else you install.

On Blackwell you need a CUDA 12.8+ torch build.

Separately, and not a Blackwell matter despite where it usually gets filed: if ComfyUI greets you with a wall of WARNING WARNING WARNING about cu130, that is a test of your torch build, not of your card. comfy/quant_ops.py reads torch.version.cuda, and when it parses below (13,) it calls ck.registry.disable("cuda") — disabling comfy-kitchen's accelerated CUDA backend. No device property is consulted anywhere in that branch, and the warning itself is scoped by generation rather than by architecture: "If you are on nvidia 20 series and above it is required that you update your pytorch to cu130 or higher." So it fires on this card exactly as on a 3090 or a 4090. It is irrelevant to the GGUF path this recipe leads with — ComfyUI-GGUF brings its own dequantisation and never touches those kernels — but it is the first thing to check if you go off and try one of the quantised-safetensors routes above.

2. Install ComfyUI-GGUF

git clone https://github.com/city96/ComfyUI-GGUF "$COMFY/custom_nodes/ComfyUI-GGUF"
pip install --upgrade gguf

On a Windows portable build, use the node pack's own instructions instead:

.\python_embeded\python.exe -s -m pip install -r .\ComfyUI\custom_nodes\ComfyUI-GGUF\requirements.txt

This is the only custom node pack this recipe needs. The node is Unet Loader (GGUF), under the bootleg category, and per the pack's README .gguf files go in ComfyUI/models/unet.

You do not need the Lightricks ComfyUI-LTXVideo pack — worth saying plainly on this card, because its own LTX-2.3 recipe requires that pack plus KJNodes. ComfyUI's shipped LTX-2.5 template loads the text encoder through a core CLIPLoader with type ltxv, not through the vendor pack's own loader — verified by reading the template's node inventory. Installing the vendor pack is not harmful, but it is a different workflow family with different default weights, and it is one more thing that can break.

3. Authenticate and download the six files

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

# 1. the transformer — community GGUF, NOT gated
hf download realrebelai/LTX-2.5_GGUFs LTX-2.5-Distilled-Q3_K_M.gguf \
    --local-dir "$COMFY/models/unet"

# 2-5. gated first-party files; the repo prefixes are already ComfyUI's directory names
hf download Lightricks/LTX-2.5 \
    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 \
    latent_upscale_models/ltx-2.5-latent-spatial-upscaler-x2-bf16-1.0.safetensors \
    --local-dir "$COMFY/models"

# 6. the prompt enhancer — a DIFFERENT repo, not gated, and required even if you turn it off
hf download Comfy-Org/gemma-4 text_encoders/gemma4_e2b_it_bf16.safetensors \
    --local-dir "$COMFY/models"

Six files, 37.244 GiB. That list is not this recipe's opinion — it is the models manifest ComfyUI's own video_ltx2_5_t2v.json template declares, with the transformer swapped for the GGUF. The video_ltx2_5_i2v template declares the identical six. Two of them are the ones people miss:

• The latent spatial upscaler is not optional garnish. The shipped template is two-stage — sample at half resolution, LTXVLatentUpsampler ×2, sample again. The template's own parameter table describes it as the "Latent upscaler applied before decoding for higher-fidelity output". Without the file the graph will not run at all.
• The prompt enhancer model is required even when the enhancer is switched off. See Troubleshooting; this is the single most common way a first attempt dies before it starts.

Two deliberate substitutions against the template's defaults:

• GGUF instead of the official INT8 transformer — 10.734 GiB against 20.027 GiB. This one is driven by the 16 GB budget.
• The convolutional video VAE, not the diffusion one. The template ships ltx-2.5-video-vae-bf16.safetensors (1.371 GiB); take ltx-2.5-video-vae-conv-bf16.safetensors (1.353 GiB) instead. On this card that is not a 19 MiB saving (1,472,223,346 B against 1,452,269,922 B is 19,953,424 B — subtracting the rounded GiB figures gives 18 and is wrong), it is the single highest-leverage line on the page — see the decode section below, where an owner of this exact card measured generations dropping from 376 s to 53 s on nothing but this substitution. The vendor's own workflow note rates the conv file "Lower memory & faster" against the diffusion decoder's better quality (LTX-2.5_T2V_I2V_Single_Stage_Distilled.json), and it is also the decoder the open gray-tile report does not implicate.

If you would rather not deal with the gate. Ungated third-party copies exist for all four gated files, each returning 302 unauthenticated (re-verified 2026-08-13). Prefer first-party where you can; these are two different things, and the Hugging Face API tells you which is which without downloading anything, by comparing git blob oids.

• text encoder: DmitryDB/LTX-2.5-ComfyUI-Quants → text_encoders/gemma4-12b-with-proj-ltx-2.5-int8_lean_convrot.safetensors, 15,373,015,746 B. It is the same size to three decimals as the first-party file but not byte-identical — 43,960 bytes larger — so treat it as a comparable rebuild rather than a copy.
• both VAEs and the spatial upscaler: ChrisColeTech/LTX-2.5-turbo-GGUF, which reports gated: false, carries all three under split/ — vae/ltx-2.5-video-vae-conv-bf16.safetensors (blob 2905ee1b0e1c), vae/ltx-2.5-audio-vae-bf16.safetensors (blob 08403b5a5cf1) and latent_upscale_models/ltx-2.5-latent-spatial-upscaler-x2-bf16-1.0.safetensors (blob cec7bee61862). All three oids match Lightricks/LTX-2.5 exactly, so that is the same content rather than a re-export. Every file under split/ matches, in fact — including the diffusion video VAE (blob 4f679fe8f92b) and the temporal upscaler (blob 3fe643add92b), neither of which this recipe uses; the diffusion decoder is the one the section below tells you not to take on this card.

This is the list this recipe checked, not a survey of what exists — other ungated copies are on the Hub, and since the LTX-2 Community License travels with the bytes, working out what you are agreeing to is easier from the licence page than from a mirror. The text encoder is not substitutable with a stock Gemma 4 12B checkpoint either way — it carries LTX's own text_embedding_projection and audio_projector layers, and the quantiser's README is blunt about it: "A plain Gemma checkpoint will not substitute."

4. Place the files

$COMFY/models/
├── unet/LTX-2.5-Distilled-Q3_K_M.gguf                                       # the GGUF goes HERE, not diffusion_models
├── 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.5-latent-spatial-upscaler-x2-bf16-1.0.safetensors

Both Gemma files go in text_encoders/ — they are different models doing different jobs, not alternatives. One conditions the diffusion; the other rewrites your prompt.

Running

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

Open Workflow → Browse Templates → Video → LTX-2.5: Text to Video. In comfyui-workflow-templates 0.11.40 — the version ComfyUI's requirements.txt currently pins, and the latest on PyPI — this is video_ltx2_5_t2v; the image-to-video sibling is video_ltx2_5_i2v and behaves identically for everything below.

The whole graph is wrapped in one subgraph, and the loaders' widgets are promoted onto the outer node — so set them there, not inside. The one edit you must make inside the subgraph is the loader swap itself: replace UNETLoader with Unet Loader (GGUF). It is a clean swap — same widget name unet_name, same MODEL output — so no links need rebuilding.

The six deltas from the shipped template

Three template defaults need no change and are load-bearing: VAEDecodeTiled already ships at [512, 64, 64, 16], and both LTXVDualCFGGuider nodes already sit at [1, 1]. All three re-read from the template JSON on 2026-08-13. Leave them alone — on this card that is not boilerplate; it is the setting every public failure report here turned out to be about.

Why multiple = 64 matters

ResolutionSelector computes total_pixels = megapixels * 1024 * 1024 — binary megapixels, not 1e6 — then rounds each side to the nearest multiple (comfy_extras/nodes_resolution.py). The base stage then samples at width/2, and the VAE floors that to a multiple of 32. At the shipped multiple = 32 you silently lose a rung: 0.2 MP promises 608×352, 608/2 = 304 floors to 288, ×2 = 576×320. At multiple = 64 the halved size is always a clean multiple of 32, so the promised size is the delivered size.

The 16:9 ladder at multiple = 64, computed from that node's own formula:

This table differs from the one the template ships in its own Size Settings Reference note, which is computed at multiple = 32. Both are correct for their own setting — and note that the community timings quoted above are in the reporter's own megapixel settings, whose multiple he does not state, so his MP labels and this table's rows are not guaranteed to name the same pixel dimensions.

Clip length

Frames are fps × duration + 1 and must land on 1 mod 8, for the VAE's 8× temporal compression. At 24 fps every whole second works: 2 s → 49, 4 s → 97, 6 s → 145, 8 s → 193. The template imposes no upper bound, and the community reports on this card go to 50-second clips. Note, though, that every public LTX-2.5 decode complaint — including all three from this card — involves a 10-second or longer clip. Long durations are the axis that has actually bitten people.

Distilled means CFG 1.0

Both LTXVDualCFGGuider nodes ship at [1, 1] and should stay there. The quantiser's README puts it plainly: "Guidance is baked into the weights; applying it again degrades output regardless of quantization."

Results

• Speed: no figure is published here for this install. Nobody has timed the Q3_K_M GGUF path on an RTX 5070 Ti. Community timings for this card exist and are reproduced in the INT8 section with their author, hardware and launch flags attached — but they are a different transformer, self-reported, and carry no stated frame rate, so nothing on this page converts them into a rate. The only instrumented LTX-2.5 run on a 16 GB card in this catalogue is on the RTX 5060 Ti, a card with half the memory interface width and materially less compute, so its seconds-per-megapixel-frame constant is a floor of unknown depth rather than an estimate — and rescaling it by a spec ratio would manufacture a measurement. Contribute a timing on the GGUF path and this bullet becomes a number.
• VRAM usage: 13.354 GiB of resident weights, derived from file byte counts, not observed. The three fixed companions account for 2.620 GiB of that and do not change with the rung. Real peak will be higher — activations, latents, CUDA context and the desktop all sit on top. On the RTX 5060 Ti, the one 16 GB card where this has been instrumented, that overhead ran between roughly 0.5 and 2.2 GiB over the same weight sum, depending on whether the prompt was re-encoded. No owner of this card has published a VRAM figure for LTX-2.5 in any surface listed at the end of this page. See /check/ltx-2-5/rtx-5070-ti for whatever has landed since.
• Headroom strategy: start at 0.9–1.0 MP and 97 frames, confirm it completes, then move one axis at a time — and change the prompt as rarely as you can while you do it. The encoder reload is the expensive event, not the frame count.
• Quality notes: Q3 is a real compromise and the specific risk at this tier is audio, not video. realrebelai's build protects the audio-video mixing gates from quantisation; the publisher's README explains why that matters — "Quantize them and video still looks fine while audio desyncs or degrades" — a failure mode that is easy to ship and hard to notice. The publisher's own table rates this rung "Usable, softer detail". No side-by-side against the INT8 anchor exists at any resolution, so treat that as a description of intent, not a measured quality claim.
• Image-to-video: the video_ltx2_5_i2v template declares the identical six-file manifest and the identical VAEDecodeTiled and guider defaults, so everything above transfers. One behavioural difference worth knowing in advance: ResolutionSelector is a scale hint in i2v, because the frame geometry comes from the input image's aspect ratio, so i2v frames do not follow the t2v ladder exactly.

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

Troubleshooting

Decoding hangs, stalls, or OOMs

This is the failure this card is known for. Every public LTX-2.5 report from an RTX 5070 Ti owner — three of them, within 36 hours of release — is about the video-decode stage, and all three were solved by changing what the decoder is or how it tiles. Neither the transformer nor the card's capacity was the problem in any of them.

Report 1 — the wrong video VAE, and a 2×-to-10× swing. On 2026-08-12, Reddit user desktop4070 filed "LTX 2.5 takes forever to generate some videos, specifically on the VAE Decode (Tiled) stage" (thread) from an RTX 5070 Ti 16GB with 64GB DDR5, running the stock template with --reserve-vram 2. The first reply told him to use the conv video VAE. He did, and published the before-and-after himself (thread): "Switching to the convrot video VAE sped up a lot of my slowest gen times." Two of his eight pairs, verbatim — "1.0MP @ 5 seconds: 376s -> 53s" and "0.3MP @ 13 seconds: 437s -> 45s". He adds: "I was trying to figure out why my gen times were insanely slow for hours, tried like a dozen different fixes, but this one single change immediately fixed the slow issue entirely."

His "before" times are wildly non-monotonic — two runs at the same 0.4 MP and one second apart in duration came in at 76 s and 292 s — which is the signature of a decoder falling off a cliff rather than of a card running out of room. The individual pairs improve by between roughly 2× and 10×. Take the direction and the magnitude as real and the exact ratios as one operator's wall-clock on Windows, not a controlled benchmark. This is why the download step tells you to take ltx-2.5-video-vae-conv-bf16.safetensors. It is one line and on this card it is worth more than any other line on the page.

Report 2 — the tiling widgets, same card. In the same thread, hiperjoshua reports from an "RTX 5070 Ti + 64 GB RAM" that the plain VAE Decode node ran ComfyUI out of memory and that he "had to set tile size to 512, overlap 64, temporal size 256 and temporal overlap 32" on the tiled node, plus a VRAM-unload node before it.

Report 3 — the temporal axis alone. At Lightricks/LTX-2.5 discussion #15, a thread opened on 2026-08-12 about the basic I2V workflow hanging on 10-second clips, another participant posted what is, across all 30 discussions on the model repo and all eight community quant repos, the single mention of this card on Hugging Face: "Mine got stuck too. I have a 5070ti but I adjusted these and it goes pretty fast." He names temporal_size: 64 and temporal_overlap: 16 as his fix and adds "I didn't do the 512, but it works nonetheless." — so on his machine the temporal axis was the binding half and the spatial tile was not needed at all. Beyond those two widget values he states no transformer file, no VAE, no resolution, no frame count and no performance number of any kind, so read it as evidence that this card hits and clears the decode issue, and as evidence of nothing else.

What the current template already does for you. Commit c74863f8 (2026-08-12, PR #1120) changed the VAE Decode (Tiled) widgets in all three LTX-2.5 templates. In video_ltx2_5_t2v and video_ltx2_5_i2v — the two this recipe uses — the array went from [768, 64, 4096, 32] to [512, 64, 64, 16]: tile 768→512, temporal size 4096→64, temporal overlap 32→16. (The third, video_ltx2_5_flf2v, started from [768, 64, 4096, 64] and landed on the same values; its temporal overlap was 64 rather than 32. Read from the commit patch, not from one template.) It ships in comfyui-workflow-templates 0.11.40, which is what ComfyUI pins today. That is a strict superset of report 3's fix and it drops the tile further than report 2's. The old temporal size of 4096 meant the decoder was effectively not tiling over time at all, which is why the complaint is always about long clips. A commenter in report 1's follow-up thread makes the same point — "Those default decode settings are way too high. There was a template update."

So: if you are on template package 0.11.40 or newer and you took the conv VAE, both known causes are already handled. If you are on an older package, set those four values by hand. If you are current and still stalling, check that you did not raise the tile size — with fixed-size tiling a larger output frame means more tiles, not a larger decode buffer, which is why decode cost grows with area while decode memory does not. That property is what keeps a 16 GB budget viable at high resolutions; raise the tile and you give it away.

The problem is not confined to this card, which is a reason to trust the diagnosis rather than to discount it: an RTX 4060 Ti 16GB owner in report 1's thread reports the identical VAE fix, having swapped the diffusion video VAE for the conv one — "allowed me to actually generate videos, and the generation speed is pretty good for my RTX 4060 Ti 16GB." — and ComfyUI issue #15544 (open, filed 2026-08-12) describes the same stage from a machine with 24 GB of VRAM and 96 GB of RAM, where 5-second clips finish in about 60 seconds while "the process gets stuck during the decoding stage, where it wastes several hundred seconds" at 10.

Separately, LTX-2 issue #277 reports gray frame tails from the diffusion video VAE decoder under AUTO tiling, reproduced by a community user on an A100 80 GB with the vendor CLI. Different decoder, different runtime — one more small reason to take the conv file.

size mismatch for keyframes_abs_pos_embedding... on the GGUF loader

The most common failure on the GGUF path, and it is about which GGUF you downloaded, not about your card. LTX-2.5's DiT dimensions are not derivable from tensor shapes — ComfyUI reads them from a config blob in the safetensors metadata, and a plain GGUF conversion has no equivalent field. A naive conversion therefore builds an LTX-2.3-shaped model and pours 2.5 weights into it. The quantiser's README states the consequence directly: "If you convert LTX-2.5 to GGUF yourself, it will not load."

The symptom is a wall of shape mismatches on UnetLoaderGGUF, typically keyframes_abs_pos_embedding: [4096] against [1, 4096], or learnable_registers: [128, 2048] against [128, 3840]. It is reported on a 16 GB card at ComfyUI issue #15540, where a community user writes "I'm using the default LTX 2.5 workflow. I replaced the default 'Diffusion Model Loader' with the UNET GGUF loader and used LTX 2.5 Q4_K_S.gguf file." and gets exactly that error. His own hardware line in the same issue body reads Sapphire Nitro 7800XT , 16GB, so it is a 16 GB AMD card rather than this one — the failure is about the file, not the vendor. That issue is now closed (state re-read 2026-08-13); the reporter never named which publisher's GGUF he used.

Fix: use a build whose author solved it, and all three named on this page did. Reading each publisher's GGUF header directly over HTTP Range on 2026-08-13: realrebelai, Abiray and vantagewithai all declare general.architecture = ltxv, 4349 tensors, and a 2199-character string KV named config carrying the AVTransformer3DModel definition, which ComfyUI-GGUF/loader.py surfaces to ComfyUI. They also all solve the keyframes_abs_pos_embedding half, by two different routes: realrebelai stores that tensor 1-D and adds a comfy.gguf.orig_shape.keyframes_abs_pos_embedding = [1, 4096] key, which the loader's get_orig_shape reads first; Abiray and vantagewithai store the tensor with its trailing singleton dimension intact, which the loader's fallback recovers by reversing the dims. Either way the model builds. Do not roll your own conversion.

The model widget is greyed out and you cannot point it at the GGUF

You are editing the outer subgraph node instead of the inner loader. ComfyUI issue #15539 is exactly this frustration — "The model input is greyed out, so there's absolutely no way to link the GGUF." — and it was closed the same day it was filed, without a code change. The promoted widget on the outer node is bound to the inner UNETLoader; you have to enter the subgraph and replace that node with Unet Loader (GGUF) first, after which its unet_name widget promotes into the same slot. This is the one edit that must happen inside.

Turning audio off to save memory can make things worse

Counterintuitive, and specific to 16 GB. ComfyUI issue #15356 (open) reports that ComfyUI's generic activation-memory estimator sizes an LTXAV latent very differently depending on whether audio is present: video-plus-audio arrives as a nested latent flattened to (B, 1, N), video-only stays a 5D (B, 128, T, H, W), and the estimator multiplies dimensions from index 2 — so the 128 video-latent channels are counted in one case and skipped in the other, a factor of exactly 128.

Disambiguation, because it matters: that report was filed 2026-08-06, before LTX-2.5 shipped, so it describes an earlier model in the same ComfyUI LTXAVModel class rather than this one, and it is against the INT8-scale checkpoint rather than a GGUF. The part that is model-class-independent is the estimator and the latent representation, and the practical advice is one line: if you are hunting memory, do not assume dropping the audio branch is a saving. It changes the memory plan rather than shrinking it. Leave audio on unless you have a reason.

"CLIP Loader is missing a required model file" with the enhancer switched off

Download gemma4_e2b_it_bf16.safetensors anyway. All six files are required to queue, even though only five are required to run.

The enhancer branch is gated by a ComfySwitchNode whose on_false/on_true inputs are declared lazy=True, and its check_lazy_status only ever requests the taken branch (comfy_extras/nodes_logic.py). So at runtime the enhancer's CLIPLoader genuinely never executes and never reaches VRAM. But ComfyUI's frontend validates every model widget in the graph before queueing, laziness notwithstanding: a missing file paints the node red and raises that error.

Note also that the enhancer ships ON. Reading the template JSON on 2026-08-13: the governing value is the boolean widget on the outer subgraph node, which is true in both video_ltx2_5_t2v and video_ltx2_5_i2v. Do not read the inner nodes to check this — the inner ComfySwitchNode's serialized widget says false and the inner PrimitiveBoolean says true, and both are overridden by links, so either one read on its own gives you a wrong answer. The template's own parameter table advertises the feature as "Toggle the built-in Prompt Enhancer: expands short prompts into rich cinematic instructions at near-zero extra compute". Turning it off is one of this recipe's six deltas, and the wall-clock case for that is not ours: in the RTX 5070 Ti timing thread the top comment reads "to anyone using the official comfyui template, make sure to disable the prompt enhancer. it adds an additional 1-2min".

Out of memory, or a stall that looks like one

In this order:

1. Note where it failed. An OOM during prompt encoding is the 14.317 GiB encoder stage and is a different problem from an OOM during sampling or decode. And a decode-stage stall is very likely not an OOM at all — see the decode section above, which is where all three reports from this card landed.
2. Stop editing the prompt. On the RTX 5060 Ti — the one 16 GB card where this has been instrumented — re-encoding was the only operation that moved the peak. Fix the prompt, then tune size and duration.
3. Do not raise the decode tile size. See above.
4. Drop a rung — Q2_K at 8.228 GiB is the smallest sane one, at a real quality cost.
5. Launch with --lowvram.
6. Fix the pagefile before blaming the GPU. ComfyUI-GGUF's own source carries the warning in a code comment: "Windows doesn't over-commit memory so without this 24GB+ of pagefile is used". A host-RAM OOM here reads exactly like a VRAM problem and will send you down the wrong rung. Our 24 GB anchor recommends 64 GB of RAM, and both RTX 5070 Ti owners who published run details had 64 GB; 32 GB is workable on the GGUF path with the pagefile sorted first.

Unexpected text model architecture type in GGUF file: 'gemma4'

Two different mistakes produce this one string, and it is worth knowing which you made before you go looking for a fix.

The common one is the prompt enhancer. ComfyUI-GGUF issue #474 is exactly this: a user points a community GGUF of the small gemma-4-E2B-it at the Generate LTX2 Prompt node — the enhancer — and gets the exception. That node takes the 9.573 GiB gemma4_e2b_it_bf16.safetensors, a different model in a different slot from the ~14.3 GiB conditioning encoder this recipe budgets for, and quantising it buys you nothing this page wants: the enhancer is off in the six deltas above, and switching it off frees the whole 9.573 GiB stage rather than shrinking it. The issue is open as of 2026-08-13.

The other is the conditioning encoder, and there the answer is that stock ComfyUI-GGUF cannot load one. Its text-model loader keeps an explicit allow-list, and reading it at the pinned commit settles that half without needing a bug report: loader.py declares TXT_ARCH_LIST = {"t5", "t5encoder", "llama", "qwen2vl", "qwen3", "qwen3vl", "gemma3"} and raises for anything outside it. gemma3 is on that list and gemma4 is not — which is also why an LTX-2.3-era GGUF encoder is no substitute. It is one gate serving both slots, since gguf_clip_loader calls gguf_sd_loader(path, is_text_model=True).

And the gap is deeper than one missing set entry, which matters for how quickly it might close. Counting occurrences in that file: gemma4 appears zero times and gemma3 eight, spread across a GEMMA3_SD_MAP state-dict remap, a gemma3_norm_corrections pass, a dedicated gguf_gemma3_tokenizer_loader, and three dispatch sites. Adding gemma4 to the set would not be enough; the architecture needs a branch. That is why the one repo below has to ship a patch rather than a filename.

A GGUF encoder now exists, it appeared while this page was being written, and nobody has run it. elix3r/gemma4-12b-with-proj-ltx-2.5-GGUF was created at 18:04 UTC on 2026-08-13 — twenty-three minutes before this draft was saved — and ships gemma4-12b-with-proj-ltx-2.5-Q5_K_M.gguf at 9,514,920,864 B = 8.861 GiB, which is 5.456 GiB lighter than the first-party INT8 encoder. It also ships patches/ComfyUI-GGUF-ltx25-gemma4.patch, and that patch is the confirmation of everything in the paragraph above: the file cannot be loaded by stock ComfyUI-GGUF, which is exactly why its publisher had to write one.

Everything known about it is public metadata. The repo is gated, so an unauthenticated fetch of the GGUF, the patch and even QUANTIZATION.md all return 401 — neither the patch body nor the weights are readable without accepting the licence, and this page has not read them. It has 0 downloads and 0 likes, and it is moving: the patch was 1,594 B when a first reader checked it and 1,711 B when this page checked it forty minutes later. Do not install this today on the strength of this page. It is recorded because it exists and because it changes what the next reader should search for, not because anyone has generated a frame with it.

The record of what was searched, and when. Before that repo appeared, a search of the Hugging Face model index on the single tokens ltx, LTX-2.5, ltxv, gemma4 and gemma-4 — single tokens because that index substring-matches the model id, so any multi-word query returns nothing regardless of reality — surfaced 309 distinct repos, 112 of them naming Gemma, and no GGUF build of an LTX-2.5 conditioning encoder among them. The two repos that republish that encoder for LTX-2.5, DeepNeuralNerd/Gemma-4-12B-it-uncensored-heretic-DeepNeuralNerd-LTX_2.5_ComfyUI and ibyteohdear/gemma4-12b-heretic-ltx-2.5-bf16, ship safetensors only. That was true of that index at that hour and is kept here as the shape of the search rather than as a claim about the world — a model this young acquires quantisations faster than a page can describe them. Requests remain open on both sides of the boundary: ComfyUI-GGUF issue #450 has asked for Gemma 4 text-model support since 2026-05-28, months before this model existed, and LTX-2 issue #278 asks Lightricks for the encoder GGUF directly. Both open, neither answered.

A missing GGUF encoder is not the same as a missing lighter encoder, and the difference is worth 4 GiB of disk. The gate above is specific to GGUF; ComfyUI's own quantised-safetensors formats are not affected, and three community builds of the conditioning encoder exist in them — DmitryDB's nvfp4 at 11,197,310,236 B (10.428 GiB), Winnougan's w4a8-convrot at 10,604,323,186 B (9.876 GiB), and joeygambino's w4a8 at 10,604,342,914 B (9.876 GiB — a different build from Winnougan's, 19,728 B apart). Any of them is roughly 4.4 GiB lighter on disk than the 14.317 GiB first-party INT8 file. None has a published end-to-end run, and the encoder is a sequential stage, so what they buy you is disk and prompt-change time rather than resident VRAM — but if the encoder stage is what hurts, this is the direction, and the GGUF gate is not what stands in the way.

So budget the 14.317 GiB INT8 encoder on disk and treat everything lighter as unfinished business. It is a sequential stage, so it costs you disk and a prompt-change penalty, not resident VRAM. Of the four lighter builds named above — three quantised-safetensors and one patched GGUF — not one has a published end-to-end run on any card, so the honest summary is that the encoder is the least-explored file in this recipe and the one most likely to look different in a week.

QuantStack/LTX-2.5-GGUF is still empty

If you came looking for the publisher whose LTX-2.3 GGUFs you used, that repo held exactly one file — .gitattributes, 1519 B — when this was written, re-checked 2026-08-13. The reason is visible in realrebelai's discussion #1, where the QuantStack quantiser says he is still working on his own Q2_K before uploading. If QuantStack ships, re-check the rung table — a different build could move the Q4_K_S near-miss.

You are arriving from the LTX-2.3 recipe on this card

Plausible, since that pair is published here — though note it is published and not benchmarked: that page is also verdict: unknown with zero benchmarks, so it is a derived recipe like this one. Almost nothing carries over, and on this card the gap is wider than the file list suggests.

• The transformer does not. A 2.3 GGUF will not load into a 2.5 graph, and vice versa — see the shape-mismatch section above.
• The text encoder does not. LTX-2.3 conditions on Gemma 3; LTX-2.5 conditions on a Gemma 4 12B carrying LTX's own projections, and ComfyUI's own comfy/text_encoders/lt.py keeps separate tokenizer paths for the two eras (Gemma3_12BTokenizer against ltxav_gemma4_tokenizer). The symptom of getting this wrong is not an error, it is prompts being quietly ignored: in an r/comfyui thread a commenter diagnoses exactly that for someone's 2.5 workflow — "LTX 2.5 uses Gemma4, LTX 2.3 used Gemma3 which you still have there in your workflow".
• The VAEs are the subtle one, and on this card that is the expensive mistake. A report at LTX-2 issue #275 finds every encoder tensor byte-identical between 2.3 and 2.5, with only the video decoder differing. That is why keeping an old VAE appears to work — it generates, it just decodes with the wrong half. Given that the decoder is what every RTX 5070 Ti report on this model turned out to be about, download the 2.5 files and take the conv one.

The install shape is different too, and more so here than on our other 16 GB pages. The published LTX-2.3 recipe on this card fits the model by forcing the Gemma 3 12B encoder off the GPU entirely — --novram or --reserve-vram 10, a separately quantised GGUF encoder, and the vendor's ComfyUI-LTXVideo pack alongside KJNodes. None of that applies to 2.5 under ComfyUI core: the encoder is a sequential stage the graph already evicts by itself, there is no launch flag to set, no vendor node pack, and the lever is the transformer's quantisation rung instead. If you keep the 2.3 install, keep it in a separate ComfyUI directory — mixing template package versions across two installs that share one environment is a documented way to silently lose the LTX-2.5 templates.

Something else

The space searched, so you can judge the negatives above. All 30 Lightricks/LTX-2.5 Hugging Face discussions were enumerated individually and every message grepped: exactly one mentions this card. The discussions on all eight community LTX-2.5 quant and redistribution repos were enumerated the same way: zero mentions. The Comfy-Org/ComfyUI, city96/ComfyUI-GGUF, Lightricks/LTX-2 and Lightricks/ComfyUI-LTXVideo trackers were walked issue-by-issue over their most recent 300 each (Lightricks/LTX-2 in full, #1–#281): no issue mentions both this card and LTX-2.5, and every 5070 hit in the ComfyUI tracker is a MiniMax H3 report. On Reddit — searched through old.reddit.com, because www.reddit.com serves crawlers an empty shell and a zero result there means nothing — more than a dozen query variants were run across r/StableDiffusion, r/comfyui and site-wide, and every candidate thread was then fetched in full and grepped rather than judged from its title. That last step is what found the three threads quoted above: none of them came back from a query naming this card. Not searched: CivitAI, YouTube, Discord and X — Discord being the likeliest place for reports this page has missed. Everything attributed above is quoted from the thread it links to; nothing is inferred from a summary. Report problems, or the first instrumented measurement, via the submission form.