Get Device
Ask a recipe where it lives — and hand that answer back to the merge
- a (param)
- recipe
Get Device Mecha Recipe is a reflection-style node in a pack that's usually all about composing merges. It takes one recipe and returns, as a param recipe, the device that recipe's tensors live on - cuda:0, cpu, whatever it is. You then wire that string into another param input, so you can write workflows that adapt to where data actually is instead of hard-coding it.
It exists because comfy-mecha makes parameters (like device and dtype) part of the recipe graph. The pack's Mecha Merger has its own default_merge_device and output_device settings on the node itself, so most people never need this. Where it earns its keep: building self-adaptive merges - recipes that read the current device of one branch and pass it into a cast-style param elsewhere, so the workflow behaves correctly whether the GPU is loaded or everything has fallen back to CPU.
Inputs & output
a (param)- the recipe to inspect. Note the merge-space suffix saysparam; you can inspect anything, but the output is naturally aparam.merge_checkpointing- the usual branch-cache toggle.
Output: one recipe (MECHA_RECIPE) carrying the device string, e.g. "cuda:0". You can pipe it into any param socket that accepts a string recipe - device slots on cast-style operations, or store it via a Serializer to see what a branch resolved to.
How to use it (and when not to)
The realistic use is debugging and adaptive graphs. For debugging: wire a recipe through this node into a Serializer, run, and read the device in the serialized text - a quick way to confirm a branch actually moved to CPU. For adaptive graphs: instead of guessing, let the merge ask the model where it is. But if you're just trying to control where a merge runs, don't reach for this - the Mecha Merger node's default_merge_device / output_device dropdowns are the direct controls, and they're simpler.
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; only dependency is sd-mecha==1.1.7.
The one thing that trips people: the output is a param recipe, not a string you can read in a text box directly - you need a Serializer (or Mecha Regex Weights's recipe_txt) to see it. And because it's a param, it flows into param sockets only; feeding it into a weight socket will refuse or misbehave. It's a niche node. You'll probably use it once, to understand your own graph, and then forget it exists - which is fine, that's the job.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| a (param) | 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. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| recipe | MECHA_RECIPE | — |