HyperLoRA Apply LoRA
The LoRA you generated isn't useful until it hits your model
- model
- lora
- MODEL
All the clever machinery upstream produces a LORA - but a LoRA sitting on a wire does nothing. HyperLoRAApplyLoRA is the node that fuses the generated weights into your SDXL checkpoint. It's deliberately boring: model in, LoRA in, weight in, patched model out. That simplicity is the point. It's the same operation ComfyUI's built-in LoRA application does, which is itself a quiet confirmation that HyperLoRA's output is a real LoRA, not some special sauce that only works inside this pack.
What it is and why it matters
HyperLoRA's whole promise is "LoRA-quality identity with zero training." The punchline only lands when the generated weights actually change how your base model draws. This node does exactly that, using ComfyUI's own load_lora_for_models under the hood - the standard LoRA patching path. Because it's a normal application, you can also treat it like any LoRA stage: stack the ID LoRA and a base LoRA, or drop the weight low for a subtler effect.
The inputs that matter
model- your SDXL checkpoint, straight from aLoad Checkpointnode. HyperLoRA is SDXL-only, and not every SDXL base works - the README confirms RealVisXL v4.0 (best), LEOSAM's HelloWorld XL 3.0, and CyberRealistic XL v1.1 are compatible, while ArienMixXL v4.0 is not. This is the compatibility check to make before anything else.lora- the generated LoRA fromHyperLoRAGenerateIDLoRA(or the Uni generator). You can also feed it a saved.safetensorsloaded through the normalLoad LoRAnode, since it's a real file.weight- the strength, a float from -1.5 to 1.5, default 0.8. This is the tuning dial that actually matters. The README's guidance: 0.75–0.85 is the sweet spot for likeness, nudge up for long prompts, nudge down if you want more editability. Above ~1.0 you'll start seeing identity artifacts smother the prompt; below ~0.5 the face tends to drift.
Output: the patched MODEL, which feeds your KSampler like any other model chain.
Installing
Pack install is the usual: ComfyUI Manager → "ComfyUI-HyperLoRA", or git clone https://github.com/bytedance/ComfyUI-HyperLoRA into custom_nodes, pip install -r requirements.txt, restart. Note that this node itself needs none of the model downloads - it's pure LoRA patching. The CLIP/InsightFace/HyperLoRA model files under models/hyper_lora/ and models/insightface/models/ are required by the nodes upstream of it, so you'll still be downloading them to get a LoRA to apply in the first place.
Gotchas
Two things bite people. First, the weight really is a dial you have to find by feel - the README gives ranges, not a universal answer, and the right value shifts with prompt length and the variant you loaded (v1_fidelity vs v1_edit). Second, remember the workflow-level contract: the prompt must open with the trigger words fcsks fxhks fhyks, or the LoRA barely fires, and the example workflows set stop_at_clip_layer to -2 (which is why they need the ComfyUI_ADV_CLIP_emb pack). If your output looks like the identity vanished, check the trigger words before you blame the weight.
If the face comes out but the likeness is soft, that's HyperLoRA doing its normal thing - the community's standard fix is a FaceDetailer pass over the result, or an InstantID ControlNet stacked on top for the strongest similarity.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| lora | LORA | — | |
| weight | FLOAT | 0.80-1.5–1.5 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |