LTX-2.5 generates picture and sound in one pass. It is also 42 GB of bf16 weights, and the text encoder beside it is another 26 GB. This repo is the set of weights that make it run on a card that does not have that.

Two families, because ComfyUI has two loaders and people are split across them:

.gguf — for ComfyUI-GGUF (city96). The familiar Q-ladder.
comfy-*.safetensors — for stock ComfyUI 0.32+, no custom nodes. These use ComfyUI's own quantisation system (comfy_quant + the comfy-kitchen kernels), the same machinery Lightricks' official int8-convrot build uses. The 4-bit ones are the smallest way to run this model without a custom node in the graph.

What fits

Sizes are measured, not estimated. "Fits 16 GB" assumes the text encoder is not resident at the same time — ComfyUI frees it before sampling — and tiled VAE decode. File sizes are decimal GB (bytes / 10^9); card capacities are the usual binary GiB, so a 15.9 GB file occupies 14.8 GiB of a 16 GiB card. The gap is real and it is where your activation pool lives.

file	GB	12 GB	16 GB	24 GB
`LTX25-distilled-DiT-comfy-w4a4.safetensors`	11.2	tight	yes	yes
`LTX25-distilled-DiT-comfy-w4a8.safetensors`	12.5	—	yes	yes
`LTX25-distilled-DiT-Q2_K.gguf`	7.9	yes	yes	yes
`LTX25-distilled-DiT-Q3_K_M.gguf`	10.6	tight	yes	yes
`LTX25-distilled-DiT-Q4_K_S.gguf`	12.9	—	yes	yes
`LTX25-distilled-DiT-Q4_K_M.gguf`	14.2	—	tight	yes
`LTX25-distilled-DiT-Q5_K_M.gguf`	15.9	—	—	yes
`LTX25-distilled-DiT-Q6_K.gguf`	17.8	—	—	yes
`LTX25-distilled-DiT-comfy-nvfp4.safetensors`	12.5	—	yes	yes
`LTX25-distilled-DiT-comfy-mix4x8-13.8GB.safetensors`	13.8	—	yes	yes
`LTX25-distilled-DiT-comfy-mix4x8-17GB.safetensors`	17.0	—	—	yes
`LTX25-distilled-DiT-Q8_0.gguf`	22.7	—	—	tight
`LTX25-distilled-DiT-comfy-int8.safetensors`	21.5	—	—	tight
`gemma4-12b-ltx25-comfy-w4a8.safetensors`	10.6	tight	yes	yes

