The visible workflow describes the image. The hidden runtime decides what the machine can afford to make.
ComfyUI is not mainly a box-and-wire interface for diffusion models. It is an inference runtime whose schedule happens to be visible. The graph tells the engine which components a result needs, which outputs can be reused, and which expensive object should occupy fast memory next. Treat it as a drawing tool and the canvas looks complicated. Treat it as a memory schedule and the design starts to explain itself.
That distinction matters more as visual models stop arriving as one checkpoint. A current image workflow can include one or more text encoders, a diffusion transformer, a VAE, ControlNet or reference-conditioning models, LoRAs, an upscaler, and intermediate latents. Those parts do not all perform their heaviest work at the same moment. ComfyUI’s separate diffusion-model, text-encoder, and VAE loaders expose that decomposition instead of hiding it behind one pipeline call.
The graph therefore describes more than data flow. It describes residency opportunities. Text encoders can prepare conditioning before the denoiser performs its repeated sampling steps. The VAE can wait until the latent is ready to decode. An upscaler belongs after the first image exists. A runtime that understands those dependencies can keep the active component on the GPU, move inactive weights to system memory, and reclaim space for the next stage.
ComfyUI exposes several coarse memory modes, but the current defaults have moved beyond the old advice to launch everything with --lowvram. The official startup reference says Dynamic VRAM is automatic on NVIDIA and ROCm 7.14 or newer. NVIDIA also gets asynchronous weight offload by default. --reserve-vram holds capacity back for the operating system and other software, while --disable-smart-memory forces more aggressive offload instead of retaining models in VRAM (ComfyUI startup flags). Those controls change placement policy, not the mathematical job the graph requests.
Current stable core makes storage part of that policy. ComfyUI v0.37.0, released September 21, ships Aimdo 0.5.5 and automatic fast-disk detection. The merged implementation can prefer disk-backed Dynamic VRAM loading for a model on sufficiently fast storage instead of first consuming RAM for an unpinned buffer. Its test evidence spans several GPUs and visual workloads, but those numbers remain project-reported results for specific machines. The architectural point is narrower: an NVMe device can become a lower memory tier when the transfer path is fast enough, while a slower model drive can still receive RAM priority.
That is the same hierarchy local text inference keeps rediscovering. VRAM is the fast working set. System RAM is a larger staging tier. Fast storage can hold weights that do not deserve permanent RAM residency. The graph gives ComfyUI information a generic sequential script often throws away: which component is needed now, which dependency comes next, and which branch will never execute for this output.
Partial graph execution extends the idea from weights to work. ComfyUI’s stable README states that a repeated graph executes only the parts that changed and the nodes that depend on them. Change the final upscale branch and the engine can reuse upstream results instead of running text encoding and denoising again. Keep the graph identical and the second submission can resolve from cached outputs. The current executor implements input-signature caches plus classic, LRU, RAM-pressure, and disabled cache modes (ComfyUI execution source).
Cached computation and resident weights are different budgets. A cached image, latent, or conditioning output can save execution while consuming RAM or VRAM. A loaded model can avoid transfer while leaving less headroom for the next component. The startup flags make the trade explicit: --cache-none lowers memory use by re-executing every node, while an LRU cache retains a chosen number of node results and may use more memory. The best setting depends on whether the workflow repeats expensive branches or changes nearly everything on every run.
Quantization adds another budget, though the support boundary needs careful wording. ComfyUI core can load diffusion weights and text encoders as separate components, and the built-in diffusion loader exposes lower-precision weight choices such as FP8. GGUF diffusion loading is still commonly supplied by the separate ComfyUI-GGUF custom-node project, which calls itself work in progress and replaces the stock diffusion or text-encoder loader with quant-aware variants. A smaller file or lower-bit tensor can improve fit. It does not prove identical output quality, backend compatibility, or faster generation after dequantization and transfer costs.
The custom-node distinction is operational, not cosmetic. ComfyUI core, its frontend, the desktop shell, model files, and third-party nodes can move on different release trains. The core README warns that commits outside stable tags may break custom nodes. Pinning a working visual pipeline therefore means saving the workflow, the core version, the custom-node revisions, model hashes, precision choices, and launch flags. A JSON graph without its runtime environment is only half a reproduction.
The current stable versions make that separation unusually visible. Core is v0.37.0, while Comfy Desktop v1.1.3 shipped September 25 from the newer desktop repository. Desktop simplifies installation and environment management; it does not collapse every component into one version number. Record both when diagnosing a change. A workflow that worked yesterday may have the same nodes and different memory machinery underneath them.
Offline operation also needs a precise boundary. ComfyUI core can run fully offline and says it downloads nothing unless requested. Launching with --disable-api-nodes disables optional paid API nodes and keeps built-in execution local (ComfyUI v0.37.0 README). Custom nodes can add their own network behavior, and model installation still requires acquiring files somehow. “Runs locally” describes the selected execution path, not an automatic audit of everything installed in the graph.
Dynamic placement brings real failure modes. The open Dynamic VRAM issue #15255 documents Windows CUDA failures in pinned host-buffer transfers, including multi-GPU configurations where reported free VRAM did not explain the crash. Maintainers list restricting ComfyUI to one GPU or disabling pinned memory as workarounds for affected systems. That issue does not invalidate Dynamic VRAM. It does invalidate treating a successful load or a free-memory reading as proof that the transfer path is stable.
I would evaluate a ComfyUI workflow the same way I evaluate a text runtime. Fit means the whole graph completes at the intended resolution, batch size, and precision without exhausting VRAM or RAM. Speed means cold and warm end-to-end time meet the workflow’s limit, including component loads and VAE decode. Quality means the chosen quantization, sampler, step count, and decode path pass a repeatable visual acceptance set. One generated image can establish none of those by itself.
The useful measurement unit is the graph revision. Change one placement or precision decision at a time. Record peak VRAM and RAM across text encoding, sampling, decode, and upscale rather than sampling one moment after completion. Time the first run after launch, a warm repeat, a prompt-only change, and a late-branch change. Those four cases reveal what the scheduler kept resident, what the cache reused, and what the graph forced it to repeat.
ComfyUI earns its complexity when the graph becomes a resource plan instead of decoration. Every loader names a component. Every edge defines when its output becomes necessary. Every cache hit avoids work, and every offload buys capacity with transfer time. The node graph is the part you edit. The memory schedule is the product you are actually running.
If this was useful, forward it to one engineer who needs less noise in their feed.