C2C GPU Inventory

The cards in your machine are not the question. The question is what this ComfyUI install, this torch wheel and this driver can actually do with more than one of them - and almost nothing in ComfyUI answers it. nvidia-smi shows you two cards and tells you nothing about whether torch has real kernels for the newer one, whether they can talk to each other without routing through host memory, or whether a distributed process group can even be created on your OS.

C2C GPU Inventory is the node that answers it. It's a diagnostic, not a pipeline node: it touches no pixels, emits no model, and belongs in the scratch workflow you keep around for "what is this box, actually."

What it reads

Per GPU, the node reports the architecture (Turing through Blackwell, datacenter parts included), memory, whether BF16 / FP8 / FP4 are supported, and - the interesting one - whether the kernel set in your torch build covers that card. That last check is worth the node on its own. A card running same-major cubins instead of native kernels doesn't crash, it just behaves oddly and slowly, which is the hardest kind of problem to diagnose by feel.

It also maps the P2P and NVLink links between GPUs, spots Grace / aarch64 hosts, and ends with a list of which multi-GPU modes this machine can actually run.

Then there's the part that's genuinely clever. The node has exactly one input, probe_backends (on by default), and turning it on makes it spawn a subprocess and really create a NCCL / gloo process group instead of reading a capability flag and trusting it. That distinction matters, because OS-level capability reporting lies. A current Windows build reports is_nccl_available() as false and then fails to create a gloo device anyway - makeDeviceForHostname(): unsupported gloo device - so "does this box have working collectives" is a question you want answered before you spend a weekend on a multi-GPU plan. The probe costs a few seconds and the answer is cached until ComfyUI restarts.

The two outputs

summary is the human-readable report, the same text the node prints on itself. report_json is that report structured, for diffing two machines or keeping a record of what a rented host actually gave you. Both are plain strings - you don't wire these into a sampler. If you want them out of the graph, hang a text display node off one.

Because it's registered as an output node, it runs with nothing connected downstream, which is exactly how a diagnostic should behave: drop it in, hit Run, read the report.

Installing it

ComfyUI Manager → search CustomNodePacks, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Code2Collapse/ComfyUI-CustomNodePacks.git

Then read requirements.txt before you run it, and this is where people get burned. The README's dependency table lists opencv, scipy and safetensors and calls the rest optional, but the file that actually installs also pulls timm, einops, huggingface_hub, ftfy, regex, cryptography>=41 and opencolorio>=2.6. Running the whole thing into a healthy ComfyUI is a fine way to acquire a torch-versus-numpy mismatch, which is the classic way this ecosystem eats an afternoon. Check first, install only what's missing:

pip list | grep -i "opencv\|scipy\|safetensors"

Restart and confirm the pack loaded. The pack prints a long line: [C2C] CustomNodePacks: 115 nodes loaded (… C2C Distributed 2 …) - 0 failed. No line at all means an import failed higher up and nothing registered.

Where people get burned

The node lives under 🐺 C2C › 🧰 Core › Distributed, which is not a menu anyone visits while hunting for a utility node. Use the search box.

If you just changed your driver or your torch version and the report still says what it said before, restart ComfyUI - the backend probe is cached for the life of the process, so a stale "no" outlives the fix.

Both distributed nodes respect a C2C_DISTRIBUTED=off environment variable, and if something in your environment set it (a testbed, an inherited container), the node refuses with that reason instead of reporting.

And the honest limit: this tells you what the hardware and runtime can do. It won't tell you which mode is worth your time. Keep the author's own status line in mind when you plan around it - the speed-up from the pack's split node has not been measured yet, because measuring it needs a machine with two or more GPUs. Reading the inventory is step one, not the payoff.