GKE의 추론 권장사항 개요

Autopilot Standard

이 문서에서는 GKE에서 추론 워크로드를 실행하기 위한 권장사항을 개략적으로 설명합니다.

이 문서는 Kubernetes 및 GKE를 사용하여 GPU, TPU와 같은 가속기로 추론 워크로드에 권장사항을 적용하려는 데이터 관리자, 운영자, 개발자를 대상으로 합니다. 일반적인 역할에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참고하세요.

GKE에서 추론 제공 준비

이 섹션에서는 추론 워크로드 배포를 준비할 때 따라야 하는 기본적인 권장사항을 설명합니다. 이러한 사례에는 사용 사례 분석, 모델 선택, 액셀러레이터 선택이 포함됩니다.

추론 사용 사례의 특성 분석

추론 워크로드를 배포하기 전에 특정 요구사항을 분석하세요. 이 분석을 통해 성능, 비용, 안정성의 균형을 맞추는 아키텍처 결정을 내릴 수 있습니다. 사용 사례를 이해하면 서비스 수준 목표(SLO)를 충족하는 적절한 모델, 액셀러레이터, 구성을 선택하는 데 도움이 됩니다.

분석을 안내하려면 워크로드의 다음 주요 차원을 평가하세요.

• 성능 및 지연 시간 요구사항 정의: 지연 시간 및 처리량에 대한 애플리케이션의 SLO를 결정합니다. 정의할 주요 측정항목에는 초당 요청 수 (RPS), 응답 지연 시간, 입력 및 출력 토큰 길이, 접두사 캐시 적중률이 포함됩니다. 자세한 내용은 추론 성능 측정항목을 참고하세요.
• 모델 요구사항 및 확장 평가: 선택한 모델의 특성은 인프라 요구사항에 직접적인 영향을 미칩니다. 모델이 지원하는 최대 컨텍스트 길이를 고려하고 워크로드에 필요한 길이와 비교합니다. 사용 사례에 최대 컨텍스트가 필요하지 않은 경우 최대 컨텍스트 길이를 줄이면 더 큰 KV 캐시를 위해 액셀러레이터 메모리를 확보하여 처리량을 늘릴 수 있습니다.
• 비용 및 비즈니스 제약조건 설정: 예산과 비즈니스 목표는 지속 가능하고 비용 효율적인 추론 서비스를 설계하는 데 중요한 요소입니다. 입력 및 출력의 타겟 백만 토큰당 비용과 이 워크로드의 총 월별 예산을 정의합니다. 가격 대비 성능, 최저 지연 시간, 최고 처리량과 같은 최적화 목표와 앱이 가변 지연 시간을 허용할 수 있는지 여부를 파악합니다.

추론 사용 사례에 적합한 모델 선택

적절한 모델을 선택하면 추론 애플리케이션의 성능, 비용, 실현 가능성에 직접적인 영향을 미칩니다. 최적의 모델을 선택하려면 다음 기준에 따라 후보를 평가하세요.

• 작업 및 모달리티 정렬: 지정된 작업 및 지원되는 모달리티를 기반으로 모델을 평가합니다. 특정 작업에 최적화된 모델은 거의 항상 더 범용적인 모델보다 성능이 뛰어납니다.
• 기술적 특성: 모델의 아키텍처와 데이터 유형 정밀도(예: FP16, FP8, FP4)는 리소스 요구사항과 성능을 결정하는 주요 요소입니다. 이 평가를 통해 양자화 기법을 적용해야 하는지 확인할 수 있습니다. 모델 가중치의 지원되는 정밀도를 확인하고, 프레임워크 지원을 확인하고, 모델의 최대 지원 컨텍스트 길이를 확인합니다.
• 성능 및 비용 효율성: 데이터 기반 결정을 내리려면 공개적으로 제공되는 벤치마크와 자체 내부 테스트를 사용하여 선택한 모델을 비교하세요. Chatbot Arena와 같은 리더보드를 사용하여 모델을 비교하고 타겟 하드웨어에서 각 모델의 백만 토큰당 비용을 평가합니다.

모델에 양자화 적용

양자화는 모델의 메모리 사용량을 줄여 추론 워크로드를 최적화하는 기법입니다. 모델의 가중치, 활성화, 키-값 (KV) 캐시를 정밀도가 높은 부동 소수점 형식 (예: FP16, FP32, FP64)에서 정밀도가 낮은 형식 (예: FP8, FP4)으로 변환합니다. 메모리가 줄어들면 성능과 비용 효율성이 크게 개선될 수 있습니다.

양자화는 모델의 메모리 사용 공간을 줄여 데이터 전송 오버헤드를 줄이고 더 큰 KV 캐시를 위한 메모리를 확보합니다.

모델에 양자화를 효과적으로 적용하려면 다음 권장사항을 따르세요.

• 정확도 절충 평가: 양자화로 인해 모델 정확도가 손실될 수 있습니다. 양자화의 정확도 트레이드오프를 평가할 때는 8비트 양자화로 정확도 손실을 최소화할 수 있는 경우가 많다는 점을 고려하세요. 반면 4비트 양자화는 액셀러레이터 메모리 요구사항을 최대 4배까지 줄일 수 있지만 8비트 양자화에 비해 정확도 손실이 더 클 수도 있습니다. 정확도가 여전히 허용 범위 내에 있는지 확인하기 위해 특정 사용 사례에서 양자화된 모델의 성능을 평가합니다. 정확도 손실을 평가하려면 OpenCompass 및 Language Model Evaluation Harness와 같은 도구를 사용하면 됩니다.
• 하드웨어 가속 지원 평가: 양자화의 이점을 최대한 활용하려면 양자화된 모델이 사용하는 데이터 형식에 하드웨어 가속을 제공하는 가속기를 사용하세요. 예를 들면 다음과 같습니다.
  • NVIDIA H100 GPU는 FP8 및 FP16 작업을 위한 하드웨어 가속을 제공합니다.
  • NVIDIA B200 GPU는 FP4, FP8, FP16 작업에 하드웨어 가속을 제공합니다.
  • Cloud TPU v5p는 FP8 작업을 위한 하드웨어 가속을 제공합니다.
• 사전 양자화된 모델 확인: 모델을 직접 양자화하기 전에 Hugging Face와 같은 공개 모델 저장소를 확인하세요. 이상적으로는 낮은 정밀도로 기본적으로 학습된 모델을 찾는 것이 좋습니다. 이렇게 하면 학습 후 양자화로 인한 정확도 손실 가능성 없이 성능 이점을 얻을 수 있습니다.
• 양자화 라이브러리 사용: 사전 양자화된 모델을 사용할 수 없는 경우 라이브러리를 사용하여 직접 양자화를 실행합니다. vLLM과 같은 추론 서버는 다양한 기법으로 양자화된 모델 실행을 지원합니다. llm-compressor와 같은 도구를 사용하여 양자화되지 않은 모델에 양자화 기법을 적용할 수 있습니다.
• KV 캐시 양자화 고려: 모델의 가중치를 양자화하는 것 외에도 KV 캐시를 양자화할 수 있습니다. 이 기법은 런타임에 KV 캐시에 필요한 메모리를 더욱 줄여 성능을 개선할 수 있습니다.

