LTX-2.5 on RTX 4060 Ti 16GB: 22B audio-video in 16 GB via a community Q3_K_M GGUF

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 4060 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, and it does not fit here. The GGUF rung does.

Hardware data: RTX 4060 Ti 16GB (Ada, sm_89) · resident weights 13.354 GiB of 16 GiB on the lead rung — derived from file bytes, not measured on this card · See benchmark data

⚠️ Nothing on this page was measured on this card. /check/ltx-2-5/rtx-4060-ti-16gb reads verdict: unknown with zero benchmarks as this is written, and this recipe does not pretend otherwise. What you get below is the file set, the byte arithmetic, and the workflow — all of which are properties of the model and of ComfyUI, not of the card. What you do not get is a single second or a single megabyte observed on a 4060 Ti. Our RTX 5060 Ti page is measured; that is a different card and its numbers stay on its page. If you run this pair, contribute your numbers — one instrumented run would make this the best-documented 16 GB page for this model.

ℹ️ The one finding that does transfer, because it is a property of the pipeline. On the measured RTX 5060 Ti, peak VRAM did not scale with frame size or clip length: across an 11.3× range of frame area and a 3.9× range of frame count the peak stayed inside a narrow band, and the largest job of that session produced the lowest peak. What moved the peak was the 14.317 GiB text encoder re-entering VRAM when the prompt text changed, on top of the transformer ComfyUI keeps resident between jobs. That is a consequence of how ComfyUI stages this graph — encode, evict, sample, upscale, decode — and it is the same graph here. Operationally: fix the prompt first, then tune size and duration, and expect a prompt edit to be the expensive operation rather than a bigger frame.

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. This card already has a published LTX-2.3 recipe, so this is worth spelling out: no LTX-2.3 GGUF will load here, and the 2.3 text encoder is the wrong model entirely (2.3 conditions on Gemma 3, 2.5 on a projection-carrying Gemma 4). See Troubleshooting if you are arriving with a 2.3 install on disk.

ℹ️ Gated weights. Lightricks/LTX-2.5 is gated, so an unauthenticated request to any file under it returns 401 (verified 2026-08-13; the sibling Lightricks/LTX-2.3 repo returns a redirect on the same shape of request, so the gate is new for 2.5). Accept the licence on the model page and run hf auth login with a Read token before the download step. ComfyUI's own template says as much in a note: "Before you download all the models, please make sure you have granted access to" LTX-2.5 first. The weights are under the LTX-2 Community License, not Apache-2.0. Ungated third-party rebuilds exist for the text encoder and both VAEs — 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, and on this card it is a non-starter. 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 and CUDA context. That is the whole fit argument, and it is card-independent — the same four files, the same bytes, on any 16 GB card. For a sense of what the gap actually gets spent on: on the measured RTX 5060 Ti, whole-card peak across fifteen runs ran between 0.47 and 2.19 GiB above this same weight sum. Read that as the shape of the overhead, not as a prediction for this card — those samples include a different machine's desktop, driver and allocator.

The 14.317 GiB text encoder is excluded from that sum on purpose. Adding it gives 27.671 GiB, which fits nothing here. ComfyUI encodes the prompt as its own stage and evicts the encoder before sampling, so the two are sequential rather than simultaneous — which is also why a prompt change is the expensive operation, and why the system-RAM requirement is real rather than decorative.

The rung ladder

Every figure below is a file size from the publishers' tree APIs plus the 2.620 GiB of VAEs and upscaler that ride along in every case. None of it is measured on this card; the last column is arithmetic against a nominal 16 GiB.

Two things worth reading twice.

The same nominal quant differs by 1.3 GiB between publishers. Q3_K_M is 10.734 GiB from realrebelai and 12.036 GiB from the other two, at an identical 4349-tensor count. The name describes a recipe, not a file; which tensors stay at higher precision is the publisher's choice. It runs the other way too — vantagewithai's Q2_K is 11.292 GiB, larger than realrebelai's Q3_K_M. Pick the file, not the label. And note that realrebelai's README rounds its own size column loosely (Q4_K_M | ~13 GB against a real 15,086,587,904 B); when a rung is close, go by the tree API bytes.

Q4_K_S is the interesting failure. Its weights alone need 15.522 GiB of a nominal 16, leaving 0.478 GiB — less than the smallest overhead the measured 5060 Ti session ever recorded above the same weight sum, and on that card the same rung projected 64 MiB over its usable 16311 MiB, i.e. the question was decided inside half a percent of the card. Nobody has tried it here. Treat it as one deliberate experiment (fresh start, cached prompt, decode tile left alone), not as something to plan a workflow around — and if you do try it, tell us what happened.

