배치 처리 (Batch Processing) vs 실시간 추론 (Real-Time Inference): 이미지 생성 시 각각을 언제 사용해야

두 회사가 동일한 이미지 생성 모델을 사용합니다.

한 회사는 이커머스 카탈로그를 위해 100,000개의 제품 이미지가 필요합니다. 다른 회사는 사용자가 몇 초 이내에 이미지를 기대하는 디자인 플랫폼을 운영합니다.

동일한 모델. 아마도 동일한 GPU.

완전히 다른 인프라스트럭처 (Infrastructure).

왜일까요?

한 회사는 이미지가 완료되는 것이 필요하기 때문입니다. 다른 회사는 사용자들이 이미지를 기다리고 있기 때문입니다.

대부분의 팀은 모델, 추론 프레임워크 (Inference frameworks) 및 GPU 사양을 비교하는 것부터 시작합니다. 그러한 선택들도 중요하지만, 비용과 GPU 활용도 (GPU utilisation)에 종종 더 큰 영향을 미치는 또 다른 질문이 있습니다:

이미지가 지금 당장 존재해야 합니까, 아니면 나중에 생성되어도 됩니까?

이 질문에 대한 답이 보통 배치 처리 (Batch processing), 실시간 추론 (Real-time inference) 또는 이 둘의 조합이 적절한 접근 방식인지를 결정합니다.

배치 처리 (Batch Processing) vs 실시간 추론 (Real-Time Inference) 한눈에 보기

<table><tbody><tr><td><p><strong>요인 (Factor)</strong></p></td><td><p><strong>배치 처리 (Batch Processing)</strong></p></td><td><p><strong>실시간 추론 (Real-Time Inference)</strong></p></td></tr><tr><td><p>주요 목표</p></td><td><p>최대 처리량 (Maximum throughput)</p></td><td><p>빠른 응답 시간 (Fast response time)</p></td></tr><tr><td><p>사용자 대기</p></td><td><p>아니오</p></td><td><p>예</p></td></tr><tr><td><p>큐잉 (Queueing)</p></td><td><p>예상됨</p></td><td><p>지연 시간 (Latency) 제한 내 유지</p></td></tr><tr><td><p>GPU 활용도 (GPU utilisation)</p></td><td><p>보통 최대화하기 더 쉬움</p></td><td><p>종종 여유 용량 필요</p></td></tr><tr><td><p>용량 계획 (Capacity planning)</p></td><td><p>작업량 및 마감 기한 기준</p></td><td><p>트래픽 및 지연 시간 목표 기준</p></td></tr><tr><td><p>비용 우선순위</p></td><td><p>완료된 이미지당 낮은 비용</p></td><td><p>일관된 사용자 경험</p></td></tr><tr><td><p>인프라스트럭처 (Infrastructure) 우선순위</p></td><td><p>효율성 (Efficiency)</p></td><td><p>가용성 (Availability)</p></td></tr></tbody></table>

이 차이는 운영상의 차이처럼 보일 수 있습니다.

실제로는 전체 배포 아키텍처 (Deployment architecture)를 형성합니다.

배치 처리 (Batch Processing)가 의미 있는 때는 언제인가?

배치 처리 (Batch processing)는 이미지 생성을 즉각적으로 응답해야 하는 서비스가 아니라, 반드시 완료되어야 하는 작업으로 취급합니다.

다음과 같은 경우에 효과적입니다:

• 제품 카탈로그 생성 (Product catalogue generation)
• 대량 이미지 개선 (Bulk image enhancement)
• 마케팅 자산 제작 (Marketing asset production)
• 미디어 렌더링 파이프라인 (Media rendering pipelines)
• 대규모 디자인 자동화 (Large-scale design automation)

이러한 경우, 비즈니스는 총 출력량과 인도 시간 (delivery time)에 관심을 가집니다. 모든 이미지가 요청 후 몇 초 만에 나타나는지 여부는 대개 중요하지 않습니다.

그러한 유연성은 유용합니다.

요청은 대기열 (queue)에서 기다릴 수 있습니다. 호환 가능한 작업들을 함께 그룹화할 수 있습니다. GPU는 예측 불가능한 사용자 트래픽을 위해 용량을 비워둘 필요 없이 계속해서 처리를 진행할 수 있습니다.

목표는 간단합니다:

GPU를 계속 사용 상태로 유지하고 가능한 한 많은 작업을 완료하는 것.

배달 트럭을 채우는 것을 생각해보세요. 배달이 급하지 않을 때는 여러 번 반쯤 빈 트럭으로 이동하는 것보다 트럭을 가득 채워 보내는 것이 더 효율적입니다.

배치 이미지 생성도 동일한 원리를 따릅니다.

NVIDIA Triton dynamic batching과 같은 기술은 호환 가능한 추론 (inference) 요청들을 더 큰 배치로 결합하여 처리량 (throughput)을 향상시킬 수 있습니다.

여기서 대기열은 반드시 병목 현상 (bottleneck)인 것은 아닙니다.

그것은 최적화 전략 (optimisation strategy)의 일부입니다.

