GKE 추론 게이트웨이 정보

이 페이지에서는 생성형 AI 애플리케이션의 최적화된 제공을 위해 GKE 게이트웨이를 확장한 Google Kubernetes Engine (GKE) 추론 게이트웨이의 주요 개념과 기능을 설명합니다.

이 페이지에서는 사용자가 다음 사항을 알고 있다고 가정합니다.

이 페이지는 다음 페르소나를 대상으로 합니다.

  • AI/ML 워크로드를 서빙하기 위해 Kubernetes 컨테이너 조정 기능을 사용하는 데 관심이 있는 머신러닝 (ML) 엔지니어, 플랫폼 관리자 및 운영자, 데이터 및 AI 전문가
  • Kubernetes 네트워킹과 상호작용하는 클라우드 설계자 및 네트워킹 전문가

개요

GKE Inference Gateway는 생성형 인공지능 (AI) 워크로드를 제공하기 위한 최적화된 라우팅 및 부하 분산을 제공하는 GKE Gateway의 확장 프로그램입니다. AI 추론 워크로드의 배포, 관리, 관측 가능성을 간소화합니다.

AI/ML 워크로드에 최적의 부하 분산 전략을 선택하려면 GKE에서 AI 추론을 위한 부하 분산 전략 선택을 참고하세요.

특징 및 이점

GKE 추론 게이트웨이는 GKE에서 생성형 AI 애플리케이션을 위한 생성형 AI 모델을 효율적으로 제공하기 위해 다음과 같은 주요 기능을 제공합니다.

  • 지원되는 측정항목:
    • KV cache hits: 키-값(KV) 캐시에서 성공한 조회 수입니다.
    • GPU 또는 TPU 사용률: GPU 또는 TPU가 활발하게 처리하는 시간의 비율입니다.
    • 요청 큐 길이: 처리되기를 기다리는 요청 수입니다.
  • 추론을 위한 최적화된 부하 분산: AI 모델 서빙 성능을 최적화하기 위해 요청을 분산합니다. 생성형 AI 워크로드에 대해 가속기(예: GPU 및 TPU)를 더 효율적으로 사용하기 위해 모델 서버의 측정항목(예: KV cache hits 및 queue length of pending requests)을 사용합니다. 이를 통해 요청 본문을 분석하여 식별된 공유 컨텍스트가 있는 요청을 캐시 적중률을 최대화하여 동일한 모델 복제본으로 전송하는 핵심 기능인 접두사-캐시 인식 라우팅이 사용 설정됩니다. 이 접근 방식은 중복 계산을 크게 줄이고 첫 번째 토큰까지의 시간을 개선하므로 대화형 AI, 검색 증강 생성 (RAG), 기타 템플릿 기반 생성형 AI 워크로드에 매우 효과적입니다.
  • 동적 LoRA 미세 조정 모델 제공: 공통 액셀러레이터에서 동적 LoRA 미세 조정 모델을 제공하는 것을 지원합니다. 이렇게 하면 공통 기본 모델과 액셀러레이터에서 여러 LoRA 미세 조정 모델을 멀티플렉싱하여 모델을 서빙하는 데 필요한 GPU와 TPU의 수가 줄어듭니다.
  • 추론을 위한 자동 확장 최적화: GKE 수평형 포드 자동 확장 (HPA)은 모델 서버 측정항목을 사용하여 자동 확장하므로 효율적인 컴퓨팅 리소스 사용과 최적화된 추론 성능을 보장하는 데 도움이 됩니다.
  • 모델 인식 라우팅: GKE 클러스터 내 OpenAI API 사양에 정의된 모델 이름을 기반으로 추론 요청을 라우팅합니다. 트래픽 분할 및 요청 미러링과 같은 게이트웨이 라우팅 정책을 정의하여 다양한 모델 버전을 관리하고 모델 출시를 간소화할 수 있습니다. 예를 들어 특정 모델 이름에 대한 요청을 서로 다른 InferencePool 객체로 라우팅할 수 있으며, 각 객체는 서로 다른 버전의 모델을 제공합니다. 이 기능을 구성하는 방법에 대한 자세한 내용은 본문 기반 라우팅 구성을 참고하세요.
  • 통합 AI 안전 및 콘텐츠 필터링: GKE Inference Gateway는 Google Cloud Model Armor와 통합되어 게이트웨이에서 프롬프트와 응답에 AI 안전 검사와 콘텐츠 필터링을 적용합니다. Model Armor는 회고 분석 및 최적화를 위해 요청, 응답, 처리 로그를 제공합니다. GKE 추론 게이트웨이의 개방형 인터페이스를 사용하면 서드 파티 제공업체와 개발자가 추론 요청 프로세스에 맞춤 서비스를 통합할 수 있습니다.
  • 모델별 서빙 Priority: AI 모델의 서빙 Priority을 지정할 수 있습니다. 지연 시간에 민감한 요청을 지연 시간에 관대한 일괄 추론 작업보다 우선시합니다. 예를 들어 지연 시간에 민감한 애플리케이션의 요청에 우선순위를 지정하고 리소스가 제한될 때 시간 민감도가 낮은 작업을 삭제할 수 있습니다.
  • 추론 관측 가능성: 요청률, 지연 시간, 오류, 포화도와 같은 추론 요청의 관측 가능성 측정항목을 제공합니다. Cloud Monitoring 및 Cloud Logging을 통해 추론 서비스의 성능과 동작을 모니터링하고, 세부정보를 파악할 수 있는 특화된 사전 빌드 대시보드를 활용하세요. 자세한 내용은 GKE Inference Gateway 대시보드 보기를 참고하세요.
  • Apigee를 사용한 고급 API 관리: Apigee와 통합되어 API 보안, 비율 제한, 할당량과 같은 기능으로 추론 게이트웨이를 강화합니다. 자세한 안내는 인증 및 API 관리를 위해 Apigee 구성하기를 참고하세요.
  • 확장성: 사용자 관리 엔드포인트 선택기 알고리즘을 지원하는 확장 가능한 오픈소스 Kubernetes Gateway API 추론 확장 프로그램을 기반으로 빌드됩니다.

