The bf16 checkpoints are 46.1 GB. Your GPU is not. Quantization is how those two facts get reconciled — and LTX 2.3 has an official, documented quantization path that most tutorials skip in favor of community GGUF builds.
There are two FP8 policies in the official code, they are not interchangeable, and picking the wrong one on the wrong GPU either fails or leaves performance on the table. There is also an environment variable the docs insist on that half the guides omit, and it matters.
This article covers the official path first, then honestly places INT8, NVFP4, and GGUF — three terms people search for that mean very different things. Sourced from the LTX-2 optimization docs, ltx-core documentation, and the ComfyUI LTX-2.3 tutorial, checked July 2026.
Two FP8 policies, and how to choose
| Policy | CLI flag | How it works | Use when |
|---|---|---|---|
| FP8 Cast | --quantization fp8-cast | Downcasts transformer linear weights to FP8 during loading, upcasts on the fly during inference. No extra dependencies. | You have a bf16 checkpoint. Works on any FP8-capable GPU. |
| FP8 Scaled MM | --quantization fp8-scaled-mm | Uses PyTorch's torch._scaled_mm for FP8 matrix multiplication. Weights stored in FP8 with per-tensor scaling; inputs quantized dynamically. | You have an FP8 checkpoint and a GPU with native FP8 support — best on Hopper and newer. |
The pairing rule is the part people get wrong, and the official README states it directly: fp8-cast should be used with bf16 checkpoints (it downcasts them on the fly), while fp8-scaled-mm should be used with fp8 checkpoints.
So the decision is not "which is better." It is:
- Downloaded the 46.1 GB bf16 files and running on a consumer GPU → fp8-cast
- Have FP8 weights and a Hopper-class or newer card → fp8-scaled-mm
The flag everyone forgets
The optimization docs pair quantization with an allocator setting, and they include it in every example:
PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True python -m ltx_pipelines.ti2vid_two_stages \
--quantization fp8-cast --checkpoint-path=...expandable_segments:True changes how PyTorch's CUDA allocator handles memory segments, which matters a great deal when you are close to the ceiling — fragmentation is what turns "should fit" into an out-of-memory error. If you are quantizing because you are tight on VRAM, you are exactly the person who needs it.
The same requirement applies when you build pipelines in Python rather than the CLI. The docs are explicit: you still need the environment variable at launch.
from ltx_core.quantization.fp8_cast import build_policy as build_fp8_cast_policy
pipeline = TI2VidTwoStagesPipeline(
checkpoint_path=ltx_model_path,
distilled_lora=distilled_lora,
spatial_upsampler_path=upsampler_path,
gemma_root=gemma_root_path,
loras=[],
quantization=build_fp8_cast_policy(ltx_model_path),
)Quantization is not your only lever
FP8 shrinks the weights. It does not move them off the GPU. Those are different problems with different flags, and combining them is how small cards participate at all:
--offload {none,cpu,disk}— moves transformer weights out of VRAM.cpukeeps them in system RAM;diskstreams them when RAM is also short, and the docs note it is slower. Default isnone.--max-batch-size— defaults to 1; raising it reduces layer-streaming transfers at the cost of peak memory. On a tight card, leave it.- Skip inter-stage memory cleanup — pipelines clean GPU memory between stages by default; skipping it is a speed win only if you have headroom.
--compile mode=reduce-overhead— captures CUDA graphs, described as the main latency lever for the denoising loop, but it reserves static memory pools. It trades VRAM for speed, so it is the opposite of what a memory-constrained setup wants.
The order that works when you are hitting OOM: FP8 first, then offload cpu, then reduce resolution, then reduce frame count. Compilation comes last and only if you have room.
Not in the mood to tune allocator flags? Quantization work is worth it when you generate daily. If you just need a result, ltx23.app runs LTX 2.3 in the browser with none of this.
The ComfyUI shortcut
If you use ComfyUI, most of this is already handled: the official templates are built around pre-quantized FP8 checkpoints:
ltx-2.3-22b-dev-fp8.safetensors— T2V, I2V, IA2V, ID-LoRA workflowsltx-2.3-22b-distilled-fp8.safetensors— FLF2V, IC-LoRA workflows
Plus an FP4-mixed text encoder build, gemma_3_12B_it_fp4_mixed.safetensors, in models/text_encoders/.
You are downloading FP8 weights rather than casting bf16 at load time, which means less disk, less RAM pressure during loading, and no flags to remember. ComfyUI's documentation also notes that no custom nodes are required for BF16 and FP8 — that is the native path.
For most people on consumer hardware, this is simply the better route. The CLI quantization flags matter when you are scripting, batching, or using pipelines the templates do not expose.
Now the honest part: INT8, NVFP4, and GGUF
Three heavily-searched terms, three different origins. Conflating them causes a lot of wasted evenings.
INT8 — official for training, community for inference.
INT8 appears in Lightricks' own documentation in a specific place: the ltx-trainer low-VRAM config for 32 GB GPUs uses INT8 quantization. That is a training path, not an inference policy — the inference CLI exposes FP8 policies only. Community repositories do publish INT8 inference builds; for example, Kijai/LTX2.3_comfy hosts an int8 transformer-only checkpoint for ComfyUI. Useful, but community-maintained.
NVFP4 — a hardware format, not an LTX feature.
NVFP4 is NVIDIA's 4-bit floating-point format associated with Blackwell-class hardware. People search ltx 2.3 nvfp4 and ltx 2.3 fp4 in real volume, but the official LTX-2 documentation does not describe an NVFP4 quantization policy — its published backends are FP8 cast and FP8 scaled MM. If you find NVFP4 LTX 2.3 weights, they are community conversions or tooling-specific builds. Treat any performance claim about them as unverified.
GGUF — entirely community. GGUF quantizations of LTX 2.3 are popular for low-VRAM ComfyUI setups and are not part of the official repository. They need their own loader nodes and lag official point releases. Genuinely useful, genuinely unofficial.
The rule that keeps you out of trouble: official = FP8 (inference) and INT8 (training low-VRAM config). Everything else is community, and community builds may not track the latest distilled 1.1 or upscaler x2-1.1 releases.
What quantization does not fix
Worth stating, because expectations here get inflated:
- It does not remove the Gemma 3 12B text encoder dependency. ComfyUI's FP4-mixed encoder build helps; the requirement remains.
- It does not change the ÷32 resolution or 8k+1 frame rules.
- It does not make a two-stage pipeline skip the spatial upscaler or distilled LoRA.
- It does not convert a memory problem into a speed win — offloading to disk is explicitly slower.
Quantization buys you entry. Resolution and frame count still decide whether the run is pleasant.
FAQ
What is the official LTX 2.3 quantization?
FP8, in two policies: fp8-cast for bf16 checkpoints on any FP8-capable GPU, and fp8-scaled-mm for FP8 checkpoints on Hopper and newer.
Do I need the allocator environment variable?
The docs include PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True in every quantization example, CLI and Python alike.
Is there an official NVFP4 build? Not in the documented backends. The published policies are FP8 cast and FP8 scaled MM.
FP8 or GGUF for low VRAM? FP8 is the supported path and what ComfyUI's native templates use. GGUF is community work — viable, but unofficial and slower to track releases.
Does quantization hurt quality? Any quantization is a trade. The docs present FP8 as the memory-reduction path without publishing a quality delta, so evaluate on your own prompts rather than trusting a claimed percentage.
Can I combine FP8 and offload?
Yes, and that combination is the practical answer for constrained cards. Note the HDR pipeline's --offload documentation warns offloading disables FP8 quantization when set to anything but none — check per-pipeline behavior.
Bottom line
LTX 2.3's official memory story is FP8 with two policies, matched to your checkpoint format and GPU generation, plus an allocator flag and an offload switch. ComfyUI users get it pre-packaged as FP8 builds and should just use those.
INT8, NVFP4, and GGUF all have real uses, but only one of them appears in Lightricks' own inference documentation — and knowing which is the difference between a setup that works and an evening on Discord.
Or skip the whole layer: ltx23.app runs LTX 2.3 without any of it.
Sources
Verified July 2026 against primary documentation:
- LTX-2 optimization documentation — FP8 cast vs scaled MM, allocator flag, compilation, memory cleanup
- ltx-core package documentation — quantization backends and
build_policyusage - Lightricks/LTX-2 — official GitHub repository — checkpoint/policy pairing guidance
- LTX-2 installation & CLI flags —
--quantization,--offload,--max-batch-size - LTX-2 available pipelines documentation — per-pipeline offload/quantization interactions
- ltx-trainer documentation — INT8 low-VRAM training config for 32 GB GPUs
- ComfyUI official LTX-2.3 tutorial — FP8 checkpoint builds and FP4-mixed text encoder
- Lightricks/LTX-2.3 — Hugging Face model card — bf16 checkpoint sizes and constraints
- Lightricks/ComfyUI-LTXVideo — official ComfyUI integration
- google/gemma-3-12b-it-qat-q4_0-unquantized — text encoder dependency
- LTX-2 technical paper (arXiv 2601.03233)
Community quantization repositories are referenced for orientation only and are not maintained by Lightricks.