왜 배치 처리가 비용이 더 적게 들 수 있는가?

배치 워크로드 (Batch workloads)는 팀이 GPU 용량을 언제, 어떻게 사용할지에 대해 더 많은 제어권을 부여합니다.

유사한 요청을 그룹화하고, 여유 용량이 있을 때 작업을 스케줄링하며, 더 긴 시간 동안 지속적으로 작업을 처리할 수 있습니다.

이를 통해 GPU 시간당 완료되는 이미지 수를 늘리고 이미지당 실질 비용을 줄일 수 있습니다.

하지만 배칭 (batching)이 자동으로 이루어지는 마법은 아닙니다.

요청들이 동일한 모델, 해상도 또는 추론 설정 (inference configuration)과 같이 호환 가능한 설정을 사용할 때 가장 잘 작동합니다. 매우 다양한 요청은 별도의 대기열이나 스케줄링 규칙이 필요할 수 있습니다.

속도는 여전히 중요하지만, 측정 지표 (metric)가 달라집니다.

배치 파이프라인 (Batch pipeline)은 100,000개의 이미지를 생성하는 데 몇 시간이 걸릴 수도 있습니다. 만약 출력이 비즈니스 마감 시한 전에 준비된다면, 그것은 설계된 목적을 정확히 달성한 것입니다.

실시간 추론 (Real-Time Inference)은 언제 적합한가?

이제 사용자가 프롬프트 (prompt)를 입력하고 이미지 생성 (Generate Image) 버튼을 클릭하는 상황을 상상해 보십시오.

사용자는 GPU 활용률 (GPU utilisation)에 대해 생각하지 않습니다.

그들은 로딩 화면을 지켜보고 있습니다.

인프라 (infrastructure)는 요청이 도착했을 때 가용 용량 (capacity)을 확보하고 있어야 합니다. 더 큰 배치를 만들기 위해 기다리는 동안 모든 요청을 몇 분씩 편안하게 붙잡고 있을 수는 없습니다.

추가되는 매 초가 제품 경험 (product experience)의 일부가 됩니다.

이러한 특성 때문에 실시간 추론은 다음과 같은 경우에 적합합니다:

• 대화형 이미지 생성 도구 (Interactive image generation tools)
• AI 디자인 플랫폼 (AI design platforms)
• 라이브 사진 편집 애플리케이션 (Live photo-editing applications)
• 고객 대상 콘텐츠 제작 도구 (Customer-facing content creation tools)
• 엄격한 응답 시간 목표 (response-time targets)가 있는 애플리케이션

실시간 인프라는 갑작스러운 트래픽 증가를 처리할 수 있도록 트래픽이 적은 시간대에도 여분의 GPU 용량을 보유해야 할 수도 있습니다.

인프라 관점에서는 해당 용량이 과소 사용되는 것처럼 보일 수 있습니다.

하지만 제품 관점에서는 사용자 경험을 보호하는 것입니다.

실시간 추론은 배칭 (Batching)을 하지 않는다는 의미인가?

아닙니다.

이것은 중요한 차이점입니다.

실시간 시스템도 여전히 작거나 동적인 배치 (dynamic batches)를 사용할 수 있습니다. 차이점은 요청이 제한된 시간 동안만 기다릴 수 있다는 것입니다.

예를 들어, 추론 서버 (inference server)는 다른 호환 가능한 요청이 도착하는지 확인하기 위해 요청을 몇 밀리초 (milliseconds) 동안 유지할 수 있습니다. 그런 다음 눈에 띄는 지연 (delay) 없이 두 요청을 함께 처리할 수 있습니다.

하지만 여기에 트레이드오프 (trade-off)가 있습니다.

시스템이 배치를 만들기 위해 더 오래 기다릴수록 더 높은 처리량 (throughput)을 얻을 수 있지만, 지연 시간 (latency) 또한 늘어납니다.

NVIDIA의 Triton 최적화 가이드는 최소 지연 시간 (minimum latency)과 최대 처리량 (maximum throughput)을 서로 다른 튜닝 목표로 취급합니다. 두 가지를 동시에 최대화하는 경우는 드뭅니다.

실제 트레이드오프: 활용률 (Utilisation) vs 응답성 (Responsiveness)

배치 효율성 (Batch Efficiency)을 개선하는 많은 기술은 대화형 애플리케이션 (Interactive Applications)을 더 느리게 느껴지게 만들 수 있습니다.

• 더 큰 큐 (Queues)는 처리량 (Throughput)을 향상할 수 있지만 대기 시간 (Waiting Time)을 증가시킵니다.
• 더 높은 활용률 (Utilisation)은 유휴 용량 (Idle Capacity)을 낮출 수 있지만 트래픽 급증 (Traffic Spikes)에 대응할 여유를 줄입니다.
• 공격적인 스케줄링 (Aggressive Scheduling)은 GPU를 바쁘게 유지할 수 있지만 대화형 요청 (Interactive Requests)을 지연시킵니다.