자세한 내용은 GPU에서 LLM 추론 워크로드 최적화를 참고하세요.

적절한 가속기 선택

적절한 액셀러레이터를 선택하면 추론 서비스의 성능, 비용, 사용자 경험에 직접적인 영향을 미칩니다. 최적의 선택은 모델의 메모리 요구사항, 성능 목표, 예산을 분석하여 결정됩니다.

도움말: 모델 서빙 성능 및 비용을 자세히 분석하려면 GKE Inference Quickstart 도구를 사용하는 것이 좋습니다. 자세한 내용은 GKE Inference Quickstart 가이드와 함께 제공되는 Colab 노트북을 참고하세요.

특정 사용 사례에 맞는 가속기를 선택하려면 다음 단계를 따르세요.

1. 메모리 요구사항 계산: 먼저 모델을 로드하고 실행하는 데 필요한 최소 액셀러레이터 메모리를 계산합니다. 총 메모리는 모델 가중치, 추론 엔진 오버헤드, 중간 활성화, KV 캐시에 필요한 메모리의 합계입니다.

   필요한 메모리를 추정하려면 다음 방정식을 사용하세요.

   \[ \begin{aligned} \text{Required accelerator memory} = {} & (\text{Model weights} + \text{Overhead} + \text{Activations}) \\ & + (\text{KV cache per batch} \times \text{Batch size}) \end{aligned} \]

   방정식의 용어는 다음과 같습니다.

   • 모델 가중치: 모델 매개변수의 크기입니다.
   • 오버헤드: 추론 서버 및 기타 시스템 오버헤드를 위한 버퍼로, 일반적으로 1~2GB입니다.
   • 활성화: 모델 실행 중에 중간 활성화에 필요한 메모리입니다.
   • 배치당 KV 캐시: 단일 시퀀스의 KV 캐시에 필요한 메모리로, 컨텍스트 길이와 모델 구성에 따라 확장됩니다.
   • 배치 크기: 추론 엔진에서 동시에 처리할 시퀀스 (max_num_sequences)의 수입니다.

   예: Gemma 3의 가속기 메모리 요구사항 계산

   텍스트 생성 사용 사례를 위해 BF16 정밀도로 Gemma 3 270억 매개변수 모델을 배포하는 데 필요한 액셀러레이터 메모리를 계산하려면 다음 값을 사용하면 됩니다.

   이 계산에 관한 대화형 안내는 모델에 필요한 VRAM은 얼마인가요?를 참고하세요. Colab 노트북

   • 입력:
     • 모델 가중치: 54GB
     • 배치 크기 (max_num_sequences): 1
     • 평균 입력 길이: 1,500개 토큰
     • 평균 출력 길이: 200토큰
     • 추론 엔진 오버헤드: 1GB (추정)
     • KV 캐시 데이터 유형 크기: 2 (BF16의 경우)
     • KV 벡터: 2 (키용 1개, 값용 1개)
   • Gemma 3 27B 명령 조정 모델의 모델 구성:
     • hidden_size: 5376
     • intermediate_size: 21504
     • num_attention_heads: 32
     • num_hidden_layers: 62
     • num_key_value_heads: 16
   • 메모리 계산:
     • sequence_length = avg_input_length + avg_output_length = 1500 + 200 = 1700 토큰
     • pytorch_activation_peak_memory = (max_num_sequences * sequence_length * (18 * hidden_size + 4 * intermediate_size)) / (1000^3) = ~0.31GB (추정치)
     • head_dims = hidden_size / num_attention_heads = 5376 / 32 = 168
     • kv_cache_memory_per_batch = (kv_vectors * max_num_sequences * sequence_length * num_key_value_heads * head_dims * num_hidden_layers * kv_data_type_size) / (1000^3) = (2 * 1 * 1700 * 16 * 168 * 62 * 2) / (1000^3) = ~1.13GB
     • 필요한 액셀러레이터 메모리 = Model weights + Overhead + Activations + KV cache per batch = 54 + 1 + 0.31 + 1.13 = ~56.44GB

   모델을 배포하는 데 필요한 총 예상 가속기 메모리는 약 57GB입니다.

