LTX-2.5 on RTX 4080 SUPER: 22B audio-video in 16 GB, and why the SUPER badge changes nothing

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

⚠️ Nothing on this page was measured by us on an RTX 4080 SUPER. /check/ltx-2-5/rtx-4080-super reads verdict: unknown with zero benchmarks as this is written, and this recipe does not pretend otherwise. Every VRAM figure below is arithmetic over file byte counts. Our RTX 5060 Ti page is instrumented; that is a different card and its numbers stay on its page.

What this card does have, unusually for a 16 GB page in this catalogue, is two public community reports of LTX-2.5 running on 4080-class hardware — one of them on an RTX 4080 SUPER by name, with timings. They are self-reported Reddit posts, not benchmarks: no instrumentation, no VRAM trace, no controlled configuration. They are quoted, attributed and bounded in "The official INT8 route" below and in Results, and they are worth more than nothing and less than a measurement. If you run this pair properly, contribute your numbers.

ℹ️ If you own a plain RTX 4080, you are in the right place — and that is a finding, not a courtesy. The two cards are near-identical, and the ways they differ are not the ways that decide anything here. NVIDIA's RTX 4080 family spec table gives both cards 16 GB GDDR6X on a 256-bit interface and both as Ada Lovelace; the SUPER's advantage is 10240 CUDA cores against 9728 and 836 AI TOPS against 780. Every verdict on this page is a capacity verdict, and capacity is the one number the two cards share exactly. See "What differs between the RTX 4080 and the SUPER" below for the full table and the one place the distinction could have mattered.

ℹ️ The one finding that transfers, because it is a property of the pipeline rather than of the silicon. 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 it 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 all four first-party files this recipe uses. 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.

Note the yardstick: nominal 16 GiB, not this card's usable capacity, which nobody has reported. The one 16 GB card in this catalogue that has actually been instrumented reports 16311 MiB usable, and that figure belongs to that card, not to this one.

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

Transformer files against a nominal 16 GiB, each plus the fixed 2.620 GiB of VAEs and upscaler. Byte counts are from each repo's tree API, read 2026-08-13. The table is bounded, not exhaustive, and here is the bound: it lists every published rung whose resident total lands under 17 GiB, plus the two first-party checkpoints. Above that line realrebelai, Abiray and vantagewithai ship 15 further distilled rungs between them — Q4_1, Q4_K_M, Q5_0, Q5_1, Q5_K_S, Q5_K_M, Q6_K and Q8_0 in various combinations — and the lightest of them is 17.079 GiB resident, more than a gigabyte past a nominal 16 GiB. A fourth publisher, elix3r, appeared on 2026-08-13 with a single Q5_K_M at 16,878,535,040 B — 18.339 GiB resident, likewise out. None of them changes a verdict, and none is listed below.

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 those rungs, which changes no GiB figure and no verdict, but is worth printing rather than averaging away.

Three things in that table are worth stopping on.

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, 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; 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 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. Note the unit before arguing 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 measured RTX 5060 Ti, adding that delta to the roomiest of fifteen observed peaks landed 64 MiB past the capacity that card reports, so the question was decided there 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.

The official INT8 route, and the one report of it on this exact card

Every 16 GB page in this catalogue has to answer the obvious objection: ComfyUI will stream a model larger than VRAM rather than refuse it, so why quantise at all? On the other 16 GB pages that question is left open for want of evidence. On this card it is not, and the answer is interesting enough to state before the ladder is taken as settled.

In an r/StableDiffusion thread filed 2026-08-11 as a failure report and resolved in its own comments, u/Kind_Owl2245 gives his rig as "4080 Super + 64GB RAM DDR5" and names the model he is loading as ltx-2.5-22b-distilled-transformer-comfy-int8-convrot.safetensors — the official 20.027 GiB INT8 checkpoint, not a GGUF. His pasted console log shows ComfyUI staging it dynamically at 20484MB in the foreground on a 16 GB card, and sampling completing at 8/8 [00:05<00:00, 1.53it/s] before the stall he was writing in about.

The order of what happened next matters, because the two timings come from two different configurations:

1. u/Gsus6677 tells him to drop the decode tile from 768 to 512. That unblocks the first generation, and the OP reports "It took 45 seconds for a 5-second video at 0.9, it seems very fast even without Sage Attention!" — so this figure is on the reduced tile and, crucially, still on the wrong VAE he had not yet discovered.
2. He then tries 1080p and it still crashes in decode. That failure was never a memory ceiling.
3. He finds the actual cause — he had loaded the wrong video VAE — and reports "I solved it, it was the wrong VAE model, with convrot you have to use the Convrot VAE. I reset the value to 768 and now I can also create 1080 videos." … "A 7-second 1080 video was generated in 300 seconds." So the 300-second figure is on the corrected VAE and a tile size back at 768.

A second thread, r/StableDiffusion again, has u/skyrimer3d writing "5 secs 1080p vid on 226 secs on my 4080 is just nuts." He says "my 4080" and nothing more — no VRAM figure, no "SUPER", and no model file — so which of the two cards it is cannot be established, and neither can which checkpoint he ran. Both variants are 16 GB Ada, so the capacity story is the same either way; the timing is not attachable to a configuration.

How to read this, precisely. It establishes that the INT8 offload route runs on this card and is not absurdly slow — that is a real finding and it is more than the sibling 16 GB pages can say. It does not establish a peak VRAM figure, a comparison against the GGUF rung, or a reproducible configuration: no one measured memory, the resolutions are given as template settings rather than pixel dimensions, and the 300-second run was made after raising the decode tile back to 768, which is the opposite of what this recipe advises. Treat these as existence proofs with timings attached, not as benchmarks.

This recipe still leads with the GGUF rung, for three reasons that the reports do not touch: it is the only rung with an instrumented run on any 16 GB card (the RTX 5060 Ti), it fits resident rather than streaming a 20.5 GB working set across PCIe on every step, and its memory behaviour is therefore predictable rather than dependent on how much the desktop happens to be holding. If you have 64 GB of system RAM and would rather run the official checkpoint, the report above says you can — and if you do, contribute a proper measurement, because that is the comparison neither route currently has.

What differs between the RTX 4080 and the SUPER

Worth settling explicitly, because the two names are one word apart and a reader who owns one may well have landed on the other's page. From NVIDIA's own RTX 4080 family spec table:

Not one verdict on this page moves between those two columns. Every verdict here is a capacity verdict — which transformer file fits in 16 GiB alongside 2.620 GiB of fixed companions — and capacity is precisely what the two cards share. The SUPER's 512 extra CUDA cores and 56 extra AI TOPS should make it modestly the quicker of the pair; they do not make Q4_K_M loadable, they do not shrink the first-party nvfp4 file, and they do not change which side of ComfyUI's NVFP4 gate the card sits on, because both cards are Ada. If you own the plain 4080, read every rung, every file path and every widget on this page as written.

Two things this page deliberately does not claim. NVIDIA prints no memory-bandwidth figure for either card on that page, so no bandwidth number and no bandwidth ratio appears anywhere here. And NVIDIA's CUDA GPU compute-capability list does not name the RTX 4080 SUPER at all — the string "SUPER" does not occur on it. What that list does say is that the GeForce RTX 4080 is compute capability 8.9, alongside every other Ada GeForce part; what NVIDIA's product page says is that the SUPER is the same architecture. Those are the two statements this page rests on, and they are worth separating from the confident "sm_89" you will see asserted elsewhere, including in our own older recipes.

The Ada line: nvfp4 is a fallback here, not an accelerator

This is the one genuine architectural difference between this card and the 16 GB Blackwell cards in this catalogue, and it is checkable in ComfyUI's source rather than inferred.

ComfyUI gates the native NVFP4 kernels in comfy/model_management.py:

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

    return True

The test is on the major version of the compute capability, and the line falls between Ada and Blackwell: Ada GeForce parts are 8.9, so props.major is 8 and the function returns False; NVIDIA's list puts the RTX 5080 and the RTX 5060 Ti at 12.0, so they clear it. DmitryDB, who publishes the only community nvfp4 rebuild small enough to fit 16 GB, describes exactly this split in product terms — the file is a "supported fallback on RTX 4090 and native acceleration on supported Blackwell hardware." The RTX 4090 named there is an Ada part, which is the same side of the line as this card.

So the nvfp4 route is available here and will run, but the thing that makes it interesting on a Blackwell card — tensor cores that eat the format directly — is not available on this one. Combined with 0.740 GiB of headroom, a validation the publisher describes as a loader-level smoke test on an RTX 4090 rather than an end-to-end comparison ("A prompt-to-decoded-video/audio perceptual A/B has not yet been completed."), and the card's own disclaimer that "These are community conversions, not official Lightricks or ComfyOrg releases.", it is the interesting thing to try second. It is not the thing to try first.

