Model Memory Use Report Patch

This one doesn't touch what your model produces at all - it patches the model object with callbacks that print memory-usage stats during and after sampling, so instead of guessing where your VRAM is going, you can actually watch it happen in the console. It's a pass-through: MODEL in, the same MODEL out, just instrumented. Wire it in, run a generation, read your terminal.

Worth knowing why this matters at all: GPU VRAM bandwidth so far outstrips PCIe and system RAM that ComfyUI can't meaningfully substitute one for the other when you're tight on memory - the community's own shorthand is that shuffling data from VRAM to system RAM "makes it usually not worth it." So when you're right at the edge of your card's VRAM, knowing exactly when during sampling the peak happens is worth more than a blanket "lower your resolution" - it tells you whether the bottleneck is model loading, a particular sampling stage, or something growing steadily across the batch.

This is squarely a debugging tool, and it's most useful when something's going wrong that a plain OOM error doesn't explain well enough - a workflow that runs fine at one resolution and blows up at another, a multi-model pipeline where you're not sure which stage is actually the hog, or a slow VRAM creep across a batch that you suspect is a leak rather than expected usage.

The input and output that matter

There's exactly one of each, so there's nothing to configure:

• model in.
• MODEL out - the same model, patched with reporting callbacks.

Everything this node does happens as a side effect during sampling, not through any widget on the node itself.

How to install it

Standard KJNodes install: ComfyUI Manager → search "KJNodes for ComfyUI" → install, or cd ComfyUI/custom_nodes && git clone https://github.com/kijai/ComfyUI-KJNodes, pip install -r ComfyUI-KJNodes/requirements.txt, restart. No model downloads, no extra dependencies beyond the pack's own - it's pure instrumentation code.

Common issues & troubleshooting

You won't see anything in the graph. The whole point is that this reports to your ComfyUI server's console/terminal output, not to a node widget or a preview image. If you're only watching the browser tab, you'll miss it - tail the terminal running ComfyUI while your generation runs.

Placement matters. Since it's wrapping the model with callbacks, it needs to sit after your loader (and after any other model-patching nodes you're using) and before the sampler, so the hooks are actually wrapping the forward passes you care about. Stick it right before your KSampler.

It's a diagnostic tool, not a permanent fixture. The instrumentation adds real overhead - extra Python calls on every step you wouldn't otherwise pay for. Once you've found what you were looking for, take it back out rather than leaving it in a production workflow.

Pair it with StartRecordCUDAMemoryHistory if the console printout isn't giving you enough detail. That's the other memory-debugging node in this pack - where this one gives you a running commentary, that one gives you a full allocator trace you can load into a proper memory profiler afterward. Reach for this node first since it's zero-setup; escalate to the recorder when you need to see exactly which allocation is the problem.