주요 개념 이해

GKE 추론 게이트웨이는 GatewayClass 객체를 사용하는 기존 GKE 게이트웨이를 개선합니다. GKE Inference Gateway는 OSS Kubernetes Gateway API 확장 프로그램(추론용)과 일치하는 다음과 같은 새로운 Gateway API 커스텀 리소스 정의(CRD)를 도입합니다.

  • InferencePool 객체: 동일한 컴퓨팅 구성, 가속기 유형, 기본 언어 모델, 모델 서버를 공유하는 포드 (컨테이너) 그룹을 나타냅니다. 이렇게 하면 AI 모델 제공 리소스가 논리적으로 그룹화되고 관리됩니다. 단일 InferencePool 객체는 서로 다른 GKE 노드에 걸쳐 여러 포드를 포함할 수 있으며 확장성과 고가용성을 제공합니다.
  • InferenceObjective 객체: OpenAI API 사양에 따라 InferencePool에서 제공되는 모델의 이름을 지정합니다. InferenceObjective 객체는 AI 모델의 Priority과 같은 모델의 서빙 속성도 지정합니다. GKE Inference Gateway는 우선순위 값이 더 높은 워크로드를 선호합니다. 이를 통해 GKE 클러스터에서 지연 시간에 민감한 AI 워크로드와 지연 시간에 덜 민감한 AI 워크로드를 다중화할 수 있습니다. LoRA 미세 조정 모델을 제공하도록 InferenceObjective 객체를 구성할 수도 있습니다.

다음 다이어그램은 GKE 추론 게이트웨이와 GKE 클러스터 내의 AI 안전, 관측 가능성, 모델 제공과의 통합을 보여줍니다.

GKE 추론 게이트웨이 `InferencePool` 및 `InferenceObjective` 객체 간의 관계
그림: GKE Inference Gateway 리소스 모델

다음 다이어그램은 두 개의 새로운 추론 중심 페르소나와 이들이 관리하는 리소스에 초점을 맞춘 리소스 모델을 보여줍니다.

추론 중심 페르소나 및 해당 리소스의 리소스 모델
그림: 추론 중심 페르소나가 있는 GKE Inference Gateway 리소스 모델

GKE 추론 게이트웨이 작동 방식

GKE Inference Gateway는 게이트웨이 API 확장 프로그램과 모델별 라우팅 로직을 사용하여 AI 모델에 대한 클라이언트 요청을 처리합니다. 다음 단계에서는 요청 흐름을 설명합니다.

요청 흐름 작동 방식

GKE 추론 게이트웨이는 초기 요청에서 모델 인스턴스로 클라이언트 요청을 라우팅합니다. 이 섹션에서는 GKE 추론 게이트웨이에서 요청을 처리하는 방법을 설명합니다. 이 요청 흐름은 모든 클라이언트에서 공통적으로 사용됩니다.

  1. 클라이언트는 OpenAI API 사양에 설명된 형식으로 요청을 GKE에서 실행되는 모델에 전송합니다.
  2. GKE 추론 게이트웨이는 다음 추론 확장 프로그램을 사용하여 요청을 처리합니다.
    1. 본문 기반 라우팅 확장 프로그램: 클라이언트 요청 본문에서 모델 식별자를 추출하여 GKE 추론 게이트웨이로 전송합니다. 그런 다음 GKE Inference Gateway는 이 식별자를 사용하여 Gateway API HTTPRoute 객체에 정의된 규칙에 따라 요청을 라우팅합니다. 요청 본문 라우팅은 URL 경로를 기반으로 한 라우팅과 유사합니다. 차이점은 요청 본문 라우팅이 요청 본문의 데이터를 사용한다는 것입니다.
    2. 보안 확장 프로그램: Model Armor 또는 지원되는 서드 파티 솔루션을 사용하여 콘텐츠 필터링, 위협 감지, 삭제, 로깅을 포함한 모델별 보안 정책을 적용합니다. 보안 확장 프로그램은 요청 및 응답 처리 경로 모두에 이러한 정책을 적용합니다.
    3. 엔드포인트 선택기 확장 프로그램: InferencePool 내 모델 서버의 주요 측정항목을 모니터링합니다. 각 모델 서버에서 키-값 캐시 (KV-cache) 사용률, 대기 중인 요청의 대기열 길이, 접두사 캐시 색인, 활성 LoRA 어댑터를 추적합니다. 그런 다음 이러한 측정항목을 기반으로 요청을 최적의 모델 복제본으로 라우팅하여 지연 시간을 최소화하고 AI 추론의 처리량을 극대화합니다.
  3. GKE 추론 게이트웨이는 엔드포인트 선택기 확장 프로그램에서 반환된 모델 복제본으로 요청을 라우팅합니다.

다음 다이어그램은 GKE 추론 게이트웨이를 통해 클라이언트에서 모델 인스턴스로의 요청 흐름을 보여줍니다.

GKE 추론 게이트웨이를 통해 클라이언트에서 모델 인스턴스로의 요청 흐름
그림: GKE Inference Gateway 요청 흐름

트래픽 분배 작동 방식

GKE 추론 게이트웨이는 InferencePool 객체 내의 모델 서버에 추론 요청을 동적으로 분산합니다. 이렇게 하면 리소스 활용도를 최적화하고 다양한 부하 조건에서 성능을 유지할 수 있습니다. GKE 추론 게이트웨이는 다음 두 가지 메커니즘을 사용하여 트래픽 분산을 관리합니다.

  • 엔드포인트 선택: 추론 요청을 처리하는 데 가장 적합한 모델 서버를 동적으로 선택합니다. 서버 부하와 가용성을 모니터링한 다음 여러 최적화 휴리스틱을 결합하여 각 서버의 score를 계산하여 최적의 라우팅 결정을 내립니다.

    • 접두사 캐시 인식 라우팅: GKE 추론 게이트웨이는 각 모델 서버에서 사용 가능한 접두사 캐시 색인을 추적하고 접두사 캐시 일치가 더 긴 서버에 더 높은 점수를 부여합니다.
    • 부하 인식 라우팅: GKE Inference Gateway는 서버 부하(KV 캐시 사용률 및 대기열 깊이)를 모니터링하고 부하가 낮은 서버에 더 높은 점수를 부여합니다.
    • LoRA 인식 라우팅: 동적 LoRA 서빙이 사용 설정된 경우 GKE 추론 게이트웨이는 서버별 활성 LoRA 어댑터를 모니터링하고 요청된 LoRA 어댑터가 활성화되어 있거나 요청된 LoRA 어댑터를 동적으로 로드할 여유 공간이 있는 서버에 더 높은 점수를 부여합니다. 위의 모든 항목의 총점이 가장 높은 서버가 선택됩니다.

  • 대기열 및 셰딩: 요청 흐름을 관리하고 트래픽 오버로드를 방지합니다. GKE 추론 게이트웨이는 수신 요청을 대기열에 저장하고 정의된 우선순위에 따라 요청의 우선순위를 지정합니다.

GKE Inference Gateway는 숫자 Priority 시스템(Criticality이라고도 함)을 사용하여 요청 흐름을 관리하고 과부하를 방지합니다. 이 Priority는 각 InferenceObjective에 대해 사용자가 정의한 선택적 정수 필드입니다. 값이 클수록 요청이 더 중요합니다. 시스템에 부담이 가해지면 Priority이 0보다 작은 요청은 우선순위가 낮은 것으로 간주되어 먼저 삭제되고, 더 중요한 워크로드를 보호하기 위해 429 오류가 반환됩니다. Priority의 기본값은 0입니다. Priority이 0보다 작은 값으로 명시적으로 설정된 경우에만 우선순위로 인해 요청이 삭제됩니다. 이 시스템을 사용하면 지연 시간에 민감한 온라인 추론 트래픽을 시간에 덜 민감한 일괄 작업보다 우선 처리할 수 있습니다.

GKE 추론 게이트웨이는 지속적인 또는 거의 실시간 업데이트가 필요한 챗봇 및 실시간 번역과 같은 애플리케이션의 스트리밍 추론을 지원합니다. 스트리밍 추론은 단일의 완전한 출력이 아닌 증분 청크 또는 세그먼트로 대답을 제공합니다. 스트리밍 응답 중에 오류가 발생하면 스트림이 종료되고 클라이언트가 오류 메시지를 수신합니다. GKE 추론 게이트웨이는 스트리밍 응답을 재시도하지 않습니다.

애플리케이션 예시 살펴보기

이 섹션에서는 GKE 추론 게이트웨이를 사용하여 다양한 생성형 AI 애플리케이션 시나리오를 해결하는 방법을 보여줍니다.

예 1: GKE 클러스터에서 여러 생성형 AI 모델 제공

한 회사에서 다양한 워크로드를 처리하기 위해 여러 대규모 언어 모델 (LLM)을 배포하려고 합니다. 예를 들어 챗봇 인터페이스에는 Gemma3 모델을, 추천 애플리케이션에는 Deepseek 모델을 배포할 수 있습니다. 회사는 이러한 LLM의 최적의 제공 성능을 보장해야 합니다.

GKE 추론 게이트웨이를 사용하면 선택한 액셀러레이터 구성으로 이러한 LLM을 InferencePool에서 GKE 클러스터에 배포할 수 있습니다. 그런 다음 모델 이름 (예: chatbot 및 recommender)과 Priority 속성을 기반으로 요청을 라우팅할 수 있습니다.

다음 다이어그램은 GKE 추론 게이트웨이가 모델 이름과 Priority에 따라 요청을 다양한 모델로 라우팅하는 방법을 보여줍니다.

모델 이름과 우선순위에 따라 요청을 다른 모델로 라우팅
그림: GKE Inference Gateway를 사용하여 GKE 클러스터에서 여러 생성형 AI 모델 서빙

이 다이어그램은 example.com/completions의 생성형 AI 서비스에 대한 요청이 GKE 추론 게이트웨이에서 처리되는 방식을 보여줍니다. 요청은 먼저 Infra 네임스페이스의 Gateway에 도달합니다. 이 Gateway는 챗봇 및 감정 모델 요청을 처리하도록 구성된 GenAI Inference 네임스페이스의 HTTPRoute에 요청을 전달합니다. 챗봇 모델의 경우 HTTPRoute은 트래픽을 분할합니다. 90% 는 현재 모델 버전 ({pool: gemma}에서 선택)을 실행하는 InferencePool으로 전달되고 10% 는 일반적으로 카나리아 테스트를 위해 최신 버전 ({pool: gemma-new})이 있는 풀로 전달됩니다. 두 풀 모두 챗봇 모델 요청에 Priority 10을 할당하는 InferenceObjective에 연결되어 이러한 요청이 우선순위가 높은 것으로 처리되도록 합니다.

예 2: 공유 가속기에서 LoRA 어댑터 제공

한 회사가 문서 분석을 위해 LLM을 제공하고 영어와 스페인어 등 여러 언어를 사용하는 잠재고객에 집중하고 있습니다. 각 언어에 맞게 모델을 미세 조정했지만 GPU 및 TPU 용량을 효율적으로 사용해야 합니다. GKE Inference Gateway를 사용하여 공통 기본 모델 (예: llm-base) 및 가속기에 각 언어 (예: english-bot 및 spanish-bot)에 맞게 동적으로 LoRA 미세 조정된 어댑터를 배포할 수 있습니다. 이렇게 하면 공통 가속기에 여러 모델을 밀도 있게 패킹하여 필요한 가속기 수를 줄일 수 있습니다.

다음 다이어그램은 GKE 추론 게이트웨이가 공유 액셀러레이터에서 여러 LoRA 어댑터를 제공하는 방법을 보여줍니다.

공유 가속기에서 여러 LoRA 어댑터 서빙
그림: 공유 가속기에서 LoRA 어댑터 제공

다음 단계