Everything here is free and stays free — the format spec, the nodes, the workflows, the cartridges, the LoRAs. If it saved you a night of debugging (it contains several hundred of mine), tips keep the 5090 warm:<ul><li>☕ <a target="_blank" rel="ugc" href="https://ko-fi.com/joeygambino">Buy me a coffee on Ko-fi</a></li><li>💛 <a target="_blank" rel="ugc" href="https://github.com/sponsors/jlucasmcrell">Sponsor on GitHub</a></li><li>🔁 <a target="_blank" rel="ugc" href="https://liberapay.com/joeygambino">Liberapay</a> (recurring)</li><li>⚡ Or right here: the Civitai tip button on this page sends Buzz directly.</li></ul><h1 id="ltx-2.5-22b-cut-down-to-fit-your-card">LTX-2.5 22B, cut down to fit your card</h1>LTX-2.5 makes picture and sound in one pass, which is the whole reason to want it. It is also 42 GB of bf16 weights, with a text encoder beside it that is another 26 GB. This is the set of weights that make it run on a card that does not have that.Fourteen builds, every one cut from Lightricks' bf16 originals and never from another quant. Pick your version above by how much VRAM you have.<h2 id="read-this-first:-there-are-two-loaders">Read this first: there are two loaders</h2>Half these files need a custom node and half do not, and picking the wrong loader gives you an error that does not explain itself.<ul><li><code>.gguf</code> - load with <a target="_blank" rel="ugc" href="https://github.com/city96/ComfyUI-GGUF">ComfyUI-GGUF</a> (city96), node <code>Unet Loader (GGUF)</code>. The familiar Q-ladder.</li><li><code>comfy-*.safetensors</code> - load with the stock <code>Load Diffusion Model</code> node on ComfyUI 0.32 or newer. No custom node at all. These use ComfyUI's own quantisation system, the same machinery behind Lightricks' official <code>int8-convrot</code> build.</li></ul>Every filename with <code>-comfy-</code> in it is the second kind. That is the whole rule.<h2 id="which-file-do-i-want">Which file do I want</h2>12 GB card - take <code>Q3_K_M</code> at 10.60 GB and shorten your clips. It fits at reduced frame counts and looks like the rest of the ladder. <code>Q2_K</code> at 7.91 GB is the fallback when you need the frames more than the picture - it renders the scene correctly but softly, with faces losing their detail and a haze over the whole frame. Reach for it second, not first.16 GB card - <code>Q3_K_M</code> at 10.60 GB is the sweet spot. <code>comfy-w4a8</code> at 12.52 GB if you would rather not install a custom node. <code>comfy-mix4x8-13.8GB</code> if you can spare the room: it is the most quality per byte in this tier, for reasons measured below.24 GB card - <code>Q5_K_M</code> at 15.90 GB or <code>Q6_K</code> at 17.75 GB, or <code>comfy-mix4x8-17GB</code> at 17.01 GB with no custom node.32 GB card - <code>Q8_0</code> at 22.73 GB, or <code>comfy-int8</code> at 21.50 GB with no custom node. At this size you are buying certainty, not visible quality.The Gemma-4 text encoder at 10.60 GB is in the 16 GB version and you want it whichever transformer you pick - at bf16 that encoder is 26.3 GB, which on a small card means it owns the whole machine for the one step that just builds an embedding.<h2 id="the-16-gb-recipe">The 16 GB recipe</h2><ul><li><code>LTX25-distilled-DiT-Q3_K_M.gguf</code> at 10.6 GB, or <code>comfy-w4a8</code> at 12.5 GB for the no-custom-node route</li><li><code>gemma4-12b-ltx25-comfy-w4a8.safetensors</code> for the text encoder</li><li>the stock bf16 VAEs, <code>ltx-2.5-video-vae-bf16</code> and <code>ltx-2.5-audio-vae-bf16</code> - 1.5 GB and 0.4 GB, and quantising them is not worth what it costs</li><li>tiled VAE decode: <code>tile_size</code> 512, <code>temporal_size</code> 32</li><li>the distilled schedule: 9 steps then 4, <code>video_cfg</code> and <code>audio_cfg</code> at 1.0</li><li>first pass at 0.2 to 0.5 megapixels - <code>608x352</code> or <code>960x544</code> - then upscale. The two-pass sigma schedule is tuned for that band, and rendering pass one at full resolution is the most common way to get mush out of this model</li></ul><h2 id="two-formats-in-one-file-and-how-the-layers-were-picked">Two formats in one file, and how the layers were picked</h2>Two of these builds carry two quantisation formats at once - some layers 4-bit, some 8-bit, inside one file. ComfyUI supports this natively: it reads the format from a small blob attached to each individual layer, so a file may declare a different one on every Linear and the stock loader takes it without complaint.Which layers earn the extra four bits was measured, not guessed. All 1440 quantised layers were reconstructed at both precisions and compared against the original bf16 weights, then promoted in order of error removed per byte spent until the size budget ran out.The efficiency is the point. <code>mix4x8-13.8GB</code> spends 1.29 GB of the 8.98 GB that separates all-4-bit from all-8-bit - about a seventh of the cost - and recovers 39.5% of the reconstruction error that going all the way to int8 would remove. <code>mix4x8-17GB</code> spends half the cost for 82% of the benefit. Neither sits near the straight line between the two ends, which is the only reason a mix is worth building.One finding worth stealing if you build your own: ranking layers by relative error does not work. Across all 1440 layers the 4-bit relative error falls between 0.0721 and 0.0737 - a two percent spread - so by that measure every layer looks equally worth promoting and the ranking is noise. Weighting each layer by its actual weight magnitude is what separates them, and once you do, 363 of the first 386 promotions land in the audio tower rather than the video one.<h2 id="what-they-actually-look-like">What they actually look like</h2>Every build was rendered from the same scene, same seed, same size - 544x960 first pass, 2x to 1088x1920, 385 frames - so the weights are the only variable. Frames compared at 1:1, plus two independent audio-capable reviewers on the extremes.<ul><li>Q3_K_M and up are genuinely hard to separate. Hair holds strand detail, faces keep structure, background foliage and fence mesh survive. If you are choosing between Q4_K_S and Q6_K on quality grounds, you are choosing on a difference you will struggle to see.</li><li>The comfy-native 4-bit builds - <code>w4a4</code>, <code>w4a8</code>, <code>nvfp4</code> - hold up against the mid GGUFs at equal or smaller size and need no custom node. <code>nvfp4</code> is the best-looking of the three.</li><li>Q2_K is visibly degraded. A haze sits over the frame, contrast is flat, small light sources smear. It is here because a 12 GB card has nothing else, not because it is good.</li></ul>A warning about comparing these yourself. Between arms the model 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 encoded bitrate is not a stand-in for detail retained: measured across this ladder it ranked Q2_K above Q5_K_M, which the frames flatly contradict. It measures high-frequency content, and noise counts as content.<h2 id="what-is-deliberately-not-here">What is deliberately not here</h2>Four builds were made and then cut, which is worth saying plainly because you will find some of them elsewhere.<ul><li>Q3_K_S is broken, not merely worse. In a three-shot render a man turned into a dog-like animal mid-sentence while his voice carried on. Two independent reviewers caught it unprompted at the same timestamp. <code>Q3_K_M</code> is 0.9 GB larger and fine.</li><li>The whole FP8 family is dominated by int8, on both axes. Accuracy across 24 identical real layers: <code>int8_tensorwise</code> 0.00942 relative error, <code>mxfp8</code> 0.02656, <code>float8_e4m3fn</code> 0.02682, <code>float8_e5m2</code> 0.05289 - all at the same 21.5 GB except mxfp8, which is 0.6 GB bigger. Speed on an RTX 5090 at 4096 tokens: int8 0.264 ms, <code>float8_e4m3fn</code> 0.415 ms, so it is 1.58x slower as well as three times less accurate. And <code>float8_e5m2</code> does not run at all - PyTorch refuses to multiply two e5m2 matrices. There is no card and no workload for which those three are the better choice, so they are not in the listing.</li><li>No IQ ladder. Not an omission - <code>llama-quantize</code> refuses IQ types for this class of file outright.</li><li>The VAEs are not quantised and should not be. 1.5 GB and 0.4 GB - the saving disappears into a 16 GB budget and decode is exactly where artefacts show.</li></ul><h2 id="smaller-than-the-other-ltx-2.5-ggufs">Smaller than the other LTX-2.5 GGUFs</h2>Against the closest comparable set on Hugging Face these come out a flat 0.9 GB smaller at every level, and against the other published ladder the gap is wider still below Q5 - between 2.3 and 4.2 GB. No quality argument is involved in the first case: the roughly 2600 tensors that are never quantised - norms, biases, the scale-shift tables, the two input projections - are written F16 here and F32 there. Same weights, half the bytes.<h2 id="how-these-were-made">How these were made</h2>The tooling is public at <a target="_blank" rel="ugc" href="https://github.com/jlucasmcrell/ltx25-quant-lab">github.com/jlucasmcrell/ltx25-quant-lab</a>, because two things about converting this model are not obvious and each costs an afternoon.GGUF quietly loses the config. ComfyUI does not infer LTX-2.5's transformer config from tensor shapes - it reads it from the safetensors metadata block, which GGUF does not have. A straight conversion produces a file that loads, samples, and then decodes audio through a connector sized 3840 instead of this checkpoint's 2048. Nothing errors. You get video with wrong sound. The fix is to carry the metadata across as GGUF key-values, which survive <code>llama-quantize</code> untouched.K-quants are legal here. 4041 of 4349 tensors have a last dimension divisible by 256. Of the rest, all but two are bias vectors that stay F16 anyway - the two real exceptions are the input projections, whose 128-wide axis falls back to F16, which is what you want for those layers regardless.The comfy-native builds mirror Lightricks. The set of 1440 Linears to quantise is taken from Lightricks' own <code>int8-convrot</code> release rather than guessed. adaLN, the timestep embedders, every norm and bias and the scale-shift tables stay bf16. Those steering layers are about 6% of the file, and rounding them is how a quantised DiT dies.<h2 id="honest-limits">Honest limits</h2><ul><li><code>comfy-w4a4</code> and <code>comfy-nvfp4</code> were built and tested on Blackwell. The kernel paths declare SM 7.5+ and SM 8.0+, but neither has been run here on an Ada or Ampere 16 GB card, which is most of the audience this set is aimed at. If you are on a 4080 or 4070 Ti Super and one falls back to something slow, that is a real possibility and worth reporting. NVFP4 is Blackwell-only by construction. The GGUF ladder has no such question over it.</li><li>The dev (non-distilled) transformer is present at fewer sizes than the distilled one. Distilled is what most people run.</li><li>These are quantisations, not fine-tunes. Anything the base model does badly, these do badly and smaller.</li></ul><h2 id="where-the-pieces-live">Where the pieces live</h2><ul><li>These files on Hugging Face - <a target="_blank" rel="ugc" href="https://huggingface.co/joeygambino/LTX-2.5-Quantized">LTX-2.5-Quantized</a>, the same builds with the full measurement write-up, if you would rather pull them with <code>huggingface-cli</code> than click.</li><li>A workflow that already uses them - Dual Engine: MiniMax-H3 + LTX-2.5, on <a target="_blank" rel="ugc" href="https://huggingface.co/joeygambino/Dual-Engine-H3-LTX25">Hugging Face</a> and <a target="_blank" rel="ugc" href="https://github.com/jlucasmcrell/Dual-Engine-H3-LTX25">GitHub</a>. One graph, one script, one switch: render a scene as a continuous take with H3 or as an edited scene with native cuts using LTX-2.5. Point its two LTX loaders at any build here.</li><li>The GGUF loader the <code>.gguf</code> half needs - <a target="_blank" rel="ugc" href="https://github.com/city96/ComfyUI-GGUF">ComfyUI-GGUF</a> by city96. The <code>comfy-*</code> files need nothing.</li><li>How these were cut, if you want to make your own - <a target="_blank" rel="ugc" href="https://github.com/jlucasmcrell/ltx25-quant-lab">ltx25-quant-lab</a>: the converter that survives the metadata trap, the ComfyUI-native quantiser, the mixed-precision solver and the load-check.</li><li>The originals - <a target="_blank" rel="ugc" href="https://huggingface.co/Lightricks/LTX-2.5">Lightricks/LTX-2.5</a>. Every file here is cut from those bf16 weights, never from another quant.</li></ul><h2 id="license">License</h2>LTX-2.x Community License Agreement, inherited from Lightricks/LTX-2.5. The license text travels inside every <code>.safetensors</code> file's metadata.

