이 페이지에서는 생성형 AI 애플리케이션의 최적화된 제공을 위해 GKE 게이트웨이를 개선한 Google Kubernetes Engine (GKE) 추론 게이트웨이를 소개합니다. 주요 개념, 기능, GKE 추론 게이트웨이의 작동 방식을 설명합니다.
이 페이지는 다음 사용자를 대상으로 합니다.
- AI/ML 워크로드를 제공하기 위해 Kubernetes 컨테이너 조정 기능을 사용하는 데 관심이 있는 머신러닝 (ML) 엔지니어, 플랫폼 관리자 및 운영자, 데이터 및 AI 전문가
- Kubernetes 네트워킹과 상호작용하는 클라우드 설계자 및 네트워킹 전문가
이 페이지를 읽기 전에 다음 사항을 숙지해야 합니다.
- GKE의 AI/ML 조정
- 생성형 AI 용어집
- 서비스 및 GKE 게이트웨이 API를 비롯한 GKE 네트워킹 개념
- Google Cloud의 부하 분산, 특히 부하 분산기가 GKE와 상호작용하는 방식
개요
GKE 추론 게이트웨이는 생성형 AI (AI) 워크로드 제공을 위해 최적화된 라우팅 및 부하 분산을 제공하는 GKE 게이트웨이의 확장 프로그램입니다. AI 추론 워크로드의 배포, 관리, 관찰 가능성을 간소화합니다.
특징 및 이점
GKE 추론 게이트웨이는 GKE에서 생성형 AI 애플리케이션을 위한 생성형 AI 모델을 효율적으로 제공하기 위한 다음과 같은 주요 기능을 제공합니다.
- 추론을 위한 최적화된 부하 분산: 요청을 분산하여 AI 모델 제공 성능을 최적화합니다.
KVCache Utilization및queue length of pending requests와 같은 모델 서버의 측정항목을 사용하여 생성형 AI 워크로드에 GPU 및 TPU와 같은 가속기를 더 효율적으로 사용합니다. - 동적 LoRA 파인 튜닝 모델 제공: 공통적인 가속기에서 동적 LoRA 파인 튜닝 모델을 제공하는 기능을 지원합니다. 이렇게 하면 공통 기본 모델 및 가속기에서 여러 개의 LoRA 미세 조정 모델을 다중화하여 모델을 제공하는 데 필요한 GPU 및 TPU 수를 줄일 수 있습니다.
- 추론을 위한 최적화된 자동 확장: GKE 수평형 포드 자동 확장 처리 (HPA)는 모델 서버 측정항목을 사용하여 자동 확장하므로 효율적인 컴퓨팅 리소스 사용과 최적화된 추론 성능을 보장할 수 있습니다.
- 모델 인식 라우팅: GKE 클러스터 내
OpenAI API사양에 정의된 모델 이름을 기반으로 추론 요청을 라우팅합니다. 트래픽 분할 및 요청 미러링과 같은 게이트웨이 라우팅 정책을 정의하여 다양한 모델 버전을 관리하고 모델 출시를 간소화할 수 있습니다. 예를 들어 특정 모델 이름에 대한 요청을 각각 다른 버전의 모델을 제공하는 여러InferencePool객체로 라우트할 수 있습니다. - 모델별 게재
Criticality: AI 모델의 게재Criticality를 지정할 수 있습니다. 지연 시간에 관대한 일괄 추론 작업보다 지연 시간에 민감한 요청을 우선시합니다. 예를 들어 지연 시간에 민감한 애플리케이션의 요청에 우선순위를 두고 리소스가 제약된 경우 시간에 민감하지 않은 태스크를 중단할 수 있습니다. - 통합 AI 안전: 게이트웨이의 프롬프트와 응답에 AI 안전 검사를 적용하는 서비스인 Google Cloud Model Armor와 통합됩니다. 모델 아머는 회고 분석 및 최적화를 위한 요청, 응답, 처리 로그를 제공합니다. GKE 추론 게이트웨이의 개방형 인터페이스를 사용하면 서드 파티 제공업체와 개발자가 맞춤 서비스를 추론 요청 프로세스에 통합할 수 있습니다.
- 추론 관측 가능성: 요청 빈도, 지연 시간, 오류, 포화도와 같은 추론 요청에 관한 관측 가능성 측정항목을 제공합니다. 추론 서비스의 성능과 동작을 모니터링합니다.
주요 개념 이해
GKE 추론 게이트웨이는 GatewayClass 객체를 사용하는 기존 GKE 게이트웨이를 개선합니다. GKE 추론 게이트웨이는 추론을 위한 OSS Kubernetes Gateway API 확장 프로그램에 따라 다음과 같은 새로운 Gateway API 커스텀 리소스 정의 (CRD)를 도입합니다.
InferencePool객체: 동일한 컴퓨팅 구성, 가속기 유형, 기본 언어 모델, 모델 서버를 공유하는 포드 (컨테이너) 그룹을 나타냅니다. 이렇게 하면 리소스를 제공하는 AI 모델을 논리적으로 그룹화하고 관리할 수 있습니다. 단일InferencePool객체는 여러 GKE 노드에 걸쳐 여러 포드에 걸쳐 확장될 수 있으며 확장성과 고가용성을 제공합니다.InferenceModel객체:OpenAI API사양에 따라InferencePool에서 게재 모델의 이름을 지정합니다.InferenceModel객체는 AI 모델의Criticality와 같은 모델의 게재 속성도 지정합니다. GKE 추론 게이트웨이는Critical로 분류된 워크로드를 우선시합니다. 이를 통해 GKE 클러스터에서 지연 시간에 민감한 AI 워크로드와 지연 시간에 관대한 AI 워크로드를 멀티플렉스할 수 있습니다. LoRA 미세 조정 모델을 제공하도록InferenceModel객체를 구성할 수도 있습니다.TargetModel객체: 대상 모델 이름과 모델을 제공하는InferencePool객체를 지정합니다. 이를 통해 트래픽 분할 및 요청 미러링과 같은 게이트웨이 라우팅 정책을 정의하고 모델 버전 출시를 간소화할 수 있습니다.
다음 다이어그램은 GKE 추론 게이트웨이와 GKE 클러스터 내의 AI 안전, 관측 가능성, 모델 제공과의 통합을 보여줍니다.
다음 다이어그램은 두 가지 새로운 추론 중심 캐릭터와 이러한 캐릭터가 관리하는 리소스에 중점을 둔 리소스 모델을 보여줍니다.
GKE 추론 게이트웨이 작동 방식
GKE 추론 게이트웨이는 게이트웨이 API 확장 프로그램과 모델별 라우팅 로직을 사용하여 AI 모델에 대한 클라이언트 요청을 처리합니다. 다음 단계에서는 요청 흐름을 설명합니다.
요청 흐름 작동 방식
GKE 추론 게이트웨이는 초기 요청에서 모델 인스턴스로 클라이언트 요청을 라우팅합니다. 이 섹션에서는 GKE 추론 게이트웨이가 요청을 처리하는 방법을 설명합니다. 이 요청 흐름은 모든 클라이언트에 공통적으로 적용됩니다.
- 클라이언트는 OpenAI API 사양에 설명된 형식의 요청을 GKE에서 실행 중인 모델에 전송합니다.
- GKE 추론 게이트웨이는 다음 추론 확장 프로그램을 사용하여 요청을 처리합니다.
- 본문 기반 라우팅 확장 프로그램: 클라이언트 요청 본문에서 모델 식별자를 추출하여 GKE 추론 게이트웨이로 전송합니다.
그러면 GKE 추론 게이트웨이는 이 식별자를 사용하여 Gateway API
HTTPRoute객체에 정의된 규칙에 따라 요청을 라우팅합니다. 요청 본문 라우팅은 URL 경로를 기반으로 하는 라우팅과 유사합니다. 차이점은 요청 본문 라우팅은 요청 본문의 데이터를 사용한다는 점입니다. - 보안 확장 프로그램: Model Armor 또는 지원되는 서드 파티 솔루션을 사용하여 콘텐츠 필터링, 위협 감지, 정리, 로깅을 비롯한 모델별 보안 정책을 시행합니다. 보안 확장 프로그램은 이러한 정책을 요청 및 응답 처리 경로 모두에 적용합니다. 이렇게 하면 보안 확장 프로그램이 요청과 응답을 모두 정리하고 로깅할 수 있습니다.
- 엔드포인트 선택기 확장 프로그램:
InferencePool내의 모델 서버에서 주요 측정항목을 모니터링합니다. 키-값 캐시 (KV-cache) 사용률, 대기 중인 요청의 대기열 길이, 각 모델 서버의 활성 LoRA 어댑터를 추적합니다. 그런 다음 이러한 측정항목을 기반으로 요청을 최적의 모델 복제본으로 라우팅하여 지연 시간을 최소화하고 AI 추론의 처리량을 극대화합니다.
- 본문 기반 라우팅 확장 프로그램: 클라이언트 요청 본문에서 모델 식별자를 추출하여 GKE 추론 게이트웨이로 전송합니다.
그러면 GKE 추론 게이트웨이는 이 식별자를 사용하여 Gateway API
- GKE 추론 게이트웨이는 엔드포인트 선택기 확장 프로그램에서 반환한 모델 복제본으로 요청을 라우팅합니다.
다음 다이어그램은 GKE 추론 게이트웨이를 통해 클라이언트에서 모델 인스턴스로의 요청 흐름을 보여줍니다.
트래픽 분배 작동 방식
GKE 추론 게이트웨이는 InferencePool 객체 내의 모델 서버에 추론 요청을 동적으로 배포합니다. 이렇게 하면 리소스 사용량을 최적화하고 다양한 부하 조건에서 성능을 유지하는 데 도움이 됩니다.
GKE 추론 게이트웨이는 다음 두 가지 메커니즘을 사용하여 트래픽 분산을 관리합니다.
엔드포인트 선택: 추론 요청을 처리하는 데 가장 적합한 모델 서버를 동적으로 선택합니다. 서버 부하와 가용성을 모니터링한 후 라우팅 결정을 내립니다.
대기열 및 셰딩: 요청 흐름을 관리하고 트래픽 오버로드를 방지합니다. GKE 추론 게이트웨이는 수신되는 요청을 대기열에 저장하고, 정의된 기준에 따라 요청의 우선순위를 지정하며, 시스템에 과부하가 발생하면 요청을 삭제합니다.
GKE 추론 게이트웨이는 다음 Criticality 수준을 지원합니다.
Critical: 이러한 워크로드에 우선순위가 부여됩니다. 시스템은 리소스 제약 조건이 있는 경우에도 이러한 요청이 처리되도록 합니다.Standard: 이러한 워크로드는 리소스가 사용 가능한 경우 제공됩니다. 리소스가 제한된 경우 이러한 요청은 삭제됩니다.Sheddable: 이러한 워크로드는 기회주의적으로 제공됩니다. 리소스가 부족하면 이러한 요청이 삭제되어Critical워크로드가 보호됩니다.
시스템에 리소스 문제가 발생하면 Critical 워크로드를 보호하기 위해 Standard 및 Sheddable 요청이 429 오류 코드와 함께 즉시 삭제됩니다.
스트리밍 추론
GKE 추론 게이트웨이는 지속적인 업데이트 또는 거의 실시간 업데이트가 필요한 채팅봇 및 실시간 번역과 같은 애플리케이션의 스트리밍 추론을 지원합니다. 스트리밍 추론은 단일의 완전한 출력으로 응답을 전달하는 대신 증분 청크 또는 세그먼트로 응답을 전달합니다. 스트리밍 응답 중에 오류가 발생하면 스트림이 종료되고 클라이언트는 오류 메시지를 수신합니다. GKE 추론 게이트웨이는 스트리밍 응답을 다시 시도하지 않습니다.
애플리케이션 예시 살펴보기
이 섹션에서는 GKE 추론 게이트웨이를 사용하여 다양한 생성형 AI 애플리케이션 시나리오를 해결하는 예시를 제공합니다.
예 1: GKE 클러스터에서 여러 생성형 AI 모델 제공
회사에서 여러 대규모 언어 모델 (LLM)을 배포하여 서로 다른 워크로드를 처리하려고 합니다. 예를 들어 챗봇 인터페이스에는 Gemma3 모델을, 맞춤 콘텐츠 애플리케이션에는 Deepseek 모델을 배포할 수 있습니다. 회사는 이러한 LLM의 최적의 게재 성능을 보장해야 합니다.
GKE 추론 게이트웨이를 사용하면 InferencePool에서 선택한 가속기 구성을 사용하여 GKE 클러스터에 이러한 LLM을 배포할 수 있습니다. 그런 다음 모델 이름 (예: chatbot 및 recommender) 및 Criticality 속성을 기반으로 요청을 라우팅할 수 있습니다.
다음 다이어그램은 GKE 추론 게이트웨이가 모델 이름과 Criticality를 기반으로 요청을 여러 모델로 라우팅하는 방법을 보여줍니다.
예 2: 공유 가속기에서 LoRA 어댑터 제공
한 회사가 문서 분석을 위해 LLM을 게재하고자 하며 영어와 스페인어 등 여러 언어의 잠재고객을 타겟팅합니다. 각 언어에 맞게 모델을 미세 조정했지만 GPU 및 TPU 용량을 효율적으로 사용해야 합니다. GKE 추론 게이트를 사용하여 공통 기본 모델 (예: llm-base) 및 가속기에 각 언어 (예: english-bot 및 spanish-bot)에 맞게 미세 조정된 동적 LoRA 어댑터를 배포할 수 있습니다. 이렇게 하면 공통 가속기에 여러 모델을 고밀도로 패킹하여 필요한 가속기 수를 줄일 수 있습니다.
다음 다이어그램은 GKE 추론 게이트웨이가 공유된 가속기에서 여러 LoRA 어댑터를 제공하는 방식을 보여줍니다.
