ProsGrow가 시간당 FLUX.2 이미지 변형 59,881장을 달성한 방법

전체 이미지 서비스가 처리 용량을 결정한다

카탈로그 팀에는 승인된 이미지 변형을 워크플로에 전달하는 서비스가 필요합니다. 서비스에는 프롬프트 인코딩, 노이즈 제거, 디코딩, API 처리, PNG 인코딩, 결과 저장이 포함됩니다. 모델 실행이 빨라지면 결과 전달을 제한하는 단계도 달라집니다.

ProsGrow는 FLUX.2 Klein 4B로 전체 경로를 측정했습니다. 동일 조건의 단일 GPU 비교에서 네이티브 NVFP4는 처리량을 32.5% 높였습니다. 다음 과제는 공유 인프라였습니다. 단일 GPU를 가장 빠르게 만든 설정이 노드 전체에 배포되자 느려졌습니다. 이 역전을 분석해 실측 시간당 이미지 변형 59,881장을 제공하는 서비스 구성을 선택했습니다.

조건을 통제한 수치 정밀도 비교

공식 NVFP4 체크포인트는 Black Forest Labs가 제공하고, ComfyUI는 네이티브 양자화 실행 경로를 제공합니다. ProsGrow는 의도한 정밀도 경로가 활성화되었는지 검증하고 워크플로를 고정해 PNG 저장까지 측정했습니다. 처리량 향상과 함께 요청 지연 시간도 24.5% 감소했습니다.

메모리 사용량 감소로 작업을 겹쳐 실행할 여유가 생겼지만 정밀도 변경만으로 노드를 충분히 활용하지는 못했습니다. 첫 NVFP4 배포에서 표본 측정한 GPU 연산 유닛 활성도는 52.5%에 불과했습니다. 이에 스케줄링과 GPU 작업 사이의 호스트 단계를 더 자세히 살펴봤습니다.

단일 GPU의 최적 설정은 노드 규모에서 뒤처졌다

ComfyUI는 워크플로 큐를 순차 처리합니다. 독립적인 상주 워커를 겹쳐 실행하면 다른 요청이 API 통신, PNG 인코딩, 파일시스템 출력을 처리하는 동안에도 GPU 작업이 계속됩니다. 단독 GPU에서는 중첩 실행을 늘릴수록 활용률과 처리량이 높아졌습니다.

노드 규모에서는 같은 경향이 이어지지 않았습니다. 모든 GPU가 동일한 호스트 자원을 놓고 경쟁하자 단일 GPU에서 가장 빠른 설정은 시간당 46,759장에 그쳤습니다. 덜 밀집된 서비스 토폴로지는 보수적인 반복 측정에서 시간당 57,540장을 기록했습니다. 낮은 전력에서 정체되는 구간은 호스트, API, PNG 또는 파일시스템 단계의 지연과 부합했지만, 추적 데이터는 특정 구성 요소 하나를 유일한 원인으로 분리하지 못했습니다.

핵심 시스템 교훈은 국소 최적이 노드 수준 최적은 아니라는 것입니다. 단일 GPU 활용률을 높이면 다른 곳의 자원 경쟁이 심해질 수 있습니다. ProsGrow는 동기화된 노드 측정을 기준으로 완료 출력, 메모리 사용량, 실행 간 변동을 함께 고려해 서비스 토폴로지를 선택했습니다.

명확히 정의한 제작 워크플로의 처리 용량

제작 워크플로에서는 한 소재의 여러 버전을 요청하는 경우가 많습니다. 이 서비스 요건에 맞춰 ProsGrow는 요청당 하나의 프롬프트에서 두 가지 변형을 생성하는 방식을 평가했습니다. 선택한 설정은 세 차례 동기화된 노드 실행의 최저값을 기준으로 시간당 59,881개 변형을 달성했습니다. 이는 이전 보수적 노드 속도보다 4.07% 높았고, 실행 간 편차는 1.61%였습니다.

처리 용량의 단위가 중요합니다. 생성된 변형 수는 서로 다른 프롬프트 수가 아닙니다. 클라이언트는 통제된 프롬프트를 재사용하고 노이즈 시드를 바꿨으며 ComfyUI 캐시를 사용할 수 있었습니다. 이 결과는 다양한 신규 프롬프트 흐름이나 요청마다 새로운 프롬프트를 인코딩하는 상황을 측정하지 않습니다.

측정한 출력 2,880개를 모두 확인했으며 지정된 오류 표식은 발견되지 않았습니다. 각 실행은 약 57초였습니다. 이는 고객 파일럿의 측정 기반 출발점을 제공하며, 지속적인 요청 유입, 대기열, 고객 수용 여부가 실제 사용 가능한 용량을 결정합니다.

처리 용량이 비용에 미치는 의미

