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

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

⚠️ Nothing on this page was measured by us, on this card or any other in the 40 series. /check/ltx-2-5/rtx-4080 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 read from the Hugging Face tree API on 2026-08-13. No instrumented run of this recipe's install exists on an RTX 4080, so this page publishes no seconds-per-frame figure of its own. If you run this pair, contribute your numbers — one instrumented run would make this the best-documented 16 GB Ada page for this model.

ℹ️ The community has reported on this card — which no other 16 GB page in this catalogue can say — but read carefully what each report covers. Three posts are relevant and none of them is a benchmark.

• A plain RTX 4080, named by its owner. In an r/StableDiffusion first-impressions post on release day, u/skyrimer3d writes "5 secs 1080p vid on 226 secs on my 4080 is just nuts". That establishes the pair runs, on this exact card, at minutes rather than hours. It establishes little else: he states no checkpoint, no quantisation and no system-RAM figure anywhere in the post, and he is driving a third-party node stack — "I'm using LTX Director + Seedhunter node and worked just fine" — rather than the shipped ComfyUI template this recipe documents. Treat it as an existence proof with an order of magnitude attached, not as a number for this install.
• Two RTX 4080 SUPER owners — a different card, 16 GB GDDR6X on the same 256-bit Ada bus with more shader cores. One hit a decode stall, worked out the cause and posted wall-clocks afterwards; the other reported the same stall and never followed up. Unlike the post above, the first one does name his checkpoint — the official INT8 file — so he is the only evidence here about the weight-streaming route. His failure has a fix and it is the first entry in Troubleshooting.

Their figures stay attributed to the card that produced them throughout this page. None is restated as a figure for this recipe's GGUF path, and no constant is derived from any of them.

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

Variant pin. This recipe targets LTX-2.5, canonical repo Lightricks/LTX-2.5, which is a different and non-interchangeable file set from LTX-2.3. This card already has a published LTX-2.3 recipe, so this is worth spelling out: no LTX-2.3 GGUF will load here, and the 2.3 text encoder is the wrong model entirely (2.3 conditions on Gemma 3, 2.5 on a projection-carrying Gemma 4). See Troubleshooting if you are arriving with a 2.3 install on disk — the fit strategy is different in kind, not just in file names.

ℹ️ Gated weights. Lightricks/LTX-2.5 carries gated: "auto", so an unauthenticated request to any file under it returns 401 (re-verified 2026-08-13 against the conv video VAE). Accept the licence on the model page and run hf auth login with a Read token before the download step. ComfyUI's own template says as much in a note: "Before you download all the models, please make sure you have granted access to" LTX-2.5 first. The weights are under the LTX-2 Community License, not Apache-2.0. Ungated third-party copies exist for all four gated files — see the download step.

Requirements

Why 16 GB works, in bytes

The official ComfyUI path loads a 20.027 GiB INT8 transformer (ltx-2.5-22b-distilled-transformer-comfy-int8-convrot.safetensors, 21,504,034,224 B). That is what ComfyUI's shipped template points at by default, and on this card it does not fit in VRAM. 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 — identical on every rung — which is what makes the ladder below a straight comparison of transformer files. The whole fit argument is card-independent: the same four files, the same bytes, on any 16 GB card. For a sense of what the gap actually gets spent on, the measured RTX 5060 Ti session recorded whole-card peaks between roughly 0.5 and 2.2 GiB above this same weight sum. Read that as the shape of the overhead, not as a prediction for this card — those samples include a different machine's desktop, driver and allocator.

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

The rung ladder

Byte counts re-read from each publisher's tree API on 2026-08-13, plus the fixed 2.620 GiB of companions. The last column is arithmetic against a nominal 16 GiB, not a measurement on this card.

That table carries every transformer file that fits a nominal 16 GiB, plus the near-misses, across the six publishers this page found on 2026-08-13 — including the non-GGUF ones, which is why W4A4, W4A8 and nvfp4 rows sit among the K-quants. What it omits is files that do not fit, and only those: the GGUF publishers' Q5, Q6 and Q8 tiers (realrebelai's Q5_K_M alone is 16,818,835,456 B), vantagewithai's Q4_0 / Q4_1 / Q5_0 / Q5_1 / Q5_K_S, joeygambino's 17 GB mixed build at 17,010,342,592 B, and tsolful's W4A8 at 15,412,311,232 B. Each of those lands past 16 GiB resident — that is the comparison, against the card, not against the heaviest row in the table, since the table deliberately keeps two first-party files that are far heavier still.

