Observe ComfyUI memory use before changing the workflow
An observer is useful here as a diagnostic habit, not as an undocumented ComfyUI node that automatically fixes memory pressure. Record what the workflow is doing when usage rises, then test a specific intervention against the unchanged baseline.
Define the observation record
Keep the graph, input files and model identities with a chronological log of the run. Mark when loading begins, sampling begins, decoding begins and the output is saved. This lets a memory observation refer to a real stage instead of an unexplained peak on a chart.
Include failed runs. The moment before an allocation failure can be more informative than the largest number in a completed run. Avoid entering sensitive prompts or personal file paths into a public bug report; make a minimal reproducible example with safe inputs.
Use two measurements carefully
A device-level monitor and a framework allocator answer different questions. NVIDIA's management-interface reference explains device statistics. PyTorch documents peak allocated tensor memory within the process. State which you used and preserve its units rather than labelling every field simply VRAM.
The observation interval also matters: a periodic external sample can miss a short peak. Do not claim exact agreement between different tools or add their values together. Record concurrent GPU applications and whether the observation came from a fresh process or a reused session.
Turn an observation into a hypothesis
If the rise occurs at image decoding, investigate that stage before changing the text encoder. If it occurs while an optional model loads, test a copy of the graph without that optional stage. The hypothesis should name the suspected component and the specific comparison that could disprove it.
Keep the original graph unchanged and vary one condition in its copy. A successful run after several unrelated changes proves only that the combination worked once. It does not establish which change mattered or whether the output still meets the original requirement.
Close the loop with evidence
Repeat a useful intervention across representative inputs and after restarting the environment. Compare the saved outputs as well as memory and completion time. Document tradeoffs when reduced memory increases waiting time or changes the visible result. A slower but reliable configuration may be appropriate for one job and unsuitable for another.
The earlier fictional observer-node framing has been replaced with this inspectable procedure. No automatic memory controller or new benchmark is claimed. Share the graph, stage log and measurement method when reporting a finding, and use the maintained troubleshooting documentation to decide which supported option to test next.