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

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.

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

1. 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)
2. gemma4-12b-ltx25-comfy-w4a8.safetensors for the text encoder
3. 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)
4. tiled VAE decode: tile_size 512, temporal_size 32
5. 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.

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:

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.

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.

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.