HSWQ ConvRot INT8/ConvRot NVFP4 UNet Loader

Confusingly named - the class is HSWQFP8E4M3UNetLoader, but the display title is "HSWQ ConvRot INT8/ConvRot NVFP4 UNet Loader" and its main reason to exist is NVFP4, not FP8. FP8 was the HSWQ line's past; NVFP4 is its present. Understood that way, the node is simple: it's the stock UNetLoader wrapper, pointed at models/diffusion_models, with weight-dtype options that the checkpoint loader doesn't offer.

Why this node exists separately

The HSWQ pack has two loaders, and the split is architectural. The HSWQ Checkpoint Loader (SDXL) handles SDXL, whose NVFP4 path is a Linear→NVFP4 Tensor Core product path with online activation rotation. This UNet loader is for everything else - most visibly Z Image / ZIT and Krea2 UNet packs - and its weight_dtype list is what gives the game away:

• default - with auto-detect: INT8-looking packs take the INT8 path, NVFP4-looking packs take the ConvRot NVFP4 path.
• fp8_e4m3fn / fp8_e4m3fn_fast / fp8_e5m2 - the general FP8 modes, which (unlike the NVFP4 modes) work with any compatible weights, not just HSWQ ones.
• int8_tensorwise - the INT8 path.
• Z Image ConvRot NVFP4 - HSWQ-quantized Z Image / ZIT packs.
• Krea2 ConvRot NVFP4 - HSWQ-quantized Krea2 packs.

The README is insistent on one thing: this is not the SDXL path. Z Image NVFP4 runs through a Comfy parity path - stock GEMM plus online activation rotation, the same path the author's benchmark scripts use - rather than the Tensor Core product path the SDXL checkpoint loader takes. "Do not expect the SDXL Checkpoint Loader's Tensor Core product path here," it says, and it means it. Pick the loader by model family, not by whichever you happen to have clicked.

The mechanism

Under the hood it's a thin wrapper over comfy.sd.load_diffusion_model, which is why using it with a normal FP8 or plain FP16 UNet feels identical to stock. The cleverness lives in the pack's patches - INT8 load compatibility patches that cover Conv2d, LoRA, ControlLora and handoff, plus the NVFP4 load/forward patches in nodes/nvfp4/ - which fire when a checkpoint advertises the right comfy_quant markers. If you load an HSWQ NVFP4 Z Image pack and it comes up as a dim image rather than an error, this is where the work actually happened.

Inputs and outputs

• unet_name - any file in models/diffusion_models.
• weight_dtype - the seven choices above.

Outputs are a single MODEL. Note there's no CLIP socket and no device selector; you pair this with a normal CLIPLoader (for Z Image, that's the Qwen3 text encoder; for Krea2, the Qwen3-VL encoder - people routinely forget the encoder file and then blame the model). One honest caveat: the auto-detect only inspects markers in the file, and NVFP4 dispatch is installed after INT8 dispatch specifically so mixed packs (NVFP4 Linear + INT8 Conv) don't get stolen by INT8-only detection. If your pack is genuinely mixed, leave weight_dtype on default.

Installing and gotchas

Same story as the rest of the pack: ComfyUI Manager, or

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

then restart. The requirements.txt is heavy - it drags in diffusers, transformers, insightface, onnxruntime, peft, accelerate and friends - so let Manager handle it if you can.

The gotcha is the same as the SDXL loader, and it applies to any ConvRot NVFP4 or HSWQ INT8 UNet load: put General Purge VRAM V2 from ComfyUI-DistorchMemoryManager at the end of the workflow with the HSWQ toggle on, or the second generation can fail on NVFP4 runtime pools / CUDA graph state that ComfyUI's normal unload leaves behind. It reads as a workaround, and it is - but it's the documented one.