2. 가속기 옵션 평가: 메모리 요구사항을 추정한 후 GKE에서 사용 가능한 GPU 및 TPU 옵션을 평가합니다.

   가속기 메모리 크기 외에도 평가를 위해 다음 모델 요구사항을 고려하세요.

   • 액셀러레이터가 두 개 이상 필요한 모델의 경우 통신 지연 시간을 줄이기 위해 NVLINK 및 GPUDirect와 같은 고속 연결 지원을 확인하세요.
   • 양자화된 모델의 경우 FP8, FP4와 같은 낮은 정밀도 데이터 유형에 네이티브 하드웨어 가속이 적용된 액셀러레이터를 사용하여 성능을 최대한 높이세요.

   선택에는 이러한 기능, 성능, 비용, 가용성 간의 절충이 포함됩니다.

   사용 사례별 권장 가속기

   도움말: 서빙 성능 벤치마크 및 비용 분석에 기반한 최신 가속기 추천을 위해 GKE Inference Quickstart 도구를 사용할 수도 있습니다. 자세한 내용은 GKE Inference Quickstart 문서를 참고하세요.

   워크로드에 적합한 가속기를 선택할 수 있도록 다음 표에서는 일반적인 추론 사용 사례에 가장 적합한 옵션을 요약합니다. 이러한 사용 사례는 다음과 같이 정의됩니다.

   • 소규모 모델 추론: 계산 부하가 단일 호스트로 제한되는 수십억 개의 파라미터가 있는 모델
   • 단일 호스트 대규모 모델 추론: 파라미터가 수십억에서 수백억에 달하는 모델로, 단일 호스트 머신의 여러 액셀러레이터 간에 컴퓨팅 부하가 공유됩니다.
   • 다중 호스트 대규모 모델 추론: 수천억에서 수조 개의 파라미터가 있는 모델로, 계산 부하가 여러 호스트 머신의 여러 가속기에 공유됩니다.

   사용 사례	추천 액셀러레이터	머신 계열	주요 특징
   소규모 모델 추론	NVIDIA L4	G2	소규모 모델에 적합한 비용 효율적인 옵션 (GPU당 24GB 메모리)
   	NVIDIA RTX Pro 6000	G4	300억 미만의 파라미터 모델 및 이미지 생성에 비용 효율적입니다 (GPU당 96GB 메모리). 직접 GPU P2P 통신을 지원하므로 단일 호스트, 멀티 GPU 추론에 적합합니다.
   	TPU v5e	-	비용 효율성을 위해 최적화되었습니다.
   	TPU v6e	-	트랜스포머 및 텍스트 이미지 변환 모델에 가장 높은 가치를 제공합니다.
   단일 호스트 대규모 모델 추론	NVIDIA A100	A2	단일 노드에 적합한 대부분의 모델 (총 메모리 최대 640GB)에 적합합니다.
   	NVIDIA H100	A3	단일 노드 (최대 640GB 총 메모리)에 적합한 추론 워크로드에 적합합니다.
   	NVIDIA B200	A4	단일 노드에 적합한 까다로운 모델을 위한 미래 지향적 옵션 (최대 1,440GB 총 메모리).
   	TPU v4	-	비용과 성능 간의 균형을 잘 유지합니다.
   	TPU v5p	-	까다로운 워크로드를 위한 고성능 옵션입니다.
   멀티 호스트 대규모 모델 추론	NVIDIA H200	A3 Ultra	대규모 메모리 집약적 모델 (최대 1,128GB 총 메모리)에 적합합니다.
   	NVIDIA B200 / GB200	A4 / A4X	가장 까다롭고 컴퓨팅 집약적이며 네트워크 바운드 워크로드에 적합합니다. A4X 머신은 Arm 기반 CPU를 사용하므로 워크로드에서 x86 전용 기능이나 최적화를 사용하는 경우 워크로드 리팩터링 (간단한 컨테이너 재빌드를 넘어선 코드 변경)이 필요할 수 있습니다.
   	TPU v5e	-	중대형 LLM 제공을 위한 비용 효율성 및 성능에 최적화되어 있습니다.
   	TPU v5p	-	대규모 병렬화가 필요한 멀티 호스트 추론을 위한 고성능 옵션입니다.
   	TPU v6e	-	변환기, 텍스트-이미지, CNN 서빙에 최적화되어 있습니다.

   예: 260GB 모델의 가속기 선택

   총 가속기 메모리가 260GB (모델용 200GB, KV 캐시용 50GB, 오버헤드용 10GB)인 모델을 배포해야 한다고 가정해 보겠습니다.

   메모리 요구사항만 고려하면 가장 큰 G2 머신이 최대 192GB의 가속기 메모리를 제공하므로 NVIDIA L4 GPU를 제외할 수 있습니다. 또한 L4 GPU는 가속기 간의 고속, 짧은 지연 시간 연결을 지원하지 않으므로 여러 노드에 워크로드를 분산하는 것은 원하는 성능을 달성하기 위한 실행 가능한 옵션이 아닙니다.

   x86-64 워크로드를 리팩터링하지 않으려면 (즉, 다른 유형의 프로세서에서 실행될 수 있도록 코드를 수정해야 함) Arm 기반 CPU를 사용하는 NVIDIA GB200 및 GB300 액셀러레이터도 제외합니다.

   따라서 다음과 같은 옵션이 있습니다.

   • NVIDIA A100
   • NVIDIA RTX Pro 6000
   • NVIDIA H100
   • NVIDIA H200
   • NVIDIA B200

   이러한 모든 가속기에는 충분한 메모리가 있습니다. 다음 단계는 타겟 지역에서 사용할 수 있는지 평가하는 것입니다. 특정 리전에서 NVIDIA A100 및 NVIDIA H100 GPU만 사용할 수 있다고 가정해 보겠습니다. 이 두 옵션의 가격 대비 성능 비율을 비교한 후 워크로드에 NVIDIA H100을 선택할 수 있습니다.

   멀티 인스턴스 GPU

   GPU 사용률을 높이고 GPU 비용을 최적화하려면 멀티 인스턴스 GPU 구성을 사용하면 됩니다. 이 구성을 사용하면 지원되는 GPU를 파티셔닝하여 GKE의 여러 컨테이너에서 단일 GPU를 공유할 수 있습니다. 멀티 인스턴스 GPU를 프로비저닝할 때는 전체 GPU만 GKE 노드에 연결하며 해당 GPU 가격이 적용됩니다. 신뢰할 수 있는 워크로드에만 멀티 인스턴스 GPU를 사용하는 것이 좋습니다.

   예를 들어 NVIDIA RTX PRO 6000을 연결하고 다음 작업을 할 수 있습니다.

   • 가속기 메모리가 각각 24GB인 인스턴스 4개로 파티셔닝하고, 약 80억 개의 파라미터가 있고 모델 가중치에 FP16 데이터 형식 정밀도를 사용하는 모델과 같은 확산 모델 또는 소형 모델 추론 워크로드를 실행합니다. 이 파티션은 NVIDIA L4에 비해 가격 대비 성능 비율이 더 나을 수 있습니다.
   • 두 인스턴스로 파티셔닝하고 (각 인스턴스는 48GB의 가속기 메모리 제공) 약 150억 개의 파라미터가 있고 모델 가중치에 FP16 데이터 형식 정밀도를 사용하는 모델과 같은 소규모 모델 추론 워크로드를 실행합니다. 이 파티션은 NVIDIA A100 40GB GPU에서 추론 워크로드를 실행하는 대안이 될 수 있습니다.

   자세한 내용은 멀티 인스턴스 GPU 실행을 참고하세요.

   자세한 내용은 Compute Engine 문서의 GPU 머신 유형 및 가속기 최적화 머신 계열을 참고하세요.

