INT8 Grouped LoRA

The best thing you can say about INT8 Grouped LoRA is that it's boring - and that's a compliment. It does one job, does it on one node, and keeps the LoRA question out of your way while you enjoy the 1.5–2x INT8 speedup this pack's loader gives you on Flux2, Krea2, Chroma, Z-Image and friends. Where people get burned with INT8 setups isn't the quantization itself; it's that slapping a LoRA on after the fact can quietly double your generation time. This node is the stacking-side fix.

It comes from BobJohnson24's ComfyUI-INT8-Fast pack, the custom-node effort that made INT8-ConvRot practical on 20/30/40/50-series cards before ComfyUI's native INT8 landed. The honest framing: core ComfyUI's normal LoraLoader now works on INT8 models too, so this node's real value is convenience and one specific safety fix. Chain ten LoraLoader nodes and you can do the same math - this just does it in one box.

How it works

Under the hood it's a thin wrapper around the same machinery core ComfyUI uses: it clones the model patcher, loads each LoRA's weights, and calls add_patches. The INT8-aware part is that the actual patch application is intercepted by the pack's Int8TensorwiseOps - so the loader's lora_mode setting (None / Stochastic / Dynamic) decides how your LoRAs get merged into the quantized weights. None bakes with plain rounding, Stochastic uses stochastic INT8 rounding (occasionally closer to the BF16 baseline), Dynamic applies at inference time and is slower but works with stubborn LoRAs.

The boring-but-important detail: the node deliberately carries over the safetensors metadata the INT8 loader stashes on the model. Skip that and a downstream save can produce a checkpoint that won't load again. It's the kind of fix you never notice until it isn't there.

The inputs that matter

• model (required) - your MODEL output, straight from the INT8 loader. Wire this in first; nothing else is mandatory.
• lora_1 … lora_10 - a dropdown each, listing every LoRA in your loras folder. Leave unused slots on "None".
• strength_1 … strength_10 - matching strength per slot, default 1.0, range −10 to 10. Negative strengths work if that's your thing.

The single MODEL output feeds straight into your sampler, or into the pack's INT8ModelSave if you're baking a merged checkpoint. If you're stacking styles, the usual advice holds: add one at a time on a fixed seed, and put your bigger "character" LoRAs first - interactions are unpredictable, and INT8 doesn't change that rule.

Installing it

This is the pack's shared install. Via ComfyUI Manager, search "ComfyUI-INT8-Fast" and hit install. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/BobJohnson24/ComfyUI-INT8-Fast

Then restart ComfyUI. Real dependency to know about: it needs Triton for the fast path, plus a current ComfyUI (the README calls for "ComfyKitchen" latest, possibly with PyTorch built for cu130). On 20-series cards you'll want triton-windows on Windows or triton==3.2.0 - SM75 support was dropped in 3.3.0. And fair warning: the author says INT8 is now native in ComfyUI and his older pre-quantized checkpoints may not load due to a naming mismatch - convert_to_comfy.py in the repo converts them.

Troubleshooting

The classic gotcha is a LoRA that "doesn't work" on INT8 - washed out or melting output. That's almost never this node; it's the lora_mode on the loader. Try Dynamic if a LoRA refuses to behave, or Stochastic on the ones that need it (the pack's Metrics.md documents a few that just don't bake with normal rounding). The opposite failure - LoRA works but your generation time balloons - is the post-hoc application trap: if you're using core ComfyUI's loader rather than this pack's, adding a LoRA can cost you the whole INT8 win. One 3060 Ti owner measured INT8 with a LoRA dropping back to FP8-level speed; the fix the community landed on was this pack's loader in Dynamic mode. Keep the quantized model and the LoRA both inside the pack's nodes and the speedup holds.