수요와 서비스 요구 사항이 명확해지면 처리 용량을 비용 연구에 활용할 수 있습니다. 기존 $100,000 노드 및 유료 수요 10% 시나리오에서 실측 속도는 연간 52.46백만 개의 판매 변형에 해당합니다. 모델링한 연간 인프라 비용 약 $40,058을 적용하면 판매 변형당 $0.000764입니다.

이 시나리오는 3년 감가상각, 연간 유지보수 5%, 연간 8,760시간, 전력 단가 $0.10/kWh, 전력 사용 배수 1.30, 서버 유휴 전력 1.016 kW 및 활성 전력 6 kW를 가정합니다. 인건비, 사업 운영, 네트워킹, 스토리지, 서비스 예비 용량은 제외합니다. 구매 결정에 적용하기 전에 수요와 출력 승인율을 검증해야 합니다.

선택한 설정에서는 호스트와 냉각을 제외한 이미지당 GPU 보드 에너지 0.0571 Wh도 측정했습니다. 두 수치 모두 반복 프롬프트와 두 변형 생성 조건에 연결됩니다. 호스팅 서비스와의 품질 또는 비용 동등성을 입증하지는 않습니다.

프로덕션 운영 설정 선택

일괄 제작 워크플로에서는 시간당 승인된 변형 수가 유용한 목표가 될 수 있습니다. 대화형 도구는 낮은 요청 지연과 급증하는 트래픽을 처리할 여유도 필요합니다. 워커 중첩은 메모리와 공유 호스트 용량을 소모하므로 입력 처리, 저장, 재시도, 목표 요청 유입률을 위한 여유를 남겨야 합니다.

측정 과정은 수치 정밀도 검증을 서비스 프로파일링 및 노드 수준 검증과 연결합니다. 고객의 다음 결정은 분명합니다. 대표적인 프롬프트 조합에서도 필요한 품질과 전달 기한을 충족하며 용량 향상을 유지하는가? 이것이 전용 엔드포인트 규모 산정의 근거입니다.

방법론 및 한계

• 하드웨어 및 소프트웨어: RTX PRO 6000 Blackwell GPU 8개를 장착한 노드 1대, GPU당 공칭 메모리 96 GB, ComfyUI 0.32.0, comfy-kitchen 0.2.30, PyTorch 2.11.0, CUDA 13.0을 사용했습니다. NVFP4 체크포인트 리비전은 1db2b2f7입니다.
• 워크로드: FLUX.2 Klein 4B, 1024×1024 출력, Euler 4단계, 통제된 스튜디오 제품 사진 프롬프트를 사용했습니다. 동일 조건의 정밀도 비교는 요청당 이미지 1장, 선택한 노드 설정은 요청당 변형 2개를 생성했습니다. 반복 프롬프트와 사용 가능한 캐시는 다양한 고객 트래픽에 대한 추론을 제한합니다.
• 시간 측정: 측정 전 모델을 로드하고 워밍업했습니다. 동일 조건의 ComfyUI 비교는 API 대기열/폴링 오버헤드, 프롬프트 인코딩, 노이즈 제거, VAE 디코딩, PNG 인코딩과 저장을 포함하며 정밀도별 30개 요청을 측정했습니다. 이전 Diffusers 결과는 PNG 인코딩을 제외하므로 정밀도 기준선이 아닙니다.
• 노드 집계 및 반복: 선택한 속도는 첫 측정 클라이언트 시작부터 마지막 완료까지의 공통 시간 구간으로 총 출력을 나누어 계산합니다. 각 960개 출력을 생성한 세 차례 짧은 실행의 최저값이며, 단독 GPU 속도의 8배 대비 확장 효율 92.49%입니다. 이전 워커 속도 합산값은 동일 조건의 노드 기준선으로 사용하지 않습니다. 이 측정은 지속적인 프로덕션 SLA를 확립하지 않습니다.
• 품질: 선택한 출력 8개를 육안 검토했습니다. 모두 요청한 라벨을 읽을 수 있는 일관된 제품 사진이었습니다. 6개는 정확하고 깔끔한 라벨, 1개는 작은 추가 텍스트, 1개는 불필요한 문장부호가 있었습니다. 이 기본 점검으로 전반적인 양자화 품질, 프롬프트 준수, 타이포그래피, 콘텐츠 조정 또는 고객 수용성을 입증할 수는 없습니다.

측정은 2026년 8월 12~21일에 수행했습니다. 호스팅 API 품질, 운영 신뢰성, 총비용의 동등성은 시험하지 않았습니다.

ComfyUI를 이용한 프라이빗 FLUX.2 이미지 생성

FLUX.2 Klein과 ComfyUI로 프라이빗 이미지 생성을 계획하는 팀에게 이 벤치마크는 창작 워크플로의 변형 수와 납기에 맞춰 처리 능력을 파악하도록 돕습니다. 시간당 이미지 변형 수와 요청 지연 시간은 서로 다른 계획상의 질문에 답합니다. 배포 시 대표 프롬프트로 성능을 확인하고 품질 요구 사항을 충족하는 출력을 집계해야 합니다.