What it costs in time — the part nobody has measured

This is the honest weak spot of this page, so here is exactly what is and is not known.

Known, from NVIDIA's own spec pages: the RTX 4060 Ti carries 16 GB GDDR6 on a 128-bit interface and is Ada Lovelace (NVIDIA RTX 4060 family); the RTX 5060 Ti behind our only measured run carries GDDR7 on the same 128-bit interface and is Blackwell (NVIDIA RTX 5060 family). NVIDIA publishes no memory-bandwidth figure for either card on those pages, so this page prints no bandwidth ratio. Same bus width, older memory generation, older architecture: slower here than there, by an amount nobody has measured.

Known, from the runtime's source: the GGUF rung does not buy arithmetic throughput. ComfyUI-GGUF's GGMLOps exists to "Dequantize weights on the fly before doing the compute", and its linear layer does exactly that — cast_bias_weight and then a plain torch.nn.functional.linear (ops.py). There is no quantized GEMM here of the kind llama.cpp gets on LLMs: every step still reads the transformer and computes at the input dtype, with dequantisation added on top. The rung saves 9.293 GiB against the official INT8 transformer, which is what makes the model fit at all; it costs a little time rather than saving it, and that cost lands on the memory system.

Known, from the community, on other hardware: the stage people report as slow on LTX-2.5 is the VAE decode, not sampling. Reports of it hanging or dragging come from a 5090 owner and from a 5070 Ti owner, and the fix in both cases is the tiled-decode settings the current template already ships. See Troubleshooting — that section is not optional reading here, it is the difference between a working install and a stall.

Not known: any seconds-per-frame figure on an RTX 4060 Ti. There is no benchmark at /check/ltx-2-5/rtx-4060-ti-16gb, no community report of this pair on any surface searched for this page, and no vendor table that names the card. The sibling page's throughput constant is a measurement of a Blackwell card and is deliberately not reproduced here, rescaled or otherwise; inventing a ratio out of a bandwidth guess would be exactly the kind of number this site exists not to publish. Start at 0.4–0.6 MP and 49 frames, watch where the wall-clock actually goes, and contribute the numbers.

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: the tag commit is dated hours before bd34f338 "Fix float64 device in ltx diffusion decoder" (#15516), so a plain v0.32.0 checkout does not contain it — and decode is the stage this model is reported to struggle in. Master was b323a345 when this was written.

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.

Do not copy the sibling's torch pin. The measured RTX 5060 Ti session ran a CUDA 12.8 nightly because its card is Blackwell, sm_120. This card is Ada Lovelace, compute capability 8.9 on NVIDIA's own CUDA-GPU list — an older target than the one that forced that build — so install torch the ordinary way and skip the nightly. Our LTX-2.3 recipe on this same card reaches the same conclusion.

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. Per the pack's README, "Simply use the GGUF Unet loader found under the bootleg category. Place the .gguf model files in your ComfyUI/models/unet folder."

You do not need the Lightricks ComfyUI-LTXVideo pack. 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 — read straight out of 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. Two of the six are the ones people miss:

• The latent spatial upscaler is not optional garnish. The shipped template is two-stage — sample at half resolution, upscale the latent ×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.

Two deliberate substitutions against the template's defaults, both driven by the 16 GB budget:

• GGUF instead of the official INT8 transformer — 10.734 GiB against 20.027 GiB.
• The convolutional video VAE, not the diffusion one. The template ships ltx-2.5-video-vae-bf16.safetensors (1.371 GiB); our 24 GB anchor prefers ltx-2.5-video-vae-conv-bf16.safetensors (1.353 GiB), and the vendor's own workflow note rates that file "Lower memory & faster" against the diffusion decoder's better quality (LTX-2.5_T2V_I2V_Single_Stage_Distilled.json). On a card this tight, and this reliant on decode being cheap, take the lighter decoder. It is also the decoder that the one open gray-tile report does not implicate — see Troubleshooting.

If you would rather not deal with the gate. Ungated copies exist for all four gated files, and each returned 302 unauthenticated on 2026-08-13. Prefer first-party where you can.

• 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 (14.317 GiB). 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 reports gated: false and carries all three under split/ — split/vae/ltx-2.5-video-vae-conv-bf16.safetensors (1,452,269,922 B), split/vae/ltx-2.5-audio-vae-bf16.safetensors (364,866,540 B) and split/latent_upscale_models/ltx-2.5-latent-spatial-upscaler-x2-bf16-1.0.safetensors (995,778,752 B). These are not rebuilds: each one's git blob oid is identical to the first-party entry for the same path (2905ee1b…, 08403b5a…, cec7bee6…), so the content is the same file, not merely the same size. The temporal upscaler is there too, which this recipe does not use.

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. On comfyui-workflow-templates 0.11.40 this is video_ltx2_5_t2v; the image-to-video sibling is video_ltx2_5_i2v and behaves identically for everything below. Both are in the shipped package, dated 2026-08-11.

The whole graph is wrapped in one subgraph, and the loaders' widgets are promoted onto the outer node — which is why the model field on the outer node cannot be re-wired, a design that has already produced its own ComfyUI issue. 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 quantiser's README puts the whole procedure in one line: "Everything else stays as the template ships it."

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]. Leave all three alone.

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, lines 77–81). 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 the node's own formula:

