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

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 5060 Ti, 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.

Unlike the 24 GB pages, this one is measured. Fifteen instrumented generations on the card, 2026-08-13, zero OOM — including 1920×1088 with audio.

Hardware data: RTX 5060 Ti (16GB VRAM, Blackwell sm_120) · peak 13.82–15.54 GiB of 15.93 GiB across 15 runs · 1920×1088 × 97 frames with audio in 183.12 s · See benchmark data

ℹ️ Where the numbers come from, and how far to trust them. Every timing and VRAM figure below is from a single instrumented session on the site operator's own RTX 5060 Ti, run on 2026-08-13 and recorded as benchmark 281 at /check/ltx-2-5/rtx-5060-ti with verdict: runs. It is filed at confidence 0.6 on purpose: one rig, one operator, one driver, one evening — unreplicated by construction. Peaks are whole-card nvidia-smi samples at 500 ms, so they include the Windows desktop's share and are not comparable to per-process torch.cuda.max_memory_allocated figures. The trace covers only the active session — it opens at 13,726 MiB and never drops below 2505 MiB — so it carries no measured idle baseline to subtract. If you run this pair, contribute your numbers — a second rig is the single most valuable thing this page is missing.

⚠️ The finding that should change how you drive this card: peak VRAM does not scale with resolution or clip length. It scales with whether you edited the prompt.

Across an 11.3× range of frame area (576×320 → 1920×1088) and a 3.9× range of frame count (49 → 193), peak stayed inside a 14155–15912 MiB band with no positive correlation to either axis — the Pearson correlation of peak against output megapixel-frames is −0.42 over all 15 runs and −0.64 across the eleven runs that reused a cached prompt. The largest job of the day (1664×960, 193 frames) produced the lowest peak of all fifteen.

What does move the peak is the 14.317 GiB text encoder re-entering VRAM when the prompt text changes, on top of the transformer ComfyUI keeps resident between jobs. The four prompt-change runs averaged 15570 MiB against 14699 MiB for the eleven cached ones — 871 MiB; the cleanest matched pair (runs 13 and 14, same mode, same 1344×768 frame, differing in prompt and frame count) differ by 1316 MiB, with the longer clip being the roomier one. Every one of the three tightest runs of the day was a prompt change.

Operationally: start at the size you want and leave the prompt alone while you tune. "Start small and work up" is the wrong advice on this card.

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. One deliberate exception: the LTX-2.3 repo is not gated, which matters only as a contrast in the download step.

ℹ️ 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). Accept the licence on the model page and run hf auth login with a Read token before the download step. The template's own model note says as much: it asks you to make sure you have granted access to LTX-2.5 before downloading anything. The weights are under the LTX-2 Community License, not Apache-2.0 — a licence that travels with the file, so the ungated copies below carry it too. Ungated copies exist for all four gated files — see the download step.

Requirements

Why 16 GB works, in bytes

The official ComfyUI path loads a 20.027 GiB INT8 transformer (ltx-2.5-22b-distilled-transformer-comfy-int8-convrot.safetensors, 21,504,034,224 B). That is what ComfyUI's shipped template points at by default, and on this card it is a non-starter. A GGUF quantisation of the same distilled transformer replaces it, and the rest of the graph is unchanged.

Resident weights during the graph, using the lead rung:

Against a nominal 16 GiB that leaves 2.646 GiB of derived headroom for activations, latents and CUDA context — and the measurement lands exactly where that predicts: the lowest observed whole-card peak was 13.823 GiB, a shade above the weight sum, and the highest was 15.539 GiB.

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 on this card, and why the system-RAM requirement is real rather than decorative.

The rung ladder

Q3_K_M is the rung that was actually measured. The others are ranked by byte count, and the two above it are projected against the most favourable measured peak (14155 MiB, run 15) — a deliberately optimistic test that they still fail:

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

It is the obvious alternative, and the honest answer is that no measurement of that route on this card surfaced in any source this recipe searched — the Hugging Face discussions on the vendor and quantiser repos, the Lightricks, ComfyUI and ComfyUI-GGUF issue trackers, and r/comfyui and r/StableDiffusion. ComfyUI will stream a model larger than VRAM rather than refuse it, so the 20.027 GiB INT8 file is not a hard "no" — it is an unmeasured cost. There is evidence the offload route works well below 16 GB: in Lightricks/LTX-2.5 discussion #25 a community user reports LTX-2.5 on an RTX 3060 12GB, writing "Running a basic, default ComfyUI workflow (960x544, T2V) gets me a 15-second video in just about 5 minutes." — a default workflow, so the INT8 checkpoint, on a card that cannot hold a third of it. Taken at face value and assuming the template's default 24 fps, that is 0.498 megapixels × 361 frames = 180 megapixel-frames in 300 s, or 1.7 s per megapixel-frame against the 0.97 measured here — but on a much older and slower card, at a different quantisation, with a stated time the reporter himself rounds. It is not a controlled comparison and should not be read as one. What it does establish is that the offload route runs. The GGUF rung is the one this recipe measured, so it is the one it documents.