3. 추론 배포 전략 선택: 모델이 단일 액셀러레이터에 비해 너무 큰 경우 워크로드 요구사항에 따라 배포 전략을 선택합니다.

   먼저 하드웨어의 토폴로지에 따라 배포 전략을 선택합니다.

   • 단일 가속기: 모델이 단일 가속기에 적합한 경우 가장 간단하며 권장되는 접근 방식입니다.
   • 단일 노드, 다중 가속기: 모델이 다중 가속기가 있는 단일 노드에 적합한 경우 텐서 동시 로드를 사용하여 해당 노드의 가속기에 모델을 분산할 수 있습니다.
   • 다중 노드, 다중 액셀러레이터: 모델이 단일 노드에 비해 너무 큰 경우 텐서와 파이프라인 동시 로드를 조합하여 여러 노드에 분산할 수 있습니다.

   이러한 전략을 구현하려면 다음 병렬 처리 기법을 사용하면 됩니다.

   • 텐서 병렬 처리: 이 기술은 여러 가속기에 모델의 레이어를 샤딩합니다. NVLINK 또는 직접 피어 투 피어 PCIe와 같은 고속 상호 연결이 있는 단일 노드 내에서는 매우 효과적이지만 액셀러레이터 간에 상당한 통신이 필요합니다.

     예: 텐서 동시 로드

     예를 들어 1, 090억 개의 매개변수가 있는 모델을 배포해야 한다고 가정해 보겠습니다. 기본 BF16 (16비트) 정밀도에서 모델의 가중치를 가속기 메모리에 로드하려면 약 113GB가 필요합니다. 단일 NVIDIA H100 GPU는 80GB의 메모리를 제공합니다. 따라서 KV 캐시와 같은 다른 메모리 요구사항을 고려하지 않더라도 텐서 병렬 처리 크기 2를 사용하여 모델을 로드하려면 NVIDIA H100 GPU가 2개 이상 필요합니다.

   • 파이프라인 병렬 처리: 이 기법은 여러 노드에 모델의 레이어를 순차적으로 파티셔닝합니다. 멀티 호스트 배포에서 여러 노드에 모델을 분산하는 데 적합하며 텐서 병렬 처리보다 모델 순위 간 통신이 적게 필요합니다.

     예: 하이브리드 병렬 처리 (텐서 및 파이프라인)

     파라미터가 6, 000억 개가 넘는 매우 큰 모델의 경우 메모리 요구사항이 1.1TB를 초과할 수 있습니다. a3-megagpu-8g 노드가 2개 (각각 NVIDIA H100 GPU 8개 포함)인 시나리오에서 전체 클러스터의 가속기 메모리는 1.28TB입니다. 모델을 실행하려면 각 노드 내에서 8방향 텐서 동시 로드를, 두 노드 간에 2방향 파이프라인 동시 로드를 사용하는 하이브리드 전략을 구현합니다. 모델이 두 단계로 분할되어 레이어의 전반부는 첫 번째 노드에 있고 후반부는 두 번째 노드에 있습니다. 요청이 도착하면 첫 번째 노드가 요청을 처리하고 중간 데이터를 네트워크를 통해 두 번째 노드로 전송하여 계산을 완료합니다.

   단일 모델 복제본의 분산 추론 전략 선택에 관한 자세한 가이드라인은 vLLM 문서의 병렬 처리 및 확장을 참고하세요.

4. 가속기 최적화 머신 유형 선택: 가속기 선택 및 필요한 수에 따라 해당 리소스를 제공하는 머신 유형을 선택합니다. 각 머신 유형은 vCPU, 시스템 메모리, 네트워크 대역폭의 특정 조합을 제공하며, 이는 워크로드의 성능에도 영향을 미칠 수 있습니다. 예를 들어 NVIDIA H100 GPU가 16개 필요한 경우 a3-megagpu-16g 머신 유형을 선택합니다.

5. 자체 벤치마크 실행: 추론 워크로드의 성능은 특정 사용 사례에 따라 크게 달라집니다. 자체 벤치마크를 실행하여 선택사항을 검증하고 구성을 미세 조정하세요.

추론 서버 구성 최적화

추론 워크로드를 배포할 때 최적의 성능을 얻으려면 벤치마킹 및 튜닝 주기를 사용하는 것이 좋습니다.

1. GKE 추론 빠른 시작으로 시작하여 사용 사례에 맞게 최적화된 기준 Kubernetes 구성을 가져옵니다.
2. 벤치마크를 실행하여 기준 처리량 및 지연 시간 측정항목을 캡처합니다.
3. 추론 서버의 구성을 조정합니다.
4. 벤치마크를 다시 실행하고 결과를 비교하여 변경사항을 검증합니다.

다음 권장사항은 vLLM 추론 서버를 기반으로 하지만 원칙은 다른 서버에도 적용됩니다. 사용 가능한 모든 설정에 관한 자세한 안내는 vLLM 최적화 및 조정 문서를 참고하세요.

• 병렬 처리 구성:
  • 텐서 병렬 처리 (tensor_parallel_size): 워크로드를 샤딩하기 위해 단일 노드의 가속기 수로 설정합니다. 예를 들어 tensor_parallel_size=4를 설정하면 워크로드가 4개의 액셀러레이터에 분산됩니다. 이 값을 늘리면 과도한 동기화 오버헤드가 발생할 수 있습니다.
  • 파이프라인 병렬 처리 (pipeline_parallel_size): 모델을 배포할 노드 수로 설정합니다. 예를 들어 가속기가 각각 8개인 두 노드에 배포하는 경우 tensor_parallel_size=8 및 pipeline_parallel_size=2를 설정합니다. 이 값을 늘리면 지연 시간 페널티가 발생할 수 있습니다.
• KV 캐시 조정 (gpu_memory_utilization): 이 매개변수는 모델 가중치, 활성화, KV 캐시를 위해 예약된 GPU 메모리의 비율을 제어합니다. 값이 클수록 KV 캐시 크기가 증가하여 처리량이 개선될 수 있습니다. 이 값을 0.9~0.95 사이의 값으로 설정하는 것이 좋습니다. 메모리 부족 (OOM) 오류가 발생하면 이 값을 낮춥니다.
• 최대 컨텍스트 길이 (max_model_len) 구성: KV 캐시 크기 및 메모리 요구사항을 줄이려면 모델의 기본값보다 낮은 최대 컨텍스트 길이를 설정하면 됩니다. 이를 통해 더 작고 비용 효율적인 GPU를 사용할 수 있습니다. 예를 들어 사용 사례에 40,000개의 토큰 컨텍스트만 필요하지만 모델의 기본값은 256,000인 경우 max_model_len를 40,000으로 설정하면 더 큰 KV 캐시를 위한 메모리가 확보되어 처리량이 높아질 수 있습니다.
• 동시 요청 수 구성 (max_num_batched_tokens, max_num_seqs): KV 캐시의 공간이 부족할 때 선점을 방지하기 위해 vLLM이 동시에 처리하는 최대 요청 수를 조정합니다. max_num_batched_tokens 및 max_num_seqs 값이 낮을수록 메모리 요구사항이 줄어들고, 값이 높을수록 OOM 오류 위험이 있지만 처리량이 향상될 수 있습니다. 최적의 값을 찾으려면 성능 실험을 실행하고 vLLM에서 내보내는 Prometheus 측정항목의 선점 요청 수를 관찰하는 것이 좋습니다.

자세한 내용은 다음 리소스를 참조하세요.

• 이러한 매개변수를 조정하는 방법을 자세히 알아보려면 vLLM 성능 조정: xPU 추론 구성에 관한 궁극적인 가이드를 참고하세요.
• 모델 메모리 최적화에 관한 자세한 내용은 GKE에서 GPU를 사용하여 대규모 언어 모델 추론을 최적화하기 위한 권장사항을 참고하세요.
• 배포 가능한 전체 예시는 GKE 추론 참조 구현을 참고하세요.

