이미지 제작 과정에서 예산을 망가뜨리는 것은 단 하나의 프레임이 아니라, 긴급한 수정 요청의 대기열입니다. 당신은 이미지 한 장당 생성 비용을 계산하여 매니저에게 한 번의 실행(pass)당 아름다운 수치를 보여주지만, 한 달이 지나면 디자이너들이 수정 사항을 처리하기 위해 40분 동안 기다리고 있다는 사실을 알게 됩니다. 단 하나의 그래픽 카드(GPU)에 대기열이 형성되었기 때문입니다. 여기서 프레임당 가격은 문제가 아닙니다. 처리량(throughput)이 무너지는 것이 문제입니다.

이제 저는 한 가지 질문에 답하기 위해 간단한 모델을 구축합니다: 로컬 FLUX가 당신 팀의 수정 요청 흐름을 견딜 수 있는가? 여기서 척도는 단 하나입니다. 대기 시간이 용납할 수 없는 수준이 되기 전까지, 하나의 GPU와 한 명의 작업자(operator)를 통해 시간당 얼마나 많은 작업이 통과하느냐 하는 것입니다. 계산기에는 작업의 크기, 실행당 GPU 시간, 재시도 횟수 및 작업자의 휴지 시간(operator pauses)이 포함됩니다. 솔직하게 미리 말씀드리자면, 이것은 당신의 하드웨어에서 측정한 값이 아니라 예상되는 입력 데이터를 기반으로 한 예측치입니다. 실제 소요 시간은 직접 대입해야 합니다.

그리고 계산을 하기 전에 기록해 두어야 할 또 다른 차이점이 있습니다: GPU 병목 현상(GPU bottleneck)과 작업자 휴지 시간은 해결책이 다른 별개의 문제입니다. 첫 번째는 하드웨어나 더 빠른 모델 모드로 해결할 수 있습니다. 두 번째는 그래픽 카드가 아니라 프로세스의 문제입니다. 계산기가 필요한 이유는 바로 이 둘을 혼동하여, 수동 검수 과정에서 지연이 발생하는데도 두 번째 GPU를 구매하는 실수를 방지하기 위함입니다.

프레임당 가격은 당신의 부하를 속인다

벤더(Vendor)는 실행당 가격을 게시하며, 이는 편리하고 정직하며 검증 가능한 수치입니다. 2026-07-18 기준 docs.bfl.ai 가격표에 따른 Black Forest Labs의 호스트 API는 Klein 9B의 수정 비용을 출력물의 첫 1메가픽셀(megapixel)당 $0.015부터 책정하며, 추가 메가픽셀은 그 위에 가산됩니다. "~부터" 및 "메가픽셀 단위"라는 표현은 실제 수정 비용이 해상도에 따라 달라짐을 의미하며, 이를 이미지당 정확한 가격으로 사용할 수는 없고 오직 규모(order of magnitude)를 파악하는 용도로만 사용할 수 있습니다.

수치는 정확하지만, 이는 다른 질문에 대한 답입니다. 프레임당 가격은 선형적입니다. 즉, 100번의 수정은 1번의 수정보다 100배 더 비쌉니다. 하지만 대기열(Queue)은 비선형적입니다. 평온한 날의 100번의 수정과 출시 직전 2시간 동안의 100번의 수정은 비용은 동일하지만, 대기 시간(Wait time) 측면에서는 완전히 다릅니다. 로컬 실행(Local run)의 적합성에 대한 논쟁은 거의 항상 총 소유 비용(TCO)과 프레임당 가격의 관점에서 이루어지며, 바로 이 점 때문에 팀들이 정기적으로 판단을 그르칩니다. 저의 논지는 더 간단하며 반박될 수도 있습니다. 만약 계산 결과가 허용 가능한 대기 시간을 초과하는 대기열을 보여준다면, 단일 프레임의 가격이 아무리 매력적이더라도 로컬 모드는 정해진 수정 흐름(Flow of edits)을 감당할 수 없다는 것입니다.

이 논지를 반박하는 것은 쉽습니다. 만약 팀의 수정 흐름이 드물고 일정하다면 대기열은 형성되지 않으며, 이 경우에는 처리량(Throughput)이 아니라 바로 TCO가 결정 요인이 됩니다. 아래의 모델은 이 사례를 직접 보여줍니다. 흐름이 낮고 실행 시간이 짧으면 GPU와 작업자가 유휴 상태(Idle)가 되므로, 대기열에 관한 모든 논의는 불필요해집니다.

