Z-FUSE: No-Loss Bake (Export)
Freeze your tuned Z-Image LoRA stack into one file you can load anywhere
- model
- SAVE_STATUS
You've spent an afternoon tuning three LoRAs in the Visual Layer Tuner, zeroing weak blocks, and nudging the TIES threshold until the render finally sings. Now you don't want to keep the whole rig alive forever - four tuners, an orchestrator, and a prayer that nothing gets nudged. ZFuseBake is the exit ramp: it takes the fused result and writes it out as a real .safetensors LoRA you can load with a plain LoraLoader in any future workflow.
The name "No-Loss Bake" is doing real work. Because the Orchestrator has already merged everything into a single delta, the bake doesn't have to re-approximate anything - it just writes that delta to disk.
How it works
Feed it the Orchestrator's patched MODEL output (the one with the fused patches applied), pick a save_name, an export_rank, and a precision, and run. The node walks the model's internal patches, extracts each "diff" delta, and writes a LoRA file. Two paths:
- Full (No Loss) writes the complete delta -
lora_upholds the whole change,lora_downis an identity matrix. Zero SVD compression, zero quality loss, and the honest price is a 3–6 GB file. - 128 (High Quality, ~500 MB) and 64 (Standard, ~250 MB) run a truncated SVD on each delta instead, and log the retained energy per layer so you can see what you gave up. For most stacks, 128 is the practical sweet spot; the quality difference from Full is audible-in-theory, invisible-in-practice at normal strengths.
precision defaults to bf16, which the tooltip calls out as the right choice for Z-Image. Add an optional comma-separated trigger_words and they're embedded in the file's metadata (ss_trained_words), so the baked LoRA shows up in tools that read trigger words.
The only output is SAVE_STATUS, a string log telling you what got written, layer count, and file size. Yes - it's an output node, so it shows up in your results panel.
Install
cd ComfyUI/custom_nodes
git clone https://github.com/destinyfaux/Z-Fuse.git
then restart, or grab Z-Fuse via ComfyUI Manager. No extra dependencies beyond what ComfyUI already ships.
Where people get burned
- It must come after the Orchestrator. The bake reads
patchesoff the model - if you wire in the raw base model (or a KSampler's output... which isn't a MODEL anyway), you'll get the telltaleERROR: No patches found. Apply LoRA through Orchestrator first.That error message is the pack telling you the exact mistake to avoid. - It saves to
ComfyUI/output/loras/, notmodels/loras/. This is the classic one. You'll export, go hunting in your LoRA folder, and find nothing. The file lands underoutput/loras/<save_name>_<rank>_<precision>.safetensors, and the status log prints the full path. - Full rank is a disk hog. "No Loss" is honest about the math and silent about the gigabytes. A single Full export can eat more disk than your entire LoRA collection. Use 128 unless you're archiving something precious or the SVD energy log genuinely shows a problem.
- It's a snapshot, not a live link. The baked file captures that exact stack at that exact moment. Tweak a block after baking and you're back to re-baking - which is fine, that's the point of a deterministic pipeline.
One honest caveat: baked fusions are great for reproducibility and sharing, but a baked stack is a stack - it's not a clean trained LoRA, so don't expect to re-tune its components afterward. Treat it as a distributable artifact of a workflow you liked. For a "set and forget" render rig, that's exactly what you want.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | Model with fused LoRAs applied | |
| save_name | STRING | zfuse_merged | Output filename (no extension) |
| export_rank | COMBO | 64 (Standard) | Full=~3-6GB, 128=~500MB, 64=~250MB |
| precision | COMBO | bf16 | bf16 recommended for Z-Image |
| trigger_wordsopt | STRING | Comma-separated trigger words to embed in metadata |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| SAVE_STATUS | STRING | — |