ZImageLoraManagerAdvanced

ZImageLoraManagerAdvanced (registered as "ZImage LoRA Manager Advanced (Bake/Extract)") does one thing you can't do with the stock LoRA loader: it writes a LoRA's weights into a full Z-Image checkpoint, producing a standalone model - or runs the reverse, pulling a LoRA back out of a merged/fine-tuned model. And it does all of it on CPU, no GPU load at all.

Why would you bother? The author's pitch, from his reddit announcement: this is for people with limited VRAM who can't fine-tune. Train a normal LoRA, bake it into Z-Image Base, and you've got your own custom checkpoint. It also sidesteps Z-Image's known multi-LoRA stacking collapse, and the community has noticed CivitAI checkpoints with baked LoRAs often hold up better than live LoRA loading.

How it works

This is raw state-dict math, not a training run. In bake mode it loads the base checkpoint and the LoRA, then for every matching layer applies the classic LoRA merge: W' = W + BA × (alpha/rank) × your_alpha. The merged tensor is saved back out as a full .safetensors checkpoint.

Extract mode is the exact reverse. It takes your original base model and the merged/fine-tuned model, subtracts (merged − base) to get the "delta" the LoRA contributed, runs SVD on that difference, and keeps only the top rank components. Those become new lora_down, lora_up, and alpha tensors - a working LoRA, named the way training scripts expect.

It also handles format conversion for you. Z-Image LoRAs come out of trainers (AI Toolkit, OneTrainer) in sd-scripts layout with separate to_q/to_k/to_v keys, but ComfyUI's loader wants the combined attention_qkv form. The node auto-detects which you've got and converts both directions.

The inputs that matter

The dropdowns are populated by recursively scanning your models folder, so they only show files you actually have.

• mode - bake or extract. This is the entire personality of the node; everything else depends on it.
• base_model - in bake mode this is what the LoRA gets merged into; in extract mode it's the original unmodified base you need for the subtraction.- lora_model / merged_model - the LoRA for baking, or the fine-tuned model to extract from. Only the relevant one is used per mode, but extract needs both base and merged set or it just returns an error.
• alpha - strength of the bake, 0–10, default 1.0. Leave it at 1 unless you know you want a stronger or lighter merge.
• rank - how many SVD components to keep when extracting (1–128, default 16). Lower rank = smaller, less faithful LoRA.
• convert_to_comfy_format - keep this on; it's what makes the extracted LoRA drop straight into the stock loader.

The single output is a status string telling you what got written and where - the actual product lands in ComfyUI/output/, with a _1, _2 suffix if the filename already exists.

Installing it

No model downloads, no requirements.txt, no heavy deps - it only uses torch and safetensors, which every ComfyUI install already has. Easiest route is ComfyUI Manager, searching for the pack title, or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/GraftingRayman/ComfyUI-ZImage-Bake-Extract

Restart ComfyUI and the two ZImage nodes appear under the ZImage category. That's the entire install.

Where people get burned

The big one: this node only understands Z-Image key naming. The bake/extract logic matches Z-Image's training layout (layers.{N}.feed_forward.w{N}, layers.{N}.attention.qkv.weight, and LoRA prefixes like lora_unet_layers_{N}_...). Feed it an SDXL or Flux LoRA and those keys won't be found - the code logs "Base key not found. Skipping." and quietly writes a checkpoint that is just your base model wearing a few gigabytes of extra bloat. This is a Z-Image tool; don't reach for it as a generic model merger.

Also worth knowing before you queue it: bake output is a full multi-gigabyte checkpoint (Z-Image Base is ~12GB in BF16), and the whole thing loads into CPU RAM - no VRAM, but you want decent system memory free.

The honest take

Baking locks a LoRA in at one fixed strength forever, and a ~170MB LoRA becomes gigabytes of disk. If you only use a LoRA sometimes, keep loading it live - that's the "why burn the drive space?" argument and it's a fair one. Bake instead when you want a curated, self-contained checkpoint: one LoRA you always run at the same strength, a style you want merged before handing a model to someone else, or you're on hardware where you can't fine-tune at all. That's the niche, and for it this is the easiest path in ComfyUI.