이 문서에서는 Google Kubernetes Engine (GKE)에서 배치 추론 워크로드를 실행하기 위한 권장사항을 제공합니다. 일괄 추론은 머신러닝 모델을 사용하여 대규모 데이터 세트에 대한 예측을 생성하는 프로세스로, 즉각적이고 지연 시간이 짧은 응답보다 높은 처리량과 비용 효율성을 우선시합니다.
이 가이드에서는 일괄 추론과 요청 일괄 처리 (또는 동적 일괄 처리)를 구분합니다. 요청 일괄 처리는 vLLM 또는 SGLang과 같은 엔진에서 가속기 효율성을 최적화하기 위해 동시 실시간 요청을 그룹화하는 서버 측 기술입니다. 일괄 추론 워크로드에 요청 일괄 처리를 적용할 수 있습니다.
이 가이드의 권장사항은 다음과 같은 두 가지 일반적인 일괄 추론 패턴을 다룹니다.
- 거의 실시간 배치 추론: 데이터가 생성된 후 곧바로 청크 단위로 데이터를 처리합니다. 일반적으로 지연 시간이 초에서 분 단위인 이 접근 방식은 최신 데이터의 필요성과 여러 항목을 동시에 처리하는 효율성 사이에서 균형을 유지합니다.
- 오프라인 일괄 추론: 누적된 대량의 데이터를 예약된 간격 (예: 매일 밤 또는 매주)으로 처리합니다. 이러한 작업은 리소스 가용성을 극대화하기 위해 비성수기에 예약되는 경우가 많으므로 지연 시간은 일반적으로 몇 시간에서 며칠까지 걸립니다.
이러한 권장사항은 GKE의 추론 권장사항 개요에 설명된 기반을 토대로 구축된 전문적인 최적화 레이어입니다. 일괄 워크로드에 맞게 최적화하기 전에 모델 선택, 양자화, 가속기 선택에 관한 핵심 권장사항을 따랐는지 확인하세요.
일괄 추론 처리를 위한 아키텍처 패턴 선택
올바른 아키텍처 패턴을 선택하는 것은 지연 시간, 처리량, 비용 간의 절충에 영향을 미치므로 일괄 추론 워크로드를 배포하는 데 가장 중요한 결정입니다. 효율성을 유지하려면 대기열이 무한정 늘어나지 않도록 비수기 동안 추론 처리량이 수신되는 쿼리 비율을 초과해야 합니다.
버스트 작업에 거의 실시간 일괄 추론 사용
실시간에 가까운 일괄 처리는 다음과 같이 빈번한 증분 업데이트가 필요한 사용 사례에 적합합니다.
- 최근 상호작용을 기반으로 몇 분마다 사용자 추천 프로필을 업데이트합니다.
- 실시간 모니터링을 위해 1분 간격으로 소셜 미디어 멘션을 처리합니다.
- 고빈도 금융 데이터 스트림에서 시장을 움직이는 신호를 감지합니다.
- 수신되는 고객 의견 또는 뉴스 피드에 대한 감정 분석을 수행합니다.
워크로드가 몇 초에서 몇 분에 이르는 지연 시간을 허용할 수 있는 경우 이 패턴을 선택하세요.
거의 실시간 배치 추론을 구현할 때는 다음 특성을 고려하세요.
- 지연 시간: 첫 번째 토큰까지의 시간이 수십 초에서 수분까지 걸릴 수 있습니다.
- 데이터 소스: 일반적으로 짧은 시간 내에 누적된 Pub/Sub의 메시지나 Cloud Storage의 파일과 같은 메가바이트에서 기가바이트에 이르는 데이터 세트를 처리합니다.
- 컴퓨팅 패턴: 인프라가 빈번한 작업 급증을 처리하는 지속적인 서비스를 지원해야 합니다.
- 비용 최적화: 이 패턴은 짧은 지연 시간의 실시간 추론과 높은 처리량의 오프라인 처리 간의 균형을 제공합니다.
대규모 데이터 세트에 오프라인 일괄 추론 사용
오프라인 일괄 처리는 다음과 같이 몇 시간 또는 며칠의 지연을 허용할 수 있는 대규모 에피소드 작업에 적합합니다.
- 전날의 금융 거래를 기반으로 매일 밤 위험 평가 보고서를 생성합니다.
- 다운스트림 검색 및 추천 시스템을 지원하기 위해 전체 카탈로그의 제품 임베딩을 만듭니다.
- 모델 학습 또는 보관 분류를 위해 대규모 이미지 데이터 세트에 라벨을 지정합니다.
대량의 데이터를 처리하고 지연 시간이 몇 시간에서 며칠까지 허용되는 경우 이 패턴을 선택하세요.
오프라인 배치 추론을 구현할 때는 다음 특성을 고려하세요.
- 지연 시간: 작업이 비수기에 예약되는 경우가 많으므로 워크로드 시작 지연 시간은 일반적으로 몇 분에서 며칠까지입니다.
- 데이터 소스: 일반적으로 Cloud Storage 또는 BigQuery 테이블에 저장된 기가바이트에서 페타바이트에 이르는 대규모 데이터 세트를 처리합니다.
- 컴퓨팅 패턴: 초기화하고 데이터를 처리한 후 종료되는 에피소드식 버스트 작업을 사용합니다.
- 비용 최적화: 이 패턴은 종량제 모델로 매우 최적화할 수 있습니다. 오프라인 작업에는 완료 기간이 유연하므로 스팟 VM을 사용하여 비용을 절감하는 것이 좋습니다.
처리량 및 비용 효율성 최적화
일괄 추론 워크로드는 중단이 발생할 수 있는 비용 절감 인프라에 적합합니다.
스팟 VM을 사용하여 컴퓨팅 비용 절감
일괄 작업에 스팟 VM 의 할인을 사용하세요. 일괄 추론 워크로드는 일반적으로 지연 시간과 중단에 대한 허용 범위가 넓기 때문에 스팟 용량의 할인된 가격을 적용하기에 적합합니다.
일괄 추론 코드가 체크포인트를 구현하여 잠재적인 선점 이벤트를 처리하는지 확인합니다. 스팟 VM이 선점되면 0부터 다시 시작하는 대신 새 노드를 만들고 마지막으로 처리된 배치에서 워크로드를 재개할 수 있습니다.
워크로드 배치 크기 및 요청 배치 크기 조정
리소스 경합과 작업 시간 초과를 방지하려면 서버에서 처리할 수 있는 동시 요청 (요청 배치)만큼 엔진 (워크로드 배치)으로 전송되는 항목 수가 커야 가속기가 제대로 활용되지 않는 상황을 방지할 수 있습니다.
워크로드 배치 크기 조정
워크로드 배치 크기는 단일 작업 단위로 추론 엔진에 전송되는 총 항목 수입니다. 데이터를 샤딩하거나 여러 항목을 단일 요청으로 그룹화하여 클라이언트 제출 로직 또는 Kubernetes 작업 구성에서 이를 구성합니다.
최적의 워크로드 배치 크기를 확인하려면 다음 경계를 사용하세요.
- 최소 배치 크기 계산: 워크로드 배치 크기가 요청 배치 크기 이상인지 확인합니다. 예를 들어 동시에 256개의 항목을 처리할 수 있는 서버에 하나의 항목을 전송하면 활용도가 크게 떨어집니다. 최소 크기를 확인하려면 vLLM의
max_num_seqs인수와 같은 추론 서버 구성을 확인하세요. 여러 항목을 단일 요청으로 그룹화하도록 클라이언트 로직을 구성하거나 각 작업이 요청 일괄 처리 크기를 충족하거나 초과하는 최소한의 데이터를 수신하도록 데이터를 샤딩할 수 있습니다. - 최대 배치 크기 계산: 워크로드 배치 크기가 Kubernetes 작업에 정의된
activeDeadlineSeconds제한 시간에 도달하기 전에 포드가 완료될 수 있도록 합니다. 하나의 요청 일괄 처리에 필요한 시간을 추정하고 포드가 기한 내에 완료되도록 워크로드 크기를 설정합니다. 예를 들어activeDeadlineSeconds이 3,600초이고 시작 오버헤드가 600초인 경우 최대 실행 시간이 포드가 3,000초 미만으로 완료되도록 해야 합니다.
워크로드 배치 크기가 너무 작으면 포드 시작 오버헤드 (가중치 다운로드, 프로비저닝, 액셀러레이터 초기화)에 시간이 낭비됩니다. 너무 크면 activeDeadlineSeconds 타임아웃으로 인해 GKE에서 작업을 종료하여 작업이 실패하고 진행 상황이 손실될 수 있습니다.
요청 배치 크기 조정
요청 배치 크기는 추론 서버가 가속기에서 동시에 처리하는 동시 요청 수입니다. 추론 서버 구성에서 서버별 플래그 (예: vLLM의 경우 --max-num-seqs 플래그)를 조정하여 이 매개변수를 최적화합니다.
목표는 메모리 부족 (OOM) 오류를 트리거하지 않고 GPU 사용률을 극대화하는 것입니다. 요청 배치 크기가 보정되지 않으면 시스템에서 액셀러레이터를 충분히 활용하지 못하거나 모델 서버가 비정상 종료됩니다. vLLM의 경우 vLLM auto_tune 스크립트와 같은 도구를 사용하여 특정 하드웨어에 맞는 max_num_seqs 및 max_num_batched_tokens 설정의 최적 값을 찾을 수 있습니다. 자세한 내용은 GKE의 추론 권장사항 개요 가이드의 추론 서버 구성 최적화를 참고하세요.
거의 실시간 일괄 처리를 위해 비동기 구성요소 구현
거의 실시간 일괄 처리의 경우 메시지 버퍼를 사용하여 수집 레이어를 추론 레이어에서 분리하는 것이 좋습니다.
다음 아키텍처 다이어그램은 거의 실시간 배치 추론 플랫폼의 예를 보여줍니다. 이 아키텍처는 트래픽 급증으로부터 추론 서버를 보호하고, 작업 백로그를 관리하며, 높은 액셀러레이터 사용률을 보장합니다.
이 다이어그램은 Pub/Sub에서 구독자, 추론 게이트웨이, 추론 서버로의 흐름을 보여주며, 결과는 AlloyDB에 유지되고 실패한 메시지는 데드레터 주제로 전송됩니다.
이 아키텍처는 다음 구성요소로 구성됩니다.
- Pub/Sub 주제: 수신 클라이언트 메시지의 영구 버퍼 역할을 하며 보관 기간은 7~31일입니다.
- 구독자: 메시지 일괄 처리를 읽고, 추론 서버에 요청을 보내고, 처리를 확인하는 구성요소입니다.
- 구독자 HPA:
num_undelivered_messages측정항목 (확인되지 않은 메시지 수)을 기반으로 구독자 배포를 확장합니다. - 스토리지: 데이터베이스 (예: AlloyDB) 또는 객체 스토리지 (예: Cloud Storage)를 사용하여 추론 결과를 유지합니다.
- 추론 게이트웨이: 추론 워크로드를 구독자에게 노출합니다.
- 추론 서버: 일괄 추론 요청을 처리합니다 (예: vLLM).
- 서버 HPA:
vllm:num_requests_waiting와 같은 엔진별 측정항목을 기반으로 추론 엔진을 확장합니다. - 데드 레터 주제: 설정된 횟수의 지수 백오프 재시도 후 처리에 실패한 메시지를 캡처합니다.
자세한 내용은 GitHub의 참조 구현을 참고하세요.
요청 버퍼링 및 집계
요청 흐름을 관리하려면 다음 단계를 따르세요.
- Pub/Sub을 지속 가능한 버퍼로 사용: 추론 요청을 지속적으로 저장하도록 Pub/Sub을 구현합니다. 이 설정은 소비자가 요청을 처리할 수 있을 때까지 요청을 보관하는 FIFO 버퍼 역할을 하여 트래픽 급증 시 서버 과부하를 방지합니다.
- 클라이언트 측 흐름 제어와 함께 가져오기 구독 사용: 가져오기 구독 모델을 구성합니다. 이를 통해 구독자 애플리케이션은 메시지를 처리할 수 있는 경우에만 명시적으로 메시지를 요청할 수 있으므로 소비 속도를 완전히 제어할 수 있습니다.
- 서버 배치 크기를 채우기 위해 메시지 집계: 하나의 Pub/Sub 메시지를 하나의 추론 요청으로 전송하지 마세요. 대신 구독자는 추론 서버의 최적 배치 크기 (예: vLLM의
max_num_seqs설정과 일치)에 맞는 단일 배치 요청으로 여러 메시지를 번들로 묶어야 합니다. 이 접근 방식을 사용하면 액셀러레이터가 완전히 포화 상태가 되고 처리량이 최대화됩니다. 특히 모든 모델 정방향 전달이 완전히 포화되도록 구독자의max_messages풀 설정을max_num_seqs의 배수로 구성합니다.
구독자 및 서버 자동 확장
효과적인 배치 추론을 위해서는 추론 서버 (GPU 또는 TPU 바운드)와 다르게 구독자 (CPU 바운드)를 확장해야 합니다.
작업 백로그를 기반으로 구독자 확장: Pub/Sub의
num_undelivered_messages측정항목을 기반으로 구독자 배포의 HorizontalPodAutoscaler (HPA)를 구성합니다. 자세한 내용은 측정항목을 기준으로 포드 자동 확장 최적화를 참고하세요. 다음 수식을 사용하여 사용할 복제본을 계산합니다.\[ desiredReplicas = \frac{num\_undelivered\_messages}{target\_latency\_seconds \times throughput\_per\_replica} \]
인프라 할당량 준수: HPA에서
maxReplicas설정을 구성하여 구독자의 최대 복제본 수를 명시적으로 제한합니다. 추론 서버의 GPU 또는 TPU 할당량이 지원할 수 있는 것 이상으로 구독자를 확장하지 마세요. 구독자를 과도하게 프로비저닝하면 병목 현상이 추론 서버로 이동하여 처리량을 늘리지 않고 리소스 경합이 증가합니다.엔진 측정항목을 기반으로 추론 서버 확장: CPU/메모리를 통해서만이 아닌 추론 엔진에서 직접 내보낸 측정항목을 기반으로 추론 서버 배포를 확장합니다. 예를 들어 모델 서버 수준에서 처리 백로그를 직접 측정하는 vLLM의
vllm:num_requests_waiting설정을 사용합니다. 자세한 내용은 포드 자동 확장을 참고하세요.
오류 및 제한 시간 처리
오류와 시간 초과를 처리하려면 다음 단계를 따르세요.
- 확인 기한 사전 연장: 재전송 루프 및 중복 처리를 방지하기 위해 처리 중인 메시지의 Pub/Sub 확인 (ack) 기한을 사전 연장하도록 구독자를 구성합니다. 이 접근 방식은 추론 작업이 기본 제한 시간 창보다 오래 걸리는 경우가 많기 때문에 필요합니다. 일반적으로 확장 기간을 최악의 배치 추론 시간보다 길게 설정합니다.
- 데드 레터 주제로 오류 격리: 데드 레터 주제를 사용 설정하여 전송에 실패하는 형식이 잘못된 메시지를 자동으로 격리합니다. 이 접근 방식을 사용하면 '포이즌 필' 메시지가 대기열을 차단하고 전체 파이프라인을 중지하는 것을 방지할 수 있습니다.
- 백오프 전략 구현: 추론 서버에서
429(요청이 너무 많음) 또는503(서비스를 사용할 수 없음) 오류를 반환하는 경우 구독자는 이러한 오류를 포착하고 지수 백오프 전략을 구현하여 서버가 복구될 때까지 Pub/Sub의 소비를 일시적으로 중지해야 합니다.
오프라인 일괄 작업을 대규모로 조정
대규모 데이터 세트를 처리할 때 다음 권장사항을 따라 처리량을 극대화하고, 비용 효율성을 보장하고, 감사를 위한 포괄적인 추적 가능성을 구현하고, 고급 할당량 관리 및 작업 우선순위 지정을 적용하세요.
다중 노드 분산 추론에 JobSet 사용
Kubernetes JobSet 리소스를 사용하여 TPU Pod 또는 멀티 노드 GPU 클러스터에서 실행되는 대규모 모델과 같이 여러 노드가 협력해야 하는 분산 추론 워크로드를 오케스트레이션하는 것이 좋습니다. 표준 Kubernetes 작업은 필요한 모든 포드가 동시에 시작되도록 보장할 수 없으므로 분산 워크로드에서 교착 상태가 발생할 수 있습니다.
JobSet은 작업 그룹을 하나의 단위로 관리하고 배치 추론에 다음과 같은 이점을 제공하는 Kubernetes 네이티브 API입니다.
- 그룹 스케줄링: 교착 상태를 방지하기 위해 워크로드를 시작하기 전에 TPU 슬라이스나 GPU 노드와 같은 필요한 모든 리소스를 사용할 수 있도록 지원합니다.
- 독점 배치: 단일 JobSet이 상호 연결 성능을 극대화하기 위해 네트워크 토폴로지 (예: TPU 슬라이스)에 독점적으로 액세스할 수 있도록 지원합니다.
- 실패 복구: 구성에 따라 작업자가 실패할 경우 특정 복제 작업 또는 전체 집합을 다시 시작할 수 있습니다.
데이터 샤딩에 색인화된 작업 사용
JobSet을 사용하는 경우 completionMode:
Indexed 설정을 사용하도록 ReplicatedJob를 구성합니다. 이 설정은 각 포드에 JOB_COMPLETION_INDEX 환경 변수를 자동으로 삽입합니다. 추론 코드는 이 색인을 사용하여 처리할 고유한 데이터 샤드를 결정론적으로 선택할 수 있습니다.
예를 들어 이미지가 100,000개 있는 Cloud Storage 버킷이 있고 병렬 처리가 10인 JobSet을 배포하는 경우 10개의 포드 각각이 시작 시 색인(0~9)을 읽습니다. 그러면 포드 0은 이미지 0~9,999를 처리해야 한다고 계산하고 포드 1은 10,000~19,999를 처리합니다. 이 접근 방식을 사용하면 별도의 작업 대기열 서비스가 필요하지 않습니다.
서버 포화에 사이드카 패턴 사용
액셀러레이터 사용률을 극대화하려면 사이드카 패턴을 사용하여 컨테이너가 두 개인 JobSet 포드를 구성하세요.
- 추론 서버: GPU 또는 TPU 계산에만 집중하는 최적화된 서버 (예: vLLM)입니다.
- 클라이언트 드라이버: localhost에서 서버로 많은 요청을 비동기식으로 전송하는 논리 컨테이너입니다.
이 분리를 통해 GPU 또는 TPU가 네트워크 I/O 또는 데이터 사전 처리를 기다리는 동안 유휴 상태가 되지 않고 계속 사용 중인 상태를 유지할 수 있습니다. 이 접근 방식이 없으면 데이터를 순차적으로 로드하는 모델로 인해 가속기가 I/O 작업이 완료될 때까지 기다려 활용도가 낮아질 수 있습니다. 예를 들어 데이터가 처리될 때까지 기다리는 대신 클라이언트 드라이버가 데이터를 미리 가져오고 추론 서버에 비동기 요청을 지속적으로 전송하여 가속기의 요청 대기열이 포화 상태로 유지되도록 할 수 있습니다.
체크리스트 요약
| 카테고리 | 권장사항 |
|---|---|
| 아키텍처 패턴 |
|
| 비용 및 처리량 |
|
| 메시지 및 확장 |
|
| 조정 |
|