이 문서에서는 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인수와 같은 추론 서버 구성을 확인하세요. 여러 항목을 단일 요청으로 그룹화하도록 클라이언트 로직을 구성하거나 각 작업이 요청 일괄 작업 크기를 충족하거나 초과하는 최소 데이터 양을 수신하도록 데이터를 샤딩할 수 있습니다. - 최대 일괄 작업 크기 계산: 워크로드 일괄 작업 크기를 사용하면
activeDeadlineSeconds제한 시간에 도달하기 전에 포드가 완료될 수 있습니다. Kubernetes 작업에 정의됨. 하나의 요청 일괄 작업을 처리하는 데 필요한 시간을 추정하고 포드가 제한 시간 내에 완료되도록 워크로드 크기를 설정합니다. 예를 들어activeDeadlineSeconds가 3,600초이고 시작 오버헤드가 600초인 경우 최대 실행 시간을 사용하면 포드가 3,000초 이내에 완료될 수 있습니다.
워크로드 일괄 작업 크기가 너무 작으면 작업에서 포드
시작 오버헤드 (가중치 다운로드, 프로비저닝, 가속기 초기화)에 시간을 낭비합니다.
너무 크면
GKE에서
activeDeadlineSeconds
제한 시간으로 인해 작업이 종료되어 작업이 실패하고 진행 상황이 손실될 위험이 있습니다.
요청 일괄 작업 크기 조정
요청 일괄 작업 크기는 추론 서버가 가속기에서 동시에 처리하는 동시 요청 수입니다. 추론 서버 구성에서 서버별 플래그 (예: 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의 배수로 구성합니다.
구독자 및 서버 자동 확장
효과적인 일괄 추론을 위해서는 구독자 (CPU 바인딩)를 추론 서버 (GPU 또는 TPU 바인딩)와 다르게 확장해야 합니다.
작업 백로그를 기반으로 구독자 확장: 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 사용
TPU 포드 또는 다중 노드 GPU 클러스터에서 실행되는 대규모 모델과 같이 여러 노드가 협력해야 하는 분산 추론 워크로드를 조정하려면 Kubernetes JobSet 리소스를 사용하는 것이 좋습니다. 표준 Kubernetes 작업은 필요한 모든 포드가 동시에 시작되도록 보장할 수 없으므로 분산 워크로드에서 교착 상태가 발생할 수 있습니다.
JobSet는 작업 그룹을 하나의 단위로 관리하고 일괄 추론에 다음과 같은 이점을 제공하는 Kubernetes 기본 API입니다.
- 갱 스케줄링: 교착 상태를 방지하기 위해 워크로드를 시작하기 전에 TPU 슬라이스 또는 GPU 노드와 같은 필요한 모든 리소스를 사용할 수 있도록 지원합니다.
- 독점 배치: 상호 연결 성능을 극대화하기 위해 단일 JobSet가 네트워크 토폴로지 (예: TPU 슬라이스)에 독점적으로 액세스할 수 있도록 지원합니다.
- 실패 복구: 구성에 따라 작업자가 실패하면 특정 복제된 작업 또는 전체 집합을 다시 시작할 수 있습니다.
데이터 샤딩에 색인화된 작업 사용
JobSet를 사용하는 경우 ReplicatedJob을 사용하도록 completionMode:
Indexed 설정을 구성합니다. 이 설정은 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 작업이 완료될 때까지 기다려 사용률이 저하될 수 있습니다. 예를 들어 클라이언트 드라이버는 데이터가 처리될 때까지 기다리는 대신 데이터를 미리 가져오고 추론 서버에 비동기 요청을 계속 전송하여 가속기의 요청 대기열이 포화 상태로 유지되도록 할 수 있습니다.
체크리스트 요약
| 카테고리 | 권장사항 |
|---|---|
| 아키텍처 패턴 | |
| 비용 및 처리량 |
|
| 메시징 및 확장 |
|
| 조정 |
|