LTX-2.5 on RTX 5080: 22B audio-video in 16 GB, and what the wider bus cannot buy

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 5080, 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 5080 (16GB VRAM, 256-bit GDDR7, Blackwell) · 13.354 GiB of resident weights on the lead rung — derived from file sizes, not measured on this card · See benchmark data

⚠️ Nothing on this page was measured on an RTX 5080. /check/ltx-2-5/rtx-5080 returns verdict: unknown with zero benchmarks (re-checked 2026-08-13), and no report of LTX-2.5 running on this card surfaced on any surface listed at the end of this page. Every VRAM figure below is arithmetic over file byte counts read from the Hugging Face tree API; there is no speed figure at all, because publishing one would mean inventing it. If you run this pair, contribute your numbers — this page is one measurement away from being a much better page.

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

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

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

The mechanism is in the graph, not in the card, so expect the same shape 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. No VRAM figure from an LTX-2.3 recipe transfers, and no LTX-2.3 GGUF will load here. This matters more than usual on this card: the RTX 5080 already has an LTX-2.3 recipe on this site, and the two file sets look confusingly alike.

ℹ️ Gated weights. Lightricks/LTX-2.5 carries gated: "auto", so an unauthenticated request to any file under it returns 401 (re-verified 2026-08-13 against the transformer, the conv video VAE and the spatial upscaler). Accept the licence on the model page and run hf auth login with a Read token before the download step. The weights are under the LTX-2 Community License, not Apache-2.0. Ungated third-party rebuilds exist for all four gated first-party files — see the download step.

Requirements

Why 16 GB works, in bytes

The official ComfyUI path loads a 20.027 GiB INT8 transformer (ltx-2.5-22b-distilled-transformer-comfy-int8-convrot.safetensors, 21,504,034,224 B). That is what ComfyUI's shipped template points at by default, and it does not fit resident on this card. That is a cost rather than a refusal — ComfyUI streams a model larger than VRAM instead of declining it, and a 16 GB owner has been reported doing exactly that with this checkpoint; see Why not just run the official INT8 and let ComfyUI offload? below. A GGUF quantisation of the same distilled transformer replaces it, and the rest of the graph is unchanged.

Resident weights during the graph, using the lead rung:

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

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

The rung ladder

The inclusion rule, so you can see what the table is and is not. It holds every distilled-transformer file from the six publishers named below whose resident total lands under 17 GiB, plus the two first-party checkpoints for scale. Those six publishers are what a search of the Hugging Face model index turned up on 2026-08-13, and that is a claim about that search on that date rather than a census of the Hub — a model this young acquires quantisations faster than a page can describe them, and at least one appeared while this one was being written (see the text-encoder section in Troubleshooting). Byte counts are from each repo's tree API, read the same day; totals sum unrounded bytes and round once, against a nominal 16 GiB card.