지연 시간 및 가용성 최적화

추론 서비스가 응답성이 높고 안정적이려면 시작 지연 시간이 짧고 리소스 가용성이 높도록 최적화해야 합니다.

추론 워크로드 콜드 스타트 지연 시간 최적화

추론 워크로드가 시작되는 시간을 최소화하는 것은 비용 효율성과 사용자 환경 모두에 중요합니다. 콜드 스타트 지연 시간이 짧으면 클러스터를 빠르게 확장하여 수요를 충족할 수 있으므로 비용이 많이 드는 과도한 프로비저닝의 필요성을 최소화하면서 응답성이 뛰어난 서비스를 보장할 수 있습니다.

포드 시작 시간 최적화

포드가 준비되는 데 걸리는 시간은 컨테이너 이미지를 가져오고 모델 가중치를 다운로드하는 데 걸리는 시간에 따라 크게 달라집니다. 두 가지를 모두 최적화하려면 다음 전략을 고려하세요.

• 최적화된 데이터 로더로 모델 로드 속도 높이기: 모델 가중치를 저장하고 로드하는 방법은 시작 시간에 큰 영향을 미칩니다. vLLM 버전 0.10.2 이상에서는 Run:ai Model Streamer를 사용하여 Cloud Storage 버킷에서 직접 스트리밍하여 모델을 로드하는 것이 좋습니다.

  사용 사례에 스트리머를 사용할 수 없는 경우 Cloud Storage FUSE를 사용하여 Cloud Storage 버킷을 마운트하고 계층적 네임스페이스를 사용 설정하고 병렬 다운로드 및 사전 가져오기와 같은 기법을 사용하여 성능을 조정할 수 있습니다. 이러한 기법에 대해 자세히 알아보려면 GKE 성능을 위해 Cloud Storage FUSE CSI 드라이버 최적화를 참고하세요. 어떤 경우든 Anywhere Cache를 사용하여 버킷의 고성능 리전 읽기 캐시를 만들고 균일한 버킷 수준 액세스를 사용 설정하여 버킷에 대한 액세스를 균일하게 제어하는 것이 좋습니다.

  학습 워크로드의 고성능 파일 스토리지를 위해 이미 Managed Lustre를 사용하고 있는 경우 추론을 위해 모델 가중치를 로드하는 데도 사용할 수 있습니다. 이 접근 방식은 데이터 지역성과 POSIX 호환성이 중요한 경우 지연 시간이 짧은 액세스를 제공합니다.

• 이미지 스트리밍 사용 설정: 컨테이너 이미지를 가져오는 데 걸리는 시간을 줄이려면 GKE 클러스터에서 이미지 스트리밍을 사용 설정하세요. 이미지 스트리밍을 사용하면 전체 이미지가 다운로드되기 전에 컨테이너를 시작할 수 있으므로 Pod 시작 시간을 크게 줄일 수 있습니다.

빠르게 시작하는 노드 사용 설정

빠른 확장이 필요한 워크로드의 경우 GKE의 빠른 시작 노드를 활용할 수 있습니다. 빠른 시작 노드는 표준 노드보다 시작 시간이 크게 단축된 사전 초기화된 하드웨어 리소스입니다. 클러스터가 요구사항을 충족하는 경우 GKE는 빠른 시작 노드를 자동으로 사용 설정합니다.

용량 계획 및 액셀러레이터 획득 가능성 극대화

GPU 및 TPU와 같이 수요가 많은 가속기는 가용성이 제한될 수 있으므로 사전 용량 계획 전략이 필수입니다.

용량 계획 및 예약

수요가 많은 가속기는 사용 가능 여부가 제한될 수 있으므로 사전 용량 계획 전략이 필수입니다. 필요한 리소스에 대한 액세스를 보장하려면 다음 권장사항을 따르세요.

• 용량 기준 및 최대 처리량 결정: 예약해야 하는 기준 액셀러레이터 용량을 계획합니다. 예약할 금액은 사용 사례에 따라 다릅니다. 예를 들어 지연이 허용되지 않는 중요한 워크로드에 필요한 용량의 100% 를 예약하거나 특정 백분위수 (예: 90번째 또는 95번째)를 예약하고 나머지는 주문형으로 획득하여 피크를 처리할 수 있습니다.

• 기준 용량 예약: 신뢰도가 높은 리소스를 확보하려면 예약을 만드세요. 필요에 따라 예약 유형을 선택할 수 있습니다. 예를 들어 특정 미래 기간에 가속기와 같은 수요가 많은 리소스를 예약하려면 캘린더 모드에서 미래용 예약을 만들면 됩니다.

• 피크 시 용량 오케스트레이션: 기준 예약보다 수요가 많은 경우 주문형, 스팟 VM, 동적 워크로드 스케줄러 (DWS)와 같은 다른 용량 유형을 사용하여 대체 전략을 구현할 수 있습니다. 커스텀 컴퓨팅 클래스를 사용하여 다양한 용량 유형의 프로비저닝 우선순위를 정의하면 이 대체 전략을 자동화할 수 있습니다.

• 할인된 가격으로 이용: 기준 용량의 경우 약정 사용 할인 (CUD)을 구매하여 1년 또는 3년 약정의 대가로 대폭 할인된 가격을 이용하세요.

워크로드에서 용량 획득 지연을 허용하는 경우 flex-start 프로비저닝 모드와 함께 동적 워크로드 스케줄러 사용

용량 획득에 약간의 지연이 허용되는 워크로드의 경우 flex-start 프로비저닝 모드가 있는 동적 워크로드 스케줄러 (DWS)를 사용하면 할인된 가격으로 가속기를 획득할 수 있습니다. DWS를 사용하면 최대 7일 동안 용량 요청을 대기열에 추가할 수 있습니다.

flex-start 프로비저닝 모드에서 DWS를 사용하는 경우 다음을 권장합니다.

• 커스텀 컴퓨팅 클래스에 통합: 커스텀 컴퓨팅 클래스를 사용하여 용량 획득을 위한 우선순위가 지정된 대체 전략의 일부로 DWS를 정의합니다.
• 최대 런타임 기간 설정: maxRunDurationSeconds 매개변수는 DWS를 통해 요청된 노드의 최대 런타임을 설정합니다. 이 값을 기본값인 7일보다 낮은 값으로 설정하면 요청한 노드를 얻을 가능성이 높아집니다.
• 노드 재활용 사용 설정: 워크로드의 다운타임을 방지하려면 노드 재활용을 사용 설정하세요. 이 기능은 이전 노드가 만료되기 전에 새 노드를 프로비저닝하여 더 원활한 전환을 보장합니다.
• 중단 최소화: 노드 삭제 및 업그레이드로 인한 중단을 최소화하려면 유지보수 기간 및 제외를 구성하고, 노드 자동 복구를 사용 중지하고, 단기 업그레이드 전략을 활용하세요.