배치 환경 (Batch Environment)에서는 최적화 (Optimisation)처럼 보이는 것이 실시간 환경 (Real-time Environment)에서는 병목 현상 (Bottleneck)이 될 수 있습니다.

배치 처리 (Batch Processing)에서는 기다리는 것이 효율성을 높일 수 있습니다.

실시간 추론 (Real-time Inference)에서는 기다리는 것이 고객 경험 (Customer Experience)에 영향을 미칩니다.

어떤 처리 모델을 선택해야 할까요?

한 가지 질문을 던져보세요:

이미지가 10분 뒤에 도착한다면 어떤 일이 벌어질까요?

만약 대답이 "중요한 일은 없다"라면, 배치 처리 (Batch Processing)가 아마 더 나은 선택일 것입니다.

만약 지연이 워크플로 (Workflow)를 방해하거나 기다리는 사용자를 좌절시킨다면, 실시간 추론 (Real-time Inference)이 정당화될 수 있습니다.

배치 처리 (Batch Processing)를 선택해야 하는 경우:

• 사용자가 각 이미지를 능동적으로 기다리고 있지 않을 때
• 워크로드 (Workload)에 유사한 요청이 많을 때
• 이미지가 즉시 나타나기보다 마감 기한 (Deadline)을 맞춰야 할 때
• 개별 요청 지연 시간 (Latency)보다 이미지당 비용이 더 중요할 때
• 작업이 큐잉 (Queueing) 또는 재스케줄링 (Rescheduling)을 견딜 수 있을 때

실시간 추론 (Real-Time Inference)을 선택해야 하는 경우:

• 고객이 결과를 기다리고 있을 때
• 응답 시간 (Response Time)이 제품 경험에 영향을 미칠 때
• 요청이 예측 불가능하게 도착할 때
• 애플리케이션에 명확한 지연 시간 목표 (Latency Target)가 있을 때
• 느린 생성 속도가 사용자의 워크플로 이탈을 유발할 수 있을 때

워크로드에 두 가지 모두가 필요하다면?

많은 프로덕션 애플리케이션 (Production Applications)은 하이브리드 아키텍처 (Hybrid Architecture)를 사용합니다.

대화형 요청 (Interactive Requests)은 낮은 지연 시간 (Low Latency)을 위해 설계된 인프라로 전달됩니다. 대량 작업 (Bulk Tasks)은 큐 (Queue)로 이동하여 처리량 (Throughput)에 최적화된 용량에서 실행됩니다.

예를 들어, 디자인 플랫폼은 실시간으로 미리보기 (Preview)를 생성할 수 있습니다. 사용자가 이를 승인하면, 고해상도 내보내기 (High-resolution Exports), 다양한 종횡비 (Aspect Ratios) 및 추가 변형 (Variations) 작업은 배치 파이프라인 (Batch Pipeline)으로 넘어갈 수 있습니다.

사용자는 빠른 미리보기를 얻습니다.

인프라는 모든 출력을 긴급한 것으로 취급하는 것을 피할 수 있습니다.

GPU 크기보다 워크로드 동작 (Workload Behaviour)이 더 중요한 이유

팀들은 종종 어떤 GPU를 사용해야 하는지 묻는 것으로 시작합니다.

하지만 가장 빠른 GPU가 자동으로 가장 비용 효율적인 아키텍처를 만들어내는 것은 아닙니다.

과도하게 설정된 실시간 환경 (Real-time environment)에서 낮은 활용도 (Utilisation)로 실행되는 강력한 GPU는, 배치 파이프라인 (Batch pipeline)에서 지속적으로 실행되는 더 작은 GPU보다 이미지당 비용이 더 많이 들 수 있습니다.

하드웨어는 중요합니다.

하지만 워크로드 동작 (Workload behaviour)이 해당 하드웨어가 얼마나 효율적으로 사용되는지를 결정합니다.

GPU 인스턴스를 선택하기 전에, 워크로드가 최대 처리량 (Maximum throughput), 낮은 지연 시간 (Low latency), 또는 이 둘의 균형 중 무엇을 필요로 하는지 정의하십시오.

그 후 불필요한 용량을 활성화 상태로 유지하는 대신, 클라우드 GPU 가격 책정을 통해 시간당 및 장기적인 구성을 비교할 수 있습니다.

그렇다면, 누가 이미지를 기다리고 있는가?

즉각적인 전달보다 완료 여부가 더 중요할 때는 배치 처리 (Batch processing)를 선택하십시오.

사용자 경험이 이미지를 빠르게 받는 것에 달려 있을 때는 실시간 추론 (Real-time inference)을 선택하십시오.

워크플로의 일부만 즉각적인 응답이 필요한 경우에는 하이브리드 아키텍처 (Hybrid architecture)를 사용하십시오.

GPU를 비교하거나 추론 프레임워크 (Inference frameworks)를 벤치마킹하기 전에 스스로에게 물어보십시오:

누가 이미지를 기다리고 있는가?

기다리는 사람이 아무도 없다면, 워크로드가 대기열 (Queue)에 머물게 하십시오.

사용자가 화면을 보고 있다면, 그 순간을 중심으로 인프라를 설계하십시오.