LTX-2.5 on RTX 4070 Ti SUPER: 22B audio-video in 16 GB the plain Ti does not have

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 4070 Ti SUPER, 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 4070 Ti SUPER (16GB VRAM, 256-bit GDDR6X, Ada Lovelace) · resident weights 13.354 GiB of 16 GiB on the lead rung — derived from file bytes, not measured on this card · See benchmark data

⚠️ Read this before you download 37 GiB: the RTX 4070 Ti and the RTX 4070 Ti SUPER are different cards, and only the SUPER can run this recipe. NVIDIA's own RTX 4070 family spec table puts them side by side: the 4070 Ti SUPER is 16 GB GDDR6X on a 256-bit interface with 8448 CUDA cores, and the 4070 Ti is 12 GB GDDR6X on a 192-bit interface with 7680. Both are Ada Lovelace, both are called "4070 Ti", and one word separates them on the box.

The lead rung below needs 13.354 GiB of weights resident at once, before a single activation. Twelve gigabytes does not hold that, and no rung on the ladder gets a 22B audio-video DiT plus two VAEs plus a spatial upscaler under 12 GiB with room left to sample in. If your card is the 12 GB 4070 Ti, this recipe is not for you — see what the catalogue does have for that card instead. The same warning covers the RTX 4070 SUPER, a third similarly-named card that the same NVIDIA table lists at 12 GB on 192-bit. Check the sticker, not the memory.

⚠️ Nothing on this page was measured on this card. /check/ltx-2-5/rtx-4070-ti-super 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 4070 Ti SUPER. If you run this pair, contribute your numbers — one instrumented run would settle the only open question on this page.

ℹ️ What transfers from the one card that has been measured, and what does not. Our RTX 5060 Ti page is backed by fifteen instrumented runs on the site operator's own card. That card is also 16 GB, so the file set, the fit arithmetic and the workflow carry over intact. What does not carry over is any number describing how the card behaved — peaks, timings, throughput. Those belong to the RTX 5060 Ti and are labelled as such wherever they appear below. The install path is the one thing that genuinely differs, and it differs in your favour: that card is Blackwell and needed a CUDA 12.8 build to exist at all.

ℹ️ 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. "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. 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 carries gated: "auto", so an unauthenticated request to any file under it returns 401 (re-verified 2026-08-13 against the conv video VAE). 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 copies exist for all four gated 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, 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, CUDA context and whatever the desktop is holding. The three non-transformer files sum to 2.620 GiB and are fixed — the same on every rung, which is what makes the ladder below a straight comparison of transformer files.

That 13.354 GiB figure is also the whole reason the 12 GB 4070 Ti is excluded rather than merely tight: the weights alone overrun a 12 GiB card by 1.354 GiB before anything is computed. This is a capacity wall, not a tuning problem.

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, read 2026-08-13, 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.

Three things worth reading twice.

The same nominal quant differs by 1.302 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 on its own, 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.

The publisher's recommended rung does not fit. realrebelai's README marks Q4_K_M as **Recommended**, and at 14.050 GiB of weights 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 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 RTX 5060 Ti session ever recorded above the same weight sum, and on that card the same rung projected 64 MiB over the capacity the card reports, i.e. the question was decided inside half a percent. Nobody has tried it here, and this card's usable capacity has never been read. 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.

A further publisher, hours old, that is smaller because it gives up the thing this page protects

joeygambino/LTX-2.5-Quantized was created at 10:55 UTC on 2026-08-13 — hours before this page was written — and had 0 downloads and 0 likes when it was read. It ships seven GGUF rungs of the distilled DiT, and on paper they look like the answer to this card:

It is not the lead, and the reason is a specific tensor-level difference — worth stating precisely, because the obvious summary of it is wrong. Both files' headers were range-read on 2026-08-13, same method, same day. Both carry 4349 tensors and the same 2199-character config blob, so both will load. Both have exactly 620 gate-named tensors. The split inside those 620 is where they part:

So the gate-logit weight matrices are quantised here and are not in the lead, and that is the whole difference in kind. Note what this does not say: joeygambino's README states that its 304 gate-logit biases stay F16 "like every other bias", and that is true — the biases are not the tensors that moved. Anyone checking the README against the header and stopping at the word "gate" will conclude the two builds agree. They do not.

Those weight matrices are the audio-video mixing gates whose protection this page's Results section is built on, and whose quantisation the lead's own publisher describes as the failure that leaves "video still looks fine while audio desyncs or degrades". joeygambino also stores every other tensor at F16 where the lead keeps 2603 at F32. So it is smaller partly by a blanket precision drop and partly by quantising the one family the lead deliberately spares.