The same reasoning demotes the two INT4 / W4A8 builds in the ladder. ComfyUI's kernels for that format come from comfy-kitchen, and comfy/quant_ops.py disables its CUDA backend outright below CUDA 13, with a warning whose own text names this card's generation: "If you are on nvidia 20 series and above it is required that you update your pytorch to cu130 or higher." That gate is on the CUDA version only — it is not architecture-specific, so it is not a Blackwell story and it applies here in full. It is irrelevant to the GGUF path this recipe leads with, because ComfyUI-GGUF brings its own dequantisation; it is the first thing to check if you go off and try a quantised-safetensors route.

What it costs in time — what is known, what is claimed, and what is neither

This is the honest weak spot of this page, so here is exactly what is and is not known, sorted by how much weight each kind of statement will bear.

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). 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 therefore unusually memory-bound, which is the one place a 256-bit interface has more to work with than the 128-bit cards this model has been measured on. 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.

That is a mechanism, not a measurement. No factor and no percentage appears on this page. The throughput constant measured on the RTX 5060 Ti is a property of that card — a different bus width and a different architecture generation — and is deliberately not rescaled here. Rescaling a measurement by a spec-sheet ratio produces a number that looks measured and is not.

Known, from the community, on every kind of hardware: the stage people report as slow on LTX-2.5 is the VAE decode, not sampling. Reports of it hanging come from a 3090 owner, a 5090 owner and a 5070 Ti owner in Lightricks/LTX-2.5 discussion #15 — and, importantly for this page, from the RTX 4080 SUPER owner in the Reddit thread above. The fix in every case 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.

Known, self-reported, on 4080-class hardware: the two community timings quoted in "The official INT8 route" above — 5 s at the template's 0.9 megapixel setting in 45 s, and a 7-second 1080 clip in 300 s, both on an RTX 4080 SUPER running the official INT8 checkpoint; plus 5 s at 1080p in 226 s on an unqualified "4080" whose configuration is unstated. None is instrumented and none is on this recipe's GGUF rung.

Not known: any seconds-per-frame figure for this recipe's configuration on either 4080. There is no benchmark at /check/ltx-2-5/rtx-4080-super and no vendor table that names either card. 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)", dated 2026-08-11 — and was first tagged v0.32.0. Do not stop at that tag: bd34f338 "Fix float64 device in ltx diffusion decoder" (#15516) landed the next day, 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 Blackwell siblings' torch pin. The measured RTX 5060 Ti session ran a CUDA 12.8 nightly because its card is Blackwell, sm_120, and the RTX 5080 page carries the same requirement for the same reason. This card is Ada Lovelace — 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. This is a real change from this card's LTX-2.3 recipe, which does require that pack. Installing it 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, 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, 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; these are a rebuild and a mirror, which are not the same thing as each other.

• 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, and a different git blob oid — 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 and the diffusion video VAE are there too, likewise byte-identical, and this recipe uses neither.

This is the list of redistributors this page checked, not a survey of what exists. 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 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 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] — all three re-read from the template JSON on 2026-08-13. Leave them alone.

Why multiple = 64 matters

ResolutionSelector is a top-level node, not one of the subgraph's. It 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 the 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. 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." This holds because the lead file is a quantisation of the distilled transformer. It does not hold for the dev line — see Troubleshooting.

Results

• Speed: No measured figure — but not nothing. /check/ltx-2-5/rtx-4080-super holds zero benchmarks, and the only instrumented run of this recipe's GGUF path anywhere is on a Blackwell card, whose seconds do not transfer to Ada and are deliberately not rescaled here. What does exist is three self-reported community figures on 4080-class cards, none of them on this recipe's GGUF rung. Two are from an RTX 4080 SUPER owner who does name his checkpoint — the official INT8 file — reporting "It took 45 seconds for a 5-second video at 0.9, it seems very fast even without Sage Attention!" and, later and after a separate fix, "A 7-second 1080 video was generated in 300 seconds." The third is from an owner who writes only "5 secs 1080p vid on 226 secs on my 4080 is just nuts." — he names no checkpoint and no card variant, so that figure is attributable to neither a configuration nor specifically to a SUPER. Sources, caveats and what they do not establish are in "The official INT8 route" above. /contribute to replace this bullet with a real number.
• 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. Real peak will be higher — activations, latents, CUDA context and the desktop all sit on top. On the measured 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. Read that as the shape of the overhead, not 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 — and the split is worth naming rather than leaving at the word "gate", because that word alone will mislead you when comparing builds: 304 are to_gate_logits.weight at F16, 304 are to_gate_logits.bias [32] at F32, and 12 are connector linear* tensors at F32. It is the weight matrices being left at F16 that carries the protection; a build that quantised those while keeping only the biases high-precision would describe itself the same way and would not be the same file. Only 1072 of the 4349 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 description of intent rather than a measured quality claim.
• 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 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-4080-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 a plain GGUF conversion emits 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 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 GPU : Sapphire Nitro 7800XT , 16GB — a 16 GB AMD card, not this one — and a second commenter hits the identical error on a Mac, so the failure is about the file rather than the vendor. Two things about that issue are worth knowing before you lean on it: it was closed by the reporter himself with no fix comment and no linked commit (state re-read 2026-08-13), and the config-blob explanation above is not stated anywhere in the thread — it comes from the quantiser's README, which is where the diagnosis actually lives. The reporter never named which publisher's GGUF 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 first mismatch above. The quantiser's README — not the node pack's — 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.

