INT8 Pre-Lora Loader
Bake your LoRA into the quantize step, where it belongs
- PRE_LORA
Here's the mental model for INT8 Pre-Lora Loader: quantize a model with a LoRA already in it, instead of quantize first and hope the LoRA survives. It's the "right way" answer to the question everyone hits once they run an INT8 model with adapters - and it's the node that makes that workflow a one-plug affair.
INT8 quantization is lossy, and a LoRA is a small delta on top of the weights. Do the math naively - quantize, then patch - and you're asking a low-bit representation to carry the subtle part of the signal. Pre-Lora flips the order: it merges the LoRA into a full-precision BF16 checkpoint first, then lets the loader quantize the merged result. The pack's own metrics back the intuition: pre-LoRA lands within the margin of error of the best dynamic approach and measurably beats applying the LoRA after quantization (its Qwen Image table puts pre-LoRA ahead of GGUF Q8 and well clear of FP8 with a LoRA).
What it actually does
The node is deceptively small. You pick a LoRA from the dropdown (lora_name_1), set lora_strength_1 (default 1.0), and out comes a single PRE_LORA output. That output isn't a model - it's a little bundle of instructions that plugs into the optional pre_lora input on the pack's INT8 loader (Load Diffusion Model INT8 (W8A8)). The loader then bakes the LoRA into the model before on-the-fly quantization kicks in.
Two conditions matter, and missing either silently does nothing:
- You need an unquantized base model. Pre-Lora has nothing to merge into if you point it at an already-INT8 checkpoint.
- On-the-fly quantization must be enabled on the loader - that's the
on_the_fly_quantizationtoggle. No quantization step, no bake.
If your workflow is "load a pre-converted INT8 file, done," this node isn't for you. If you're doing on-the-fly quantization anyway, it's free quality.
Installing it
Same pack, same install as every node in ComfyUI-INT8-Fast. Easiest is ComfyUI Manager → search "ComfyUI-INT8-Fast" → install, then restart. Manual path:
cd ComfyUI/custom_nodes
git clone https://github.com/BobJohnson24/ComfyUI-INT8-Fast
It wants a current ComfyUI and Triton for the fast inference path (on 20-series cards use triton-windows on Windows or triton==3.2.0, since SM75 support was dropped in 3.3.0). One heads-up from the README: on-the-fly quantization holds an extra INT8 copy in RAM on top of the source model, so on a tight box rely on swap or pre-converted models - and note that the RAM usage for LoRA loading itself was fixed to be on par with base ComfyUI.
Troubleshooting
The most common failure is silent: the PRE_LORA connection does nothing because you're on a pre-quantized model or the on-the-fly toggle is off. Check those two first - there's no error message for it. If a baked LoRA still comes out wrong, the pack's own advice is to try the loader's lora_mode set to Stochastic - some LoRAs quantize badly with plain rounding, and Stochastic is the documented workaround. Older pain points (a Windows crash in this node, OOMs when baking LoRAs onto models with .bias layers like WAN/LTX2) are fixed as of the mid-2026 releases, so keep the pack updated rather than debugging a ghost.
One honest note: now that INT8 is native in ComfyUI, the author has floated slimming this pack down to an exclusively pre-LoRA-focused node. If that happens, this is the part that's most likely to survive in some form - because "quantize the thing you actually want" is a better idea than "quantize, then fight it."
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| lora_name_1 | COMBO | 1 options: None | |
| lora_strength_1 | FLOAT | 1.00-10–10 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| PRE_LORA | PRE_LORA | — |