Nodes/ComfyUI-ltx-int8-loader/LTX2 LoRA Loader (INT8 Additive)
ComfyUI Node

LTX2 LoRA Loader (INT8 Additive)

The LoRA node that stops unquantizing your INT8 model every pass

By overpresentme·Created 4 months ago·Updated 4 months ago· 9
LTX2 LoRA Loader (INT8 Additive)
  • model
  • clip
  • model
  • clip
lora_name
strength_model1.00
strength_clip1.00

If you switched LTX to an INT8 checkpoint and then loaded a LoRA the normal way, you've been paying a hidden tax: the standard LoRA path dequantizes the int8 weights, applies the delta, and re-quantizes them - on every single forward pass. LTXInt8AdditiveLoRA exists to stop that. It's the companion to this pack's LTXInt8CheckpointLoader, and the two are built to be used as a pair.

The additive trick

Instead of the dequant-add-requant dance, this node registers the LoRA's lora_down / lora_up tensors directly on each Int8Linear module. The forward pass runs the fast W8A8 INT8 matmul, then adds the low-rank delta on top in float - no re-quantization, so no cumulative precision loss and no extra latency in the hot loop. The author's own description is honest about the scope: this works for simple LoRA types. LoHA, LoKR, DoRA, or anything with a mid layer or a reshape silently falls back to the standard path. That's not a bug - it still works, you just don't get the speedup.

Mechanically it's clean: the node first applies the LoRA through ComfyUI's normal loader, then scans the resulting patches. If a patched weight sits on an Int8Linear module and the patch is a plain LoRAAdapter, it lifts the delta onto the module and removes it from the patch list. If either condition fails, the patch stays in the standard pipeline.

The inputs that matter

  • model - the MODEL output of LTXInt8CheckpointLoader. That node is what creates the Int8Linear modules the additive path depends on; feed this a normal loader's model and there's nothing to optimize, so you're just running a stock LoRA loader with extra steps.
  • lora_name - dropdown of your models/loras folder, same as any LoRA loader.
  • strength_model - default 1.0, range −10 to 10. LTX-2.3's distilled LoRA is a 7GB file, and the community runs two-stage workflows at 0.4 on the first sampler and 0.5 on the second - a good starting pair if you're doing the full LTX-2.3 pipeline.
  • clip / strength_clip - optional; connect them only if your LoRA also patches the text encoder.

Outputs are model and clip, both wired straight into your sampler. Nothing exotic.

Installing it

Same install as the loader - one repo, two nodes. git clone https://github.com/overpresentme/ComfyUI-ltx-int8-loader into custom_nodes (or find it in ComfyUI Manager), restart, and confirm Triton plus a current ComfyUI are present. No extra model downloads; LoRA files go in models/loras like always.

Gotchas

  • Version-sensitive internals. The additive registration pokes at comfy.weight_adapter.LoRAAdapter and model_patcher.patches, which have shifted across ComfyUI releases. If a LoRA loads but seems to have no effect, first suspect your ComfyUI is behind and the patch never got lifted onto the module.
  • Silent fallback. Complex LoRAs don't error - they just take the slow path. If your LoRA is a LoHA or DoRA and you expected a speed win, that's why.
  • It needs the INT8 loader. Standalone, on a bf16 LTX model, this node is just a standard LoRA loader. Use it as the checkpoint loader's partner.
  • Context, not competition. ComfyUI's native INT8 support (June 2026) reads pre-quantized checkpoints in the default loader, but it doesn't give you this additive LoRA path - which is this pack's remaining reason to exist.

If you're on Ampere running distilled LTX-2.3 with a couple of style LoRAs stacked, this is the difference between a snappy pipeline and one that fights itself on every step.

Categoryloaders/ltx

Inputs (5)

NameTypeDefaultDescription
modelMODEL
lora_nameCOMBO0 options:
strength_modelFLOAT1.00-10–10
clipoptCLIP
strength_clipoptFLOAT1.00-10–10

Outputs (2)

NameTypeDescription
modelMODEL
clipCLIP