VRAM / Model Size Estimator 📐

There's a specific, miserable failure mode in ComfyUI: you queue a big render, wait through model loading and a few denoise steps, and then the run dies on an OOM. The VRAM / Model Size Estimator exists to catch that before you queue. Point it at your checkpoint and up to four LoRAs, and it reads the file headers and hands back a floor estimate of what the stack will cost in VRAM.

The key word is floor. The docstring is explicit: it's a sanity check, not a guarantee. It has no visibility into batch size, your attention implementation, gradient checkpointing, or ComfyUI's own dynamic offloading - all of which move real usage around. Think of it as "roughly how much does this model weigh," which is the question that answers most OOMs before they bite.

How it works

It reads only file headers and sizes - no model load, so it's instant even on a 12GB checkpoint. For safetensors files it parses the header's tensor shapes and sums up a parameter count; for .ckpt files it falls back to on-disk size. Then it converts params to bytes based on your chosen inference_dtype:

• fp16_bf16 - 2 bytes/param, the standard full-quality default
• fp32 - 4 bytes/param, ~double the VRAM, only worth it for debugging
• fp8 - 1 byte/param, half of fp16 - the KB's settled advice for Flux-class models is basically "just use it" when it fits

To that base it adds a fixed ~2GB inference overhead for the VAE, text encoder and a small activation buffer, scaled by resolution_factor - 1.0 for 512px, about 2.3 for 768, about 4.0 for 1024, since attention memory scales with pixel count.

The inputs that matter

• checkpoint_name - dropdown populated from your ComfyUI checkpoints/ folder.
• inference_dtype - pick what you'd actually load. The estimate only means something if it matches how you run.
• resolution_factor - set to ~4.0 if you're generating at 1024, not 512.
• lora_1 through lora_4 - optional dropdowns; LoRAs add their own tiny param counts. Leave None if you're not stacking.

Outputs

Three FLoats and a STRING: base_weights_gb, inference_estimate_gb (base plus overhead - the number that matters), training_estimate_gb (a full fine-tune-style figure with gradients and Adam optimizer states, mostly interesting as a "how big is this thing really" check), and report, which is the whole thing as a readable text dump including per-file line items.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/TensorVizion/OmniNodes

Restart ComfyUI; find VRAM / Model Size Estimator 📐 under TensorVizion/Model. No extra dependencies - it uses ComfyUI's own folder_paths and the standard library. Just note this is the pack's other Model submenu; a handful of files live under TensorVizion/Model while most of the category is TensorVizion/Model Utilities. This one's in the former.

Where people get burned

• Non-safetensors checkpoints get a cruder estimate. Without a header there's no param count, so it falls back to on-disk size in whatever dtype the file already is. The estimate is still useful, just less precise.
• It's a floor, and the overhead numbers are round figures. The 2GB overhead is typical for SD/SDXL-family runs, not measured for your exact architecture. On a 12GB card where the estimate says "10.9GB," that's a "probably fits" not a guarantee - try default memory flags before reaching for quantization.
• Missing checkpoint returns all zeros with an explanatory report string rather than an error. If the numbers look mysteriously empty, check the report first.

Honestly, the report STRING is the part you'll actually read - one glance and you know whether a Flux-class model plus your LoRA stack belongs on your card. It won't replace a real render test, but it beats discovering the hard way.