XB-BOX - 🧊 INT8 双CLIP加载器 (ROCm)

Flux and SD3 workflows need two text encoders, and on an 8–12GB AMD card that pair can eat a shocking chunk of VRAM before the UNet even starts. XB_DualCLIPLoaderINT8ROCm is the pack's answer for AMD users: it loads both encoders in INT8, cutting their memory footprint roughly in half versus fp16, and it does it through custom quantized ops tuned for ROCm rather than a generic torch fallback.

The "ROCm" in the name is load-bearing. This whole INT8 family (the loader here, the save node, the LoRA nodes, and the INT8 UNet loader elsewhere in the pack) is adapted from the ComfyUI-INT8-Fast-ROCM project, which exists because AMD cards historically lacked the tensor-core fast path that NVIDIA's fp8/int8 inference rides on. If you're on NVIDIA, the stock loaders do this better with less fuss - this family is for the red team.

How it works

Pick two text encoder files and a type (the dropdown carries the standard CLIP-type set - stable_diffusion, sd3, flux, wan, mochi, ltxv, hidream, cosmos, and more), and the node loads both through ComfyUI's text-encoder path with a custom operations layer (Int8TensorwiseOps) substituted in. That layer is where the magic lives: Triton-written kernels do rowwise INT8 quantization, with a round-to-nearest-even implementation and, when enable_convrot is on, a Hadamard rotation trick that rotates weights and activations before quantization to cut the error that naive INT8 would introduce. This is "quantize-on-the-fly with rotation" - a fancier beast than the plain INT8 you'd get by just rounding weights.

Two switches control the behavior:

• on_the_fly_quantization - off by default, meaning it expects pre-quantized weights (the kind the pack's save node produces). Flip it on and it quantizes fp16 weights on the fly instead.
• enable_convrot - on by default. Keep it on; it's the accuracy saver.

weight_dtype sets the compute dtype (default, fp16, bf16, fp32) the quantized ops run at. default is usually right.

Outputs and gotchas

One output, CLIP, wired straight into your text encoder. And one hard rule built into the node: it refuses scaled-FP8 text encoders. If you point it at a scaled_fp8 file it raises a clear error telling you to use the stock CLIP loader - the INT8 custom ops can't mix with scaled-FP8 in the same encoder, and the node would rather fail loudly than produce garbage.

Install is the standard XB_ToolBox route (Manager → XB_ToolBox, or git clone + restart), with two runtime requirements: a ROCm-enabled PyTorch install and Triton (the pack uses triton kernels and falls back to torch's _int_mm if missing). The accuracy question is the honest one to answer: INT8-with-rotation is close to fp16 quality for text encoders, and the community consensus on quantization holds here - if it fits in fp16, quality is a wash, but when it doesn't fit, this is the node that makes the workflow run at all.