Nodes/Z-FUSE: Surgical LoRA Orchestrator/Z-FUSE: Surgical Orchestrator
ComfyUI Node

Z-FUSE: Surgical Orchestrator

The node that fixes Z-Image 'blurry soup' by merging LoRAs before they ever touch the model

By destinyfaux·Created 8 months ago·Updated 6 months ago· 10
Z-FUSE: Surgical Orchestrator
  • model
  • clip
  • lora_stack
  • MODEL
  • CLIP
  • TRIGGER_WORDS
  • ANALYSIS_REPORT
  • STATUS_LOG
merge_modeTIES-Fast
ties_threshold0.20
final_strength1.00
strength_clamp4.0

This is the payoff node of the Z-FUSE pack. Everything else - the Bus stacker, the Visual Layer Tuner - just stages descriptions of LoRAs. ZFuseOrchestrator is where the math happens, and the math is the whole pitch: instead of ComfyUI's standard loader patching LoRAs onto the model one after another (patch on patch on patch, until the weights saturate and the image dissolves into over-bright soup), this node fuses all your LoRAs into one mathematical delta and applies that single clean patch.

Wire it like this: base Z-Image model into model, your CLIP into clip (it just passes through), and the final LORA_STACK from your Bus/Tuner chain into lora_stack. Out the other side comes a MODEL that goes straight to your KSampler, a CLIP for your text encoder, and several string outputs that tell you what happened.

How the fusion actually works

Under the hood, the pack's TIESFuser walks each LoRA and rebuilds its weight delta (up @ down, scaled by strength and the alpha/rank ratio). Then it merges those deltas with TIES logic, the same family of tricks used in model-merging research:

  • Trim the noise. The bottom ties_threshold fraction of each delta's values gets zeroed before it's considered. The default 0.2 means "ignore the quietest 20% of weights."
  • Sign election. Where two LoRAs disagree on a weight's sign, that weight is zeroed - they conflict, so neither gets to drag the result its way. This is what stops LoRAs from fighting.
  • Magnitude-weighted average. Remaining weights are blended by how big each LoRA's contribution is, so a weak LoRA doesn't drown a strong one.

Finally everything is clamped to ±strength_clamp (default 4.0) as a safety rail - the README says that headroom allows "up to 40x standard strength." The fused result is applied through ComfyUI's own load_lora_for_models path, so the model receives one coherent patch instead of N stacked ones. A good-enough analogy: sequential loading is drawing five overlapping transparencies; this is compositing them into one image first.

The inputs and outputs that matter

  • lora_stack - your chain of stackers/tuners. Empty stack → the node passes the model through untouched.
  • ties_threshold - your noise filter, 0.0–0.5. Higher prunes more aggressively: cleaner and sharper, but past ~0.3 you start losing the subtle skin texture and fine lighting that live in the weak weights. Lower keeps detail but keeps the junk that causes the wash. 0.2 is a sane start.
  • final_strength - master volume on the whole merged result. -10…+10, so you can also invert.
  • strength_clamp - max absolute weight. Leave it at 4 unless you know why you're moving it.
  • model / clip - base Z-Image model and its CLIP. The CLIP output passes through untouched.

Outputs: MODEL (→ KSampler), CLIP, TRIGGER_WORDS (harvested from your LoRAs' metadata), ANALYSIS_REPORT (per-block heat bars, sign-conflict count, and the key-match rate), and STATUS_LOG (per-LoRA mapping results). Wire the report into a text node once and you'll never stack blind again.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/destinyfaux/Z-Fuse.git

then restart ComfyUI, or search Z-Fuse in ComfyUI Manager. No extra Python packages, no model downloads.

Where people get burned

  • Check the key-match rate. STATUS_LOG reports how many LoRA keys matched the model - if you see something like 208 of 328 keys matched, that's normal (LoKRs and partial keys exist); if it's near zero, your LoRA isn't a Z-Image LoRA and is doing nothing. LoRAs are architecture-bound; an SDXL file won't map.
  • System RAM, not VRAM. Fusion aggressively offloads tensors to system RAM to protect VRAM. A big stack on a 16GB-RAM machine can thrash; close your browser tabs before the first fuse.
  • Caching is your friend and your trap. The node caches by a hash of the stack and its settings - identical inputs hit the cache and are instant, but bump any strength or block and it re-fuses. If a change you're sure you made doesn't show up, you changed the wrong node.
  • Z-Image only. This is tuned for the S3-DiT single-stream architecture, Base or Turbo. It won't hurt you on other models, but it has no reason to exist there.

If you're running Z-Image Base (the January 2026 release the community calls "SDXL 2.0") and stacking three or more LoRAs at the 1.0+ strengths that architecture demands, this is the node that makes that stack survivable. It's the one you'd reach for - and the only real contender is dropping LoRAs until the render works, which is the old way.

CategoryZ-Image/Fusion

Inputs (7)

NameTypeDefaultDescription
modelMODELBase Z-Image model
clipCLIPCLIP model (passthrough)
lora_stackLORA_STACKLoRA stack from Bus or Tuner nodes
merge_modeCOMBOTIES-FastTIES: Fast sequential merging
ties_thresholdFLOAT0.200–0.5Noise trim threshold (0.2 = trim bottom 20%)
final_strengthFLOAT1.00-10–10Final strength applied to merged LoRA
strength_clampFLOAT4.01–10Max weight value (safety clamp)

Outputs (5)

NameTypeDescription
MODELMODEL
CLIPCLIP
TRIGGER_WORDSSTRING
ANALYSIS_REPORTSTRING
STATUS_LOGSTRING