ComfyUI Node

Converter

Translate a merge recipe between key layouts — kohya, diffusers, supermerger, and back

By ljleb·Created 3 years ago·Updated about a month ago· 101
Converter
  • recipe
  • target_config_from_recipe_override
  • recipe
target_config

Mecha Converter does the unglamorous but essential job of translating a MECHA_RECIPE between model-config key layouts. The same model exists in several different key conventions: the native SDXL/SD1 layout (sdxl-sgm, sd1-ldm), the kohya LoRA conventions (lycoris vs. kohya naming, diffusers vs. original), the diffusers-style layouts, and the supermerger block format. A recipe built with keys in one convention is meaningless in another - the tensor names don't line up. This node rewrites the recipe's key mapping so the merge happens in whatever layout you need.

When do you actually need it? Mostly when your inputs speak different dialects. Load a kohya-trained LoRA (sdxl-kohya_kohya_lora) and want to merge it onto a model loaded as plain sdxl-sgm? The pack can often infer this automatically, but when it can't, or when you're deliberately working in a specific layout (supermerger block weights, or saving in a diffusers layout for another tool), Converter is the explicit translation step.

Inputs

  • recipe - the MECHA_RECIPE to convert.
  • target_config - the destination config, an enum of the pack's known model configs (17 of them, including sdxl-sgm, sd1-supermerger_blocks, sdxl-kohya_lycoris_lora, sdxl-kohya_kohya_lora, sdxl-diffusers_unet_only, sd3-comfyui, and more).
  • target_config_from_recipe_override - an alternative: feed in another recipe, and the converter uses that recipe's own config as the target. This is the "copy this recipe's layout" move - useful when you have a reference model whose exact config you want to match, rather than picking from the dropdown.

Either target_config or the override must be set; output is one recipe (MECHA_RECIPE) in the new layout. The mechanism is a config-to-config conversion of the recipe graph, key-by-key, before any merging happens.

The workflow shape

The typical chain is: load with Model Mecha Recipe / Lora Mecha Recipe (which pick a config, often "auto") → run through Converter to force a target layout → feed into merge nodes → Mecha Merger. If your merge errors with "key not found" or produces a checkpoint that another tool refuses to open, the fix is frequently a Converter step to normalize everything into one convention.

Install & gotchas

ComfyUI Manager → search mechaMecha 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; only dependency is sd-mecha==1.1.7.

The honest warning: conversion between conventions isn't free. It can't conjure keys that don't exist - a diffusers-unet-only config has no text-encoder keys, so converting a full checkpoint recipe into it drops those components. Check whether your target config actually covers the components you need (this is where Mecha Merger's omit_vae interacts: if your recipe converts away the VAE, a downstream "missing VAE" complaint is expected, not a bug). And when in doubt, let the loader's "auto" config do the work before reaching for Converter - it's a tool for mismatches, not a default.

Categorymecha

Inputs (3)

NameTypeDefaultDescription
recipeMECHA_RECIPE
target_config_from_recipe_overrideoptMECHA_RECIPE
target_configoptCOMBO17 options: singleton-mecha, sdxl-supermerger_blocks, sdxl-sgm, sdxl-kohya_lycoris_lora, sdxl-kohya_kohya_lora, sdxl-kohya_but_diffusers_lycoris_lora, +11

Outputs (1)

NameTypeDescription
recipeMECHA_RECIPE