Decode stalls with no error, and you are on the official INT8 checkpoint

This is the one LTX-2.5 failure actually reported on an RTX 4080 SUPER, so it is worth its own entry even though this recipe's lead path avoids the checkpoint involved.

u/Kind_Owl2245, rig "4080 Super + 64GB RAM DDR5", posted that generation "si blocca durante l'elaborazione del VAE e non procede (nessuna notifica di errore)" — it stalls during VAE processing and does not proceed, with no error notification. Sampling had completed normally in his own pasted log. He first tried the tile-size fix below, then found something else, and his edit at the top of the post reads "Stavo usando il modello VAE sbagliato, non Convrot" — he had been using the wrong video VAE. In the comments: "I solved it, it was the wrong VAE model, with convrot you have to use the Convrot VAE. I reset the value to 768 and now I can also create 1080 videos."

Two things to take from this, and one not to. Take: a silent decode stall with a clean sampling log points at the VAE stage, not at capacity; and the video VAE has two builds that are easy to mix up, because the transformer filename ends -int8-convrot while the matching decoder is ltx-2.5-video-vae-conv-bf16.safetensors — conv, not convrot, and there is no file literally named "convrot VAE". If you follow this page's download step you already have the conv file, which is the one to load.

Do not take his "you have to" as a rule. ComfyUI's shipped template pairs that same INT8-convrot transformer with the diffusion VAE by default, so the combination he called wrong is the one the vendor ships. What is independently established is narrower and still useful: the vendor's own workflow note rates the conv decoder "Lower memory & faster", and decode is where 16 GB cards get into trouble. His report is one person's successful fix, not a documented incompatibility. Note also that he raised his decode tile back to 768 afterwards — the opposite of what this page advises, and a reminder that his configuration is not this one.

You downloaded a dev GGUF instead of a distilled one

Easy to trip over, and absent from this model's other 16 GB pages. Read on 2026-08-13, the day of that repo's own last modification, vantagewithai/LTX-2.5-GGUF holds no files at its top level at all: everything sits under distilled/, dev/ and workflows/, and it publishes a complete second ladder built from the non-distilled dev transformer at byte-for-byte the same file sizes as the distilled one. dev/ltx-2.5-22b-dev-transformer-Q3_K_M.gguf and distilled/ltx-2.5-22b-distilled-transformer-Q3_K_M.gguf are both 12,923,897,216 B, so size will not tell you which you have — only the path will.

It matters because the "CFG 1.0" instruction above is a property of the distilled checkpoint. Guidance is baked into the distilled weights; a dev transformer expects real classifier-free guidance and a full step count, so running one at CFG 1.0 with 8 steps produces a poor result that looks like a quantisation problem and is not. If you are following this page, take the distilled path. Lightricks ships the same split first-party — the repo carries both ltx-2.5-22b-dev-transformer-* and ltx-2.5-22b-distilled-transformer-* files at identical sizes.

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. The thread was opened by an RTX 3090 owner whose 10-second clip stalled in decode; Hole-A answered "Go into the subgraph and change the VAE Decode (Tiled) node's tile size from 768 to 512." — those are Hole-A's words, and the reporter later quotes them back when confirming they worked, so do not read them as the 3090 owner's own. A third participant reports "I had the same issue, but with a 5090 32GB", and a fourth, 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 his fix. All four are community members; none is from Lightricks, and none is on a 4080 of either kind.

