Get Dtype
Read a recipe's precision as a param — wire it into cast-style merges or just debug
- a (param)
- recipe
Get Dtype Mecha Recipe is the precision twin of Get Device: it takes a recipe and returns the dtype of its tensors - float16, bfloat16, float32, int64, whatever - as a param recipe you can feed back into the graph. In a pack where every parameter is itself a recipe, "what precision is this tensor in?" becomes a first-class value you can route around like any other recipe.
It's a quiet node, and most merges never need it. But it's genuinely useful for two things: adaptive recipes that cast a branch to match whatever a model already is, and debugging - serializing a recipe through it tells you exactly what precision a merge resolved to, which is the first thing to check when a merge looks subtly wrong (fp16 accumulation can do that).
Inputs & output
a (param)- the recipe to inspect. Output is a param recipe holding the dtype string ("float32","bfloat16", and so on), which flows into any param socket that accepts a string.
The pack's Mecha Merger already has default_merge_dtype and output_dtype dropdowns covering the normal use ("merge in fp32, output fp16" is a common, sensible pair). So the honest answer to "when do I use this node?" is: when the dtype needs to be derived at runtime rather than picked by hand - e.g., a workflow that reads the precision of a loaded LoRA and asks the merge to match it, so you don't hard-code precision and drift out of sync with your actual files.
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.
Notes are short because the node is short. The output is a param recipe - to see it, run it through a Serializer; you can't read it in a plain text widget. And be careful feeding a dtype recipe into a socket that expects a different kind of param (like a float strength): a string where a number belongs will error rather than silently work, which is honestly the best case. If you never touch it, nothing breaks - dtype control on the Merger covers 99% of real workflows.
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 | — |