ComfyUI Image and Video Generation: Hands-On Measurements and Limits
In short: After actually running image and video generation through our own ComfyUI pool, the verdict is one line: "the strength is the limit." The node graph builds anything, which is exactly why it breaks easily, and even a big GPU (about 96GB) finds that model residency eats the ceiling first.
After actually running image and video generation through our own ComfyUI pool, the verdict is one line: "the strength is the limit." The node graph builds anything, which is exactly why it breaks easily, and even a big GPU (about 96GB) finds that model residency eats the ceiling first. The measurements show it plainly: with four identical 96GB cards, even at idle one sits at 86.8GB used and only 10.5GB free, and a worker refuses a job outright if there is not 24GB of free VRAM. So "big GPU" does not mean "always room for a big job."
In one line: because ComfyUI is a node graph it assembles anything but also breaks easily, and even a 96GB GPU sees model residency eat free VRAM first, so the true ceiling is "free," not "capacity," and a worker refuses a job when free VRAM drops below 24GB.
In plain terms: ComfyUI is LEGO. You snap blocks (nodes) into anything, but if one block does not fit, the whole thing will not stand. And however wide the workbench (VRAM), if models already spread out take the space, there is no room to lay out a new job.
How is the ComfyUI pool actually running?#
It runs image, video, audio, and 3D from one pool. There are 22 runnable workflows, mostly image generation (z-image, qwen-image, HiDream, FLUX2, etc.) plus video (LTX, Wan image-to-video), audio (ACE-Step), and 3D (Hunyuan image-to-model). The hardware is four RTX PRO 6000 Blackwell 96GB cards, with one concurrent job per worker (a heavy job occupies a whole GPU). The lifetime queue was 113 succeeded, 12 failed, 21 cancelled - despite appearances, not 100%.
The bar below is the measured cross-section of one 96GB card: most is already held by resident models, leaving little free for a new job.
| Item | Measured | Meaning |
|---|---|---|
| GPU | 96GB x 4 (Blackwell) | big, but residency erodes it |
| Idle VRAM | one at 86.8GB used / 10.5 free | "big GPU != always a big job" |
| Guard | refuse if <24GB free | the price of OOM prevention |
| Queue | 113 ok / 12 fail / 21 cancel | ~90% of attempts succeed |
| Step range | 8 (turbo) to 50 (full) | same pool, ~6x compute |
- 표본
- 3 measured metrics (Hax /data curated)
- 측정 환경
- bench_harness.probe_comfy_gpus (bc_comfy_gpus 실측)
- 수집일
- 2026-07-04
What is the biggest limit?#
That VRAM's ceiling is "free," not "capacity." Big models (FLUX, video models) load whole and keep tens of GB resident, and our pool keeps models resident to avoid reloading - so VRAM stays occupied even at idle. The upside (a warm, fast start) and the downside (VRAM held while idle) are two sides of one coin. On top of that, a worker enforces a min_free 24GB guard and refuses a job when free VRAM is short (better than dying on OOM). The conclusion: you cannot load unlimited models at once, and deciding what to keep resident and what to evict is the core operating decision.
The warm start (upside) and the held VRAM (downside) are two sides of the same choice. It is clearer as a picture.
Why is it not 100%?#
Because failures and cancellations are part of normal operation. The lifetime 12 failures and 21 cancellations usually come from (1) OOM (resolution, batch, or video frames exceed VRAM), (2) a broken node graph (a missing custom node or checkpoint), and (3) an older job cancelled when a newer one arrives. Also, within the same pool compute spreads up to 6x - turbo workflows run 8 steps (cfg 1) while full quality runs 50 steps (cfg 4-5), so "is ComfyUI fast or slow" is meaningless without naming the workflow. Video is heavier by its frame count. A small gotcha too: some models want their negative prompt in Chinese to behave (a trait of where the model came from).
Turbo and full quality spread their steps by about 6x even in the same pool, so naming the workflow is not optional when you talk about speed.
So how do you use it well?#
The key is managing "flexibility" and "resources" separately.
- Resources: look at free VRAM first. Clean up resident models, and pin heavy jobs (video, high-res) to one dedicated GPU and serialize them.
- Stability: pin node and model dependencies for a workflow (a missing node = total failure), and confirm reproducibility with a fixed seed first.
- Speed: choose turbo (8 steps) vs full (50 steps) by purpose, and measure on your own prompts rather than a benchmark.
Reference links
- ComfyUI (node-based generation engine)
- ComfyUI-Manager (custom nodes/dependencies)
- FLUX (image generation model)
- LTX-Video (local video generation)
- Qwen-Image (image generation/editing)
Note: figures are a live snapshot of our pool in 2026 and shift every moment with workload and model mix (not permanent numbers). VRAM occupancy, success rate, and step counts depend on workflow, resolution, and video length, so measure exact speed and quality on your own workflow (these numbers are only a start). The model and node ecosystem moves fast, so this is reviewed quarterly.
Responses
No responses yet. Be the first to respond.