That may be a perfectly good trade if you do not care about the soundtrack, and its Q4_K_M is the only Q4_K_M anyone has published that fits this card — every other publisher's is over, the lead's included, though the two Q4_K_S rungs in the ladder above do fit. But nobody has run any of it: the repo has zero discussions, zero downloads and zero likes, and no listening test on any card has been published. Treat it as the most interesting experiment on this page, not as an install path — and if you try it, report what the audio does, because that is the axis in question.

The same repo carries comfy-int8, nvfp4, w4a4, w4a8 and two mix4x8 safetensors builds, none of them GGUF. Its README — pinned to a commit, because the repo was renamed out of LTX-2.5-Quantized-16GB hours before this page was written, and HuggingFace can let a vacated name be reclaimed by someone else — is unusually candid about their limits and it is the only source found for this page that names this card at all — flagging that w4a4 and nvfp4 "were built and tested on a Blackwell card" and that neither has been "run here on an Ada or Ampere 16 GB card", with the 4070 Ti SUPER named among the cards where a slow fallback is "a real possibility and worth reporting". That is a caution about the non-GGUF routes, not a report of anyone running this model on this card, and it points the same way as the NVFP4 gate below.

Where this card sits: a wide bus on an older architecture

This card is the intersection of the two halves of our 16 GB tier, and it is worth being precise about which half governs what.

The 256-bit bus is the widest in the tier, and it buys nothing on the axis that decides this page. Every verdict in the ladder above is a capacity verdict, and bandwidth 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. The lead rung is the same rung, for the same reason it is on the 128-bit cards in this tier. Where the bus 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 its linear layer calls cast_bias_weight and then a plain torch.nn.functional.linear. Every forward pass 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. A GGUF graph is unusually memory-bound, so a wide bus 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 factor or percentage appears on this page. NVIDIA publishes no memory-bandwidth figure for this card on its own product page, so there is nothing honest to take a ratio of.

The Ada architecture is what closes a door, and this is the real difference from the Blackwell cards in this tier. ComfyUI gates its native NVFP4 kernels in comfy/model_management.py (lines 1969–1977 at the pinned commit), and the gate is four lines long:

def supports_nvfp4_compute(device=None):
    if not is_nvidia():
        return False

    props = torch.cuda.get_device_properties(device)
    if props.major < 10:
        return False

NVIDIA's CUDA-GPU list puts every GeForce RTX 40-series entry it names at compute capability 8.9 and every GeForce RTX 50-series entry at 12.0. Major version 8 is below 10; major version 12 is above it. So the generational line that function draws runs exactly between Ada and Blackwell, and this card is on the Ada side of it: the nvfp4 route runs, but through a fallback rather than through NVFP4 tensor cores. DmitryDB's own card describes its rebuild in exactly those terms — "Smallest transformer route; supported fallback on RTX 4090 and native acceleration on supported Blackwell hardware." — and the RTX 4090 it names as the fallback case is an Ada card, same as this one. That, plus the 0.740 GiB of headroom it leaves and the author's statement that "These are community conversions, not official Lightricks or ComfyOrg releases.", is why it is not the lead here and would not be even if it were faster.

A precision note on the capability figure. NVIDIA's CUDA-GPU list names base models — GeForce RTX 4070 Ti appears in the 8.9 row; the SUPER refreshes are not listed individually. NVIDIA's spec table above states the architecture of this card directly ("Ada Lovelace"), and every Ada GeForce part NVIDIA does list sits at 8.9. This page treats sm_89 as an inference from those two published facts rather than as a line item, which is what it is.

One warning you will probably see, and it is not about your architecture. ComfyUI ships comfy-kitchen pinned in its own requirements.txt and disables that backend's CUDA kernels on any torch build older than CUDA 13.0 — comfy/quant_ops.py tests cuda_version < (13,) and logs "You need pytorch with cu130 or higher to use optimized CUDA operations." The warning's own second line names the audience — "If you are on nvidia 20 series and above it is required that you update your pytorch to cu130 or higher." — so this is a torch-build gate, not a Blackwell gate, and it applies to this card exactly as it does to a newer one. It is also irrelevant to the GGUF path this recipe leads with, because ComfyUI-GGUF brings its own dequantisation and never touches those kernels. It matters only if you go off and try one of the quantised-safetensors routes.

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: the file set, the arithmetic, and the fact that the GGUF rung does not buy arithmetic throughput — it saves 9.293 GiB against the official INT8 transformer, which is what makes the model fit at all, and pays for that in dequantisation work on every forward pass.

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 an r/comfyui thread and from Lightricks/LTX-2.5 discussion #15, 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.