The same fix turns up in the RTX 4080 SUPER thread quoted above, which is the closest thing to a report on this card: u/Gsus6677 tells the 4080 SUPER owner "Its the vae decode. Lower it to 512 instead of 768. My Comfy would crash until I changed that." and gives his own hardware as "I have a 5070ti 16gb with 64gb system ram. Not sure why it struggles with the larger decode." — so that datapoint is a 5070 Ti, not a 4080, and is quoted here for the fix rather than the hardware.

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. That property is what makes a 16 GB budget viable at high resolutions; raise the tile and you give it away.

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. Reading the template JSON on 2026-08-13, the governing value is the boolean on the outer subgraph node, and it is true. Do not read the inner nodes to check this — the inner ComfySwitchNode serialises false and the inner PrimitiveBoolean serialises true, and both are overridden by links, so either one read on its own gives a wrong answer with full confidence. 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". Turn it off for a first run: it is another sequential 9.573 GiB stage, and it rewrites your prompt, which makes a first-run comparison harder to reason about.

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. 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; 32 GB is workable with the pagefile sorted first.

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

Published, though not benchmarked — /check/ltx-video-2-3/rtx-4080-super reads verdict: unknown with zero benchmarks too, so neither of this card's LTX pages rests on a measurement. Almost nothing on disk carries over, and the strategy does not carry over either.

• 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 2.3 recipe on this card leads with a Q4_K_S build from a different publisher entirely.
• 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. 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. Download the 2.5 files.
• The custom nodes do not. The 2.3 recipe here needs the Lightricks ComfyUI-LTXVideo pack and KJNodes; this one needs neither.

The 16 GB fit strategy is different in kind, and this is the part worth understanding rather than transcribing. This card's LTX-2.3 recipe fits the model by forcing the Gemma 3 encoder off the GPU — launching with --novram or --reserve-vram 10 so it runs on the CPU — because on that pipeline the encoder is the binding constraint and would otherwise sit in VRAM alongside the transformer. On 2.5 you do not need that lever: ComfyUI's own graph already runs prompt encoding as a discrete stage and evicts the encoder before sampling, so the encoder never contends with the transformer in the first place. The lever here is the transformer's quantisation rung instead. Bring the discipline, not the flags.

QuantStack/LTX-2.5-GGUF is 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, with the repo's own lastModified still at 2026-08-11. The publishers named above filled the gap instead. If QuantStack ships, re-check the rung table — a different build could move the Q4_K_S question.

The 12B conditioning encoder: stock ComfyUI-GGUF cannot load a GGUF one — budget the INT8 file

Install the 14.317 GiB gemma4-12b-with-proj-ltx-2.5-comfy-int8-convrot.safetensors and plan the disk for it. The reason is not that quantising the encoder is a bad idea — it is that the loader this recipe installs will refuse the result.

Why stock refuses, and why the obvious one-word fix is worse than the refusal. ComfyUI-GGUF/loader.py at pinned commit 6ea2651e declares TXT_ARCH_LIST = {"t5", "t5encoder", "llama", "qwen2vl", "qwen3", "qwen3vl", "gemma3"} at line 13 and raises at line 108 for anything text-shaped outside it — that raise is the ValueError in the next section. gemma3 is on the list; gemma4 is not.

The reason you should not simply add it is that there is a second, independent membership test further down, and it does not raise:

elif arch in {"llama", "qwen2vl", "qwen3", "qwen3vl", "gemma3"}:   # line 482
    ...
    elif arch == "gemma3":
        sd["spiece_model"] = gguf_gemma3_tokenizer_loader(path)    # line 490
    ...
    if arch == "gemma3":
        sd = sd_map_replace(sd, GEMMA3_SD_MAP)                     # line 495
        sd = gemma3_norm_corrections(sd)                           # line 496
...
else:
    pass                                                           # lines 504-505
return sd

Add "gemma4" to TXT_ARCH_LIST alone and the raise clears — but arch still misses the set at line 482, falls through to else: pass, and the state dict is returned untouched. No tokenizer, no tensor renaming, no norm correction, and no exception. The one-word fix a reader will reach for first fails silently, which is the more expensive failure of the two: a hard ValueError tells you to stop, a quietly unmapped encoder does not. Those three gemma3-only calls are what a real gemma4 path would have to replace, and that is why this needs a patch rather than an edit.