당신이 실제로 실행하는 것은 무엇인가: flux 2 klein 9b safetensors

대기열을 계산하기 전에 모델의 파라미터를 확정해 두겠습니다. 버전과 라이선스는 계속 변경되므로 매 계산 전에 재확인해야 합니다. 공개된 flux 2 klein 9b safetensors 체크포인트는 90억 개의 파라미터를 가진 모델로, Black Forest Labs가 Hugging Face를 통해 배포하는 약 18.2GB 크기의 파일입니다. 이와 함께 파이프라인(Pipeline) 내에서 80억 개의 파라미터를 가진 Qwen3 텍스트 인코더(Text encoder)가 작동합니다. 이는 트랜스포머(Transformer) 자체 외에 VRAM에 별도의 부하와 로딩을 추가하며, 메모리를 계획할 때 쉽게 간과하기 쉽습니다.

대기열(Queue)의 핵심은 두 가지 실행 모드이며, Comfy Org(2026-07-18)의 측정치에 따르면 이들은 근본적으로 다른 추론 시간(Inference time)을 보여줍니다. 증류된(Distilled) 버전인 Klein 9B는 4단계의 인퍼런스(Inference) 단계로 작동하며, RTX 5090에서 피크 VRAM 약 19.6GB를 사용하여 생성 또는 편집을 약 2초 만에 완료합니다. 반면 동일한 9B 모델의 비증류(Non-distilled) 베이스 버전은 50단계의 인퍼런스가 필요하며, 동일한 카드에서 약 35초와 약 21.7GB의 VRAM을 요구합니다. 추론 시간의 차이는 17배에 달합니다. 이는 대기열 측면에서 분기점이 됩니다. 즉, 동일한 작업 흐름이라도 실행 모드에 따라 서로 다른 병목 현상(Bottleneck)에 직면하게 됩니다.

최소 사양의 기준은 다음과 같습니다: 16GB의 RTX 4080이 지원되며, 24GB의 RTX 4090이 권장됩니다. 실질적인 배치(Batch) 크기는 16GB 카드에서는 이미지 1장, 24GB 이상에서는 단 2~3장의 이미지입니다. 이 배치 및 VRAM 분할 수치는 Black Forest Labs의 공식 문서가 아닌 커뮤니티(DeepWiki)에서 나온 것이므로, 저는 이를 사양(Specification)이 아닌 2차 검증 자료로 간주합니다. 하지만 가이드라인으로서 이 수치들은 중요합니다. 배치는 하나의 GPU가 대기열을 직렬화(Serialize)하기 시작하기 전까지 얼마나 많은 병렬 작업을 처리할 수 있는지를 제한하기 때문입니다.

편집(Edit)에 대해 별도로 언급하자면, Klein 9B는 하나의 참조(Reference), 여러 개의 참조, 그리고 하나의 아키텍처 내에서 반복적인 다중 패스(Multi-pass) 편집을 모두 지원합니다. 여기서 계산 시 주의해야 할 까다로운 점이 발생합니다. 대기열 내의 하나의 논리적인 "편집 작업"이 모델 호출(Model call)을 한 번이 아니라 여러 번 요구할 수 있다는 점입니다. 디자이너가 flux 2 klein 9b edit 모드에서 "배경을 수정하고, 그다음에 손을, 그다음에 조명을 수정해줘"라고 요청한다면, 이는 한 번이 아니라 세 번의 패스(Pass)가 필요하며, 따라서 대기열은 작업 단위가 아닌 호출 단위로 계산해야 합니다.

대기열이 쌓이기 시작할 때 가장 먼저 드는 생각은 수정 작업의 정점을 벤더(vendor) 측으로 넘기는 것입니다. 그곳에서는 더 이상 GPU 초(seconds) 단위가 아니라 출력되는 메가픽셀(megapixels) 단위로 계산하기 때문입니다. FLUX API는 결과물에 따라 과금되므로, 대기열은 해상도와 함께 증가하는 청구서로 변합니다. 두 경로를 동일하게 취급할 수는 없지만, 비교를 위해 최소한 하나의 외부 루프를 곁에 두는 것은 유용합니다. 예를 들어, 해외 카드가 없어도 루블 잔액으로 이미지 생성 및 편집을 사용할 수 있는 provod.ai (러시아의 OpenRouter) 같은 곳이 있습니다. 이는 비교를 위한 플랫폼이지, 해당 서비스가 로컬 FLUX보다 빠르다는 주장은 아닙니다.