Not known: any seconds-per-frame figure on an RTX 4070 Ti SUPER. There is no benchmark at /check/ltx-2-5/rtx-4070-ti-super, and no community report of this pair surfaced on any surface searched for this page (the space searched is listed at the end). The measured sibling's throughput constant is a property of a Blackwell card and is deliberately not reproduced here, rescaled or otherwise; a number derived from a spec-sheet ratio looks measured and is not. 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. Master was b323a345 when this was written, and running master is the safe default — but be clear about why, because the obvious reason does not survive checking. The one post-tag commit that names LTX, bd34f338 "Fix float64 device in ltx diffusion decoder." (#15516), touches exactly one file — comfy/ldm/lightricks/vae/na_diffusion_decoder.py, the diffusion decoder. This recipe installs the convolutional VAE instead, so that fix does not apply to the path documented here and the v0.32.0 tag is sufficient for it. Take master anyway if you are choosing today, and take it specifically if you ever switch to the diffusion decoder — which is one more small reason to stay on the conv file.

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 a Blackwell sibling's torch pin. The measured RTX 5060 Ti session ran a CUDA 12.8 nightly because its card is Blackwell, sm_120 — a target that stable wheels did not carry at the time. This card is Ada Lovelace, an older and long-supported target, so install torch the ordinary way from requirements.txt and skip the nightly. Our LTX-2.3 recipe on this same card reaches the same conclusion for the same reason.

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. This is a live distinction on this card, because the published LTX-2.3 recipe here does install that pack.

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, 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, where the first-party paths return 401. Prefer first-party where you can; these are not all the same kind of thing.

• 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 repo also carries the diffusion video VAE and the temporal upscaler, likewise blob-identical, neither of which this recipe uses.

