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

Start here. Everything in this version runs on a 16 GB card, and the smallest file runs on 12 GB.Two loaders in this list. Anything with <code>-comfy-</code> in the name loads with the stock <code>Load Diffusion Model</code> node on ComfyUI 0.32+ and needs no custom node. Anything ending <code>.gguf</code> needs ComfyUI-GGUF and its <code>Unet Loader (GGUF)</code>.The transformer - pick one<ul><li><code>LTX25-distilled-DiT-Q3_K_M.gguf</code> - 10.60 GB. The recommended file. Best balance of size and quality on a 16 GB card.</li><li><code>LTX25-distilled-DiT-comfy-w4a4.safetensors</code> - 11.24 GB. Smallest no-custom-node option.</li><li><code>LTX25-distilled-DiT-comfy-nvfp4.safetensors</code> - 12.50 GB. Best-looking of the 4-bit builds, but Blackwell only (50-series) - NVFP4 has no fallback path.</li><li><code>LTX25-distilled-DiT-comfy-w4a8.safetensors</code> - 12.52 GB. No custom node, and its kernel declares SM 8.0+, so this is the one to try first on a 30- or 40-series card.</li><li><code>LTX25-distilled-DiT-Q4_K_S.gguf</code> - 12.93 GB. The most fidelity that still leaves an activation pool at 16 GB. Shorter clips.</li><li><code>LTX25-distilled-DiT-comfy-mix4x8-13.8GB.safetensors</code> - 13.81 GB. Two formats in one file: 386 of its 1440 layers at 8-bit, the rest at 4-bit, chosen by measuring which ones actually lose the most rather than by rule. Costs a seventh of the way to full int8 and recovers 39.5% of the difference. No custom node. The best quality per byte here if you have the headroom.</li><li><code>LTX25-distilled-DiT-Q2_K.gguf</code> - 7.91 GB. For 12 GB cards. Visibly degraded: haze over the frame, flat contrast, smeared highlights. It is here because 12 GB has nothing else.</li></ul>The text encoder - you want this too<code>gemma4-12b-ltx25-comfy-w4a8.safetensors</code> - 10.60 GB, no custom node. At bf16 this encoder is 26.3 GB and at Lightricks' int8 it is 15.4 GB, either of which owns a 16 GB card outright for the one step that just builds an embedding. ComfyUI frees it before sampling so it does not have to be resident alongside the transformer - but it does have to load.Settings that matter on a small card<ul><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. Rendering pass one at full resolution is the most common way to get mush out of this model, and it costs VRAM you do not have.</li><li>Tiled VAE decode: <code>tile_size</code> 512, <code>temporal_size</code> 32.</li><li>Distilled schedule: 9 steps then 4, <code>video_cfg</code> and <code>audio_cfg</code> at 1.0.</li><li>Keep the VAEs at stock bf16. They are 1.5 GB and 0.4 GB together and quantising them buys nothing you will notice except artefacts.</li><li>If a render crawls with the GPU pinned at 100% but drawing low wattage, you have spilled into system RAM rather than run out - Windows falls back silently instead of erroring. Drop frames or resolution, or step down one level.</li></ul>Sizes above are decimal GB, the same convention the file list uses. A "16 GB" card is 16 GiB, which is 17.18 GB in these units - that gap is real and it is where your activation pool lives.

Files with SHA256: 0ead463c1c3bbcd184021788b683a9e1368e705ac5188fa61e2afd13c383943d