Cast

Most merge nodes inherit whatever device and dtype the Mecha Merger says to use, and that's usually right. This node is for when it isn't. Cast Mecha Recipe pins an entire branch of your merge graph to a specific device and dtype before it reaches anything downstream - the escape hatch for the two merge problems that actually recur: precision loss and running out of VRAM mid-graph.

What it controls

a (delta|param|weight) - the recipe branch to cast. Any merge space works.
device - where the tensors in this branch get computed and stored. cpu, cuda:0, etc. Leave None to inherit.
dtype - the precision: fp32, fp16, bf16, fp64, float64, int64, int32, fp8_e4m3fn, fp8_e5m2. Leave None to inherit.

Output: one recipe (MECHA_RECIPE) with the cast applied.

When it's actually worth it

High-precision merging. The pack's author explicitly built sd-mecha so you can "merge in high precision like fp64 without taking all the system resources." Merges are accumulations, and fp16 accumulation can drift on long multi-model recipes. Cast the fragile branches to fp32 or fp64, merge, then cast the final result back to fp16 for saving. For a two-model weighted sum nobody cares; for a 12-model TIES recipe the difference can show up in the output.

Memory triage. The lazy, one-key-at-a-time design already keeps RAM low, but you can still bottleneck if a huge branch has to materialize on the GPU. Casting a branch to cpu forces those keys to be computed and held in system RAM instead - slower, but it converts an OOM into a working merge. Pair it with the merger's output_device/output_dtype settings for the full effect.

Mixing precisions deliberately. Occasionally you want the attention keys at fp32 and the rest at fp16 (a crude approximation of what some fine-tune strategies do). Cast the branch that carries the keys you care about and leave the rest alone.

The one field people trip on: device and dtype accept a string recipe, so if you're feeling clever you can wire a per-key recipe in here - which is a genuinely useful trick for per-block precision - but for normal use just leave them None or type a value in the field.

merge_checkpointing works here like everywhere in the pack: cache the branch on CPU in fp16 once it's stable.

Install & gotchas

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 after. Dependency is sd-mecha==1.1.7.

Two footguns: casting to fp64 doubles memory per tensor relative to fp32, which can bite when you're trying to save memory - use it on the small branch, not the whole graph. And casting an already-saturated recipe up doesn't recover detail that was lost before the cast; put the Cast before the merge step you're worried about, not after.

Name	Type	Default	Description
a (delta\|param\|weight)	MECHA_RECIPE		—
device (None)opt	MECHA_RECIPE		—
dtype (None)opt	MECHA_RECIPE		—
merge_checkpointingopt	BOOLEAN	false	Speeds up an entire branch of a merge graph that does not change often in exchange of memory. - true: store the first output of this recipe node on cpu memory in fp16. On subsequent workflow executions, as long as the inputs do not change, the cached keys are returned after being cast to the original device and dtype. - false: do not store the output. The recipe and its inputs will re-execute on subsequent workflow executions. Note that the memory used to checkpoint the output is distinct from the cache feature. In general, you probably want to either use this or a cache unit, but not both at the same time because the memory adds up. The difference between merge checkpointing and cache is that merge checkpointing completely re-merges from scratch if any input changes. Merge checkpointing is also generally much faster than cache in the fast path.

What it controls

When it's actually worth it

Install & gotchas

Inputs (4)

Outputs (1)