The LTX-2 Community License travels with the bytes, so what you are agreeing to is easier to work out 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. On comfyui-workflow-templates 0.11.40 — the version ComfyUI's requirements.txt currently pins — 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.

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 78–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-4070-ti-super holds zero benchmarks, no community report of anyone running LTX-2.5 on an RTX 4070 Ti SUPER surfaced on any surface searched for this page (one quantiser's README names the card, but only to warn that its non-GGUF builds are untested on Ada — see the rung section), and the only instrumented run of this recipe's path anywhere is on a Blackwell card, whose seconds do not transfer to Ada and are not rescaled here. See "What it costs in time" above, 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 14.317 GiB text encoder is a sequential stage and is not additive. For a sense of what that 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 across fifteen runs, with zero OOM — though note the worst of those peaks reached 15912 MiB of the 16311 MiB that card reports, so "no OOM" there meant roughly 400 MiB of margin, not a comfortable one. Read it as the shape of the overhead, not as a prediction for this card — those samples include a different machine's desktop, driver and allocator.
• 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.
• Quality notes: The lead build protects the tensors that carry audio-video sync. Reading its GGUF header directly over an HTTP range request on 2026-08-13: of 4349 tensors, 620 carry gate in the name and not one of them is quantized — every one is F32 or F16 — while 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, so treat that as a statement of intent rather than a measured quality claim.
• Image-to-video: The same six-file manifest drives video_ltx2_5_i2v, with the identical VAEDecodeTiled and guider defaults, so everything above transfers. One behaviour worth knowing before you count pixels: ResolutionSelector is a scale hint in i2v, because the frame geometry comes from the input image's aspect ratio — so the megapixel figure you ask for does not determine the frame on its own, 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-4070-ti-super.

Troubleshooting

size mismatch for keyframes_abs_pos_embedding... 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 no stock GGUF conversion emits an 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 — keyframes_abs_pos_embedding at [4096] against [1, 4096], learnable_registers at [128, 2048] against [128, 3840]. It is reported on a 16 GB card driving exactly this path 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 hardware line in the same issue body reads "Sapphire Nitro 7800XT , 16GB", so that is a 16 GB AMD card rather than this one — the failure is about the file, not the vendor. The issue is now closed (state re-read 2026-08-13) and the reporter never named which publisher's GGUF he used.

Fix: use a build whose author solved 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 first mismatch above, stored one-dimensional in the file because 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 VAE Decode (Tiled) widgets in the two templates this recipe uses, video_ltx2_5_t2v and video_ltx2_5_i2v, from [768, 64, 4096, 32] to [512, 64, 64, 16] — tile 768→512, temporal size 4096→64, temporal overlap 32→16. (It touches a third LTX-2.5 template, video_ltx2_5_flf2v, whose previous overlap was 64 rather than 32; this recipe does not use it.) The change ships 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 in an r/comfyui thread an RTX 5090 owner advises 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", reporting that the stock settings capped him at 10-second clips and crashed his card. 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. The number that actually bites is the temporal one: at 4096 the decoder is not tiling over time at all, which is why these reports cluster on clips past five seconds rather than on large frames. 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 (open) 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 — the governing boolean is the widget on the outer subgraph node, and it is true in both video_ltx2_5_t2v and video_ltx2_5_i2v (re-read from the template JSON on 2026-08-13; do not check this by reading the inner nodes, which are overridden by links and disagree with each other). 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; 32 GB is workable with the pagefile sorted first.

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

Plausible, since that recipe is published — though note it is published and not benchmarked: that pair also reads verdict: unknown with zero benchmarks, so neither LTX page for this card rests on a measurement. 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.
• The VAEs are the subtle one. Download the 2.5 files; keeping the old VAE appears to work because it generates, it just decodes with the wrong half.

The 16 GB strategy is different in kind, and on this card specifically it is nearly inverted. The published LTX-2.3 recipe here is built around CPU-offloading the Gemma 3 encoder — that is the whole title of it — and asks for 64 GB of system RAM to do it. Under LTX-2.5 the encoder is not something you arrange to offload: ComfyUI already runs it as a discrete stage and evicts it before sampling, so the lever moves to the transformer's quantisation rung instead. If you came here expecting to reproduce the offload trick, the answer is that the graph does it for you and the thing you now tune is which GGUF you downloaded.

The LTX text encoder: stock ComfyUI-GGUF cannot load one, and a patched route just appeared

The conditioning encoder. Two separate things are true here and the page said only the first of them until it was checked again.

Stock ComfyUI-GGUF cannot load a Gemma 4 text encoder. That has not changed, and it is one line of source: loader.py declares TXT_ARCH_LIST = {"t5", "t5encoder", "llama", "qwen2vl", "qwen3", "qwen3vl", "gemma3"} at line 13 and raises the Unexpected text model architecture type error at line 108 for anything outside it. gemma3 is on that list; gemma4 is not. Same mechanism as the enhancer failure described below.

A GGUF of the projection-carrying encoder now exists, and it ships a patch. elix3r/gemma4-12b-with-proj-ltx-2.5-GGUF carries gemma4-12b-with-proj-ltx-2.5-Q5_K_M.gguf at 9,514,920,864 B (8.861 GiB) — 5.456 GiB lighter than the first-party INT8 encoder — alongside patches/ComfyUI-GGUF-ltx25-gemma4.patch, a QUANTIZATION.md, a SHA256SUMS and two example workflows. The GGUF's byte count is the only figure here worth pinning, because it is the only one that has held still: the patch measured 1,594 B when a first reader checked it and 1,711 B when this page checked it forty minutes later, and over the same window the README went 4,457 → 13,445 B and QUANTIZATION.md 1,248 → 3,969 B. Read every auxiliary size in this paragraph as an observation with a timestamp on it rather than as a property of the repo — it was being actively written while this was being written about. The same author published a transformer sibling, elix3r/LTX-2.5-22b-distilled-GGUF, three seconds earlier; its only rung is a Q5_K_M at 16,878,535,040 B, which comes to 18.339 GiB resident and is therefore out on this card, so no verdict in the ladder above moves.

What is and is not established about it. Both repos were created at 18:04 UTC on 2026-08-13, have 0 downloads and 0 likes, and are gated: auto — the weight file, the README, the patch body and QUANTIZATION.md all return 401 to an unauthenticated request. So the existence, filename, byte size, tags and declared base model come from the public model and tree APIs, and nothing here says the file loads, or that the conversion is faithful, or that the patch applies. Nobody has run it.

Why a one-word patch would not be enough — and this part you can check without accepting any licence. It would be easy to assume the fix is to add "gemma4" to TXT_ARCH_LIST and be done. The source says otherwise, and it says so in a way that should worry you more than a hard error would. TXT_ARCH_LIST at line 13 is only the first of two membership tests in loader.py. The second is at line 482 — elif arch in {"llama", "qwen2vl", "qwen3", "qwen3vl", "gemma3"}: — and three things live behind an exact arch == "gemma3" comparison inside it: the tokenizer load (sd["spiece_model"] = gguf_gemma3_tokenizer_loader(path), line 490), the tensor renaming (sd_map_replace(sd, GEMMA3_SD_MAP), line 495) and the normalisation fix (gemma3_norm_corrections(sd), line 496). An architecture matching neither branch falls through to else: pass at lines 504–505 and the state dict is returned untouched.

So clearing the raise alone buys you a load with no tokenizer, no tensor renaming, no norm correction and no exception — a silent failure rather than a loud one, which is the worst shape a failure can take on a file you cannot easily inspect. Whatever that 1.7 KB patch does, it has more than one place to reach. Until somebody publishes a run, 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. If you take the patched route, say what happened — a working GGUF encoder would take 5.456 GiB off the one stage measured to move the peak, which is the single most valuable unknown on this page.

On the counts, and why this page no longer prints a total. An earlier version of this section claimed the index had been paged to exhaustion and gave gemma4 → 1500 repos / 429 GGUF-tagged. That was wrong twice over: the run stopped at 15 pages of 100, and the word "exhaustion" was doing work the method had not earned. Following the API's Link: rel="next" header to natural termination on 2026-08-13 gives 101 pages, 10,072 unique ids and 2,992 GGUF-tagged for gemma4, and a single page — 36 ids, 6 GGUF publishers — for ltx-2.5. Under that sweep the encoder repo above is in the result set, so the number and the conclusion were wrong together. Two lessons the reader can use: filter on the gguf tag rather than on the repo id, because publishers whose id lacks the string are otherwise dropped silently; and treat any total as a timestamp rather than a fact — an independent sweep run minutes apart from this one returned 10,071 and 2,991.

LTX-2 issue #278 — which opens "Please release the GGUF series as soon as possible" and singles out the projection-carrying encoder by name — is still open and still unanswered by Lightricks as of 2026-08-13. It is now a request that somebody outside Lightricks has answered.

The prompt enhancer is a different model and a different failure. Loading a GGUF Gemma 4 into the Generate LTX2 Prompt node fails inside ComfyUI-GGUF with ValueError: Unexpected text model architecture type in GGUF file: 'gemma4'. That error is reported by the author of ComfyUI-GGUF issue #474, who posted his own traceback; the issue is open as of 2026-08-13 and city96 has not responded. Read it as one reproduction rather than as a chorus — of the handful of replies on it, one is from this site's own operator, and we are not going to cite ourselves back as independent corroboration. Worth separating from the paragraph above, because the two are routinely conflated: the enhancer is the optional 9.573 GiB stage this recipe turns off anyway, so quantising it saves nothing you cannot save by leaving it off.

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. Other publishers filled the gap instead — the three named in the ladder above, plus two more that appeared while this page was being written. There is reason to expect it to change: in realrebelai's discussion #1 a participant writes "im going to uploaded them on QuantStack" once he has finished testing his own Q2_K. If they land, re-check the rung table — a different build could move the Q4_K_S question.

Something else

The space searched, for evidence about this exact pair. All 30 Lightricks/LTX-2.5 Hugging Face discussions were enumerated individually and every message body grepped for GPU model numbers: no 4070 of any kind appears in any of them (the cards that do appear are the 3090, 5090, 3060, 5070 Ti and 2080 Ti). The discussion tabs of every community LTX-2.5 quant repo known at the time were enumerated. One source names this card: joeygambino's README, quoted above, warns that its w4a4 and nvfp4 builds have not been run on an Ada 16 GB card and names the 4070 Ti SUPER as a place a slow fallback could show up. That is a caution about untested files, not a report of anyone running LTX-2.5 on this card, and it is the only mention of the card found anywhere. The ComfyUI, ComfyUI-GGUF and Lightricks/LTX-2 issue trackers were searched for this card and returned nothing on it. Five Reddit searches were run through old.reddit.com, which returns real result pages where www.reddit.com serves an anti-bot shell: LTX 2.5 4070 Ti Super, LTX-2.5 4070 Ti, "LTX 2.5" 4070, LTX 2.5 4070 Ti SUPER 16GB, 4070 Ti Super LTX. They return plenty of RTX 4070 Ti SUPER posts and plenty of LTX posts; no post has both with LTX-2.5. The nearest misses are an LTX-2.3 run on this card and a post whose author has a 12 GB RTX 4070 SUPER — a different card again, which is the naming trap at the top of this page seen from the wild. Not searched: CivitAI, YouTube, Discord and X. Report problems, or a first measurement, via the submission form.