Read that as a snapshot with a date on it, not a survey. The joeygambino repo above was created at 10:55 UTC on the day this was written and had reorganised itself by 12:46; vantagewithai restructured its repo the same day. A sentence of the form "every quantisation published for LTX-2.5" would have been false within hours of being written, and a sibling page in this catalogue contains one. What is bounded here is the search: six publishers, each repo's tree API read directly rather than its README.

Four things worth stopping on.

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

The smaller Q3_K_M buys its 0.860 GiB partly out of the audio. This is why the lead here is not simply the lightest rung with the same label, and it is checkable rather than a matter of taste. Reading both files' GGUF headers directly over HTTP range requests on 2026-08-13, at the same 4349 tensors:

Two things account for the gap, and they are not equally benign: the newer build stores its unquantised tensors at F16 rather than F32, which is ordinary, and it quantises the 304 gate tensors that realrebelai deliberately protects — the ones the lead publisher's README singles out because "Quantize them and video still looks fine while audio desyncs or degrades". The same 304 are quantised in joeygambino's Q4_K_M, the one Q4_K_M on the ladder that fits. So the tempting row and the safe row are not the same row, and the failure mode you would be buying is one you will not see in the picture. Nobody has reported running either of these builds — the repo is hours old with zero downloads and no discussions — so this is a header census, not a quality verdict. If you try one, say what the audio did.

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

⚠️ Size cannot tell you which model family you downloaded. vantagewithai publishes two complete ladders — distilled/ and dev/, the latter being the non-distilled transformer — and across all thirteen quants the two are byte-identical in size (Q3_K_M is 12,923,897,216 B in both, Q2_K 12,125,172,096 B in both, and so on for every rung, checked against the tree API on 2026-08-13). Only the directory and the filename infix distinguish them. This matters beyond tidiness: everything this page says about CFG assumes the distilled weights, and the dev transformer is not a distilled model, so a silent swap breaks the [1, 1] guider setting rather than merely changing quality. That repo was also reorganised on 2026-08-13 — its GGUFs moved out of the repo root into those two subdirectories and were renamed — so a path copied from anywhere older will not resolve. Check the directory, not the byte count.

Q4_K_S is the interesting failure. Its weights alone need 15.522 GiB of a nominal 16, leaving 0.478 GiB — less than the smallest overhead the measured RTX 5060 Ti session ever recorded above the same weight sum, and on that card the same rung projected 64 MiB past the capacity it reports. Note the unit before you argue with the arithmetic: the gap from Q3_K_M is 2,328,100,864 B, which is 2.168 GiB — 2220 MiB, not 2168. Nobody has tried it here. Treat it as one deliberate experiment (fresh start, cached prompt, decode tile left alone), not as something to plan a workflow around — and if you do try it, tell us what happened.

What the 256-bit bus buys, and what it does not

This card is one of the wide-bus members of the 16 GB tier. NVIDIA's own spec table gives the RTX 4080 16 GB GDDR6X on a 256-bit interface with 9728 CUDA cores; 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. Twice the bus, roughly twice the shader count, an older architecture and an older memory generation. NVIDIA publishes no memory-bandwidth figure for either card on those pages, so this page prints no bandwidth ratio — a ratio assembled from bus width alone is a guess wearing a spec sheet.

The bus 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 as on the two 128-bit 16 GB cards, for the same reason. If you came here from the RTX 4060 Ti 16GB page expecting the wider card to unlock a heavier file, it does not.

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: cast_bias_weight and then a plain torch.nn.functional.linear. Every forward pass reads the packed weights out of VRAM and materialises an unpacked copy before any maths happens, a traffic pattern a native INT8 or NVFP4 path does not have. A GGUF graph is unusually memory-bound, so a wider 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 no factor or percentage appears on this page.

The nvfp4 route, and the line this card sits on the wrong side of

Worth checking rather than assuming, because a lighter transformer in a format the hardware understands natively is the obvious hope on a 16 GB card. Two separate questions, and they have different answers.

