- Format follows runtime, not preference. The official Python pipelines load safetensors and cut memory with quantization flags; GGUF only exists for LTX as community repackings, loaded in ComfyUI through a third-party node pack.
- A GGUF is not a compressed safetensors. It is a different file whose weights were already rounded down, and the level is in the filename.
- Before dropping precision, try block streaming. It pushes transformer blocks through the GPU a few at a time so the full model runs on a card that cannot hold it, and it keeps bf16 numerics.
You open the LTX-2.5 repository on Hugging Face and find one file per component: two transformers, two video VAEs, an audio VAE, a text encoder, two upscalers, a LoRA, a duration head. All .safetensors. Meanwhile a ComfyUI tutorial says download a GGUF. Both are correct, because they describe two different runtimes.
The answer up front: on the official LTX Python pipelines the file you want is always safetensors, because those pipelines load safetensors and reduce memory with quantization flags rather than a different container. On ComfyUI, with a card that cannot hold a bf16 checkpoint, GGUF becomes available through a third-party node pack and you trade precision for VRAM. Format choice follows runtime choice.
GGUF vs safetensors at a glance
What is a safetensors file?
Safetensors is a tensor storage format: a small JSON header naming every tensor's dtype and shape, followed by raw bytes. It contains no executable code path and memory-maps cleanly, which is why it became the default for model distribution, per the Hugging Face safetensors documentation.
What LTX-2.5 actually ships
LTX-2.5 publishes one safetensors file per component. The documented set includes ltx-2.5-22b-dev-transformer-bf16.safetensors for the full model used by the guided two-stage pipelines, ltx-2.5-22b-distilled-transformer-bf16.safetensors for the few-step distilled path, gemma4-12b-with-proj-ltx-2.5-bf16.safetensors for the LTX-specific Gemma 4 text encoder, both VAEs, and spatial and temporal latent upscalers. The quick-start subset is roughly 66 GiB.
Split files are a feature. You download only what your pipeline needs and can trade memory on one component without touching another. The video VAE is the clearest case: ltx-2.5-video-vae-bf16.safetensors is the diffusion decoder, documented as improved quality at the cost of longer decode time and more VRAM, while ltx-2.5-video-vae-conv-bf16.safetensors is the convolutional decoder, lighter and needing no extra dependencies. Swapping decoders is a VRAM lever costing nothing in transformer precision.
What is GGUF, exactly?
GGUF is a single-file container packing tensors and metadata together, originating in the llama.cpp project, with quantization baked in rather than applied at load time. A GGUF is not a compressed safetensors. It is a different file whose weights have already been rounded to lower precision, and the level is part of the filename.
Quantization levels, plainly
Quantization levels are labelled Q8, Q6, Q5, Q4 and lower, where the number is bits per weight. A Q4 file is roughly half the size of a Q8 one and carries correspondingly less precision. Every step down buys VRAM and spends fidelity, and for video that cost may show up first in motion coherence and fine texture rather than composition.
GGUF and video models
GGUF builds of LTX models exist, and none come from Lightricks. Community publishers maintain quantized repackings on Hugging Face, including unsloth/LTX-2-GGUF and realrebelai/LTX-2.5_GGUFs. They load through city96's ComfyUI-GGUF node pack, which extends ComfyUI to read GGUF UNet models: install it under ComfyUI/custom_nodes, drop the file into ComfyUI/models/unet, restart, and a GGUF loader node appears. Compatibility with a given LTX-2.5 component and ComfyUI version is the repacker's to guarantee.
Where does FP8 fit in?
FP8 is the officially supported precision reduction for LTX-2.5, and it is not a GGUF quant. FP8 is applied by the loader to a safetensors checkpoint rather than baked into a separate file, and the documentation gives a pairing rule that is easy to get wrong.
• --quantization fp8-cast should be used with bf16 checkpoints. It downcasts them on the fly, so it works with the files Lightricks publishes.
• --quantization fp8-scaled-mm should be used with fp8 checkpoints, performing FP8 scaled matrix multiplication on Hopper and newer GPUs with native FP8 support.
Pointing scaled-mm at a bf16 file, or cast at an fp8 file, is the most common configuration error here. Beyond FP8, ltx-core documents blockwise FP8, FP6 and NVFP4 Linear policies for reduced memory and faster matrix multiplication; the quantization formats guide covers the differences.
Two scoping notes. These flags belong to the local Python pipelines, not the hosted LTX API, which exposes model tiers instead of precision flags. And the trainer has its own quantization setting accepting int8-quanto, int4-quanto, int2-quanto, fp8-quanto or fp8uz-quanto, for fine-tuning rather than inference. Do not carry a value from one surface to the other.
VRAM is the real constraint
VRAM decides what you can run at all. The LTX open-source repository brief states that the codebase targets NVIDIA GPUs with 80GB or more of VRAM, with distilled variants supported on 32GB using quantization. Confirm the other prerequisites too: pure PyTorch, CUDA 13+ recommended, and the LTX-specific Gemma 4 text encoder rather than Google's stock release. If none of that is available, the hosted LTX API at docs.ltx.video needs none of it.
A third option exists that most format comparisons skip. The ltx-core package includes block streaming, which pushes transformer blocks through a small rolling set of GPU buffers, loading each block's weights just before it runs and recycling them afterwards, so the full model runs on machines that cannot hold all its weights at once. RAM streaming pre-loads blocks into pinned CPU buffers and is faster; disk streaming reads from the safetensors file on demand and uses less CPU memory. Both keep bf16 numerics, so if the model simply does not fit and fidelity matters, streaming beats dropping to Q4.
What quantization costs you
Quantization costs precision in exchange for headroom, and on LTX-2.5 there is a second cost worth knowing. Checkpoint metadata here is load-bearing. VideoDecoderConfigurator.from_config picks between the convolutional and diffusion video decoders from the checkpoint's own vae._class_name, and text encoder loading checks the encoder version against the one the checkpoint was trained with, gemma4-12b-ltx-v1, raising a Gemma version error on mismatch. The trainer likewise detects version-specific components from checkpoint metadata.
The implication is direct: any conversion that rewrites or drops that metadata changes which component the loader builds. That is not an argument against GGUF, which lives in a different loader entirely, but against assuming a converted file behaves like the original in the official pipelines.
Loading each one in practice
Loading differs by runtime, and the difference is total. The official pipelines name safetensors paths directly on the command line:
uv run python -m ltx_pipelines.distilled --transformer-path models/ltx-2.5/diffusion_models/ltx-2.5-22b-distilled-transformer-bf16.safetensors --text-encoder-path models/ltx-2.5/text_encoders/gemma4-12b-with-proj-ltx-2.5-bf16.safetensors --video-vae-path models/ltx-2.5/vae/ltx-2.5-video-vae-bf16.safetensors --audio-vae-path models/ltx-2.5/vae/ltx-2.5-audio-vae-bf16.safetensors --num-frames 121 --output-path output.mp4
Add --quantization fp8-cast --offload cpu when memory is tight. There is no GGUF equivalent of that flag, the cleanest evidence that GGUF is not part of this path. LoRA adapters follow the same pattern: the ltx-core loader fuses .safetensors adapters through a builder that loads them onto the CPU by default and moves them to the GPU sequentially during fusion, keeping peak GPU memory low. Using LoRA adapters with LTX-2.5 covers it.
In ComfyUI, the official route is the ComfyUI-LTXVideo integration, which loads the published safetensors components. The GGUF route uses the separate node pack and its own loader. Different nodes, different files, and mixing them is where most workflow errors start. The ComfyUI workflow guide covers the official setup.
Which file should you download?
1. 80GB or more, official pipelines. Published bf16 safetensors, dev transformer for guided two-stage work, distilled for speed. No quantization needed.
2. 32GB to 80GB, official pipelines. Distilled bf16 safetensors plus --quantization fp8-cast. Consider the convolutional video VAE to save more without touching transformer precision.
3. Under 32GB, official pipelines. Try block streaming with CPU or disk offload before reducing precision further. Slower, but it keeps bf16 numerics.
4. ComfyUI on a constrained card. A community GGUF is reasonable. Start at Q8 and step down only if it still does not fit.
Summary
Safetensors is the format Lightricks publishes for LTX-2.5: one bf16 file per component, roughly 66 GiB for the quick-start set, loaded directly by the ltx-pipelines CLI. GGUF is a single-file quantized container from the llama.cpp lineage, available for LTX models only as community repackings and loadable in ComfyUI through the third-party ComfyUI-GGUF node pack. The official CLI has no GGUF option; it reduces memory with --quantization fp8-cast for bf16 checkpoints and --quantization fp8-scaled-mm for fp8 checkpoints on Hopper and newer GPUs. Block streaming runs the full model on machines that cannot hold all its weights at once while keeping bf16 numerics. LTX-2.5 targets NVIDIA GPUs with 80GB or more of VRAM, with CUDA 13+ recommended and distilled variants supported on 32GB using quantization.
Ready to pull the weights? Start at the LTX-2.5 model page, then read how to install and run the model.
