Visualize CUDAMemory History
Turn an OOM into a picture
- output_path
Most VRAM advice stops at "reduce resolution" or "use a smaller quant." This node is for the point past that - when you've already OOM'd and you actually want to know what was sitting in memory when it happened, not just that something was. It takes a CUDA memory allocation snapshot and turns it into an interactive report you can open in a browser and read like a timeline.
How it works
PyTorch has a built-in mechanism for recording exactly what your CUDA allocator is doing over time - every allocation, every free, tagged with where in your code it happened - and dumping that history to a snapshot file. On its own, that file is a raw, not-remotely-readable blob. This node's whole job is the visualization step: point it at a snapshot file and it generates and opens a browser-based report showing the allocation timeline, so you can see which tensors were live, how big they were, and where memory pressure was actually building right before things broke.
One thing worth being upfront about: producing that snapshot file in the first place isn't this node's job. You need to have triggered PyTorch's memory-history recording and dumped it to disk somehow - whether that's another debug node in your workflow, or a one-off script - before this node has anything to visualize. Its contribution starts once you already have the file.
The inputs and output that matter
Just two fields, and it's deliberately simple:
snapshot_path- the path to your CUDA memory allocation snapshot file. This is the only thing you configure.output_path- the single output, the path to the generated visualization. The node is flagged as an output node, meaning it's a terminal step in the graph - you don't wire anything downstream of it, it just does its job (opening the report in your browser) and hands back where it wrote the result, mainly for your own reference or logging.
How to install it
Part of the KJNodes pack - no separate download. Through ComfyUI Manager: search "KJNodes for ComfyUI," install, restart. Manually: cd ComfyUI/custom_nodes && git clone https://github.com/kijai/ComfyUI-KJNodes, then pip install -r ComfyUI-KJNodes/requirements.txt (portable Windows: python_embeded\python.exe -m pip install -r ...), then restart. No extra models here - this is a debugging utility, not a generation node.
Common issues & troubleshooting
Nothing opens, or the node errors immediately. Double-check snapshot_path actually points at a valid CUDA memory history file and not a typo'd or half-written path. If you haven't generated a snapshot yet, this node has nothing to work with - that step happens before you get here.
You're not sure you even need this node. If your problem is a straightforward "this doesn't fit in my VRAM," the usual first moves - dropping resolution, switching to a GGUF-quantized model, reducing batch size - solve most cases without ever touching a memory snapshot. Reach for this node specifically when you're OOM'ing intermittently or unpredictably and need to see exactly which allocation tipped you over, not just accept that something did.
The report opens but you don't know what you're looking at. This is genuinely a power-user tool aimed at people debugging custom nodes or unusual model-loading patterns, not typical end-user workflow tuning. If you're here because a normal Wan or Flux workflow OOM'd, the practical fix is almost always on the workflow side - the visualization is for when the cause isn't obvious from the error message alone.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| snapshot_path | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| output_path | STRING | — |