Debug: Model Metrics

The name is the whole pitch: this is a dead-end probe you hang off a MODEL wire to see what's actually inside it. ComfyUI hands you a lot of opaque objects - a checkpoint loaded through a loader looks identical in the graph whether it's a 860M SD 1.5, a 2.6B SDXL, or a 12B Flux. Debug: Model Metrics is the node that tells you which one you really got, at what precision, and what sampling family it expects. No API, no key, no downloads - it's about fifty lines of pure Python that read the model object and print a five-line receipt.

It's the smallest, most useful kind of debug node: a terminal you can plug into anything. Grab the MODEL output from a CheckpointLoader, UNETLoader, or a GGUF loader, hit run, and the report lands in the node's output box.

What the report tells you

• Base - the latent format class, so SDXL, Flux, SD15, SD35, or similar. This is your "what architecture is this checkpoint really" answer, which matters more than you'd think once people start renaming files.
• dtype - what the weights are held as in memory: float16, bfloat16, float8_e4m3fn, and so on. This is the line that tells you whether the fp8 load actually stuck or silently fell back.
• Parameters - total count in billions. Flux is ~12B, SDXL ~2.6B, SD 1.5 ~860M. Great for sanity-checking a merge or a suspicious download.
• Model Type - the prediction family, usually EPS for SD 1.5/SDXL-era models and FLOW for Flux/SD3.5-class ones.
• Size - how much the loaded model weighs, human-readable.

How it works

Mechanically it's dead simple, which is exactly why you can trust it. The MODEL input is ComfyUI's patcher object; the node digs into the wrapped model and reads a few attributes: the latent format class for the base, the summed parameter count (sum(p.numel() ...) over the weights), get_dtype() for precision, and the model type enum. It's an output node (OUTPUT_NODE), so it terminates - don't expect to wire its result onward.

The one thing that will confuse you on first glance is the output input. It's a required STRING widget, so it looks like something you're supposed to type into. You're not. Leave it empty. It's a display hack: the pack ships a tiny bit of JavaScript that listens for ComfyUI's executed event and pastes the report into that widget after each run. Same trick a lot of "text out" debug nodes use.

Install

Two ways, both painless. Via ComfyUI Manager: Install Custom Nodes → search ComfyUI-Debug (searching just "debug" works but matches half the registry, so filter by author liusida). Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/liusida/ComfyUI-Debug

Then restart ComfyUI. That's it. There's no requirements.txt, no model files, no CUDA pins - this pack won't drag you into dependency hell. It's MIT-licensed and hasn't changed since April 2024, which for a tool this simple is a feature, not neglect.

Gotchas worth knowing

• The report only fills in after you actually run the graph, not when you wire it up.
• The dtype line is the in-memory precision, not necessarily what's stored in the file. A GGUF quantized to Q4 dequantizes on load, so dtype reflects what's sitting in VRAM - which is arguably the number you care about.
• If you're on AMD chasing black images or bf16 NaN crashes, this node is genuinely useful: it tells you what precision you're actually running in, which is half the battle in those debugging sessions.
• Model Type is a sampler hint: FLOW wants flow-matching samplers, the EPS/V_PREDICTION families want the classic schedulers.

There are fancier packs that annotate models in the graph or pretty-print layer stats. For "what the hell did I actually load," this is the one I'd reach for - it's one wire, one run, and it never lies.