대기열 계산기는 네 가지 요소로 구성됩니다

하나의 편집(edit) 대기열 모델은 작업(task), GPU 호출(또는 API 요청), 대기(waiting), 그리고 운영자(operator)라는 네 가지 요소로 구성됩니다. 다음은 예상 입력 데이터를 기반으로 한 최소한의 계산입니다. 여기에 기재된 모든 지속 시간은 가정치이며, 이 계산기가 가치 있는 이유는 바로 이러한 가정들을 명확하게 보여주기 때문입니다.

# FLUX 2 Klein 9B의 단일 편집(edit) 대기열 예측.
# 모든 지속 시간은 '가정치'입니다. 본인의 하드웨어에서 직접 측정하세요.

...

증류(distilled)된 2초를 대입하면 약 92회의 호출, 약 184초의 GPU 부하, 그리고 시간당 그래픽 카드 점유율은 약 5%에 불과하다는 결과가 나옵니다. 동일하게 40개의 작업과 25초의 휴지기를 가질 때 운영자의 업무 점유율은 28%입니다. 이러한 입력 데이터에 따른 결론은 명확합니다. 병목 현상(bottleneck)은 GPU가 아니라 운영자에게 있습니다. 두 번째 가속기를 추가해도 상황은 변하지 않습니다. 그래픽 카드가 이미 시간의 95% 동안 유휴 상태이기 때문입니다.

이제 매개변수를 하나 바꿔보겠습니다. 모드를 기본(base) 모드로 변경하고, 처리 시간을 35초로 설정합니다. GPU 부하는 시간당 약 3220초로 급증하여 점유율이 약 89%에 달하며, 대기열은 사람보다 그래픽 카드에서 먼저 쌓이기 시작합니다. 동일한 흐름에서 단 하나의 가정만 바뀌었을 뿐인데, 병목 현상이 운영자에서 GPU로 이동했습니다. 이것이 바로 계산기가 보여줘야 할 핵심입니다. 절대적인 진리가 아니라, 당신이 설정한 수치에서 어떤 요소가 가장 먼저 무너지는지를 보여주는 것입니다.

병목 현상 (Bottleneck): GPU인가 아니면 운영자(Operator)인가

이 두 가지 경우를 구분해야 하는 이유는 해결 방법이 다르며, 오류는 곧 비용으로 직결되기 때문입니다. GPU 병목 현상은 비디오 카드의 사용률(Utilization)이 100%에 가깝고, 작업들이 정확히 추론 (Inference) 단계를 기다리는 모습으로 확인할 수 있습니다. 이는 더 빠른 모드를 사용하거나, 배치 처리 (Batching)를 지원하는 두 번째 카드를 추가함으로써 해결할 수 있습니다. 운영자 병목 현상은 양상이 다릅니다. 비디오 카드는 놀고 있는데 작업은 여전히 대기 중입니다. 사람이 수정 사항을 제안하고 수락하는 속도가 따라가지 못하기 때문입니다. 이 경우 두 번째 가속기를 추가하는 것은 무용지물이며, 오직 프로세스 개선만이 도움이 됩니다. 즉, 요청 템플릿, 명백한 결과에 대한 자동 수락, 미리 준비된 프리셋 (Presets), 그리고 검토를 위한 추가 인력 투입 등이 필요합니다.

재시도 (Retry)는 '평균 시간' 속에 숨기지 말고 별도의 파라미터로 기록해야 합니다. 다회차 수정 과정에서의 재시도는 매우 교활합니다. 만약 결과가 좋지 않아 작업이 두 번째, 세 번째 라운드로 넘어가게 되면, 바로 그 병목이 발생하는 지점에서 부하를 배가시키기 때문입니다. GPU 병목 상황에서 재시도는 비디오 카드에 타격을 주고, 운영자 병목 상황에서는 프롬프트를 다시 작성해야 하는 사람에게 타격을 줍니다. 따라서 계산기에서 retry_rate를 별도로 분리해 놓은 것입니다. 이를 변경해 봄으로써, 어떤 연결 고리가 허용 가능한 대기 시간을 가장 먼저 초과하는지 확인할 수 있습니다.