Note 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. On an unmeasured card, 0.4 MP is the sensible first target — memory is not the constraint at any rung on this ladder, wall-clock is, and you want a cheap first datapoint before you spend twenty minutes on a 2.0 MP one.

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; several community reports in Troubleshooting below put the trouble threshold at long clips rather than large frames, so grow duration last.

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: Omitted — there is no measurement for this pair. /check/ltx-2-5/rtx-4060-ti-16gb holds zero benchmarks, no community report of LTX-2.5 on an RTX 4060 Ti surfaced on any surface searched for this page, and the only instrumented run of this recipe's path anywhere is on a Blackwell card, whose seconds do not transfer to Ada. See "What it costs in time" above for the reasoning, and /contribute to end this bullet.
• VRAM usage: Derived, not measured: 13.354 GiB of resident weights against a nominal 16 GiB, leaving 2.646 GiB for activations, latents and context. The text encoder's 14.317 GiB is a sequential stage and is not additive. The one measured card on this path never came close to OOM at any resolution tried — see /check/ltx-2-5/rtx-5060-ti for that data, and note it is a different card.
• Resolution ceiling: Not established here. On the measured sibling both 2.0 MP and 8 s were reached without hitting one, in separate runs rather than a single one, and the binding constraint there was wall-clock rather than memory. Given identical weights and an identical graph, expect the same shape of limit on this card and a lower ceiling on patience.
• Quality notes: The lead build protects the tensors that carry audio-video sync. Reading its GGUF header directly: of 4349 tensors, 620 carry gate in the name and not one of them is quantized (316 F32, 304 F16); only 1072 tensors are actually Q3_K. 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 rates this rung "Usable, softer detail"; no side-by-side against the INT8 checkpoint has been run on this card.
• Image-to-video: The same file set drives video_ltx2_5_i2v. One behaviour worth knowing before you count pixels: ResolutionSelector is a scale hint in i2v, because the frame comes from the input image's aspect — so i2v frames run larger than the t2v ladder predicts (observed on the measured sibling), which on a card without a measured clock is a direct wall-clock surprise.

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

Troubleshooting

size mismatch for audio_embeddings_connector... on the GGUF loader

The most common failure on this 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 GGUF 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 — learnable_registers at [128, 2048] against [128, 3840], scale_shift_table at [9, 4096] against [6, 4096], keyframes_abs_pos_embedding at [4096] against [1, 4096]. It has been reported on a 16 GB card driving exactly this path — shipped template, UnetLoaderGGUF, a Q4_K_S GGUF — at ComfyUI issue #15540, by a user on an RX 7800 XT 16GB who does not say whose build he used.

Fix: use a build whose author fixed it. Reading the lead file's GGUF header over an HTTP range request on 2026-08-13 shows both halves of the fix present: a 2199-character string KV named config describing an AVTransformer3DModel, which ComfyUI-GGUF/loader.py surfaces to ComfyUI as metadata, and a comfy.gguf.orig_shape.keyframes_abs_pos_embedding key holding [1, 4096], which the same file's get_orig_shape reads back — the exact tensor in the third mismatch above. The README explains why that key is needed at all: the shape is recorded "since ggml trims trailing singleton dimensions on rewrite". Do not roll your own conversion.

Decoding hangs, or takes far longer than sampling

The most-reported LTX-2.5 problem across the surfaces searched for this page, on every card size, and it is fixed by defaults the current template already ships — which is why the "leave VAEDecodeTiled alone" instruction above is not a formality.

