Load LoRA to use with Core ML
LoRAs in the Core ML world are baked, not blended
- clip
- lora_params
- CLIP
- lora_params
LoRAs are the reason most people get into ComfyUI at all, so it's fair to ask what happens to them when you move your UNet to Core ML. The honest answer: they stop being adjustable. Once a model is converted, its weights are frozen - there's no patching a compiled .mlpackage at load time. So this node's job is to load a LoRA the Core ML way: at conversion time, baked permanently into the model.
The node looks familiar - it's built on ComfyUI's stock LoraLoader - but there are two important differences. First, there's no model input. You don't apply the LoRA to a diffusion model, because the diffusion model doesn't exist yet as Core ML. Instead you feed the node's lora_params output into the Core ML Converter, which applies the LoRA while converting your checkpoint and stores the result as a new model in models/unet. Second, the CLIP input is required: loading a LoRA affects the text encoder too, and since CLIP stays a normal ComfyUI model in this workflow, this node is also how you get a properly LoRA-patched CLIP for conditioning.
What goes where
- lora_name - pick from your
models/lorasfolder. - strength_model - how hard the LoRA hits the diffusion model. This value is baked into the converted model. Change your mind later? Delete the converted model and re-convert. That's the whole caveat in one sentence.
- strength_clip - how hard it hits the text encoder. This one is not baked; it only affects the CLIP you're feeding, so you can tweak it after conversion without touching the model.
- lora_params (optional) - chain multiple LoRA Loaders together; the converter takes them all and bakes them together.
Outputs are CLIP (the patched text encoder, wire it into your sampler's positive/negative conditioning) and lora_params (into the Core ML Converter).
The gotchas, straight from the README
The author is refreshingly upfront that this is a workaround. The sharp edges:
- The model name is the cache key. LoRA names are encoded into the converted model's filename, so rename a LoRA file and the next run converts a brand-new model. Rename the LoRA but keep a stale converted model around, and you'll load the old baked weights without realizing it.
- Same LoRA, both sides. After conversion, when you load the baked model with the Core ML UNet Loader, you must apply the same LoRAs to CLIP again (using this node) so the text conditioning matches what was baked into the UNet. Skip it and your prompt guidance drifts from the model's intent.
- LCN LoRAs work but through a different door. For LCM LoRAs, the README's example routes the model through the Core ML Adapter and a
ModelSamplingDiscretenode into a standard KSampler - not the Core ML Sampler. Follow the example workflow on that one; it's fiddlier than it looks.
Install
Same pack as everything else: ComfyUI Manager, search "Core ML," install, restart. Or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/aszc-dev/ComfyUI-CoreMLSuite
cd ComfyUI-CoreMLSuite
pip install -r requirements.txt
Bottom line: if you're the kind of person who tweaks LoRA strength five times per image, this workflow will drive you up a wall - every change is a re-conversion. But if you've settled on a look and just want it fast, bake it once and never think about it again.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| clip | CLIP | The CLIP model the LoRA will be applied to. | |
| lora_name | COMBO | The name of the LoRA. | |
| strength_model | FLOAT | 1.00-100–100 | How strongly to modify the diffusion model. This value can be negative. |
| strength_clip | FLOAT | 1.00-100–100 | How strongly to modify the CLIP model. This value can be negative. |
| lora_paramsopt | LORA_PARAMS | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| CLIP | CLIP | The modified diffusion model. |
| lora_params | LORA_PARAMS | The modified CLIP model. |