Saya HiDream LoRA · MODEL Loader
Load a HiDream LoRA without dragging a text encoder along with it
- model
- lora_config
- hidream_model
What it is
Two inputs, one output, and that's the whole node: a MODEL and a lora_config in, a patched hidream_model out. It's the execution half of a pair - SayaHiDreamLoraSettings holds the choices, this one applies them.
Why bother, when ComfyUI already has a LoraLoader? Because the stock one patches model and CLIP, and HiDream in this stack has a quad CLIP - a T5-XXL, a Llama-3.1-8B and two smaller encoders, on the order of 13.8 GB of residency. This loader goes through ComfyUI's native model-only LoRA API: it passes no CLIP and patches no CLIP, so a diffusion LoRA can't drag your text encoding path into the transaction. It's the correct shape for the job.
It also preserves the GGUF patcher subclass. If you're running HiDream as a quantised GGUF - which, at 17B, most people are - the clone keeps the quantised-weight patch implementation intact instead of quietly flattening it. Worth knowing what that costs: patching LoRA weights into a quantised model forces a per-layer dequantize–patch–requantize cycle, which is where the well-known "LoRA on GGUF is slower than it should be" tax lives. Nothing this node can fix; it's the price of the format.
What it refuses to do
Two guards, both useful:
- Hand it an SDXL model and it stops:
Saya HiDream LoRA: connect a HiDream MODEL, not an SDXL/Naturalize model. - Hand it a file with no compatible MODEL weights - an SDXL LoRA, or a HiDream LoRA for a different architecture - and it raises
no compatible MODEL weights in <name>instead of silently returning an unpatched model. It checks that the patch count actually increased before it lets you through.
That second check is the one that matters. The single most infuriating class of ComfyUI bug is the LoRA that loads fine, produces zero visible change, and gives you no error to search for. This node refuses to be that.
Wiring it up
HiDream GGUF MODEL ──► Saya HiDream LoRA · MODEL Loader ──► ModelSamplingSD3 ──► KSampler.model
Saya HiDream LoRA · Settings & Trigger Prompt ──lora_config──► (loader)
└─hidream_trigger──► HiDream COPY
The conditioning path is completely separate: SayaComfyCoupleHiDreamCopy supplies positive and negative to the same sampler and never touches the MODEL. Because the patch is diffusion-side only, changing the LoRA filename or strength does not invalidate your cached HiDream text conditioning - only a prompt change does.
Enable, filename and strength all live on the Settings node. Set strength_model to zero, choose none, or leave enabled off, and this loader is a pass-through; the console line tells you which way it went:
[SAYA HIDREAM LORA] enabled=True name='your_lora.safetensors' strength=0.8
[SAYA HIDREAM LORA] patched_weights=496
Install
Same pack as the rest of the pair:
cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/alphaziod/saya-comfy-couple-plus.git
Restart, refresh, and keep exactly one copy - an older folder named comfy_saya_couple registers the same node IDs. For GGUF HiDream checkpoints you also need ComfyUI-GGUF. requirements.txt is NumPy and Pillow only; the pack refuses to install PyTorch so it can't stomp your CUDA or ROCm build.
Where people get burned
Red socket on lora_config. It's a custom SAYA_HIDREAM_LORA type, not a LoRA name string. Only the Settings node emits it.
A LoRA with a text-encoder component. This node is model-only by design, so anything the file carries for the encoders isn't applied. The pack's answer is the trigger field on the settings panel - put the trigger word there and let the HiDream COPY node prepend it to the prompts before encoding.
Assuming you can verify it by eye at strength 1.0. LoRA strength is a normal diffusion knob from -20 to 20 and the useful range is usually narrow. If nothing changes, check the console's patched_weights count first - if it's non-zero, the patch landed and the answer is in your strength or your trigger, not your wiring.
If you want to check a LoRA against a GGUF checkpoint without loading the 17B model, the pack ships a CPU validation script:
cd /path/to/ComfyUI
/path/to/comfy-python /path/to/saya-comfy-couple-plus/tests/validate_hidream_lora.py
Run it with ComfyUI's Python environment and ComfyUI-GGUF installed.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| lora_config | SAYA_HIDREAM_LORA | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| hidream_model | MODEL | — |