핵심 요약
1
샘플링은 양쪽 모두 스텝당 약 33초로 같았습니다.
2
warm 중앙값은 Comfy API 165.1초, Runpod 196.3초였습니다.
3
cold 요청은 양쪽 모두 3분에서 7분 사이로 흔들렸습니다.
4
실제 청구는 Runpod 10건 $2.14, Comfy API 9건 $2.29였습니다.
ComfyUI 워크플로를 API로 띄울 때 Comfy API에 맡기면 Runpod Serverless에 직접 올리는 것보다 얼마나 빠르고, 얼마나 더 낼까요? 실제로 쓰고 있는 MiniMax H3 얼굴 교체 워크플로를 두 곳에 같은 그래프로 올리고, RTX PRO 6000 96GB 한 장에서 cold 3회와 warm 5회씩 요청을 보내 시간과 청구액을 비교했습니다.
warm 요청은 Comfy API가 중앙값 기준 약 31초 빨랐는데요. 로그를 열어 보니 생성의 핵심인 샘플링은 두 곳 모두 스텝당 33초로 같았고, 차이는 이미지의 torch 버전과 배정된 GPU 서버에서 났습니다. 비용은 같은 GPU 단가가 정확히 1.3배 차이 났지만, 요청 한 건으로 계산하면 차이가 11% 정도로 줄었죠.
Runpod은 Comfy API 백엔드 인프라에 참여하는 출시 협업 파트너입니다. 이 글은 같은 GPU 위에서 워크플로 환경 관리를 Comfy API에 맡기는 경로와, Runpod Serverless에서 직접 관리하는 경로를 비교합니다. Runpod 쪽은 Runpod 기본 템플릿이 아니라 제가 직접 만든 이미지와 핸들러입니다.
같은 그래프·같은 시드로 맞춘 비교 조건
워크플로는 MiniMax H3 Ref2VA에 Turbo4 LoRA(4스텝)를 붙여, 5초짜리 인터뷰 영상의 얼굴과 머리만 다른 인물로 바꾸는 그래프입니다. 노드 18개는 모두 ComfyUI 기본 노드이고, 모델 다섯 개의 합계는 약 42GB입니다.
두 곳에서 실제로 실행된 그래프는 출력 MP4에 남은 실행 그래프로 대조했습니다. 파일 이름, 저장 경로, 시드를 빼면 18개 노드 설정이 모두 같았습니다.
측정은 2026년 10월 19일 21시부터 22시 13분(KST)까지 한 번에 진행했습니다. 순서는 Runpod cold 1회와 warm 5회, Comfy API cold 1회와 warm 5회, 그다음 양쪽 cold 2회씩입니다. warm 요청은 앞 요청이 끝나자마자 같은 쪽에 이어서 보냈습니다. 시간은 같은 Mac에서 요청을 보낸 순간부터 완료를 확인한 순간까지 쟀습니다.
Comfy API 준비 과정과 모델 출처 확인
Comfy API는 Comfy Org가 2026년 9월 30일에 내놓은 관리형 배포 서비스입니다. 워크플로에서 Build(ComfyUI 버전, 노드, 모델, 의존성)를 만들고, 불변 Release를 찍은 뒤, Deployment로 엔드포인트를 엽니다. Standard($20/월)부터 유료 플랜에서 쓸 수 있습니다.
이번에는
comfy CLI 1.22.0으로 진행했습니다.comfy build init --from-workflow h3-ref2va-turbo4.api.json --name h3-ref2va-turbo4
comfy build refs resolve <모델 파일 이름 5개>
comfy build validate . --remote
comfy build push
comfy build release create --target linux/nvidia --watch
comfy deploy up --gpu rtx-pro-6000-server --region anywhere --min 0 --max 1build init이 만든 첫 스펙에는 모델이 0개였는데요. CLI는 모델 네 개에 대해 "공용 카탈로그에 있지만 출처를 직접 넣어야 한다"고 안내했고, 영상 VAE 하나는 출처를 찾지 못했습니다. 이때 후보로 제시한 파일은 VAE가 아니라 다른 모드(FL2VA)의 확산 모델이었습니다.refs resolve로 다섯 파일을 찾자 모두 공식 Comfy-Org/MiniMax-H3가 1순위 후보로 나왔습니다. 영상 VAE 후보에는 이름만 같고 크기가 다른 파일이 다른 저장소에서 섞여 나와서, 공식 저장소 것을 직접 골라 넣었습니다.Runpod 쪽은 이미 운영하던 엔드포인트를 그대로 써서 같은 기준의 준비 시간은 재지 않았습니다. 이미지 빌드, 모델 캐시, 핸들러 작성은 모두 직접 했습니다.
warm 요청 31초 차이, 샘플링 밖에서 생긴 시간
warm 5회의 중앙값은 Runpod 196.3초, Comfy API 165.1초였습니다. 플랫폼이 기록한 실행 시간으로 보면 189.0초(
executionTime)와 161.3초(started_at–completed_at)이고, 생성 시작 전 대기는 0.2초와 1.1초로 거의 없었습니다.Runpod의 첫 warm 요청은 cold를 처리한 워커가 아니라 다른 워커가 받아 54.5초를 기다렸습니다. 나머지 네 번만 봐도 중앙값은 196.2초로 결론이 같습니다.
다섯 번이 모두 1초 안쪽으로 고르게 나와서 우연으로 보기는 어려웠는데요. 그래서 Comfy API의 작업 로그와, 같은 시드로 Runpod에 한 번 더 보낸 요청의 워커 로그를 비교했습니다.
샘플링은 사실상 같았습니다. 약 9초는 샘플링 앞뒤, 즉 입력 영상 VAE 인코딩, 텍스트 인코딩, 디코딩 구간에서 났는데요. Runpod 쪽 시작 로그에만
working around nvidia conv3d memory bug.라는 줄이 있었습니다. torch 2.9.1에서 ComfyUI가 3D 합성곱을 우회 경로로 돌린다는 뜻이고, 영상 VAE가 이 연산을 씁니다. 가장 유력한 원인이지만 torch를 올려 다시 재 보지는 않았습니다.나머지 약 19초는 GPU 서버 차이였습니다. warm 5회를 처리한 Runpod 워커(US-MO-2)의
executionTime은 약 189초였는데, 같은 이미지와 같은 시드로 다른 워커(US-NC-2)에서 돌리자 169.9초가 나왔죠. 핸들러의 입력 준비, 비교본 MP4 생성, base64 처리에 쓴 시간은 약 2초였습니다.cold 요청은 3분에서 7분, 대기 자리에 달린 첫 응답
요청 직전에 실행 중인 워커와 대기 중인 작업이 0인지 확인하고 보낸 결과입니다.
위 점 그래프의 빈 점이 cold 요청입니다. 클라이언트 기준으로 Runpod은 221.9, 221.8, 371.2초, Comfy API는 193.9, 418.8, 191.3초였고, 생성 시작 전 대기가 각각 24.8, 1.3, 145.2초와 14.1, 229.4, 11.3초였습니다.
두 곳 모두 워커가 0이어도 빠르게 다시 뜨는 대기 자리(idle 상태 워커)를 하나씩 들고 있었습니다. 그 자리가 살아나면 대기가 수십 초에 그쳤고, 새 GPU를 처음부터 잡으면 2–4분이 걸렸습니다. 세 번만으로 어느 쪽 cold가 빠르다고 할 수는 없고, 두 곳 모두 첫 응답이 3분에서 7분 사이로 흔들릴 수 있다고 보는 편이 정확합니다.
배포 직후나 오래 쉰 뒤의 첫 요청은 더 길었습니다. 측정 전 연결 확인용으로 보낸 첫 요청의 대기는 Runpod 127.3초, Comfy API 325.6초였습니다.
Comfy API 응답에서 작업 상태는 제출 2초 뒤부터
running이었는데, 실제 started_at은 5분 25초 뒤였습니다. 대기 시간을 재려면 상태 값 대신 작업의 타임스탬프를 봐야 합니다. 문서에 나온 metrics.queue_ms와 execution_ms는 이번 배포의 응답에 없었습니다.1.3배 단가가 요청당 11%로 줄어든 이유
네 GPU 모두 Comfy API 단가가 Runpod의 정확히 1.3배입니다. Comfy API에서 고를 수 있는 GPU는 이 네 종류이고, 가장 작은 것이 96GB입니다. 네트워크 저장 공간은 Comfy API $0.20/GB/월, Runpod $0.07/GB/월(1TB 미만)입니다.
warm 요청 한 건을 실행 시간 × 단가로 계산하면 Runpod 189초는 약 $0.183, Comfy API 161초는 약 $0.203입니다. 단가는 30% 비쌌지만 생성이 15% 빨라서 차이가 11% 정도로 줄었죠. 요청이 띄엄띄엄 들어와 매번 유휴 시간까지 과금된다고 보면, Runpod은 5초를 더해 $0.188, Comfy API는 30초를 더해 $0.241입니다.
실제 청구액은 다음 날 다시 조회했습니다. Runpod은 10건에 $2.14(GPU $2.129, 디스크 $0.011), Comfy API는 9건에 $2.29(크레딧 484)였습니다. 건당 평균에는 cold 기동, 유휴 시간, 배포 직후 뜬 워커 시간, 저장 공간이 모두 섞여 있습니다. Comfy API 구독료($20/월)는 별도이고, 이번 차감은 구독에 포함된 크레딧에서 빠졌습니다.
맡길 것과 쥘 것으로 나눈 선택 기준
모델이나 노드 버전 관리가 가장 손이 많이 간다면 Comfy API부터 시작하길 권합니다. Release가 불변이라 테스트한 환경이 그대로 배포되고, 42GB짜리 H3 워크플로도 CLI 몇 줄로 엔드포인트까지 갔습니다. 다만 모델 출처를 채우고 맞는 파일을 고르는 일은 직접 해야 했습니다.
24–48GB급 GPU로 충분한 워크플로라면 Runpod에 직접 올리는 편이 낫습니다. Comfy API의 가장 작은 GPU가 96GB여서, 가벼운 워크플로일수록 실제 단가 차이는 1.3배보다 커지기 때문이죠. 요청·응답 형식을 바꿔야 하거나 ComfyUI가 아닌 작업을 같은 곳에서 돌리는 경우도 마찬가지입니다.
이번처럼 96GB가 필요한 무거운 워크플로라면 요청당 비용 차이는 11% 안팎이었습니다. 이 경우에는 이미지의 torch 버전과 의존성을 직접 최신으로 유지할 시간이 있는지를 먼저 보고 고르면 됩니다. 이번 측정에서도 오래된 torch가 요청마다 약 9초를 더 쓰게 만든 것으로 보였거든요.
같은 기준으로 다시 재 보기
측정 스크립트와 그래프, Comfy API Build 스펙, 개별 실행값은 OMG Runpod Media 레시피 06에 있습니다. 글의 근거를 나중에도 확인할 수 있도록 병합 커밋에 고정한 링크입니다.
scripts/bench.py: 한 요청을 보내고 클라이언트 시간과 플랫폼 응답 원문을 저장합니다.scripts/run_matrix.py: cold 전에 워커 0을 확인하고, cold 3회·warm 5회 순서로 실행합니다.workflows/h3-ref2va-turbo4.api.json: 두 곳에 보낸 그래프입니다.comfy-build/comfy-build.yaml: Comfy API에 올린 Build 스펙입니다.results/runs.csv: 이 글의 개별 실행값입니다.
Runpod 쪽 스크립트는 제가 만든 핸들러의 입력 형식을 가정하므로, 직접 구축한 엔드포인트에 맞게 요청 형식을 고쳐 써야 합니다.
Comfy API는 상태 스냅샷이 약 5분마다 갱신돼서 cold 전 확인에 몇 분씩 걸릴 수 있습니다. 측정이 끝나면 Deployment와 Build를 모두 지워야 저장 공간 과금이 멈춥니다. 배포만 멈추면 Build의 저장 공간은 계속 과금됩니다.
자주 묻는 질문
Comfy API와 Runpod Serverless 중 어느 쪽이 더 빠른가요?
이번 H3 워크플로에서는 warm 요청 중앙값이 Comfy API 165.1초, Runpod 196.3초였습니다. 다만 샘플링 속도는 같았고, 차이는 Runpod 쪽 이미지의 torch 버전과 배정된 GPU 서버에서 났습니다. 같은 이미지를 다른 Runpod 워커에서 돌리자 실행 시간이 약 19초 줄었습니다.
Comfy API는 Runpod보다 얼마나 비싼가요?
같은 GPU의 시간당 단가는 네 종류 모두 1.3배입니다. RTX PRO 6000 기준 $4.54와 $3.49입니다. 이번 측정에서 warm 요청 한 건을 계산하면 $0.203과 $0.183으로 차이가 약 11%였고, 실제 청구액 건당 평균은 약 $0.25와 $0.21이었습니다.
Comfy API로 커스텀 모델을 올리면 모델 출처를 직접 넣어야 하나요?
이번에 comfy build init --from-workflow로 시작했을 때는 첫 스펙에 모델이 0개였고, 출처를 직접 넣어야 했습니다. comfy build refs resolve가 후보를 찾아 주지만, 이름만 같은 다른 파일이 후보에 섞여 나와 공식 저장소 것을 직접 골라야 했습니다.
min 0으로 두면 cold 요청은 얼마나 걸리나요?
이번 측정에서는 두 곳 모두 3분에서 7분 사이였습니다. 대기 자리 워커가 바로 살아나면 대기가 수십 초였고, 새 GPU를 잡으면 2–4분이 걸렸습니다. 배포 직후 첫 요청의 대기는 Comfy API에서 325.6초였습니다.