LTX2 Checkpoint Loader (INT8)
The INT8 loader that doubled LTX 2.3's speed — if you're on Ampere
- model
- vae
LTX is already the speed tier of local video - the model you reach for when Wan takes six minutes and you need an answer in seconds. This node makes the speed tier faster. LTXInt8CheckpointLoader loads LTX-2 checkpoints quantized to 8-bit integers instead of the bf16/fp8 you're probably running now, and on the hardware it targets that's worth roughly a 2x speedup. The author runs LTX-2.3 in production on an RTX 3080 Ti and measured 118.77 seconds per clip stock versus 66.45 with INT8. That's the whole pitch, and it's real - with one big caveat, so let's start there.
The caveat comes straight from the author's own benchmark post: INT8 acceleration is specifically an Ampere thing. On a 5090 you can safely ignore this node. On 20-series Turing cards you'll hit Triton compile errors. It's a tool for the 30-series middle class - 3060 Ti up through 3090 - and on that hardware it's the difference between "LTX but cramped" and "LTX that actually fits."
What it actually does
Tensorwise INT8 quantization. Each linear layer's weights are stored as int8 with a scale factor instead of fp16/bf16, and the matmul runs as a W8A8 integer GEMM. The pack ships fused Triton kernels for the hot path, with a torch._int_mm fallback if Triton is missing. Roughly half the memory of bf16, and on cards with good int8 throughput, meaningfully faster.
The mode dropdown is the one input you'll actually set:
int8_tensorwise- load a pre-quantized INT8 checkpoint (default). Grab something like Winnougan'sltx-2.3-22b-distilled-int8tensormixed.safetensorsor the author's ownovpresent/ltx-2.3-distilled-1.1-INT8repo on HuggingFace, drop it inmodels/checkpoints, and pointckpt_nameat it.int8_tensorwise_otf- quantize a normal BF16/FP8 checkpoint on the fly at load time. Slower to start, but you don't have to hunt down special files.
Either way, a shortlist of LTX-2 layers that hate quantization - the adaln_single modulation layers, patchify_proj, proj_out, and the audio conditioning bits - are kept in fp16/bf16 via an exclusion list. The on-the-fly mode also applies ConvRot, a Hadamard-rotation trick that spreads activation outliers around, which is what keeps quality from tanking when you quantize at load.
Outputs are just model and vae. Which brings us to the trap: this node does not load a text encoder. LTX-2's Gemma 3 12B encoder is the most notorious OOM source in the whole model, and you load it yourself with a separate DualCLIPLoader. Feed both into your sampler and you're done.
Installing it
One pack installs both this node and its sibling LTXInt8AdditiveLoRA:
cd ComfyUI/custom_nodes
git clone https://github.com/overpresentme/ComfyUI-ltx-int8-loader
Then restart ComfyUI (or just search "ComfyUI-ltx-int8-loader" in ComfyUI Manager). The README's dependency list is short and non-negotiable: a recent ComfyUI - it assumes the ComfyKitchen distribution on current PyTorch, possibly the cu130 build - plus Triton for the fused kernels. If your ComfyUI is old enough that comfy.ops.manual_cast doesn't exist, the checkpoint still loads, just without any quantization and without an error telling you why.
Where people get burned
- Wrong GPU class. On Ada or Blackwell you pay the quantization quality tax for no speed gain. Ampere only, per the author.
- Turing compile errors. 20-series users have hit
arith.extf"op operand must be floating-point-like, but got i8" errors inside the fused kernel - a Triton/architecture mismatch. - First run is slow. Quantization happens at load time; the ~45–70s numbers only hold from the second generation onward.
- Your stock loader may now do this. ComfyUI merged native INT8 support (PR #14636, June 2026), so pre-quantized INT8 checkpoints load in the default node. The on-the-fly mode and the additive-LoRA pairing are the reasons to keep this pack around.
The workflow
LTXInt8CheckpointLoader with mode int8_tensorwise → sampler at the usual LTX distilled settings (8 steps, CFG 1), with the Gemma encoder from DualCLIPLoader. If you stack LoRAs, run the model output through LTXInt8AdditiveLoRA first so they don't drag the INT8 path through a dequant-requant roundtrip on every pass.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| ckpt_name | COMBO | 0 options: | |
| mode | COMBO | int8_tensorwise | int8_tensorwise: load a pre-quantized INT8 checkpoint. int8_tensorwise_otf: quantize a BF16/FP8 checkpoint on-the-fly. |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| model | MODEL | — |
| vae | VAE | — |