Where a row names two publishers, the two counts are given in that order: Abiray's build is 64 bytes larger than vantagewithai's on each of those three 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 in all three (verified by HTTP Range-reading each file's GGUF header). The name describes a recipe, not a file; which tensors stay at higher precision is the publisher's choice. That gap is larger than the entire audio VAE.

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

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

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

The obvious objection to the whole ladder, and it deserves a straight answer: ComfyUI will stream a model larger than VRAM rather than refuse it, so the 20.027 GiB INT8 checkpoint is a cost, not a wall. Nobody has run it on an RTX 5080. But somebody has run it on a 16 GB card, and that is enough to retire the idea that it cannot be done.

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" — a different card from this one, 16 GB Ada rather than 16 GB Blackwell, and with twice the system RAM this page asks for. He names the model he is loading as ltx-2.5-22b-distilled-transformer-comfy-int8-convrot.safetensors, the official INT8 checkpoint, not a GGUF. His pasted console log shows ComfyUI staging it dynamically at 20484MB on a 16 GB card, and sampling completing at 8/8 [00:05<00:00, 1.53it/s].

The order matters, because his two timings come from two different configurations:

1. u/Gsus6677 — a 5070 Ti owner, not the OP — 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!" — on the reduced tile, and 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.

How to read this on an RTX 5080, precisely. It establishes that the INT8 offload route runs on a 16 GB card and is not absurdly slow, which means "the official checkpoint does not fit" is a statement about residency rather than about feasibility. It establishes nothing about this card: no peak VRAM was measured, the resolutions are given as template settings rather than pixel dimensions, and the 300-second run raised the decode tile back to 768, against the advice in Troubleshooting. Note the 64 GB of system RAM in particular — streaming a 20.5 GB working set is a host-memory problem before it is a GPU one, which makes the pagefile advice below a hard prerequisite for this route rather than a suggestion.

This recipe still leads with the GGUF rung, for reasons that report does 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 moving a 20.5 GB working set across PCIe on every step, and its memory behaviour is therefore predictable rather than dependent on what else is holding memory. If you have the system RAM and would rather run the official checkpoint, the report above says you can — and if you do, contribute a measurement, because this card has that comparison in neither direction.

What the wider bus buys, and what it does not

This is the top of the 16 GB tier. NVIDIA's spec table gives the RTX 5080 16 GB GDDR7 on a 256-bit interface, 10752 CUDA cores and 1801 AI TOPS; the card this model has actually been measured on, the RTX 5060 Ti, is 16 GB GDDR7 on a 128-bit interface with 4608 CUDA cores and 759 AI TOPS — same architecture, same memory generation, same capacity, twice the bus and rather more than twice the compute. So the obvious question for anyone landing here from the cheaper card is what that buys.

It buys nothing at all 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.

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

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

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

That is a mechanism, not a measurement, and bandwidth is not even the only axis that differs — the core and TOPS figures above move together with the bus. So no factor and no percentage appears on this page. The measured throughput constant from the RTX 5060 Ti session is a property of that card and is deliberately not rescaled here; rescaling a measurement by a spec-sheet ratio produces a number that looks measured and is not. If you time this pair, contribute the result and the two pages become the comparison neither of them can be alone.

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

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

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

A community nvfp4 rebuild: fits on paper, and it is the only route that would use NVFP4 tensor cores at all. DmitryDB publishes a 13,572,563,959 B (12.640 GiB) nvfp4 distilled transformer written, per its README, in "the stock Comfy NVFP4 wire format", plus a matching nvfp4 text encoder at 11,197,310,236 B (10.428 GiB) — 3.889 GiB lighter than the INT8 encoder, which matters because the encoder is the one thing measured to move the peak. ComfyUI gates the native NVFP4 kernels in comfy/model_management.py::supports_nvfp4_compute, which returns False for any device whose compute-capability major version is below 10 — a generational line Ada sits under and Blackwell sits over. The publisher's own table says the same thing in product terms: "Smallest transformer route; supported fallback on RTX 4090 and native acceleration on supported Blackwell hardware."

Read that as an Ada-versus-Blackwell line and nothing more. It is not a reason to prefer this card over a cheaper 16 GB Blackwell one: NVIDIA lists the RTX 5060 Ti under the same architecture, so it clears the same gate, and a 12.640 GiB file fits — or does not fit — a 16 GB card identically on both. The cards that this route genuinely leaves behind are the 16 GB Ada parts. Between two Blackwell 16 GB cards the axis is still capacity, which is the whole argument of this page.

Three reasons the nvfp4 rebuild is still not the lead. Its residency comes to 15.260 GiB, leaving 0.740 GiB — tighter than Q4_K_S, and on the RTX 5060 Ti, the one 16 GB card this model has been run on, observed peaks consumed between roughly 0.5 and 2.2 GiB on top of a comparable weight sum. Its validation is loader-level, on a different card: the README reports a stock-ComfyUI load and projection smoke test on an RTX 4090 and states plainly that "A prompt-to-decoded-video/audio perceptual A/B has not yet been completed." And it is a community conversion — the card says so itself: "These are community conversions, not official Lightricks or ComfyOrg releases." It is the most interesting thing to try second. It is not the thing to try first.

INT4 / W4A8: real support, thin provenance. ComfyUI core registers asym_w4a8_int8 as a first-class quantisation format — comfy/quant_ops.py maps it to AsymW4A8Int8Layout and comfy/ops.py loads it from weight_s_rel / weight_s_channel / weight_codebook scale tensors — and comfy-kitchen, which provides the kernels, is pinned in ComfyUI's own requirements.txt. Two publishers ship LTX-2.5 in that format, and both safetensors headers were range-read for this page: tsolful declares 1344 asym_w4a8_int8 layers, Winnougan declares 1440, and both carry the complete scale-tensor triple the loader demands plus the config blob naming AVTransformer3DModel. So these are shaped to load, and Winnougan's at 11.660 GiB would fit with room to spare.

Against that: no run of either has been reported anywhere. tsolful's model card is two lines ("15.4GB INT4 Model size with 80% INT8 Quality"), its file is 14.354 GiB rather than the advertised 15.4 GB, its total lands 0.974 GiB over a nominal 16 GiB, and in the repo's only discussion thread its author says a wrong quantisation value had been uploaded and was being replaced. Winnougan's card is worse in a specific way: its file table lists six files where the repo contains three, and the three it lists as INT4 ConvRot are not there at all. The card still carries an unremoved authoring instruction — a block-quoted line telling whoever publishes it to fix the table to match the repo's actual contents — and it links both "comfy-kitchen" and the converter that produced the files to a bare https://github.com/ with no repository path. To its credit it also says outright that the layer-protection list it reused from the INT8 profile has not been independently confirmed at W4A8 precision. Treat both as experiments, not as an install path.

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. Run master rather than the tag — but be clear about why, because the commit usually cited here does not carry the argument. bd34f338 "Fix float64 device in ltx diffusion decoder" (#15516) landed the next day, and its patch 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 is on a code path you are not running, and the v0.32.0 tag is sufficient for the path documented here. The real reason to be current is the template package: the tiled-decode defaults that answer this model's one widely-reported failure ship in comfyui-workflow-templates 0.11.40, which current ComfyUI pins. Take master as hygiene, and take it specifically if you ever switch to the diffusion decoder.

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

On Blackwell you need a CUDA 12.8+ torch build.

One warning you will probably see, and it is not about your architecture. If ComfyUI greets you with a wall of WARNING WARNING WARNING about cu130, that is a test of your torch build, not of your card. comfy/quant_ops.py reads torch.version.cuda, parses it with cuda_version = tuple(map(int, str(torch.version.cuda).split('.'))), and when that lands below (13,) calls ck.registry.disable("cuda") — switching off comfy-kitchen's accelerated CUDA backend (lines 37–43 at the pinned commit). No device property is consulted anywhere in that branch, and the warning's own second line scopes it by generation rather than by architecture: "If you are on nvidia 20 series and above it is required that you update your pytorch to cu130 or higher." So it fires on this card exactly as it does on an Ada or Ampere one — it is not a Blackwell story, and seeing it tells you nothing about whether your GPU is supported. 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 above, whose INT4 / W4A8 kernels are exactly what that backend provides.

2. Install ComfyUI-GGUF

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

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

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

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

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

3. Authenticate and download the six files

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

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

# 2-5. gated first-party files; the repo prefixes are already ComfyUI's directory names
hf download Lightricks/LTX-2.5 \
    text_encoders/gemma4-12b-with-proj-ltx-2.5-comfy-int8-convrot.safetensors \
    vae/ltx-2.5-video-vae-conv-bf16.safetensors \
    vae/ltx-2.5-audio-vae-bf16.safetensors \
    latent_upscale_models/ltx-2.5-latent-spatial-upscaler-x2-bf16-1.0.safetensors \
    --local-dir "$COMFY/models"

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

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

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

Two deliberate substitutions against the template's defaults, 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, 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 third-party rebuilds now exist for all four gated files, each returning 302 unauthenticated (verified 2026-08-13). Prefer first-party where you can; these are rebuilds and mirrors, 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. 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 under split/ — vae/ltx-2.5-video-vae-conv-bf16.safetensors at 1,452,269,922 B, vae/ltx-2.5-audio-vae-bf16.safetensors at 364,866,540 B, and latent_upscale_models/ltx-2.5-latent-spatial-upscaler-x2-bf16-1.0.safetensors at 995,778,752 B — all three byte-identical to first-party.

The text encoder is not substitutable with a stock Gemma 4 12B checkpoint either way — it carries LTX's own text_embedding_projection and audio_projector layers, and the quantiser's README is blunt about it: "A plain Gemma checkpoint will not substitute."

4. Place the files

$COMFY/models/
├── unet/LTX-2.5-Distilled-Q3_K_M.gguf                                       # the GGUF goes HERE, not diffusion_models
├── text_encoders/gemma4-12b-with-proj-ltx-2.5-comfy-int8-convrot.safetensors
├── text_encoders/gemma4_e2b_it_bf16.safetensors                             # prompt enhancer
├── vae/ltx-2.5-video-vae-conv-bf16.safetensors
├── vae/ltx-2.5-audio-vae-bf16.safetensors
└── latent_upscale_models/ltx-2.5-latent-spatial-upscaler-x2-bf16-1.0.safetensors

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

Running

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

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

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

The six deltas from the shipped template

Three template defaults need no change and are load-bearing: VAEDecodeTiled already ships at [512, 64, 64, 16], and both LTXVDualCFGGuider nodes already sit at [1, 1]. All three re-read from the template JSON on 2026-08-13. Leave them alone.

Why multiple = 64 matters

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

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

This table differs from the one the template ships in its own Size Settings Reference note, which is computed at multiple = 32. Both are correct for their own setting.

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.

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

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

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 has no equivalent field. A naive conversion therefore builds an LTX-2.3-shaped model and pours 2.5 weights into it. The quantiser's README states the consequence directly: "If you convert LTX-2.5 to GGUF yourself, it will not load."

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

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

Decoding hangs forever, or the last frames come out gray

The hang is real on 16 GB cards, 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, PR #1120) changed all three 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 — and bumped the package from 0.11.39 to 0.11.40, which is what ComfyUI pins today. That is precisely 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; other posters in the same thread report the 768→512 tile change resolving it on 32 GB and 24 GB cards. All are community members, none from Lightricks.

If you are on an older template package, apply those four values by hand. If you are on the current one and still hang, check that you did not raise the tile size — with fixed-size tiling a larger output frame means more tiles, not a larger decode buffer, which is why decode cost grows with area while decode memory does not. That property is what keeps a 16 GB budget viable at high resolutions; raise the tile and you give it away.

Separately, LTX-2 issue #277 reports gray frame tails from the diffusion video VAE decoder under AUTO tiling, reproduced by a community user on an A100 80 GB with the vendor CLI. 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.

Turning audio off to save memory can make things worse

Counterintuitive, and specific to 16 GB. ComfyUI issue #15356 (open) reports that ComfyUI's generic activation-memory estimator sizes an LTXAV latent very differently depending on whether audio is present: video-plus-audio arrives as a nested latent flattened to (B, 1, N), video-only stays a 5D (B, 128, T, H, W), and the estimator multiplies dimensions from index 2 — so the 128 video-latent channels are counted in one case and skipped in the other, a factor of exactly 128. The reporter's consequence is the interesting part: "the second sampler loads only part of the 22.4 GB LTXAV model into 16 GB VRAM" and then thrashes PCIe without reaching step 0.

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

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

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

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

Note also that the enhancer ships ON. Reading the template JSON on 2026-08-13: the governing value is the boolean widget on the outer subgraph node, which is true in both video_ltx2_5_t2v and video_ltx2_5_i2v. Do not read the inner nodes to check this — the inner ComfySwitchNode's serialized widget says false and the inner PrimitiveBoolean says true, and both are overridden by links, so either one read on its own gives you a wrong answer. The template's own parameter table advertises the feature as "Toggle the built-in Prompt Enhancer: expands short prompts into rich cinematic instructions at near-zero extra compute". For a first run turn it off — 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. On the RTX 5060 Ti — the one 16 GB card where this has been instrumented — re-encoding was the only operation that moved the peak. Fix the prompt, then tune size and duration.
3. Do not raise the decode tile size. See above.
4. Drop a rung — Q2_K at 8.228 GiB is the smallest sane one, at a real quality cost.
5. Launch with --lowvram.
6. Fix the pagefile before blaming the GPU. ComfyUI-GGUF's own source carries the warning in a code comment: "Windows doesn't over-commit memory so without this 24GB+ of pagefile is used". A host-RAM OOM here reads exactly like a VRAM problem and will send you down the wrong rung. Our 24 GB anchor recommends 64 GB of RAM; 32 GB is workable with the pagefile sorted first.

The text encoder has no stock-loadable GGUF path

Budget the 14.317 GiB INT8 encoder on disk. It is a sequential stage, so it costs you disk and a prompt-change penalty rather than resident VRAM. But plan for it because of the loader, not because the file does not exist — one now does.

Why stock refuses. 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. gemma3 is on that list; gemma4 is not. That raise is the ValueError: Unexpected text model architecture type in GGUF file: 'gemma4'.

And the one-word fix is worse than the refusal. Adding "gemma4" to TXT_ARCH_LIST clears the raise — and then misses a second, independent membership test at line 482, elif arch in {"llama", "qwen2vl", "qwen3", "qwen3vl", "gemma3"}:. 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 comes back untouched — no tokenizer, no renaming, no norm correction, and no exception. The obvious edit fails silently, which is the more expensive failure of the two: a hard ValueError tells you to stop, a quietly unmapped encoder does not. That is why the architecture needs a patch rather than a set entry.

A patched route now exists, and nobody has run it. elix3r/gemma4-12b-with-proj-ltx-2.5-GGUF was created at 2026-08-13T18:04:10Z, hours after every other source on this page, and ships 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, and lighter still than the nvfp4 encoder discussed earlier, which it displaces as the smallest published option — alongside a patches/ComfyUI-GGUF-ltx25-gemma4.patch. That its author had to ship a patch corroborates the paragraph above. The GGUF's byte count is the only figure worth pinning: the repo was being rewritten while this was being written about, the patch, README and QUANTIZATION.md all changing size inside about forty minutes, so treat any other size as an observation with a timestamp rather than a property of the repo. It is gated: auto with zero downloads, and an unauthenticated fetch of both the weights and the patch returns 401, so neither could be read for this page. 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, i.e. 18.339 GiB resident, over this card — so no verdict in the rung ladder above moves. Recorded because it exists, not because it is recommended: like the nvfp4 encoder, it is unvalidated end-to-end, and unlike it, nobody outside the gate has been able to read so much as the patch.

Do not read ComfyUI-GGUF issue #474 as being about this. It carries the identical error string against LTX-2.5, which is precisely why it will send you to the wrong conclusion. It is titled "ltx 2.5 gemma-4-E2B-it Unexpected text model architecture type", and its reporter is loading a GGUF of the small gemma-4-E2B-it into the Generate LTX2 Prompt node — the prompt enhancer, the 9.573 GiB model that rewrites your text, not the 14.317 GiB projection-carrying encoder that conditions the diffusion. The page names the enhancer node 11 times and gemma-4-E2B 31 times, and mentions neither text_encoder nor CLIPLoader once. Two different models, two different slots, one exception string — and one cause, since TXT_ARCH_LIST gates both. The issue is OPEN as of 2026-08-13. This recipe turns the enhancer off anyway, so quantising it saves nothing that switching it off does not already save.

QuantStack/LTX-2.5-GGUF is still empty

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

One open report against the lead build, no card named

For completeness rather than as a known trap: realrebelai discussion #2 is an unanswered RuntimeError: split_with_sizes expects split_sizes to sum exactly to 7680 ... but got split_sizes=[4096, 2048] at SamplerCustomAdvanced. The reporter names no GPU and no ComfyUI version. 4096 and 2048 are LTX-2.5's video and audio path widths and 7680 is twice the 3840 connector width that the LTX-2.3-shaped build uses, so it has the fingerprint of a stale ComfyUI rather than a bad file — but nobody has confirmed that, so it is recorded here as an open question, not a diagnosis.

Something else

The space searched. For evidence about this exact pair: all 28 Lightricks/LTX-2.5 Hugging Face discussions enumerated individually and every message grepped for GPU model numbers; the discussions on all six community LTX-2.5 quant repos enumerated; the ComfyUI and ComfyUI-GGUF issue trackers searched for this card; seven Reddit searches across r/comfyui and site-wide (LTX 2.5 5080, LTX-2.5 5080, LTX 2.5 RTX 5080, "LTX 2.5" 16GB, LTX 2.5 5080 subreddit:comfyui, 5080 LTX 2.5 VRAM, LTX 2.5 GGUF 5080); and two general web searches. No LTX-2.5 result on an RTX 5080 exists on any of them. The nearest on-topic Reddit post is an LTX-2.5 run on an RTX 3060, and the only RTX 5080 report in the ComfyUI-GGUF tracker is issue #283, about a different model on a 2025 PyTorch nightly, so nothing in it transfers. Not searched: CivitAI, YouTube, Discord and X. Report problems, or a first measurement, via the submission form.