커스텀 컴퓨팅 클래스 사용

커스텀 컴퓨팅 클래스 (CCC)는 워크로드의 우선순위가 지정된 인프라 구성 목록을 정의할 수 있는 GKE 기능입니다. CCC는 가속기 획득 가능성을 개선하도록 설계된 주요 기능을 제공합니다.

• 대체 컴퓨팅 우선순위: 우선순위가 지정된 구성 목록을 정의할 수 있습니다. 스케일 업 이벤트 중에 선호하는 옵션을 사용할 수 없는 경우 자동 확장 처리기는 목록의 다음 옵션으로 자동 대체하여 용량을 확보할 가능성을 크게 높입니다.
• 우선순위가 더 높은 노드로의 활성 마이그레이션: 이 기능을 구성하면 우선순위가 낮은 구성에서 실행되는 노드가 우선순위가 높은 구성의 노드로 자동으로 대체됩니다. 따라서 포드가 결국 가장 선호되는(그리고 종종 가장 비용 효율적인) 노드에서 실행됩니다.

맞춤 컴퓨팅 클래스 (CCC)를 사용하면 노드 획득을 위한 대체 전략을 만들 수 있습니다. 이 전략은 주문형 VM, 스팟 VM, 예약과 같은 다양한 용량 유형의 우선순위가 지정된 목록을 사용합니다. 이러한 각 용량 유형은 가용성 수준이 다릅니다.

• 예약: 용량 확보를 위한 최고 수준의 확신을 제공합니다. CCC로 예약을 사용할 때는 제한사항을 고려하세요. 예를 들어 일부 예약 유형은 예약할 수 있는 머신 유형이나 요청할 수 있는 최대 머신 수를 제한합니다.
• 주문형: 유연성을 제공하지만 수요가 많은 리소스의 경우 지역별 용량 제약이 적용될 수 있는 표준 프로비저닝 모델입니다.
• 스팟 VM: 예비 용량을 저렴한 가격으로 사용하지만 선점될 수 있습니다. 선점 이벤트가 발생하면 GKE는 최선을 다해 영향을 받는 포드에 최대 30초의 단계적 종료 기간을 제공합니다. 이를 활용하려면 체크포인트 및 재시도 메커니즘을 구현하여 워크로드가 선점 이벤트에 허용되도록 하세요.
• 동적 워크로드 스케줄러 (DWS): 희소 리소스에 대한 요청을 할인된 가격으로 큐에 추가할 수 있습니다. 이 기능은 용량 획득 지연을 허용할 수 있는 워크로드에 적합합니다.

기본 목표가 지연 시간 최소화인지 비용 최적화인지에 따라 우선순위 목록의 순서가 달라져야 합니다. 예를 들어 다양한 워크로드 요구사항에 대해 다음과 같은 우선순위 목록을 구성할 수 있습니다.

우선순위	짧은 지연 시간 워크로드	비용 최적화 (지연 시간 허용) 워크로드
1	예약 (특정, 모든)	예약 (특정, 모든)
2	주문형	스팟 VM
3	스팟 VM	동적 워크로드 스케줄러
4	동적 워크로드 스케줄러	주문형

지연 시간이 짧은 사용 사례의 경우 예약 후 온디맨드 용량이 우선순위가 지정됩니다. 온디맨드 용량은 용량 부족을 신속하게 보고하므로 CCC가 다음 옵션으로 빠르게 대체할 수 있습니다.

비용 최적화 사용 사례의 경우 예약 후 스팟 VM과 flex-start가 적용된 DWS가 낮은 비용을 활용하기 위해 우선순위가 지정됩니다. 주문형 용량은 최종 대체로 사용됩니다.

GKE 클러스터 및 노드 풀의 위치 정책 구성

클러스터 자동 확장 처리의 위치 정책은 확장 이벤트 중에 GKE가 영역 간에 노드를 분산하는 방식을 제어합니다. 이 설정은 CCC의 우선순위 목록을 적용하기 전에 클러스터 자동 확장 처리기가 고려할 영역을 결정하므로 커스텀 컴퓨팅 클래스를 사용할 때 특히 중요합니다.

액셀러레이터를 획득할 가능성을 높이려면 워크로드의 요구사항에 따라 위치 정책을 구성하세요.

• location-policy=ANY: 영역 간에 노드를 균등하게 분산하는 것보다 용량 확보를 우선시합니다. 이 설정은 CCC에 스팟 VM 또는 가용성이 가변적인 머신 유형이 포함된 경우에 특히 유용합니다. ANY를 사용하면 클러스터 자동 확장 처리기가 CCC의 우선순위가 지정된 노드 유형을 충족할 가능성이 가장 높은 영역을 선택할 수 있기 때문입니다. 이 설정을 사용하여 사용되지 않은 예약의 사용에 우선순위를 둘 수도 있습니다. 이 정책을 사용할 때는 클러스터 자동 확장 처리기가 용량을 찾는 데 최대한 유연할 수 있도록 num-nodes=0로 시작하는 것이 좋습니다.

• location-policy=BALANCED: 사용 가능한 모든 영역에 노드를 균등하게 분산하려고 시도합니다. 워크로드에서 쉽게 구할 수 있는 리소스를 사용하고 고가용성을 위해 영역 중복을 유지하려는 경우 이 정책을 사용하세요.

노드 풀을 만들거나 업데이트할 때 이 설정을 구성할 수 있습니다.

효율성 및 비용에 맞게 최적화

액셀러레이터를 주의 깊게 모니터링하고 워크로드를 지능적으로 확장하면 낭비를 크게 줄이고 운영 비용을 절감할 수 있습니다.

액셀러레이터 및 추론 서버 관찰

추론 워크로드의 성능과 활용도를 파악하려면 포괄적인 관측 가능성 전략이 필수적입니다. GKE는 가속기 및 추론 서버를 모니터링하는 데 도움이 되는 도구 모음을 제공합니다.

• NVIDIA GPU의 DCGM 측정항목 모니터링: NVIDIA GPU의 상태와 성능을 모니터링하려면 GKE가 NVIDIA Data Center GPU Manager (DCGM) 측정항목을 Cloud Monitoring으로 전송하도록 구성하세요.
• 자동 애플리케이션 모니터링 사용 설정: 추론 서버 모니터링 프로세스를 간소화하려면 GKE에서 자동 애플리케이션 모니터링을 사용 설정하세요.
• OpenTelemetry로 워크로드 계측: 자동 애플리케이션 모니터링에서 지원하지 않는 워크로드의 경우 OpenTelemetry를 사용하여 맞춤 측정항목과 트레이스를 수집합니다.

포드 자동 확장

