HSWQ Checkpoint Loader (SDXL)

If you grabbed one of ussoewwin's HSWQ-quantized SDXL checkpoints from Hugging Face and dropped it into the stock Load Checkpoint node, nothing useful happens. The stock loader doesn't read the comfy_quant markers in those files, so the whole quantization exercise goes nowhere. This node exists to close exactly that gap: it's the entry point to the HSWQ pack, and for most people it's the only node from the pack they'll ever touch.

What it does

It's a Load Checkpoint replacement with one genuinely new widget: weight_dtype. Under the hood it wraps ComfyUI's own load_checkpoint_guess_config, so a plain SDXL checkpoint loads exactly the way it always did. What the node adds is the routing:

• default - load normally, but auto-detect. If the safetensors has INT8 or NVFP4 comfy_quant markers, the loader picks the matching path even though you left the widget alone. This is the setting you want 90% of the time.
• fp8_e4m3fn / fp8_e4m3fn_fast / fp8_e5m2 - plain FP8 weight loading for checkpoints you want to quantize at load time (or that came pre-quantized).
• int8_tensorwise - the HSWQ ConvRot INT8 path. ComfyUI's MixedPrecisionOps handles the Linear layers, and this extension patches the Conv2d load too, which matters because a vanilla INT8 path only covers Linear and SD UNets are mostly convolutions.
• ConvRot NVFP4 - the Blackwell-focused path: Linear layers go to NVFP4 Tensor Core matmul, Conv2d layers get the INT8 + ConvRot treatment.

That last bit is worth spelling out because the README is blunt about it: the INT8 and ConvRot NVFP4 modes are supported only for models quantized with HSWQ (Hybrid-Sensitivity-Weighted-Quantization). Third-party INT8 or NVFP4 packs are explicitly out of scope. HSWQ is a sensitivity-analysis scheme rather than a keep-a-percentage-of-layers scheme - it picks which layers stay FP16 under a fixed MiB budget, keep ratio pinned at zero - so the files it produces have specific markers the loader trusts. If your quantized file came from someone else, don't expect this node to rescue it.

The inputs and outputs

• ckpt_name - the checkpoint, same list as Load Checkpoint.
• weight_dtype - the six options above.
• device - optional. Lets you pin loading to a specific GPU (cuda:0, cuda:1) or CPU, which is handy on multi-GPU boxes.

Outputs are MODEL and CLIP only. There is deliberately no VAE socket - the author's framing is "use a separate VAE loader if needed," and you should, because you will not get pixels out of this node alone.

Installing it

The pack's real requirements file pulls in a stack of face-detection and diffusers packages (insightface, onnxruntime, peft, accelerate, and friends), so the simplest route is ComfyUI Manager - search the pack title and let it handle the deps. Manually:

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

Then restart ComfyUI. The pack ships no model weights - you download the HSWQ-quantized checkpoints yourself from the author's Hugging Face repos and drop them in models/checkpoints.

Where people get burned

Two things bite. First, there's no Triton toggle on this node - INT8 Linear speed is left to ComfyUI plus comfy_kitchen's int8_linear path, so don't go hunting for an acceleration widget that isn't there. Second, and more important: the README warns that HSWQ ConvRot INT8/NVFP4 runs leave residual GPU and host memory behind that ComfyUI's generic unload doesn't release. A second generation after the first can fail with errors like quantize_nvfp4 or PyCapsule. The fix is to put General Purge VRAM V2 from ussoewwin's ComfyUI-DistorchMemoryManager at the end of the workflow with its HSWQ toggle on. Annoying, yes - but it's the documented path, and the failure mode it prevents is a silent second-run crash.