Stack

Some merge methods need to see all their inputs at once - stack them into one tensor, run a computation over the whole stack, and only then produce output. The Stack node in comfy-mecha is the raw building block for that: take a list of recipes and stack them along a new leading dimension, returning a single MECHA_RECIPE.

Its inputs are minimal:

values (delta|param|weight) - a MECHA_RECIPE_LIST (build one with Mecha Recipe List), containing the recipes to stack.

Output is one MECHA_RECIPE.

What it's actually for

Honest answer: if you're a beginner, you will almost certainly never touch this node, and that's fine. It's the low-level torch.stack exposed into the recipe graph - the kind of primitive that custom merge methods use under the hood when they need a batch of tensors to operate on (mean over a stack, rank over a stack, that sort of thing). It's part of the pack's extensibility story: the same mechanism sd-mecha uses to implement n_average and the TIES family is available to you, at one level of abstraction lower.

How it works

Per key, it collects the matching tensor from every input recipe and stacks them into a new tensor with one more leading dimension. Because it's a pure rearrangement - no math on the values - it's cheap, but it changes the shape of every tensor, which means the stacked result generally can't be fed straight into the same merge methods as its inputs; downstream, something has to know it's looking at a stack.

Install

Pack-level: 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; no model downloads.

Gotchas

Don't confuse this with combining models for a merge. A weighted sum is not a stack - Stack won't blend anything; it just rearranges tensors. If your goal is "merge these models together," the Weighted Sum / n_average / TIES nodes are the tools; if your goal is writing your own merge method that needs stacked tensors, this is your primitive. The merge_checkpointing toggle behaves like the rest of the pack: fp16 CPU caching for stable branches, don't stack it with cache units - and yes, that pun is intended.

Name	Type	Default	Description
values (delta\|param\|weight)opt	MECHA_RECIPE_LIST		—
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's actually for

How it works

Install

Gotchas

Inputs (2)

Outputs (1)