HSWQ Model Patch Loader (ConvRot INT8 / CPU offload)

Most "model patches" - the Z-Image Fun ControlNet, Qwen Image's block-wise ControlNet, the SigLIP style projector - are loaded by ComfyUI's stock ModelPatchLoader and that's the end of the story. This node exists for the two cases where the stock one doesn't get you there: the patch is quantized to INT8 and you want it to stay INT8, or you want it sitting in system RAM instead of eating VRAM before sampling even starts.

It's one of nine-ish nodes in ussoewwin/ComfyUI-HSWQ-Loader-and-Tools, the loader pack for the author's own HSWQ quantization line. You won't search for it by name - you'll hit it when a workflow ships with it or a ControlNet patch won't load anywhere else.

What it actually does

The stock loader builds the patch's module graph in the dtype it reads off the file. For a fp16 patch that's fine. For a comfy_quant INT8 file the dtype is torch.int8, which you can't build a Linear layer in - so it either errors or the comfy_quant / weight_scale keys get quietly ignored. This node sniffs the checkpoint for an int8_tensorwise comfy_quant entry, and if it finds one it picks a real float compute dtype (BF16 on Ampere and newer, FP16 on Turing/older, automatic) and builds the graph through MixedPrecisionOps. Weights land as QuantizedTensor / TensorWiseINT8Layout and stay 8-bit resident, and the forward pass runs through comfy_kitchen's int8_linear kernel with the online activation rotation that lets ConvRot INT8 hold quality close to fp8 - often better - on cards with no fp8 hardware at all. If the file isn't quantized, nothing clever happens: plain manual_cast, same as the stock node.

Then there's cpu_offload, which builds the ModelPatcher with load, offload and model device all on CPU. And it handles the three architectures: Qwen Image block-wise ControlNet, SigLIP multi-feature projector, and the Alibaba-PAI Z-Image Fun ControlNet - counting control_layers to tell 2.0 from 2.1, with a carve-out for the known Z-Image 2.0 issue where the refiner projection weights are all zeros.

The two inputs, and where the output goes

name is a dropdown of whatever is in ComfyUI/models/model_patches. cpu_offload is a boolean, default True, and the author's tooltip says it plainly: "Load model to CPU (main memory). Does not use VRAM."

The single output is MODEL_PATCH, and it plugs into stock apply nodes - QwenImageDiffsynthControlnet, ZImageFunControlnet, or USOStyleReference depending on which patch architecture you loaded. No bespoke apply node, no rewiring.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/ussoewwin/ComfyUI-HSWQ-Loader-and-Tools

Restart ComfyUI. It's also in the Manager - search for the pack title. The clone pulls a heavy requirements.txt: insightface, onnxruntime, opencv-python, facexlib, timm, diffusers, transformers, peft. None of that is for this node; it's the face detection and detailer side of the pack. The install script bumps pip/setuptools/wheel first for a reason - on Python 3.12 the facexlib → filterpy source build dies with AttributeError: module 'pkgutil' has no attribute 'ImpImporter' on an old setuptools. Slow first install; don't panic at the package list.

Where people get burned

cpu_offload is only wired end-to-end for Z-Image Fun ControlNet. The pack ships a patch that keeps ZImageControlPatch running on CPU so a CPU-resident patch doesn't get handed GPU tensors. The Qwen block-wise and SigLIP projector apply paths are not patched. So on those two, leave cpu_offload off - otherwise you're asking a CPU module to consume CUDA conditioning tensors.

The dropdown is empty and it's not the node's fault. models/model_patches doesn't exist in a fresh install, you drop the file in, and the list still shows nothing because ComfyUI scans folder contents at startup. Create the folder, put the .safetensors in it, restart the UI, then pick it. Created the folder while ComfyUI was running? Restart.

Unsupported file = hard error. If the checkpoint matches none of the three discriminator keys, you get a ValueError saying no known model patch architecture was found. That's the node telling you the file isn't a shape it can build - not a bug.

INT8 patches are an HSWQ-family thing. The upstream quantization scripts live in ussoewwin/Hybrid-Sensitivity-Weighted-Quantization, and the README scopes INT8 and NVFP4 support to models quantized with it. Grab a patch from somewhere else and the loader may build the graph and still give you garbage. Related: if you're stacking HSWQ INT8 or NVFP4 loads elsewhere in the graph, the author's instruction is to put General Purge VRAM V2 from their ComfyUI-DistorchMemoryManager at the end of the workflow with the HSWQ toggle on - generic ComfyUI unload doesn't fully release that residual memory, and your second generation can fail.

One caveat: it's a young, single-maintainer pack at 3.5.0, and this is a port of its author's own ModelPatchLoaderCustom from an earlier Flux LoRA stacker repo. It works, and it's the only game in town for INT8 model patches - just don't expect a decade of scar tissue behind it.