A patched route now exists, is hours old, and nobody has run it. As this page was being written, elix3r/gemma4-12b-with-proj-ltx-2.5-GGUF appeared — createdAt 2026-08-13T18:04:10Z, hours after every other source cited here. It carries 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, and alongside it a patches/ComfyUI-GGUF-ltx25-gemma4.patch. That the author ships a patch corroborates the section above — he evidently found stock could not load it either — though the loader source says so more plainly than the patch does, and is readable without a licence gate.

Treat every auxiliary number in that repo as a timestamped observation rather than a property: it is being edited hourly. The patch was 1,594 B when first checked and 1,711 B forty minutes later, over which span the README grew from 4,457 to 13,445 B and QUANTIZATION.md from 1,248 to 3,969 B. The one figure that has not moved is the GGUF itself, still 9,514,920,864 B — which is the only number this page leans on.

What is not known about it, which is nearly everything. It has 0 downloads and 0 likes, it is gated: auto, and every file in it returns 401 unauthenticated — so for this page neither the patch body nor the GGUF itself could be read, only the repository metadata. No run of it has been reported anywhere. Do not install it today on the strength of this page: it is recorded here because a reader who finds it should know both that it exists and that nothing about it has been verified, not because it is ready. If you try it, say what happened — a working patched encoder would take 5.456 GiB off the heaviest stage in this graph, which on a 16 GB card is a bigger prize than any transformer rung below.

The space this rests on, so you can judge it rather than take it. Hugging Face's model search is a substring match on the repo id, so a multi-word query returns nothing regardless of reality; single-token searches — ltx-2.5 (34 repos), LTX-2.5-GGUF (5), gemma4, gemma-4 — plus per-repo tree-API enumeration are what these statements cover, re-run 2026-08-13. On that pass the LTX-2.5 GGUF publishers were transformer and VAE builds only, the three repos publishing an LTX-2.5-flavoured Gemma 4 12B encoder shipped safetensors exclusively, and LTX-2 issue #278 was an open request for exactly this file. The elix3r repo then appeared and changed that answer within the same day. Searched: the Hugging Face model index and the Lightricks tracker. Not searched: unindexed or private re-uploads. Treat the encoder question as moving, and re-run the search rather than trusting this paragraph's date.

The encoder is a sequential stage, so it costs you disk and a prompt-change penalty, not resident VRAM. If that stage is what hurts and you want something that needs no patch, DmitryDB's nvfp4 encoder is the lighter option that loads stock at 11,197,310,236 B (10.428 GiB) — 3.889 GiB below the INT8 file — and it too is unvalidated end-to-end.

Unexpected text model architecture type in GGUF file: 'gemma4' — check which Gemma slot you are in

Worth its own entry, because the exception text sends people to the wrong conclusion.

There are two Gemma models in this graph, and they fail differently. If ComfyUI-GGUF raises that ValueError, you were almost certainly filling the prompt-enhancer slot, not the conditioning-encoder one. ComfyUI-GGUF issue #474 is the reference case: titled "ltx 2.5 gemma-4-E2B-it Unexpected text model architecture type", its body links a community GGUF of the small gemma-4-E2B-it loaded "for Generate LTX2 Prompt node." — the enhancer. It is OPEN as of 2026-08-13.

So the same string covers both slots for the same underlying reason — gemma4 is not in TXT_ARCH_LIST — and neither slot has a stock-loadable GGUF today. Use the safetensors file in both, which is what the download step above already does.

Something else

The space searched, so you can judge the claims above. All 30 Hugging Face discussions on Lightricks/LTX-2.5 were enumerated and fetched individually and every message grepped — "4080" occurs in none of them; the GPUs that do appear there are the 2080 Ti, 3060, 4060, 4070, 5070 Ti, 5090, an A100 and several Macs. The same was done for the discussions and READMEs of the community quant repos. The Lightricks/LTX-2, Comfy-Org/ComfyUI and city96/ComfyUI-GGUF issue trackers were searched and returned no 4080 report. Reddit was searched via old.reddit.com — www.reddit.com serves an anti-bot shell and a zero there means nothing — across r/StableDiffusion, r/comfyui and site-wide, and that is where both 4080 reports live; each was re-fetched and every quote on this page grepped byte-for-byte against the thread HTML.

So the honest summary is: two self-reported Reddit threads, no benchmark, no failure report attributable to capacity on either 4080. The backend's own /check/ltx-2-5/rtx-4080-super still holds zero benchmarks. Not searched: CivitAI, YouTube, Discord, X, and Chinese-language forums. Report problems, or a first measurement, via the submission form.