A Workflow Meets the Real World
A ComfyUI workflow can be logically unchanged while its physical execution changes. This chapter examines the runtime around the graph: how model residency, memory pressure, device choices, server boundaries, extensions, and saved artifacts affect what the graph can deliver. The practical judgment is one of ownership. The graph declares the work and its dependencies; the model runtime decides how to fit that work onto hardware; the server exposes it to clients; and extensions and files add capabilities with their own trust and reproducibility assumptions.
Logical sameness does not mean physical sameness
The graph describes which model, conditioning, latent, and output relationships should be used. It does not dictate where every model weight must live while those relationships are being evaluated. ComfyUI wraps model objects in a ModelPatcher that tracks a load device and an offload device, along with patches, clones, hooks, wrappers, and model options. That wrapper is the point where a logical model in the graph meets the physical state of a device.
When execution requests models, the runtime compares the requested objects with models already loaded. It deduplicates the requested models and any models required by model patches, calculates the memory they need, and can free or unload competing models before loading them. A model can be fully resident, partially loaded, or moved toward an offload device depending on the available memory and the selected VRAM policy. The runtime keeps track of total model size, the portion currently loaded, and the portion currently offloaded. These are operational states of a run, not new meanings in the saved graph.
That distinction explains a common surprise. Two prompts can have the same node structure and the same declared parameters, yet one can fit comfortably while another needs more memory because its image dimensions, batch, model family, or intermediate tensors are different. A graph that reuses an earlier node result can still need memory to execute a later model operation. Conversely, a graph that looks more elaborate may avoid loading a branch that the selected output does not require. Logical dependency and physical residency interact, but neither fully replaces the other.
ComfyUI exposes several ways to make that interaction explicit. A CPU mode runs the workload on the CPU, typically at a speed cost. High-VRAM or GPU-only choices favor keeping more of the working state on the accelerator. Low-VRAM and no-VRAM modes trade residency for the ability to process workloads on constrained devices, using partial loading or more aggressive movement of weights. Dynamic VRAM and asynchronous offload add different runtime strategies. The right choice depends on the workload and hardware; the presence of an option is not evidence that it is faster or more stable in every case.
Model patching adds another layer of controlled change. A node may apply a LoRA, a hook, a wrapper, or another patch to a model without replacing the entire workflow role that consumes it. The patcher keeps the model options and patch state with the model object, and the memory manager accounts for the objects that must be present. This is one reason a small visual change can have a larger physical consequence: a new model option can require additional state, different device placement, or a different amount of a model to be resident.
Quantization approaches the same constraint through representation.