LTX-2.5 22B, cut down to fit your card

For 5090 and workstation cards. Two builds, one per loader.<ul><li><code>LTX25-distilled-DiT-Q8_0.gguf</code> - 22.73 GB. Needs ComfyUI-GGUF. Top of the Q-ladder; effectively indistinguishable from the bf16 original.</li><li><code>LTX25-distilled-DiT-comfy-int8.safetensors</code> - 21.50 GB. No custom node - stock <code>Load Diffusion Model</code> on ComfyUI 0.32+. Per-channel scales with the convrot rotation, the same format Lightricks ship themselves, and the widest kernel support of anything in this listing: INT8 tensor cores go back to Turing. If a 4-bit or FP8 build ever falls back to something slow on your card, this is the one that will not.</li></ul>Why there is no FP8 build hereThere was, and it was cut on measurements rather than taste. Across 24 identical real layers, <code>int8_tensorwise</code> reconstructs at 0.00942 relative error against <code>float8_e4m3fn</code> at 0.02682, <code>mxfp8</code> at 0.02656 and <code>float8_e5m2</code> at 0.05289 - all at the same 21.5 GB except mxfp8, which is 0.6 GB larger.Speed was the last argument for keeping FP8, and it does not survive either. Timed on an RTX 5090 at 4096 tokens, milliseconds per forward pass: <code>int8</code> 0.264, 4-bit <code>w4a8</code> 0.287, <code>mxfp8</code> 0.228, <code>float8_e4m3fn</code> 0.415 - that is 1.58x SLOWER than int8 while also being three times less accurate. <code>float8_e5m2</code> does not run at all: PyTorch refuses to multiply two e5m2 matrices.So int8 is the 8-bit build, and there is no card or workload for which the FP8 ones are the better choice.Read this before you take the biggest fileAt this tier you are buying certainty, not visible quality. On identical scene, seed and size, nothing above Q4_K_M separates cleanly by eye. What a 22 GB file costs you is the activation pool, and on a 32 GB card that arithmetic gets tight faster than people expect: 22.73 GB of weights on a 32 GiB card leaves roughly 8 GB for activations, and a long high-resolution render will want more.The failure is not an out-of-memory error. On Windows the driver falls back to shared system memory silently and the render simply crawls - GPU pinned at 100%, wattage low, seconds-per-step up by more than an order of magnitude. Measured here: 329 s/it where the same shape normally runs about 15. If you see that, you have spilled, and the fix is a smaller quant rather than patience.So take <code>Q8_0</code> or <code>comfy-int8</code> for short clips and stills work where you want no doubt about the weights. For long multi-shot renders, <code>Q5_K_M</code> or the <code>mix4x8-17GB</code> build from the 24 GB version will finish while these are still spilling.One more thing that costs 32 GB owners more than anyone: a second idle ComfyUI does not give its VRAM back. An instance sitting with an empty queue held about 11 GB here and starved the one that was actually rendering down to a fifth of its normal wattage. If you keep two, free or stop the idle one first.Also grab<code>gemma4-12b-ltx25-comfy-w4a8.safetensors</code> from the 16 GB version - 10.60 GB. The bf16 encoder is 26.3 GB, so even here you want this or Lightricks' int8 build unless you are happy loading and unloading 26 GB per prompt.

Files with SHA256: 1675ff73cbcb4d965cdc6d05897fe855dc3f7bd6c4813bc842f3efe109b5d7e3