Model Info

Model Info looks at whatever model is on a wire and tells you what it is and how big it is: the class behind it (SDXL or AutoencoderKL), the precision its weights are held at, the device it runs on, and its parameter count. Tap it onto any MODEL, VAE, CLIP, ControlNet, or upscale-model wire and it reads the object without loading anything or moving it onto the GPU. It's the "is this actually what I think it is?" node, and it doubles as a self-documenting label maker for your renders.

It's a WAS Node Suite utility (WAS Suite/Utilities) - the sort of quiet diagnostic node that earns its keep the first time you debug a wrong-model problem.

How it works

One input, model, which accepts anything a loader answers on a single socket - MODEL, VAE, CLIP, CLIP_VISION, CONTROL_NET, UPSCALE_MODEL, STYLE_MODEL, and the rest. The wire is read, not changed. Six outputs come back:

• kind - the class behind the wire, which names the family: SDXL or Flux for a checkpoint, AutoencoderKL for a VAE, RRDBNet for an upscaler. A LoRA arrives as a plain dict, which is itself a useful sanity check.
• dtype - the precision the weights are held at: float16, bfloat16, float32, float8_e4m3fn. Empty where the model doesn't say.
• device - where the weights run: cuda:0, cpu, mps. For a loader that offloads, this is the device it loads onto when it runs, not where it parks between runs.
• parameter_count / parameter_millions - the weight count element by element (around 860 million for an SD1.5 checkpoint, 2.6 billion for SDXL) and the same figure in millions. Test against parameter_millions when you want a threshold check that reads cleanly.
• summary - every figure on one line, like SDXL, float16 on cuda:0, 2567.46M parameters. Wire it to Display Any or into a filename prefix to label a render with what made it.

Why you'd reach for it

Two genuinely useful jobs. First, debugging the model on a wire: the classic "why does my output look like SD1.5?" - where you thought you wired an SDXL checkpoint - gets answered in one glance at kind. The dtype output catches the other silent failure: a checkpoint that loaded at full float32 precision when you wanted half, which doubles its VRAM footprint without any error message. Second, render provenance: baking summary into the saved filename means every output file tells you its model, precision, and device - no more guessing from the render itself.

It reads without loading or offloading, so dropping it into a graph costs you nothing and can sit there permanently as an inspection tap.

Installing it

Part of WAS Node Suite v3 - ComfyUI Manager search "WAS Node Suite v3", or:

cd ComfyUI/custom_nodes
git clone https://github.com/WASasquatch/was-node-suite-comfyui.git

restart. ComfyUI 0.14.0+, Python 3.10+, no extra pip dependencies.

Where people get burned

The main thing to keep straight is what kind reports: it's the class behind the wrapper, not the filename. Two different checkpoints that are the same architecture both read SDXL, so this node confirms the type on the wire - it won't tell you which fine-tune you loaded (that's a file-naming question, not a runtime one). And for a LoRA, kind comes back dict because a LoRA on the wire isn't a model object until it's applied - that's expected, not a bug. Empty strings on dtype or device just mean the model doesn't advertise them; don't read them as failures.