HyperLoRA Loader

Every HyperLoRA workflow starts here. This node loads the whole machinery that generates face LoRAs: the CLIP ViT image encoder and its processor, the hyper-network modules that predict LoRA weights, the resampler that bridges the two, and - if you've asked for ArcFace identity - the InsightFace face analyzer and the ID projector. One node, several gigabytes of model weights, and every other node in the pack reads the HYPER_LORA bundle it produces.

What it is

Think of it as the checkpoint loader for this pack. HyperLoRALoader doesn't generate anything itself; it's the supply line. Its single output is the hyper_lora input that HyperLoRAFaceAttr, HyperLoRAIDCond, HyperLoRABaseCond, and the generate nodes all consume. In the shipped T2I workflow it comes right after HyperLoRAConfig, which builds the HYPER_LORA_CONFIG that tells the loader what to instantiate.

The inputs that matter

• config - the config object from HyperLoRAConfig. This decides which encoders get loaded (encoder_types), whether the base LoRA machinery is included (has_base_lora), the resampler shape, and the LoRA rank. With the stock config, leave it alone.
• model - a dropdown of subfolders under models/hyper_lora/hyper_lora/. You should see sdxl_hyper_id_lora_v1_fidelity (better likeness) and sdxl_hyper_id_lora_v1_edit (better editability). If it says "Not found!" your model files are in the wrong place - see below.
• dtype - fp16, bf16, or fp32. fp16 is the sensible default; the released models were trained in fp16, and fp32 buys you nothing but VRAM pain.

Output: one HYPER_LORA bundle.

How it works under the hood

The loader reads hyper_lora_modules.json to learn which SDXL attention layers the hyper-network targets, builds one HyperLoRAModule per layer, and loads hyper_lora_modules.safetensors, resampler.safetensors, and - only when ArcFace is in encoder_types - id_projector.safetensors plus the InsightFace analyzer. If has_base_lora is on, it also loads a base_resampler.safetensors. Everything is moved to your torch device in the chosen dtype and set to eval. One thing that surprises people: the InsightFace embedding runs on CPU (CPUExecutionProvider), which is slower but saves your GPU.

Install and the model-folder dance

Install is standard: ComfyUI Manager → search "ComfyUI-HyperLoRA", or git clone https://github.com/bytedance/ComfyUI-HyperLoRA into custom_nodes, pip install -r requirements.txt (pulls diffusers, insightface, onnxruntime, opencv-python, transformers), restart. The real work is the model files, and the folder names have to match exactly:

mkdir -p models/hyper_lora/clip_processor/clip_vit_large_14_processor
mkdir -p models/hyper_lora/clip_vit/clip_vit_large_14
mkdir -p models/hyper_lora/hyper_lora
mkdir -p models/insightface/models

• CLIP processor (preprocessor_config.json) and CLIP ViT (config.json + model.safetensors) from openai/clip-vit-large-patch14 on HuggingFace.
• The HyperLoRA model itself from bytedance-research/HyperLoRA, unzipped so each variant folder sits under models/hyper_lora/hyper_lora/.
• antelopev2 from the InsightFace model zoo (a manual Google Drive download - the classic stumbling block), unzipped under models/insightface/models/.

Common issues

• Dropdown says "Not found!" - the folder layout is wrong, or you haven't downloaded that piece yet. Check the exact paths above; this is the #1 setup failure.
• metadataIncompleteBuffer error on load - this is the safetensors "the file is corrupt or truncated" error. Your hyper_lora_modules.safetensors (or another model file) download got cut off. Re-download it; a broken file won't fix itself.
• Missing HyperLoRAConfig / missing node types - the pack didn't install cleanly or wasn't found by Manager; restart ComfyUI after installing, and remember the example workflows also expect ComfyUI_ADV_CLIP_emb and ComfyUI-Impact-Pack.

One more: this pack is SDXL-only, and not every SDXL checkpoint plays nice with the generated LoRAs. RealVisXL v4.0 is the README's top pick; ArienMixXL v4.0 is explicitly incompatible.