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 3090, 4090 and 3090 Ti class cards.GGUF - needs ComfyUI-GGUF and the <code>Unet Loader (GGUF)</code> node<ul><li><code>LTX25-distilled-DiT-Q4_K_M.gguf</code> - 14.17 GB. Fits 16 GB at short frame counts, comfortable at 24.</li><li><code>LTX25-distilled-DiT-Q5_K_M.gguf</code> - 15.90 GB. The default pick at this tier.</li><li><code>LTX25-distilled-DiT-Q6_K.gguf</code> - 17.75 GB. As close to the bf16 original as the GGUF ladder gets before Q8.</li></ul>No custom node - stock ComfyUI 0.32+<ul><li><code>LTX25-distilled-DiT-comfy-mix4x8-17GB.safetensors</code> - 17.01 GB. Mixed precision: 831 of its 1440 layers at 8-bit, the rest at 4-bit, picked by measured reconstruction error rather than by rule. It spends half the bytes between all-4-bit and all-8-bit and recovers 82% of the quality difference, which makes it the closest thing here to full int8 at Q6_K's size - with nothing extra in your graph.</li></ul>What you are actually buying at this tierBe honest with yourself about this. Compared at 1:1 on identical scene, seed and size, Q4_K_S and Q6_K are difficult to tell apart - hair holds strand detail, faces keep structure and fine background mesh survives at every level from Q3_K_M up. The real purchase at 24 GB is not visible fidelity, it is headroom: more frames per render, higher first-pass resolution, and room to keep an upscaler resident.If you want the most clip out of one render, take <code>Q4_K_M</code> and spend the difference on frames. If you are rendering short, take <code>Q6_K</code> or the mix.Also grab<code>gemma4-12b-ltx25-comfy-w4a8.safetensors</code> from the 16 GB version - 10.60 GB, no custom node. Even at 24 GB the bf16 encoder at 26.3 GB does not fit, so you need a quantised one or Lightricks' int8 build.Settings<ul><li>First pass still belongs at 0.2 to 0.5 megapixels - <code>960x544</code> - then upscale. That is a property of the sigma schedule, not of your VRAM, and having 24 GB does not make a full-resolution first pass a good idea.</li><li>Distilled schedule: 9 steps then 4, <code>video_cfg</code> and <code>audio_cfg</code> at 1.0.</li><li>Stock bf16 VAEs, tiled decode at <code>tile_size</code> 512, <code>temporal_size</code> 32.</li></ul>

Files with SHA256: bb6609a4478917ec759511d221356b787188df5db65d61d94b753183e249c8d6