ComfyUI 이미지·영상 생성, 직접 써본 실측·한계

ComfyUI로 이미지·영상을 우리 운영 풀에서 직접 굴려본 결론은 한 줄로 "강점이 곧 한계"다. 노드 그래프라 뭐든 조립되지만 그래서 잘 깨지고, GPU가 커도(약 96GB) 모델 상주(residency)가 천장을 먼저 먹는다. 실측이 그대로 보여준다: 같은 96GB 카드 4장인데 idle 상태에서도 한 장은 86.8GB가 차 10.5GB만 남았고, 워커는 여유 VRAM 24GB가 없으면 작업을 아예 안 받는다. 즉 '큰 GPU=항상 큰 작업 가능'이 아니다.

한 줄 요약: ComfyUI는 노드 그래프라 무엇이든 조립되지만 그만큼 잘 깨지고, 96GB GPU라도 모델 상주가 여유 VRAM을 먼저 잡아먹어 '용량'이 아니라 '여유'가 진짜 천장이며, 워커는 여유 24GB 미만이면 작업을 거절한다.

쉽게 말하면: ComfyUI는 레고다. 블록(노드)을 마음대로 끼워 무엇이든 만들지만, 블록 하나가 안 맞으면 전체가 안 선다. 그리고 작업대(VRAM)가 넓어도 이미 펼쳐둔 모델이 자리를 차지하면 새 작업을 펼 공간이 없다.

우리 comfy-pool GPU에서 실측한 VRAM 상주는?#

Hax가 자체 comfy-pool(RTX PRO 6000 ×4, 카드당 95.6 GB)에서 직접 측정한 값입니다(측정 스냅샷, 2026-07-04).

ComfyUI 풀은 실제로 어떻게 돌고 있나?#

이미지·영상·오디오·3D를 한 풀에서 돌린다. 실행 가능한 워크플로가 22개로, 대부분 이미지 생성(z-image·qwen-image·HiDream·FLUX2 등)이고 영상(LTX·Wan 이미지투비디오), 오디오(ACE-Step), 3D(Hunyuan 이미지→모델)도 섞여 있다. 하드웨어는 RTX PRO 6000 Blackwell 96GB 4장, 워커당 동시성은 1이다(무거운 한 작업이 GPU 한 장을 점유). 큐 누적은 성공 113·실패 12·취소 21건이었다 — 보기와 달리 100%가 아니다.

아래 막대가 96GB 한 장의 실측 단면이다. 이미 대부분이 상주 모델로 차 있어 새 작업이 쓸 여유가 얼마 없다.

가장 큰 한계는 무엇인가?#

VRAM은 '용량'이 아니라 '여유'가 천장이라는 점이다. 큰 모델(FLUX·영상 모델)은 통째로 올라가 수십 GB가 상주하고, 우리 풀은 재로딩을 피하려 모델을 상주시켜 둔다 — 그래서 idle에도 VRAM이 차 있다. 장점(웜 상태라 빠른 시작)과 단점(놀고 있는데도 VRAM 점유)이 동전의 양면이다. 게다가 워커는 min_free 24GB 가드를 둬, 여유가 부족하면 작업을 거절한다(OOM으로 죽는 것보다 낫다). 결론: 모델을 무한히 동시에 올릴 수 없고, 무엇을 상주시키고 무엇을 내릴지가 운영의 핵심 결정이다.

상주의 웜 시작(장점)과 VRAM 점유(단점)는 같은 선택의 양면이다. 그림으로 보면 명확하다.

왜 100%가 아닌가?#

실패·취소가 정상 운영의 일부이기 때문이다. 누적 실패 12·취소 21의 원인은 보통 ① OOM(해상도·배치·영상 프레임이 VRAM 초과), ② 노드 그래프 깨짐(빠진 커스텀 노드·체크포인트), ③ 더 새 작업이 와 기존 작업 취소다. 또 같은 풀인데 compute가 6배까지 벌어진다 — 터보 워크플로는 8스텝(cfg 1), 풀퀄은 50스텝(cfg 4~5)이라 "ComfyUI가 빠르냐 느리냐"는 워크플로를 말하지 않으면 무의미하다. 영상은 프레임 수만큼 더 무겁다. 작은 함정도 있다: 일부 모델은 네거티브 프롬프트를 중국어로 받아야 잘 듣는다(모델 출신에 따른 특성).

터보와 풀퀄은 같은 풀에서도 스텝이 약 6배 벌어진다 — 속도를 말할 때 워크플로를 빼면 무의미하다.

그래서 어떻게 잘 쓰나?#

핵심은 '유연함'과 '자원'을 따로 관리하는 것이다.

• 자원: 여유 VRAM부터 본다. 상주 모델을 정리하고, 무거운 작업(영상·고해상도)은 전용 GPU 한 장에 몰아 직렬화한다.
• 안정: 워크플로는 노드·모델 의존성을 고정하고(빠진 노드=전체 실패), 같은 시드로 재현성부터 확인한다.
• 속도: 터보(8스텝) vs 풀퀄(50스텝)을 작업 목적에 맞춰 고르고, 벤치보다 내 프롬프트로 직접 측정하라.

참고 링크

• ComfyUI(노드 기반 생성 엔진)
• ComfyUI-Manager(커스텀 노드·의존성)
• FLUX(이미지 생성 모델)
• LTX-Video(로컬 영상 생성)
• Qwen-Image(이미지 생성·편집)

참고: 수치는 2026년 우리 풀의 실호출 스냅샷이며 워크로드·모델 구성에 따라 매 순간 달라진다(영구 수치 아님). VRAM 점유·성공률·스텝 수는 워크플로·해상도·영상 길이에 좌우되니, 정확한 속도·품질은 내 워크플로로 직접 재라(여기 수치는 출발점). 모델·노드 생태계는 빠르게 바뀌니 분기별로 다시 본다.