Does it fit? The first-party ltx-2.5-22b-distilled-transformer-nvfp4.safetensors is 18,721,732,720 B = 17.436 GiB, over the card before a single companion. Two community nvfp4 rebuilds do fit on paper: DmitryDB at 13,572,563,959 B (12.640 GiB, 15.260 GiB resident), written per its README in "the stock Comfy NVFP4 wire format", and a lighter one from joeygambino at 12,499,335,336 B (11.641 GiB, 14.261 GiB resident) which is hours old and undocumented.

Would it be accelerated? On this card, no. ComfyUI gates its native NVFP4 kernels in comfy/model_management.py, and the gate is four lines long:

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

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

props.major is the compute-capability major version. NVIDIA's own CUDA-GPU list files the GeForce RTX 4080 under 8.9, so major is 8 and this card returns False; the same list files the RTX 5080 and RTX 5060 Ti under 12.0, so they return True. That is a real generational line and this card is on the Ada side of it — the one place where this page's answer genuinely differs from its Blackwell siblings' rather than merely repeating them. The publisher says the same thing in product terms: the rebuild is a "supported fallback on RTX 4090 and native acceleration on supported Blackwell hardware", and an RTX 4090 is the same 8.9 target as this card.

So it would load and run in software, at 0.740 GiB of headroom — tighter than Q4_K_S, and tighter than the smallest overhead ever observed on the one 16 GB card where this model has been instrumented. Its own validation is loader-level and on other hardware: 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." It is also explicitly a community conversion — "These are community conversions, not official Lightricks or ComfyOrg releases." Interesting to try second. Not the thing to try first, and on Ada not for the reason people expect.

The W4A8 builds are in the same category and thinner still: ComfyUI core does register asym_w4a8_int8 as a first-class format, and Winnougan's 11.660 GiB file would fit with room to spare, but no run of either W4A8 publisher's file has been reported anywhere this page looked, in tsolful's own discussion thread the publisher answers a question about his file sizes with "I accidentally changed a value on the quantization, reuploading now", and Winnougan's card lists six files where the repo contains three. Experiments, not an install path.

What it costs in time — the part nobody has measured

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

Not known: any instrumented figure for LTX-2.5 on an RTX 4080 — no benchmark at /check/ltx-2-5/rtx-4080, and no vendor table that names the card, since NVIDIA's own LTX generation guide names only 50-series cards and only LTX-2.3. What does exist is three community posts, none of which pins a configuration.

Known, on this exact card, configuration unstated: "5 secs 1080p vid on 226 secs on my 4080 is just nuts" — u/skyrimer3d, r/StableDiffusion, release day. He names no checkpoint, no quant and no system RAM, and he is running the LTX Director + Seedhunter node stack rather than the shipped template, so this cannot be attached to any particular route — including this recipe's. It is the answer to "does an RTX 4080 run this at all", and nothing more.

Known, from the card's near sibling, on a route this recipe does not take: the RTX 4080 SUPER owner in this thread reported, after fixing his decode stall, that "A 7-second 1080 video was generated in 300 seconds.", and earlier that "It took 45 seconds for a 5-second video at 0.9". Conversational figures from one person, on a different card, running the 20.027 GiB INT8 checkpoint under ComfyUI's weight streaming rather than this recipe's GGUF rung, with the frame geometry not pinned in either sentence.

Taken together those three establish that 16 GB Ada cards complete this model in minutes. They do not establish a rate, they do not agree on a configuration, and none of them is this recipe's install — so no constant is derived from them here.

Known, and a specific reason not to borrow a Blackwell sibling's clock: ComfyUI issue #15261 is an open, undiagnosed report titled "Why 5070ti + 64G is 2.3x faster than 4080 + 64G in minimax h3 ?" — a plain RTX 4080 against an RTX 5070 Ti, both 16 GB with 64 GB of system RAM, on ComfyUI's official workflow for a different video model (MiniMax H3, not LTX-2.5), where the 4080 took 690 s against the 5070 Ti's 300 s on an identical job. Different model, different graph, no maintainer response and no explanation — so it is not a claim about LTX-2.5. It is also not one measurement: the reporter timed the 4080 side himself — "tests i conducted myself" — while the 300 s RTX 5070 Ti figure he compares against is second-hand — his own parenthetical says he "heard about it from a" YouTube video, which the issue links but this page has not watched. So the 690 s is a first-hand number on this exact card and the ratio around it is not. Even discounted that far it is the closest thing anyone has to putting this card next to a same-capacity Blackwell one on an over-VRAM ComfyUI video workload, and it points the opposite way from the spec sheet. That is precisely why the measured throughput constant from the RTX 5060 Ti session is not rescaled onto this page: rescaling a measurement by a spec ratio produces a number that looks measured and is not.

