XB 📊 硬件监控面板 (Memory Visualization)

If you've ever sat there watching a generation die to an OOM and wished you could see the VRAM climbing before it happened - this is the node. XB_MemoryVisualization is XB_ToolBox's port of Kijai's ComfyUI-MemoryVisualization: a live, draggable hardware monitor that appears in the bottom-right corner of ComfyUI the moment the app starts. It shows GPU VRAM, RAM, temperatures, disk I/O, and a history graph, with shortcut buttons to unload models and clear cache.

The first thing to understand is that this node does almost nothing itself. The panel auto-loads on startup whether or not it's in your workflow. Dropping the node into a graph just gives you an anchor - a way to find it in the node list and a spot in the workflow where its "unload / clear cache" shortcuts can be triggered. The description on the node says it plainly: "the panel auto-shows at startup; this input only triggers node execution." It's a marker.

What the panel shows

Straight from the pack's own manual, the panel tracks:

• VRAM - usage split into model / torch / cache segments, with a peak number.
• RAM - system memory, process memory, pinned memory, page file.
• GPU - utilization, temperature, power draw (full on NVIDIA; on AMD it needs the LibreHardwareMonitor bridge).
• CPU, disk I/O, per-model memory breakdown, plus a VRAM history chart with area/bar/K-line/dot styles.

Right-click the panel for font size, scaling, and options; the model list even shows each loaded model's VRAM footprint, which is gold when you're trying to figure out which of your three loaders ate the card.

Install - the part where the README lies to you

The pack README swears "no extra pip dependencies! plug and play." The manual that ships with this node tells the real story:

pip install psutil pythonnet        # pythonnet drives the .NET bridge on Windows

and for AMD GPU telemetry you also need the .NET Windows Desktop Runtime 10.0.10 installed on the system, because the panel reads AMD sensors through the bundled LibreHardwareMonitorLib.dll via pythonnet. NVIDIA users get precise per-device VRAM numbers from an optional pip install nvidia-ml-py.

So the honest install for the full experience on an AMD box is: XB_ToolBox via Manager or git clone, then psutil + pythonnet + the .NET runtime. On plain NVIDIA, psutil alone gets you most of the dashboard and nvidia-ml-py makes the VRAM numbers exact. Without pythonnet, the panel still loads but AMD GPU sensors go quiet.

Common issues

• Panel never appears - check the ComfyUI console for an import error. The pack deliberately swallows missing deps (tkinter, pythonnet) so the rest of the pack still loads; the panel is the thing that silently doesn't.
• AMD shows no GPU temp/power - pythonnet or the .NET runtime is missing. The LibreHardwareMonitor DLL ships in the pack folder, but it can't run without the .NET runtime installed system-wide.
• "Current integration pack lacks a dialog dependency" - that's the folder-picker fallback path, unrelated to this node but a common console log on Chinese all-in-one packs; ignore it.
• It's using memory you didn't ask for - yes, a monitor costs a little CPU. If you're running on a potato and every cycle counts, uninstall the pack or disable the panel; the monitor is a convenience, not a necessity.

Where it fits

It's a debugging tool, not a workflow node. Keep one in a scratch workflow you open when something OOMs, or wire its any_input off a sampler so the "unload models" button is live right before a heavy generation. For the "why did my 14B video model die" class of problems, being able to watch cache fragmentation climb in real time beats guessing.