XB-BOX - 🧊 INT8 单LoRA (ROCm)

Here's the quiet problem nobody warns you about with quantized models: most LoRA loaders assume fp16 weights and, when you patch a LoRA onto an INT8 model with a stock loader, the patch path can fight the quantization - either the LoRA silently does nothing useful, or the quantized custom ops and the patched weights don't play nice. XB_INT8LoraROCm is the pack's single-LoRA loader built for exactly that situation: it applies one LoRA to a model that's already running through the INT8 ROCm machinery, carrying the INT8 metadata along so the custom ops stay in charge.

It's the lightweight half of the pack's INT8 LoRA pair - this one takes one LoRA and one strength; if you stack several, the GroupedLora variant is the one you want. Use it anywhere an INT8 model flows into a sampler and needs a LoRA on top: style LoRAs on an INT8 UNet, character LoRAs, the works.

How it works

You give it a model (a MODEL from the pack's INT8 UNet loader - or any model, but it's for the INT8 ones) plus lora (dropdown of your models/loras folder, with a None option) and strength (default 1.0, range −10 to +10 - negative strengths are allowed, which is unusual and handy for anti-LoRAs).

The node clones the model patcher, copies over the INT8 source metadata so the quantized path knows what it's dealing with, and applies the LoRA through ComfyUI's standard comfy.lora.load_lora + add_patches machinery. That last bit is important: it uses the official LoRA loading path, not a custom one, which is exactly why it behaves - a LoRA that works on the fp16 version of your model applies the same way here. The trick is that it does it in a way that leaves the INT8 custom operations as the execution layer, so you get the LoRA and the memory savings.

Output: a single MODEL wire, ready for your sampler. If lora is None or strength is 0, it passes the model straight through untouched - which is the right behavior for a loader in a template you toggle on and off.

Install and gotchas

Standard XB_ToolBox install, ROCm + Triton environment as with the rest of the INT8 family. It has no dependencies of its own beyond ComfyUI's LoRA loading.

The honest gotcha: the LoRA is applied in the model's current dtype context. A LoRA trained at fp16 precision, applied to an INT8-quantized base, is doing its math at the compute dtype you chose in the loader - if quality with a strong LoRA dips, it's the quantization interacting with the patch, not the node being broken. Keep LoRA strength modest (0.6–0.9 is often the sweet spot on INT8 bases) and the results track the fp16 version closely.