추론 워크로드가 수요 변화에 동적으로 적응할 수 있도록 수평형 포드 자동 확장 처리 (HPA)를 사용하여 포드 수를 자동으로 확장하세요. 추론 워크로드의 경우 표준 CPU 또는 메모리 측정항목이 아닌 추론 서버의 부하를 직접 반영하는 측정항목을 기반으로 확장 결정을 내리는 것이 중요합니다.

추론 워크로드의 자동 확장을 구성하려면 다음을 권장합니다.

• 추론 인식 측정항목을 기반으로 HPA 구성: 최적의 성능을 위해 추론 서버의 측정항목을 기반으로 확장하도록 HPA를 구성합니다. 최적의 측정항목은 짧은 지연 시간 또는 높은 처리량을 위해 최적화하는지에 따라 달라집니다.

  • 지연 시간에 민감한 워크로드의 경우 두 가지 기본 옵션이 있습니다.

    • KV 캐시 사용률 (예: vllm:gpu_cache_usage_perc): 이 측정항목은 임박한 지연 시간 급증을 나타내는 가장 좋은 지표인 경우가 많습니다. KV 캐시의 사용률이 높으면 추론 엔진이 용량에 가까워지고 있음을 나타냅니다. HPA는 이 신호를 사용하여 미리 복제본을 추가하고 안정적인 사용자 환경을 유지할 수 있습니다.
    • 실행 중인 요청 수 (배치 크기) (예:vllm:num_requests_running): 이 측정항목은 지연 시간과 직접적인 관련이 있습니다. 배치 크기가 작을수록 일반적으로 지연 시간이 짧아지기 때문입니다. 하지만 처리량을 최대화하는 것은 수신 요청의 크기에 따라 달라지므로 이를 사용하여 자동 확장하는 것은 어려울 수 있습니다. HPA가 적절하게 확장되도록 최대 가능한 배치 크기보다 낮은 값을 선택해야 할 수 있습니다.

  • 처리량에 민감한 워크로드의 경우 대기열 크기 (예: vllm:num_requests_waiting)를 기준으로 확장합니다. 이 측정항목은 작업 백로그를 직접 측정하며 처리 용량을 수신 수요에 맞추는 간단한 방법입니다. 이 측정항목은 대기 중인 요청만 고려하고 현재 처리 중인 요청은 고려하지 않으므로 배치 크기에 따라 확장하는 것보다 지연 시간이 더 낮지 않을 수 있습니다.

• 최소 복제본 수 설정: 일관된 가용성과 기준 사용자 환경을 보장하려면 항상 추론 배포의 최소 복제본 수를 설정하세요.

• 성능 HPA 프로필 사용 설정: GKE 버전 1.33 이상에서 성능 HPA 프로필은 HPA의 반응 시간을 개선하기 위해 적격 클러스터에서 기본적으로 사용 설정됩니다.

자세한 내용은 GPU에서 LLM 워크로드의 HPA 구성 및 TPU에서 LLM 추론 워크로드 자동 확장을 참고하세요.

워크로드에 더 가까운 곳으로 데이터 이동

모델 가중치와 같은 워크로드가 데이터를 로드하는 데 걸리는 시간은 지연 시간의 중요한 원인이 될 수 있습니다. 데이터를 컴퓨팅 리소스에 더 가까운 곳으로 이동하면 데이터 전송 시간을 줄이고 전반적인 성능을 개선할 수 있습니다.

• Anywhere Cache로 영역 읽기 캐시 만들기: Cloud Storage를 사용하여 AI/ML 워크로드의 데이터를 저장하는 경우 Anywhere Cache를 사용 설정합니다. Anywhere Cache는 Cloud Storage 버킷을 위한 고성능 영역 읽기 캐시를 만듭니다.
• 로컬 SSD에 자주 액세스하는 데이터 캐시: 임시 데이터에 대한 지연 시간이 매우 짧은 액세스가 필요한 워크로드의 경우 로컬 SSD를 고성능 캐시로 사용하세요. 자주 사용되는 데이터를 보유하는 지연 시간이 짧은 임시 스토리지로 로컬 SSD를 사용하면 가속기와 같은 고가의 리소스의 유휴 시간을 줄일 수 있습니다. 이는 가속기가 I/O 작업이 완료되기를 기다리는 시간을 대폭 줄여주기 때문입니다. 일부 머신 시리즈는 로컬 SSD를 지원하지 않으므로 가속기 선택에 영향을 미칠 수 있습니다.
• GKE 데이터 캐시로 캐시 관리: 영구 디스크에서 데이터를 자주 읽는 워크로드의 경우 GKE 데이터 캐시를 사용 설정합니다. GKE 데이터 캐시는 로컬 SSD를 사용하여 Persistent Disk의 관리형 고성능 캐시를 만듭니다. 대부분의 프로덕션 워크로드의 경우 캐시와 기본 영구 디스크 모두에 데이터를 동기적으로 작성하여 데이터 손실을 방지하는 Writethrough 모드를 사용하는 것이 좋습니다.

고급 확장 아키텍처에 맞게 최적화

대규모 또는 전역적으로 분산된 애플리케이션의 요구사항을 충족하기 위해 고급 확장 아키텍처를 채택하여 성능, 안정성, 트래픽 관리를 개선할 수 있습니다.

GKE 추론 게이트웨이를 사용하여 트래픽 부하 분산

단일 클러스터의 추론 워크로드에는 GKE 추론 게이트웨이를 사용하는 것이 좋습니다. Inference Gateway는 추론 측정항목을 모니터링하여 요청을 가장 최적의 엔드포인트로 라우팅하는 AI 인식 부하 분산기입니다. 이 기능은 성능과 액셀러레이터 활용도를 개선합니다.

GKE Inference Gateway를 사용할 때는 다음 권장사항을 따르는 것이 좋습니다.

• 제공 포드를 InferencePool로 그룹화: 추론 워크로드를 제공하는 각 포드 그룹에 대해 InferencePool를 정의합니다. 자세한 내용은 GKE Inference Gateway 구성 맞춤설정을 참고하세요.
• 지연 시간에 민감한 워크로드 다중화: InferenceObjectives를 정의하여 모델의 서빙 속성(예: 이름 및 우선순위)을 지정합니다. GKE Inference Gateway는 우선순위가 높은 워크로드에 우선권을 부여하므로 지연 시간에 민감한 워크로드와 지연 시간에 관대한 워크로드를 멀티플렉싱하고 트래픽이 많은 동안 부하 차단 정책을 구현할 수 있습니다.
• 모델 인식 라우팅 사용: 요청 본문의 모델 이름을 기반으로 요청을 라우팅하려면 본문 기반 라우팅을 사용합니다. 본문 기반 라우팅을 사용하는 경우 백엔드의 고가용성을 보장해야 합니다. 확장 프로그램을 사용할 수 없는 경우 게이트웨이에서 오류를 반환하여 요청이 잘못 라우팅되지 않도록 합니다.
• 게이트웨이가 트래픽을 자동으로 분산하도록 허용: GKE Inference Gateway는 InferencePool의 추론 서버에서 KV 캐시 사용률, 대기열 길이, 프리픽스 캐시 색인과 같은 주요 측정항목을 모니터링하여 트래픽을 지능적으로 라우팅합니다. 이 실시간 부하 분산은 기존 방식에 비해 액셀러레이터 사용률을 최적화하고, 테일 지연 시간을 줄이며, 전체 처리량을 늘립니다.
• Apigee 및 Model Armor와 통합: 보안 및 관리를 강화하려면 API 관리를 위해 Apigee와 통합하고 안전 검사를 위해 Model Armor와 통합하세요.