On the text encoder: at bf16 it is 26.3 GB and at Lightricks' int8 15.4 GB, which on a 16 GB card means the encoder alone owns the machine for the one step that just makes an embedding. No GGUF of the LTX-2.5 encoder exists — ComfyUI-GGUF gates text encoders on TXT_ARCH_LIST, which carries gemma3 but not gemma4, so LTX-2.3's gemma3 encoder does have GGUFs and this one cannot. The open request (#450, 2026-05-28) has not been picked up — but comfy-native quantisations of it do exist and landed the same day as ours (Winnougan's w4a8-convrot at 10.6 GB, DmitryDB's nvfp4 at 11.2, vonkaiser's nvfp4-torchao at 8.9). Ours is w4a8 at 10.60 GB, within 2 MB of Winnougan's — the same format at the same size, published independently. Treat it as a mirror, not a first.

The 16 GB recipe

LTX25-distilled-DiT-Q3_K_M.gguf at 10.6 GB (or comfy-w4a4 at 11.2 GB if you would rather not install a custom node)
gemma4-12b-ltx25-comfy-w4a8.safetensors for the text encoder
the stock bf16 VAEs — ltx-2.5-video-vae-bf16 and ltx-2.5-audio-vae-bf16 (1.5 GB and 0.4 GB; quantising them is not worth what it costs, see below)
tiled VAE decode: tile_size 512, temporal_size 32
the distilled schedule: 9 steps then 4, video_cfg and audio_cfg at 1.0

How these were made

Every quant is cut from Lightricks' bf16 originals, never from another quant.

GGUF. An F16 master with general.architecture = "ltxv" and the model.diffusion_model. prefix stripped, then llama-quantize. Two findings worth writing down:

K-quants are legal on essentially the whole model. 4041 of 4349 tensors have a last dimension divisible by 256. Of the 308 that do not, 306 are bias vectors that stay F16 like every other bias — 304 gate-logit biases of length 32, plus proj_out.bias and audio_proj_out.bias at length 128 — and two are real weight matrices: patchify_proj.weight and audio_patchify_proj.weight, whose 128-wide axis cannot take a K-quant. Those two fall back to F16, which is what you want anyway since they are the input projections. (MiniMax-H3, for comparison, cannot K-quant at all: its 2688-wide tensors rule it out everywhere.)
IQ-quants are not. llama-quantize refuses them for this class of file: failed to quantize: Invalid quantization type for image model (Not supported). So no IQ2/IQ3/IQ4 ladder exists for LTX-2.5, and any repo offering one is doing something else.

comfy-native. ComfyUI 0.32 has its own quantisation system, and Lightricks' comfy-int8-convrot release is a working example of the file format. The set of layers to quantise is mirrored from that file rather than guessed: the same 1440 Linears, with adaLN, the timestep embedders, every norm and bias and the scale-shift tables left in bf16. Those steering layers are about 6% of the file and rounding them is how a quantised DiT dies. What changes here is the format — 4-bit instead of 8.

Two formats in one file

Two builds here carry two quantisation formats at once — some layers 4-bit, some 8-bit, in one file. ComfyUI reads comfy_quant per layer prefix (ops.py:1136) and sets module.quant_format from that layer's own blob, so this needs nothing new on the loading side. Verified rather than assumed: both formats load out of one file and forward finite output.

Which layers earn the extra four bits was measured. All 1440 quantised layers were reconstructed at both precisions against the bf16 original, then promoted by error-removed-per-byte until the budget ran out — the greedy solution to minimising total squared reconstruction error under a size cap.

build	GB	layers at int8	bytes spent	squared error recovered
`comfy-w4a8` (floor)	12.5	0 / 1440	—	0%
`comfy-mix4x8-13.8GB`	13.8	386 / 1440	1.29 of 8.98 GB	39.5%
`comfy-mix4x8-17GB`	17.0	831 / 1440	4.49 of 8.98 GB	82.1%
`comfy-int8` (ceiling)	21.5	1440 / 1440	8.98 GB	100%

Ranking by relative error does not work, and this is the part worth stealing. Across all 1440 layers the 4-bit relative error lies between 0.0721 and 0.0737 — a two percent spread — so by that measure every layer is equally worth promoting and the ordering is noise. Weighting each layer by ‖W‖² is what separates them, and once you do, 363 of the first 386 promotions land in the audio tower, only 23 in the video tower.

Why there is no FP8 build here

There was, and it was cut. Measured across 24 identical real layers:

format	GB	relative error	vs int8
`int8_tensorwise`	21.5	0.00942	1.00x
`mxfp8`	22.1	0.02656	2.82x
`float8_e4m3fn`	21.5	0.02682	2.85x
`float8_e5m2`	21.5	0.05289	5.62x

int8 is nearly three times more accurate at the same size, and INT8 tensor cores go back to Turing where hardware FP8 needs Ada. The reason is configuration rather than the number format: int8 here carries per-channel scales and the convrot rotation that spreads outliers, the way Lightricks configure theirs, while the FP8 builds carry one scale for the whole tensor. There is no card for which those three are the better choice, so they are not published. The one thing not measured is raw matmul speed on Ada and Blackwell.

Smaller than the alternatives, and why

Against realrebelai these come out a flat ~0.9 GB smaller at every level — 0.90 to 0.93 GB, Q2_K through Q8_0 — and the reason is boring and checkable: the 2605 tensors that are never quantised — norms, biases, the scale-shift tables, the two patchify projections — are written F16 here and F32 there. Same weights, half the bytes, no quality argument involved.

Against vantagewithai / Abiray the gap is that same ~0.9 GB at Q6_K and Q8_0 but much wider below it — 2.3 to 4.2 GB from Q2_K through Q4_K_S — which the F32 argument alone does not explain. Their Q2_K and Q3_K_M differ from each other by only 0.8 GB, so much of their low-bit ladder is not actually being quantised.

level	here	realrebelai	vantagewithai / Abiray
Q2_K	7.91	8.83	12.13
Q3_K_S	9.71	—	12.65
Q3_K_M	10.60	11.53	12.92
Q4_K_S	12.93	13.85	15.33
Q4_K_M	14.17	15.09	15.69
Q6_K	17.75	18.66	18.62
Q8_0	22.73	23.63	23.60

What they actually look like

Every quant below was rendered from the same scene, same seed, same size (544x960 pass 1, x2 to 1088x1920, 385 frames) - so the only variable is the weights. Frames compared side by side at 1:1, plus two independent audio-capable reviewers on the extremes.

Q2_K - visibly degraded. A haze sits over the whole frame, contrast is flat, and small light sources smear. It exists because a 12 GB card has nothing else, not because it is good.
Q3_K_S - do not use. Soft everywhere, and it fails structurally: in a three-shot render a man turned into a dog-like animal mid-sentence while his voice continued. Two independent reviewers caught it unprompted, at the same timestamp. This is the only file here that is not merely worse but broken.
Q3_K_M and up - usable, and genuinely hard to separate at this size. Hair holds strand detail, faces keep their structure, background foliage and fence mesh survive.
The three comfy-native 4-bit builds (w4a4, w4a8, nvfp4) hold up against the mid GGUFs at equal or smaller size, and need no custom node.

A caution about how these were compared. Encoded bitrate at a fixed quality target looks like a tempting stand-in for detail retained, and it is not one. Measured across the ladder it put Q2_K (7.9 GB) above Q5_K_M (15.9 GB), which the frames flatly contradict - it is measuring high-frequency content, and noise counts as content. It separates the broken file from the rest and nothing more. Any ranking of the middle of this ladder has to come from looking.

Between arms the model also reinterprets the scene - a lamp is orange in one and violet in another, the framing sits higher or lower. That is seed-level variance amplified by quantisation, not a quality difference, and it is worth knowing before you A/B two of these and conclude one is "better".

Honest limits

The dev (non-distilled) transformer is present at fewer sizes than the distilled one. Distilled is what most people run.
The VAEs are not quantised and should not be. They are 1.5 GB and 0.4 GB; the saving is inside the noise of a 16 GB budget and the decode is where artefacts are most visible.
Q2_K is included because a 12 GB card has nothing else, not because it is good.
These are quantisations, not fine-tunes. Anything the base model does badly, these do badly and smaller.
comfy-w4a4 and comfy-nvfp4 were built and tested on a Blackwell card. The w4a4 kernel path declares SM 7.5+ and w4a8 SM 8.0+, but neither has been run here on an Ada or Ampere 16 GB card — which is most of the audience this repo is aimed at. If you are on a 4080 / 4070 Ti Super and one of them falls back to something slow, that is a real possibility and worth reporting; the GGUF ladder has no such question over it. NVFP4 is Blackwell-only by construction.

License

LTX-2.x Community License Agreement, inherited from Lightricks/LTX-2.5. The license text travels inside every .safetensors file's metadata.

joeygambino/LTX-2.5-Quantized

LTX-2.5 22B — quantised for a 16 GB card