Two things worth reading twice. The same nominal quant differs by 1.3 GiB between publishers — Q3_K_M is 10.734 GiB from realrebelai and 12.036 GiB from the other two, at an identical 4349-tensor count. The name describes a recipe, not a file; which tensors stay at higher precision is the publisher's choice. And Q4_K_S is a near-miss, not a no: the gap is 64 MiB on the single roomiest run of the day and far more on any run that reloads the encoder. Note the unit — 2.168 GiB is 2220 MiB, and reading it as "2168" is how this question gets answered wrong. It deserves one deliberate attempt (fresh start, cached prompt, tile 512); it is not something to plan a workflow around.

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. The measured session ran on Windows with ComfyUI at D:\ComfyUI; substitute your own path.

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 (#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 this card peaks. The session ran b323a345, which is v0.32.0 plus ten commits.

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 sm_120 you need a CUDA 12.8+ torch build; the session ran 2.12.0.dev20260220+cu128.

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 LTXVGemmaCLIPModelLoader — 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. Two of the six are the ones people miss:

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

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. Two ungated repos between them cover all four gated files, and each path below returns 302 unauthenticated (verified 2026-08-13). Prefer first-party where you can. Of the two sources named here, one serves the same content and one is a rebuild — a distinction the Hugging Face API lets you check without downloading anything, by comparing the git blob oid of the redistributed file against first-party's.

This is a list of the redistributors this recipe checked, not a survey of what exists. Other ungated copies of these files are on the Hub; some are anonymous re-uploads of gated weights, and since the LTX-2 Community License travels with the bytes, working out what you are agreeing to is easier from the licence page than from a mirror. If the two below stop working, the first-party repo and the gate are the durable route.

• text encoder: DmitryDB/LTX-2.5-ComfyUI-Quants → text_encoders/gemma4-12b-with-proj-ltx-2.5-int8_lean_convrot.safetensors, 15,373,015,746 B (14.317 GiB). It is the same size to three decimals as the first-party file but not byte-identical — 43,960 bytes larger — so treat it as a comparable rebuild rather than a copy.
• both VAEs and the spatial upscaler, from one ungated repo — ChrisColeTech/LTX-2.5-turbo-GGUF, which reports gated: false:
  • split/vae/ltx-2.5-video-vae-conv-bf16.safetensors — 1,452,269,922 B, blob 2905ee1b0e1c
  • split/vae/ltx-2.5-audio-vae-bf16.safetensors — 364,866,540 B, blob 08403b5a5cf1
  • split/latent_upscale_models/ltx-2.5-latent-spatial-upscaler-x2-bf16-1.0.safetensors — 995,778,752 B, blob cec7bee61862
  All three blob oids match Lightricks/LTX-2.5 exactly, so this is the same content and not a re-export. The repo also carries the temporal upscaler (261,944,000 B, blob 3fe643add92b, likewise identical), which this recipe does not use.

Of the two redistributors named here, DmitryDB's encoder is the only rebuild rather than a copy. Whichever you use, the encoder is not substitutable with a stock Gemma 4 12B checkpoint — 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 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]. Leave all three 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, every row confirmed by a produced file:

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.

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; 8 s is simply the longest measured here.

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: 0.97 seconds per megapixel-frame, where a megapixel-frame is width × height / 1048576 × frames. That is a proportional least-squares fit over the eight measured runs above 50 MPix-frames; the individual ratios span 0.892 to 1.070. Below 50 MPix-frames the fixed cost of weight load and text encode dominates and the constant runs optimistic — the smallest run of the session took 60.55 s against 8 s of predicted work. Worked anchors, all measured: 1920×1088 × 97 frames in 183.12 s, 1344×768 × 193 frames in 181.85 s, 1664×960 × 193 frames in 294.06 s, 768×448 × 97 frames in 41.92 s. Step-level at 1920×1088: 7.06 s/it on the 8-step first pass, 30.88 s/it on the 3-step second pass. See /check/ltx-2-5/rtx-5060-ti; if your numbers differ, contribute them.
• VRAM usage: peak 14155–15912 MiB of 16311 MiB across 15 runs, zero OOM — whole-card nvidia-smi samples at 500 ms, so the desktop's share is included. The worst case, 15912 MiB, is benchmark 281 and it is a prompt-change run; the roomiest was the largest job of the day. Full run table and the raw 5288-sample trace are committed alongside this recipe's source material.
• Resolution ceiling: none found. 1920×1088 with audio ran with 1799 MiB spare. The limit on this card is wall-clock, not memory. Nothing above 2.0 MP or 8 s was tried, for lack of reason rather than lack of headroom.
• Quality notes: audio came out present and in sync at Q3 across the session, which is the specific risk this quant tier carries. The reason is that realrebelai's build protects the gate tensors: reading the tensor table directly, 620 tensors carry gate in the name and not one of them is quantized (316 F32, 304 F16). The publisher's README explains why that matters — "Quantize them and video still looks fine while audio desyncs or degrades" — a failure mode that passes a quick look at the video and only shows up in the audio. Only 1072 of the file's 4349 tensors are actually Q3_K; ComfyUI logs the same mix at load time. What this does not establish: no side-by-side against the 24 GB INT8 anchor was run, so "no visible degradation" is one operator's judgement on the clips produced, not a measured quality claim. The publisher's own table rates this rung "Usable, softer detail".
• Image-to-video: works, produces audio the same way, with two behaviours worth knowing. ResolutionSelector is a scale hint in i2v — the frame comes from the input image's aspect, so the megapixel figure you ask for does not determine the frame on its own. It does not follow that i2v frames run larger than the ladder predicts: all five i2v runs landed on rungs the t2v runs also used (640×320, 768×448, 1344×768 twice, 1664×960), and since the run table records delivered sizes rather than requested ones, nothing measured here shows a size offset between the two modes in either direction. And character consistency is resolution-bound, not quantization-bound: identity drifted visibly at 640×320 and held far better from 768×448 up. On the hardest test — a full-body exit from a car, where everything below frame has to be invented — it still drifted. The standard remedy is a seed lottery, which is cheap here precisely because the prompt stays cached and every cached-prompt run of the session had between 1196 and 2156 MiB of headroom.

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

Troubleshooting

size mismatch for audio_embeddings_connector... on the GGUF loader

The most common failure on this path, and it is about which GGUF you downloaded, not about your card. LTX-2.5's DiT dimensions are not derivable from tensor shapes — ComfyUI reads them from a config blob in the safetensors metadata, and no stock GGUF conversion emits an equivalent field. (The format itself is not the obstacle — its key-value store carries the config perfectly well once a publisher chooses to write it, which is exactly what the Fix below turns on.) 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 learnable_registers: [128, 2048] against [128, 3840], or keyframes_abs_pos_embedding: [4096] against [1, 4096]. It is reported on a 16 GB card at ComfyUI issue #15540 — a community user on an RX 7800 XT 16GB 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; a second user reports the same. Neither states which publisher's file they used.

Fix: use a build whose author fixed it. The three files this recipe names carry the full transformer config as a GGUF string KV named config (2199 chars, AVTransformer3DModel), which ComfyUI-GGUF/loader.py surfaces to ComfyUI as metadata — verified by HTTP Range-reading the headers of all three publishers' Q3_K_M on 2026-08-13. All three also survive the second half of the error above — keyframes_abs_pos_embedding, whose true shape is [1, 4096] — but by two different routes, which is worth knowing if you evaluate a fourth publisher. ComfyUI-GGUF/loader.py first looks for a comfy.gguf.orig_shape.<tensor> key and, failing that, falls back to reversed(tensor.shape) at line 129. realrebelai's file takes the first route: ggml trimmed the trailing singleton, so the tensor is stored one-dimensional as [4096], and the file carries exactly one orig-shape key — comfy.gguf.orig_shape.keyframes_abs_pos_embedding = [1, 4096] — to put it back. Abiray's and vantagewithai's take the second: no orig-shape key at all, but the tensor keeps both dimensions as [4096, 1], which reversed is [1, 4096]. Either mechanism works; having neither is what produces the error. 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 measured session never saw it, and why the "leave VAEDecodeTiled alone" instruction above is not a formality. The gray-frame report is a separate matter and is covered at the end of this section.

Commit c74863f8 (2026-08-12) changed the LTX-2.5 templates' VAE Decode (Tiled) widgets from [768, 64, 4096, 32] to [512, 64, 64, 16] — tile 768→512, temporal size 4096→64, temporal overlap 32→16 — shipping in comfyui-workflow-templates v0.11.40. 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 other 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 — the fixed-size tiling is the single setting most responsible for this card behaving well, because a larger frame means more tiles, not a larger buffer. Raise it and the flat-peak property this whole recipe rests on disappears.

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.

"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 — confirmed by the stage-by-stage peaks. 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. Observed directly.

Note also that the enhancer ships ON: prompt_enhance is true on the outer node of both the shipped t2v and i2v templates (re-verified 2026-08-13), and the template's own parameter table advertises it as "Toggle the built-in Prompt Enhancer: expands short prompts into rich cinematic instructions at near-zero extra compute". 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. Re-encoding costs 871 MiB by group means and 1316 MiB on the cleanest matched pair, and it is the only thing measured to move 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. The measured machine had 31.1 GiB of RAM and a 2 GiB auto-managed pagefile; a fixed 32 GiB (max 64) pagefile on a second volume was added before the runs and nothing thrashed. 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.

Two ComfyUI installs sharing one Python environment

If you have a legacy packaged ComfyUI alongside a current one, check they do not share a venv. The measured machine had a v0.32.0 git install and a v0.17.2 packaged install pointed at the same environment; the old one's requirements.txt pins comfyui-workflow-templates==0.9.21 and comfyui-embedded-docs==0.4.3, so launching it rolled the new install's packages back mid-session — silently removing the LTX-2.5 templates. Fixed by copying the venv and pointing the current install's adoptedPythonPath at the copy.

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.

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 when this was written (re-checked 2026-08-13). The three publishers named above filled the gap instead. If QuantStack ships, re-check the rung table — a different build could move the Q4_K_S near-miss.

Something else

No other widely-reported issues surfaced for this pair. Report problems, or a second measurement, via the submission form.