여러 노드에 추론 워크로드 배포

단일 노드에 맞지 않는 매우 큰 모델의 경우 여러 노드에 추론 워크로드를 분산해야 합니다. 이를 위해서는 노드 간 통신 지연 시간을 최소화하고 분산 워크로드의 모든 구성요소가 단일 단위로 관리되도록 하는 아키텍처가 필요합니다.

다음 권장사항을 고려하세요.

• 액셀러레이터 네트워크 대역폭 및 처리량 극대화: 워크로드가 여러 노드에 분산되면 네트워크가 중요한 성능 요소가 됩니다. 노드 간 통신 지연 시간을 최소화하려면 NVIDIA GPUDirect와 같은 고성능 네트워킹 기술을 사용하세요. 클러스터의 규모와 워크로드에 필요한 통신 강도에 따라 다음 옵션 중에서 선택할 수 있습니다.

  • GPUDirect-TCPX: A3 High에서 실행되는 다양한 멀티 노드 추론 워크로드에 효과적입니다.
  • GPUDirect-TCPXO: 더 큰 오프로드와 더 높은 대역폭으로 성능을 향상시켜 표준 TCPX에 비해 더 큰 클러스터에 유용하며 A3 Mega 머신에서 실행됩니다.
  • GPUDirect RDMA: CPU를 우회하여 서로 다른 노드 간 GPU 간 직접 메모리 액세스를 허용하여 노드 간 대역폭이 가장 높고 지연 시간이 가장 짧으며, A3 Ultra 및 A4 머신에서 가장 까다로운 대규모 추론 시나리오에 가장 적합합니다.

  자세한 내용은 다음을 참고하세요.

  • Standard 모드 클러스터에서 GPU 네트워크 대역폭 극대화
  • Autopilot 모드 클러스터에서 GPU 네트워크 대역폭 극대화

  멀티 노드 네트워크 구성이 예상대로 작동하는지 확인하려면 NVIDIA Collective Communications Library (NCCL)과 같은 도구로 테스트를 실행하는 것이 좋습니다.

• LeaderWorkerSet을 사용하여 분산 워크로드 관리: 멀티 노드 추론 서비스와 같은 상태 저장 분산 워크로드를 배포할 때는 모든 구성요소를 단일 단위로 관리해야 합니다. 이렇게 하려면 관련 포드 그룹을 단일 항목으로 관리할 수 있는 Kubernetes 네이티브 API인 LeaderWorkerSet을 사용하세요. LeaderWorkerSet은 세트의 모든 포드가 함께 생성되고 삭제되도록 보장하므로 분산 워크로드의 무결성을 유지하는 데 중요합니다.

• 압축 배치를 사용하여 노드를 물리적으로 가까이 배치: 분산 워크로드의 노드 간 물리적 거리는 노드 간 네트워크 지연 시간에 큰 영향을 미칠 수 있습니다. 이 지연 시간을 최소화하려면 GKE 노드 풀에 압축 배치 정책을 사용하세요. 압축 배치 정책은 GKE에 영역 내에서 노드 풀의 노드를 최대한 물리적으로 가까운 곳에 배치하도록 지시합니다.

여러 리전에 추론 워크로드 배포

고가용성과 낮은 지연 시간이 필요한 전역 분산 애플리케이션의 경우 여러 리전에 추론 워크로드를 배포하는 것이 중요한 권장사항입니다. 멀티 리전 아키텍처는 안정성을 높이고, 액셀러레이터 획득 가능성을 개선하고, 사용자가 인식하는 지연 시간을 줄이고, 위치별 규제 요구사항을 충족하는 데 도움이 될 수 있습니다.

멀티 리전 추론 서비스를 효과적으로 배포하고 관리하려면 다음 권장사항을 따르세요.

• 예약된 용량이 있거나 최대 부하를 처리하기 위해 용량이 필요할 것으로 예상되는 여러 리전에 GKE 클러스터를 프로비저닝합니다.
• 모델 가중치에 적합한 스토리지 전략을 선택합니다. 운영 효율성을 최적화하려면 멀티 리전 Cloud Storage 버킷을 만드세요. 비용을 최적화하려면 각 리전에 리전 버킷을 만들고 모델 가중치를 복제하세요.
• Anywhere Cache를 사용하여 Cloud Storage 버킷의 영역별 읽기 캐시를 만들어 네트워크 지연 시간과 데이터 이그레스 비용을 모두 줄이세요.

권장사항 요약

다음 표에서는 이 문서에 설명된 권장사항을 요약해서 보여줍니다.

주제	작업
배포 및 구성	추론 사용 사례의 특성 분석 추론 사용 사례에 적합한 모델 선택 모델에 양자화 적용 적절한 액셀러레이터 선택 추론 배포 전략 선택 추론 서버 구성 최적화
콜드 스타트 지연 시간	포드 시작 시간 최적화 빠르게 시작하는 노드 사용 설정
용량 계획 및 가속기 획득 가능성	용량 계획 및 예약 동적 워크로드 스케줄러 사용 커스텀 컴퓨팅 클래스 사용 GKE 클러스터 및 노드 풀의 위치 정책 구성
리소스 및 가속기 효율성	액셀러레이터 및 추론 서버 관찰 포드 자동 확장 워크로드에 더 가까운 곳으로 데이터 이동
부하 분산	단일 클러스터 배포에 GKE Inference Gateway 사용
다중 노드 배포	액셀러레이터 네트워크 대역폭 및 처리량 최대화 LeaderWorkerSet을 사용하여 포드 그룹화 간단한 배치를 사용하여 물리적으로 인접한 노드 배치
멀티 리전 배포	여러 리전에서 GKE 클러스터 프로비저닝 리전 간 트래픽 부하 분산 Cloud Storage 버킷에 모델 가중치 저장 Anywhere Cache로 데이터 캐시

다음 단계

• GKE 추론 참조 아키텍처를 참고하세요.