SDXL-KOHYA_BUT_DIFFUSERS Components Params

Real-world checkpoints refuse to be tidy. A kohya-trained SDXL might have text-encoder and VAE keys in kohya naming while the UNet keys come out in Hugging Face diffusers naming - a hybrid you'll meet often enough that comfy-mecha ships a dedicated param node for it. That's the SDXL-KOHYA_BUT_DIFFUSERS Components Params node. Read the name as "SDXL-KOHYA, but the diffuser is DIFFUSERS."

It's a Components Params node, so it doesn't merge by itself - it emits a MECHA_RECIPE of per-component weights you plug into a merge method's (delta|param|weight) input. Inputs:

• diffuser - the UNet (diffusers key naming here)
• clip_l, clip_g - the two text encoders (kohya naming)
• vae - the autoencoder

Same four sliders as the plain kohya node; the difference is entirely in which key names the UNet component expects. Setting a slider to 0 leaves that component untouched.

Why you'd reach for it

You've got a checkpoint that was converted or exported with mixed naming and you want to merge it without hand-writing key maps. This node's config knows the kohya names for the text encoders and VAE and the diffusers names for the UNet, so the whole thing lines up. It's the "I know my files are messy, but the pack has a node for exactly my mess" moment.

How it works

Each float becomes a literal per-key weight restricted to one component of the config (pick_component internally), and the four combine into a single MECHA_RECIPE. That goes into a merge recipe node, and you finish at Mecha Merger to get MODEL/CLIP/VAE out. The "BUT_DIFFUSERS" clause only changes key matching - the math is identical to the rest of the family.

Install

Same as the whole pack: ComfyUI Manager → search "mecha" → Mecha Merge Node Pack, or:

cd ComfyUI/custom_nodes
git clone https://github.com/ljleb/comfy-mecha.git
pip install -r comfy-mecha/requirements.txt

Restart ComfyUI. Only dependency is sd-mecha; nothing to download.

Gotchas

Get the "BUT" right. If your UNet keys are genuinely diffusers-style, this node is the one. If they're fully kohya, the plain SDXL-KOHYA node is a better fit - and the LoRA-trained siblings SDXL-KOHYA_BUT_DIFFUSERS_KOHYA_LORA / _LYCORIS_LORA extend this same mixed layout to LoRA key handling. When in doubt, the honest move is to open the checkpoint's key list once and match the model.diffusion_model. prefix to the right variant; it saves a confusing merge.