February 2026 archive: measuring memory pressure by workflow stage
A workflow's peak memory demand can occur while loading, sampling, decoding or enhancing an output. Diagnose the failing stage and define the measurement before changing settings; otherwise a lower number can reflect a different workload rather than a genuine improvement.
Start with a stage map
Save the original graph and identify its required path from inputs to the final file. Mark optional adapters, decoding choices and enhancement stages. Record the first failure and its error message before assuming the whole workflow is too large for the device.
Keep model identity, output dimensions and batch settings alongside that map. A small preview can help isolate a problem but is not equivalent to the intended deliverable. Make any reduced condition explicit so a successful diagnostic run does not become a misleading production claim.
Name the measurement and its boundary
Device diagnostics and framework instrumentation answer different questions. NVIDIA's management interface describes device observations; PyTorch's maximum-memory-allocated function reports a peak for tensor allocations managed by its allocator. Neither should be relabelled as additional physical memory capacity.
Record the tool, units and interval observed. Include other processes using the device and distinguish allocated memory from reserved or device-wide readings. Do not add these overlapping views together. If sampling is intermittent, acknowledge that a short peak may not appear in the recorded samples.
Change one supported condition
Use maintained ComfyUI troubleshooting guidance to select a relevant change for the failing stage. Preserve a baseline and change one condition in a copy. Verify that the selected model and backend actually support the option instead of borrowing settings from an unrelated workflow.
Offloading or reduced-memory execution can trade transfer or processing time for lower device pressure. Measure completion and inspect output quality as well as memory. If a change modifies precision, resolution or enabled stages, identify that difference before comparing the result with the original workload.
Report a workload envelope, not a slogan
Repeat important cases after restart and keep failed attempts. Record the largest tested condition that met the defined acceptance criteria, not an untested maximum. A passing case establishes evidence for that environment and graph; it does not certify every model that uses the same application.
Keep the graph, source identities, measurements and output together so the conclusion can be checked. This archive does not claim that software doubles installed VRAM or that a particular device always achieves a fixed speedup. Its method produces a bounded statement about a tested task and makes capacity, latency and output fidelity separate decisions.