PM Save LoRA

Merging LoRAs is only useful if you can keep the result. This is the node that turns a merged LoRABundle into a real .safetensors file on disk - the artifact you can then load with any standard LoRA loader, share, or reuse in workflows that have no idea this pack exists. It's the endpoint of the whole merge pipeline.

You'll typically reach for it after testing a merge with PM LoRA Apply and deciding the result is worth keeping. It's also how you'd produce a merged file for use outside ComfyUI entirely - the output is a standard-format safetensors.

How it works

It takes the merged LoRA plus the model context, and writes a standard-format safetensors file to ComfyUI's LoRA directory (where the standard loader looks). If the bundle still carries original CLIP weights, they're saved along with the UNet-side patches - so the saved file behaves like a normal LoRA that affects both model and text encoder.

The inputs that matter

• model - the model, needed for key context when writing the file.
• lora - the merged LoRABundle from PM LoRA Merger.
• file_name - the output filename without extension (default merged). This is what you'll type into any LoRA loader later.
• extension - currently safetensors, the only choice.

It's an output node with no outputs - it exists to write a file and stop.

Installing

Part of the LoRA Power-Merger pack. ComfyUI Manager (search "LoRA Power-Merger") or:

cd ComfyUI/custom_nodes
git clone https://github.com/larsupb/LoRA-Merger-ComfyUI
cd LoRA-Merger-ComfyUI
pip install -r requirements.txt

Restart ComfyUI; the node shows as PM Save LoRA. Dependencies: PyTorch, lxml, mergekit.

Common issues

The most common confusion is a fresh merge that "doesn't save anywhere" - you usually want the file to land where the standard loader reads from, so confirm the output path matches your models/loras directory, and remember the filename excludes the extension. If you saved a file and a normal LoraLoader won't load it, the usual culprits are rank/format edge cases (standard LoRA format only - LoHA/LoCon/DoRA inputs to this pipeline won't round-trip cleanly) or a merge that ran with merge_clip off when you expected CLIP behavior. And there's no strength stored in the file - like any LoRA, strength is applied when you load it, so a "weak" saved merge is really a merge-time scaling problem, not a save problem.