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 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 — 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

Every transformer file published for LTX-2.5 at the time of writing, plus the 2.620 GiB of fixed companions, against a nominal 16 GiB card. Byte counts are from each repo's tree API, read 2026-08-13.

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.

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. Do not stop at that tag: bd34f338 "Fix float64 device in ltx diffusion decoder" (#15516) landed the next day, and decode is where a 16 GB card gets into trouble.

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. Note one thing while you are choosing: ComfyUI disables comfy-kitchen's accelerated CUDA backend below cu130 and prints a warning saying so. That is irrelevant to the GGUF path this recipe leads with — ComfyUI-GGUF brings its own dequantisation — but it is the first thing to check if you go off and try one of the quantised-safetensors routes above.

2. Install ComfyUI-GGUF

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

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

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

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

You do not need the Lightricks ComfyUI-LTXVideo pack. 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.

There is no GGUF path for the text encoder

Only the transformer has one. Substituting a GGUF Gemma 4 for either text-encoder slot fails inside ComfyUI-GGUF with ValueError: Unexpected text model architecture type in GGUF file: 'gemma4' — reported at ComfyUI-GGUF issue #474, open and unanswered as of 2026-08-13. Budget the 14.317 GiB INT8 encoder on disk; it is a sequential stage, so it costs you disk and a prompt-change penalty, not resident VRAM. If the encoder stage is what is hurting, the nvfp4 encoder discussed earlier is the only published lighter option, and it is unvalidated end-to-end.

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.