그리고 GPU 사용률에서도, 운영자의 휴지기에서도 보이지 않는 세 번째 제한 요소가 있습니다. 모델 카드 (Model Card), 라이선스, 가격표 그 어디에도 동시성 (Concurrency)의 한계, 대기열의 깊이, 그리고 로컬 Klein 9B를 위해 여러 개의 GPU로 확장할 때의 동작 방식에 대한 설명은 없습니다. 이러한 파라미터들은 벤더 (Vendor)가 운영자에게 직접 측정하도록 남겨두는 것이지, 공식적으로 선언하는 것이 아니기 때문입니다. 즉, 당신의 계산에 포함된 병렬성 (Parallelism)에 관한 모든 수치는 당신의 가정(Assumption)이며, 그에 걸맞은 태도로 접근해야 합니다.

모드는 추론 비용이 아니라 예측 후에 결정해야 합니다

결정은 추론(inference) 비용이 아니라 대기열(queue) 예측 후에 내려져야 합니다. 아래는 두 가지 로컬 모드와 기준점으로서의 호스팅 경로(hosted route)를 비교한 요약입니다. 수치는 벤더와 커뮤니티에서 발표한 것이며, 병목 현상(bottleneck) 행은 저의 가정을 바탕으로 계산기에서 도출한 값입니다.

표를 읽는 방법은 다음과 같습니다. 트래픽이 높지 않고 수정 사항이 짧다면, distilled 모드는 GPU를 거의 자유로운 상태로 유지하며 수용 프로세스를 결정합니다. 이 경우 로컬 실행은 타당하며, 병목은 하드웨어가 아닌 인력(people)에 달려 있습니다. 만약 수정 사항이 무겁고 base 모드로 진행된다면, GPU는 빠르게 포화 상태가 됩니다. 이때는 배치(batching)를 위해 더 강력한 카드를 사용하거나, 트래픽의 일부를 외부 경로로 돌려야 합니다. 호스팅된 FLUX API는 하드웨어 문제를 해결해주지만, 그 대가로 픽셀당 비용과 사용자가 볼 수도 제어할 수도 없는 제공업체 측의 대기열을 부여합니다.

어떠한 대역폭(throughput)도 뛰어넘을 수 있는 법적 한계에 대해 별도로 언급하겠습니다. Klein 9B의 가중치(weights)는 기본적으로 FLUX Non-Commercial License 하에 출시되었습니다. 즉, 별도의 상업용 라이선스를 획득하기 전까지는 수익 창출 목적의 프로덕션(production) 또는 엔드 유저(end-user) 배포가 엄격히 금지됩니다. 이는 9B 체크포인트(checkpoint)를 사용하여 프로덕션 수정 대기열을 운영하려는 모든 팀에게 매우 엄격한 전제 조건입니다. bfl.ai의 2026-07-18 데이터에 따르면, Black Forest Labs의 셀프 호스팅 상업용 요금제는 하드웨어와 관계없이 월간 이미지 생성량을 제한합니다. 예를 들어, Builder 플랜은 단일 도메인당 월 1만 장, Platform 플랜은 10만 장을 허용합니다. 즉, 최대 지속 가능한 대기열 규모는 GPU가 아니라 라이선스 조건에 의해 제한될 수 있습니다. 그리고 이 조건들은 계속 변하므로, 구매 전에 반드시 재확인해야 합니다.

이 계산이 해결하지 못하는 것

예측은 실제 작업용 하드웨어에서의 측정값을 대체할 수 없습니다. 이것이 이 계산의 가장 큰 한계이며, 저는 여러분이 이 모델을 실제 측정값으로 오해하지 않기를 바랍니다. Comfy Org의 타이밍(Timings)은 Comfy Org의 특정 환경 내 특정 RTX 5090에서 측정된 것입니다. 여러분의 그래픽 카드, 드라이버 및 해상도에 따라 수치는 달라질 것입니다. 계산기는 주어진 가정 하에서 어떤 요소가 가장 먼저 병목 현상(Bottleneck)을 일으키는지 보여주지만, 그 가정 자체에 대한 책임은 여러분에게 있습니다.