Commit c74863f8 (2026-08-12) changed the LTX-2.5 templates' VAE Decode (Tiled) widgets from [768, 64, 4096, 32] to [512, 64, 64, 16] — tile 768→512, temporal size 4096→64, temporal overlap 32→16 — shipping in comfyui-workflow-templates 0.11.40, which is what ComfyUI's requirements.txt pins today. That is exactly what the community had converged on independently: in Lightricks/LTX-2.5 discussion #15 a user on a 16 GB RTX 5070 Ti writes "Mine got stuck too. I have a 5070ti but I adjusted these and it goes pretty fast." and names temporal_size: 64 / temporal_overlap: 16 as the fix, while an r/comfyui thread has a 5090 owner advising others to "change the VAE Decode (Tiled) node settings to 512 from 768 for tile size and the temporal size down to 128 from 4096" after his own install could not get past a 10-second clip. All are community members, none from Lightricks.

So: check your comfyui-workflow-templates version before you touch anything else. An install carrying an older package still has the 768/4096 widgets, and every report above is from someone who had them. If you are on the current package and decode is still slow, do not raise the tile size — the fixed-size tiling is what keeps peak memory flat, because a larger frame means more tiles, not a larger buffer. In the same thread a poster reports going the other way (256/32/300/12) with no quality difference he could see; on an unmeasured card that is a reasonable thing to try, and a good thing to report back.

Separately, LTX-2 issue #277 reports gray frame tails from the diffusion video VAE decoder under AUTO tiling, on an A100 80 GB with the vendor CLI. That is a different decoder and a different runtime from this recipe, which uses the convolutional VAE under ComfyUI's explicit tiling — one more small reason to take the conv file.

"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 — prompt_enhance is true on the outer node of both the shipped t2v and i2v templates (verified 2026-08-13 against the template JSON, reading the outer subgraph node rather than the inner widgets, which are overridden by links). The template's own parameter table advertises it as "Toggle the built-in Prompt Enhancer: expands short prompts into rich cinematic instructions at near-zero extra compute". Turn it off for a first run: it is another sequential 9.573 GiB stage, it rewrites your prompt so a first-run comparison is harder to reason about, and at least one user in the decode thread above reports that turning it off is what fixed his decode time — "it went right back to normal decode time when I turned it off".

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.
2. Stop editing the prompt. Re-encoding is the only operation measured to move the peak on the sibling card. Fix the prompt, then tune size and duration.
3. Do not raise the decode tile size. See above.
4. Drop a rung — Q2_K, an 8.228 GiB transformer for 10.848 GiB resident, is the smallest sane one, at a real quality cost.
5. Launch with --lowvram.
6. Fix the pagefile before blaming the GPU. Two of the six files — the 14.317 GiB text encoder and the 9.573 GiB prompt enhancer, 23.890 GiB together — are sequential stages that live in host RAM rather than on the GPU. 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; on the measured 16 GB sibling 31.1 GiB of RAM plus a fixed 32 GiB pagefile was enough and nothing thrashed.

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

Likely, since that pair is benchmarked and published. Almost nothing on disk carries over:

• 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 — the two eras have separate tokenizer paths in ComfyUI's own comfy/text_encoders/lt.py (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. 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 the old VAE appears to work — it generates, it just decodes with the wrong half. In Abiray's repo discussion a user asks exactly this and the publisher tells him to switch. Download the 2.5 files.

The 16 GB fit strategy is also different in kind. The published LTX-2.3 recipe on this card streams the encoder from RAM under --novram; here the encoder is a sequential stage the graph already evicts, and the lever is the transformer's quantisation rung instead.

QuantStack/LTX-2.5-GGUF is empty

If you came looking for the publisher whose LTX-2.3 GGUFs you used, that repo held only a .gitattributes file (1519 B) when this was written — re-checked 2026-08-13. The three publishers named above filled the gap instead. There is reason to expect it to change: in realrebelai's repo discussion a participant says he is preparing quants to upload there. If they land, re-check the rung table — a different build could move the Q4_K_S question.

There is no GGUF path for the text encoder

Only the transformer has one. Substituting a GGUF Gemma 4 for either text-encoder slot fails inside ComfyUI-GGUF with ValueError: Unexpected text model architecture type in GGUF file: 'gemma4' — reported at ComfyUI-GGUF issue #474, open as of 2026-08-13, and asked for again at LTX-2 issue #278. Budget the 14.317 GiB INT8 encoder on disk; it is a sequential stage, so it costs you disk and a prompt-change penalty, not resident VRAM.

Something else

No other widely-reported issues surfaced for this pair in the sources searched — and note that for this card specifically, nothing at all surfaced, in either direction. Report problems, or a first measurement, via the submission form.