Known, from the runtime's source: the GGUF rung does not buy arithmetic throughput. It saves 9.293 GiB against the official INT8 transformer, which is what makes the model fit at all; it costs a little time rather than saving it, and that cost lands on the memory system.

Start at 0.4–0.6 MP and 49 frames, watch where the wall-clock actually goes, and contribute the numbers.

Installation

Every command block below is anchored to $COMFY. Set it once in the shell you are going to use, and the blocks become order-independent.

1. Get ComfyUI new enough

export COMFY="$HOME/ComfyUI"        # anywhere you like; every later block reads this

git clone https://github.com/Comfy-Org/ComfyUI "$COMFY"
cd "$COMFY"
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

LTX-2.5's audio-video nodes are in core (comfy_extras/nodes_lt.py), not in a custom pack. Support landed in commit 57ce8e1a ("Add support for LTX 2.5 (#15499)", 2026-08-11), which touches fifteen files across the LTX model, the Gemma 4 text encoder and the LTX nodes, and it was first tagged v0.32.0. For this recipe's path, that tag is enough — a claim worth stating plainly, because the sibling pages in this catalogue tell you to go past it and the reason they give does not apply here.

The commit they point at is bd34f338 "Fix float64 device in ltx diffusion decoder" (#15516), which landed the next day. Reading its patch: it changes exactly one file, comfy/ldm/lightricks/vae/na_diffusion_decoder.py — the diffusion decoder. This recipe deliberately installs the convolutional VAE instead, so that fix is on a code path you are not running. It matters if you go and try the diffusion decoder on purpose; it is not a reason to avoid the tag. This page pins master at b323a345 (v0.32.0 plus ten commits) because that is the tree every source-level fact below was read from, not because the tag is broken for this install.

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 needs one. This card is Ada Lovelace, compute capability 8.9 on NVIDIA's own CUDA-GPU list — an older and long-supported target — so install torch the ordinary way and skip the nightly. Our LTX-2.3 recipe on this same card reaches the same conclusion for the same reason.

One thing to know while choosing a torch build anyway, because it is easy to misread as an architecture gate and it is not: ComfyUI disables comfy-kitchen's accelerated CUDA backend whenever torch.version.cuda is below 13, and prints a warning that names "nvidia 20 series and above" — i.e. it applies to this card as much as to any Blackwell one, because it keys on the torch build, not the GPU. It is irrelevant to the GGUF path this recipe leads with, since ComfyUI-GGUF brings its own dequantisation. 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. 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 one of the concrete differences from this card's LTX-2.3 recipe, which does lead with the vendor 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, upscale the latent ×2, sample again. The template's own parameter table describes it as the "Latent upscaler applied before decoding for higher-fidelity output". Without the file the graph will not run at all.
• The prompt enhancer model is required even when the enhancer is switched off. See Troubleshooting.

Two deliberate substitutions against the template's defaults:

• GGUF instead of the official INT8 transformer, driven by the 16 GB budget — 10.734 GiB against 20.027 GiB.
• The convolutional video VAE, not the diffusion one. This is the substitution that matters most on this card, and unlike the transformer swap it is not primarily about memory. The template's manifest ships ltx-2.5-video-vae-bf16.safetensors (1.371 GiB), the diffusion decoder; this recipe uses ltx-2.5-video-vae-conv-bf16.safetensors (1.353 GiB), the convolutional one, which the vendor's own workflow note rates "Lower memory & faster" against the diffusion decoder's better quality (LTX-2.5_T2V_I2V_Single_Stage_Distilled.json). It is also the file two separate 16 GB owners — one of them on an RTX 4080 SUPER — found to be the difference between a decode that finishes and one that does not. See Troubleshooting; that section is not optional reading on this card.

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 while the first-party paths returned 401. Prefer first-party where you can.

• text encoder: DmitryDB/LTX-2.5-ComfyUI-Quants → text_encoders/gemma4-12b-with-proj-ltx-2.5-int8_lean_convrot.safetensors, 15,373,015,746 B. 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 — 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 them under split/ — split/vae/ltx-2.5-video-vae-conv-bf16.safetensors, split/vae/ltx-2.5-audio-vae-bf16.safetensors and split/latent_upscale_models/ltx-2.5-latent-spatial-upscaler-x2-bf16-1.0.safetensors. These are not rebuilds: each one's git blob oid matches the first-party entry for the same path (2905ee1b…, 08403b5a…, cec7bee6…), so the content is the same file, not merely the same size. The repo also carries the temporal upscaler (3fe643ad…) and the diffusion video VAE (4f679fe8…), both likewise blob-identical to first-party — worth knowing if you want to try the diffusion decoder deliberately, though see Troubleshooting for why this page does not.

This is the list of redistributors this recipe checked, not a survey of what exists on the Hub. The LTX-2 Community License travels with the bytes either way, so the licence page is a better place to work out what you are agreeing to than a mirror's README. The text encoder is not substitutable with a stock Gemma 4 12B checkpoint from either source — 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 computes total_pixels = megapixels * 1024 * 1024 — binary megapixels, not 1e6 — then rounds each side to the nearest multiple (comfy_extras/nodes_resolution.py, lines 78–81). The base stage then samples at width/2, and the VAE floors that to a multiple of 32. At the shipped multiple = 32 you silently lose a rung: 0.2 MP promises 608×352, 608/2 = 304 floors to 288, ×2 = 576×320. At multiple = 64 the halved size is always a clean multiple of 32, so the promised size is the delivered size.

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

Note this table differs from the one the template ships in its own Size Settings Reference note, which is computed at multiple = 32. Both are correct for their own setting. On an unmeasured card, 0.4 MP is the sensible first target — memory is not the constraint at any rung on this ladder, wall-clock is, and you want a cheap first datapoint before you spend twenty minutes on a 2.0 MP one.

Clip length

Frames are fps × duration + 1 and must land on 1 mod 8, for the VAE's 8× temporal compression. At 24 fps every whole second works: 2 s → 49, 4 s → 97, 6 s → 145, 8 s → 193. The template imposes no upper bound; several community reports in Troubleshooting put the trouble threshold at long clips rather than large frames, so grow duration last.

Distilled means CFG 1.0

Both LTXVDualCFGGuider nodes ship at [1, 1] and should stay there. The quantiser's README puts it plainly: "Guidance is baked into the weights; applying it again degrades output regardless of quantization."

Results

• Speed: Omitted — nothing here is measured at a pinned configuration. /check/ltx-2-5/rtx-4080 holds zero benchmarks. One owner of this exact card reports a 5-second 1080p clip in 226 s on an unstated checkpoint and a third-party node stack, and an RTX 4080 SUPER owner reports comparable wall-clocks on the INT8 offload route; both are quoted with attribution in "What it costs in time" above and neither is converted into a figure for this install. The only instrumented run of this recipe's exact path anywhere is on a Blackwell card, whose seconds do not transfer to Ada — and an open ComfyUI issue on a different video model has this card running 2.3× slower than a same-capacity Blackwell one, which is a reason to measure rather than to extrapolate. /contribute to end this bullet.
• VRAM usage: Derived, not measured: 13.354 GiB of resident weights against a nominal 16 GiB, leaving 2.646 GiB for activations, latents and context. The three fixed companions account for 2.620 GiB of that and do not change with the rung. The text encoder's 14.317 GiB is a sequential stage and is not additive. Real peak will be higher; 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.
• Resolution ceiling: Not established here. On the measured sibling both 2.0 MP and 8 s were reached without hitting one, in separate runs rather than a single one, and the binding constraint there was wall-clock rather than memory. Given identical weights and an identical graph, expect the same shape of limit on this card and an unknown ceiling on patience.
• Quality notes: The lead build protects the tensors that carry audio-video sync, and that is the whole reason it leads rather than the lighter same-label rung. Reading its GGUF header directly on 2026-08-13: of 4349 tensors, 620 carry gate in the name and not one of them is quantized (316 F32, 304 F16); only 1072 tensors are actually Q3_K. The one rung on the ladder that undercuts it at the same label quantises 304 of those 620 — see "The smaller Q3_K_M buys its 0.860 GiB partly out of the audio" above. 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, which declares the identical six-file manifest and the identical decode and guider defaults. 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.

Troubleshooting

Decode hangs forever, or takes far longer than sampling — check which video VAE you loaded

Start here. This is the most-reported LTX-2.5 problem across every surface searched for this page, it has bitten this card's near sibling twice, and it has two independent causes that produce the same symptom. Work through them in this order.

Cause 1 — the shipped template pairs the wrong video VAE with the convrot transformer. The template's models manifest declares ltx-2.5-video-vae-bf16.safetensors, the diffusion decoder, alongside the ...-int8-convrot transformer. Two independent 16 GB owners hit an indefinite stall at the VAE stage with that pairing and both fixed it the same way. On r/StableDiffusion, the reporter — whose own hardware line reads "4080 Super + 64GB RAM DDR5" — worked through it over two days and concluded "I solved it, it was the wrong VAE model, with convrot you have to use the Convrot VAE.", after which he could generate at 1080 with the decode tile back at its old 768. In a second thread an RTX 5070 Ti 16 GB owner got the same one-line answer from another community member — "You need to use the conv video VAE" — and posted a dedicated follow-up saying the single change fixed it entirely. A second RTX 4080 SUPER owner reported the same stall in that thread and never followed up.

Two caveats on that, because they are community diagnoses rather than a maintainer's. The "you have to use the Convrot VAE" framing is disputed in the follow-up thread, where a commenter points out that the file is a convolutional VAE and the template's default is a diffusion VAE — the "convrot" in the transformer's name is a different thing. And nobody has established whether the correct pairing is a hard requirement or merely much faster. What is not in dispute is the action and the outcome: switching to ltx-2.5-video-vae-conv-bf16.safetensors is what this recipe already installs, and it is the first thing to verify if your decode never finishes.

Cause 2 — an old template package with the old decode widgets. Commit c74863f8 (2026-08-12, PR #1120) changed three LTX-2.5 templates' VAE Decode (Tiled) widgets, shipping in comfyui-workflow-templates 0.11.40, which is what ComfyUI's requirements.txt pins today. In video_ltx2_5_t2v and video_ltx2_5_i2v — the two this recipe uses — the change is [768, 64, 4096, 32] → [512, 64, 64, 16]: tile 768→512, temporal size 4096→64, temporal overlap 32→16. (The third, video_ltx2_5_flf2v, lands on the same [512, 64, 64, 16] but started from a temporal overlap of 64, not 32, so quote the before-values per template rather than as a single set.) That is exactly what the community had converged on independently: in Lightricks/LTX-2.5 discussion #15 a user on a 16 GB RTX 5070 Ti writes "Mine got stuck too. I have a 5070ti but I adjusted these and it goes pretty fast." and names temporal_size: 64 / temporal_overlap: 16 as the fix, while an r/comfyui thread has an RTX 5090 owner advising others to "change the VAE Decode (Tiled) node settings to 512 from 768 for tile size and the temporal size down to 128 from 4096" after his own install could not get past a 10-second clip. All are community members, none from Lightricks.

So: check your comfyui-workflow-templates version before you touch anything else, then check the VAE filename. If you are on the current package with the conv VAE 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. Raise it and you give that property away. In the same r/comfyui thread a poster reports going the other way (256/32/300/12) with no quality difference he could see, and another reports that turning the prompt enhancer off is what fixed his decode time — "it went right back to normal decode time when I turned it off". On an unmeasured card both are reasonable things to try, and good things to report back.

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

size mismatch for audio_embeddings_connector... on the GGUF loader

The most common failure specific to the GGUF path, and it is about which GGUF you downloaded, not about your card. LTX-2.5's DiT dimensions are not derivable from tensor shapes — ComfyUI reads them from a config blob in the safetensors metadata, and no stock GGUF conversion emits an equivalent field. A naive conversion therefore builds an LTX-2.3-shaped model and pours 2.5 weights into it. The quantiser's README states the consequence directly: "If you convert LTX-2.5 to GGUF yourself, it will not load."

The symptom is a wall of shape mismatches on UnetLoaderGGUF — keyframes_abs_pos_embedding at [4096] against [1, 4096], learnable_registers at [128, 2048] against [128, 3840]. It is reported on a 16 GB card driving exactly this path at ComfyUI issue #15540, where the reporter 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." — 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, and he never says whose build he used. That issue is now closed (state re-read 2026-08-13).

Fix: use a build whose author solved it. Reading the lead file's GGUF header over an HTTP range request on 2026-08-13 shows both halves of the fix present: general.architecture = ltxv, 4349 tensors, 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 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.

"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 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, it rewrites your prompt so a first-run comparison is harder to reason about, and at least one user in the decode thread above reports that turning it off is what fixed his decode time.

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 instrumented sibling card. Fix the prompt, then tune size and duration.
3. Do not raise the decode tile size. See above.
4. Drop a rung — Q2_K, an 8.228 GiB transformer for 10.848 GiB resident, is the smallest sane one, at a real quality cost.
5. Launch with --lowvram.
6. Fix the pagefile before blaming the GPU. Two of the six files — the 14.317 GiB text encoder and the 9.573 GiB prompt enhancer, 23.890 GiB together — are sequential stages that live in host RAM rather than on the GPU. A host-RAM OOM here reads exactly like a VRAM problem and will send you down the wrong rung. Our 24 GB anchor recommends 64 GB of RAM; both RTX 4080 SUPER reports and both 16 GB reports of the decode stall came from machines with 64 GB, and on the measured 16 GB Blackwell sibling 31.1 GiB of RAM plus a fixed 32 GiB pagefile was enough and nothing thrashed.

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. The consequence the reporter describes is a second sampler that loads only part of the model into 16 GB and then thrashes PCIe without reaching step 0.

Disambiguation, because it matters twice over: that report was filed 2026-08-06, before LTX-2.5 shipped, so it describes an earlier checkpoint in the same ComfyUI LTXAVModel class rather than this one, and the reporter's card is an RTX 5080 rather than this one. What 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.

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

Quite likely — LTX-2.3 on RTX 4080 is published and this card is a long-standing 16 GB target for that model. Worth knowing up front that that pair is not benchmarked either: it also reads verdict: unknown with zero benchmarks, so neither page is quoting you a measured second. Almost nothing on disk carries over:

• The transformer does not. A 2.3 GGUF will not load into a 2.5 graph, and vice versa — see the shape-mismatch section above.
• The text encoder does not. LTX-2.3 conditions on Gemma 3; LTX-2.5 conditions on a Gemma 4 12B carrying LTX's own projections — the two eras have separate tokenizer paths in ComfyUI's own comfy/text_encoders/lt.py (Gemma3_12BTokenizer against ltxav_gemma4_tokenizer). The symptom of getting this wrong is not an error, it is prompts being quietly ignored: in an r/comfyui thread a commenter diagnoses exactly that for someone's 2.5 workflow — "LTX 2.5 uses Gemma4, LTX 2.3 used Gemma3 which you still have there in your workflow".
• The VAEs do not, and this is the one that will not announce itself. Download the 2.5 files, and take the conv one.

The 16 GB strategy is different in kind, not just in file names. This card's LTX-2.3 recipe is titled "GGUF + CPU-Offloaded Gemma" for a literal reason: there, the Gemma 3 12B encoder is the binding constraint and the recipe's whole lever is forcing it off the GPU with --novram or --reserve-vram 10, driving the vendor ComfyUI-LTXVideo pack's own example workflows. Here the encoder is a sequential stage that ComfyUI's core template already evicts on its own, no vendor pack is involved, and the lever moves to the transformer's quantisation rung. If you arrive expecting to re-apply the offload flags, you will be tuning the wrong thing.

QuantStack/LTX-2.5-GGUF is empty

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

Stock ComfyUI-GGUF cannot load a GGUF conditioning text encoder

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. There is no lighter GGUF drop-in for it — the emphasis is on drop-in, and the reason is in the node pack rather than in what anyone has published.

ComfyUI-GGUF/loader.py gates text-encoder architectures against a fixed list, and at the pinned commit 6ea2651e that list is TXT_ARCH_LIST = {"t5", "t5encoder", "llama", "qwen2vl", "qwen3", "qwen3vl", "gemma3"}. It has gemma3 and no gemma4. That single line is what produces the Unexpected text model architecture type in GGUF file: 'gemma4' error documented below, and it means a GGUF encoder cannot be loaded by an unmodified install however good the file is.

Here is the space the search covered, so you can judge how current it is. As of 2026-08-13, every LTX-2.5 GGUF repository this page found published transformer quants only: the six repos — realrebelai, Abiray, vantagewithai, QuantStack, ChrisColeTech and joeygambino — carry zero encoder-shaped .gguf files between them, checked file-by-file against each repo's tree API on 2026-08-13. Searching the Hub more broadly for a Gemma-4 GGUF that is also an LTX artifact returns nothing: LTX GGUF repos are transformers, and Gemma 4 GGUF repos are chat models. (The Hub's search is a substring match on the repo id, so it must be queried one token at a time — gemma4, gemma, ltx, ltxv — and filtered by hand; a multi-word query returns zero regardless of what exists.)

The demand side agrees. LTX-2 issue #278 is an open request from a community user asking Lightricks for exactly this file — "Please release the GGUF series as soon as possible, especially the" gemma4-12b-with-proj-ltx-2.5- one — which is not something anyone writes about a file that already exists.

Lighter encoders exist, and none is validated. Three community rebuilds undercut the 14.317 GiB first-party file, and since the encoder is the one stage measured to move the peak on a 16 GB card, they are worth knowing about even though this recipe leads with none of them:

The first two are safetensors, so neither goes anywhere near the ComfyUI-GGUF loader at all. The nvfp4 one gets no native kernels on this card for the reason given earlier, and its publisher says no end-to-end test has been done. The W4A8 one is hours old with zero downloads and its filename drops the with-proj marker the first-party file carries, which this page has not verified means anything either way — check its tensor names before you trust it to carry LTX's projections.

The third one is a GGUF, and it postdates this page's search by fifty minutes. elix3r/gemma4-12b-with-proj-ltx-2.5-GGUF was created at 18:04 UTC on 2026-08-13 and ships a Q5_K_M conditioning encoder at 8.861 GiB, 5.456 GiB under the first-party file. It does not make the paragraph above stale in the way it looks: the repo also ships patches/ComfyUI-GGUF-ltx25-gemma4.patch, i.e. its author had to patch the node pack around the TXT_ARCH_LIST line quoted at the top of this section, so this is a patched route rather than a drop-in, and the install instruction on this page is unchanged. Everything stated here about it comes from public repository metadata: the repo is gated: auto and an unauthenticated fetch of both the GGUF and the patch returns 401, so neither the weights nor the patch body could be read for this page. Zero downloads, zero likes, no discussions, and no report of anyone running it. It is recorded because it exists, not because it is recommended — if you accept its gate and try it, say what happened.

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

Worth its own entry, because the exception text is identical to what the section above would produce and it will send you to the wrong conclusion.

ComfyUI-GGUF issue #474 — open, state read from the GitHub REST API on 2026-08-13 — carries this error against LTX-2.5, and it is not about the conditioning encoder. The reporter is feeding a third-party 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. Two different models, two different slots, one exception string. The issue names the enhancer node and gemma-4-E2B throughout and mentions neither text_encoder nor CLIPLoader once.

If you were quantising the enhancer to save memory, stop and just switch it off instead: that frees the whole 9.573 GiB stage, costs you nothing but auto-rewritten prompts, and this recipe turns it off by default anyway. See the enhancer note above for why you still have to download the file.

Something else

The space searched, so you can tell what this page does and does not cover. For evidence about this exact pair: all 30 Lightricks/LTX-2.5 Hugging Face discussions enumerated individually and every message grepped for GPU model numbers (zero mention of any 4080 there); the discussions on all six community LTX-2.5 quant repos enumerated (one of which, joeygambino, was created the same day this page was written and is not referenced by any sibling recipe); the Lightricks/LTX-2, city96/ComfyUI-GGUF and Comfy-Org/ComfyUI issue trackers searched for this card; seventeen Reddit searches on old.reddit.com across r/comfyui, r/StableDiffusion and site-wide, with every promising thread opened and read in full rather than judged from its title; and two general web searches. That turned up the plain-RTX 4080 post and the two RTX 4080 SUPER reports quoted above, and no other. Not searched: CivitAI, YouTube, Discord and X — and note that the one plain-4080 datapoint on this page mentions a Discord in passing, so that is a real gap rather than a formality.

Two notes on how to redo this search, because both cost time here. Reddit is genuinely searchable, but only through old.reddit.com: www.reddit.com serves an anti-bot shell, the .json endpoints return 403, and even the working HTML endpoint intermittently returns an empty body under load — a zero result has to be re-run before it means anything, and several here flipped from zero to twenty-five on a retry. Hugging Face model search is a substring match on the repo id, so multi-word queries return nothing regardless of what exists; query one token at a time and filter by hand.

Report problems, or a first instrumented measurement, via the submission form.