# ComfyUI GPU requirements depend on the entire workflow

Choose a GPU for ComfyUI using the complete workflow, model and node versions, resolution, batch and memory peaks across generation and decoding.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/comfyui-gpu-requirements/
Language: en

Choose a ComfyUI GPU for a specific workflow: models, resolution, batch size and additional processing nodes. The interface does not define one minimum card for every task. Generating a simple image does not establish capacity for a larger graph with upscaling, extra models or video processing.

## Save the complete graph

Preserve the workflow along with model files and revisions, custom-node versions and the software environment. A graph file without its dependencies may not reproduce on another server. Record any external inputs needed by the control task and ensure they can be used in the pilot.

Keep a small known workflow separate from the target graph. The first checks the basic environment; the second tests the actual requirement. A failure introduced by an additional node should not automatically be attributed to the GPU model or to ComfyUI itself.

## Identify memory consumers by stage

| Workflow part | What to record | Requirement to test |
| --- | --- | --- |
| Main model | Exact file and representation | Weight placement |
| Text encoder | Model and device | Additional memory |
| Generation | Image size and batch | Working-data peak |
| Decoding | VAE configuration | A different stage's peak |
| Extra nodes | Versions and order | More models and intermediates |

Observe the complete pass, not only model loading. A graph can pass sampling and fail later while decoding the result. Keep timestamps with memory observations so the peak is associated with the responsible stage.

## Verify the supported environment

ComfyUI's system requirements distinguish installation and hardware routes. Support for the base environment does not guarantee every third-party node works on every card. Check the relevant node's dependencies and preserve its version when reporting a result.

Start with a cleanly described setup rather than a collection of undocumented extensions. Change one dependency at a time when diagnosing the graph. If precision, memory management or a node changes, repeat the control output and review usefulness alongside memory.

## Compare first and repeated runs

Measure initial loading separately from a repeated pass with the environment ready. Then test a sequence of representative jobs, including the larger input or batch the task actually needs. Record errors, peak VRAM, RAM and complete time to a saved output.

The resulting profile should state the tested graph and its boundary, rather than a universal claim about the card. That supports a concrete pilot and helps an operations partner relate additional resources to an observed stage of the task.

Official references: [github.com — ComfyUI](https://github.com/Comfy-Org/ComfyUI), [docs.comfy.org — system requirements](https://docs.comfy.org/installation/system_requirements).

Related guides: [A GPU OCR pipeline for a 1,000-page PDF workload](/journal/pdf-ocr-gpu-pipeline/), [ComfyUI offloading: when moving data to RAM helps](/journal/comfyui-gpu-offload/).