이 페이지에서는 생성형 AI 애플리케이션의 최적화된 서빙을 위해 GKE 게이트웨이를 확장한 Google Kubernetes Engine(GKE) 추론 게이트웨이의 주요 개념과 기능을 설명합니다.
이 페이지에서는 사용자가 다음 사항을 알고 있다고 가정합니다.
- GKE의 AI/ML 조정
- 생성형 AI 용어
- 서비스 및 GKE Gateway API를 비롯한 GKE 네트워킹 개념
- Google Cloud의 부하 분산, 특히 부하 분산기가 GKE와 상호작용하는 방식
이 페이지는 다음 사용자를 대상으로 합니다.
- AI/ML 워크로드를 서빙하기 위해 Kubernetes 컨테이너 조정 기능을 사용하는 데 관심이 있는 머신러닝(ML) 엔지니어, 플랫폼 관리자 및 운영자, 데이터 및 AI 전문가
- Kubernetes 네트워킹과 상호작용하는 클라우드 설계자 및 네트워킹 전문가
개요
GKE Inference Gateway는 생성형 인공지능(AI) 워크로드를 서빙하기 위한 최적화된 라우팅 및 부하 분산을 제공하는 GKE Gateway의 확장 프로그램입니다. AI 추론 워크로드의 배포, 관리, 모니터링 가능성을 간소화합니다.
AI/ML 워크로드에 최적의 부하 분산 전략을 선택하려면 GKE에서 AI 추론을 위한 부하 분산 전략 선택을 참조하세요.
특징 및 이점
GKE Inference Gateway는 GKE에서 생성형 AI 애플리케이션을 위한 생성형 AI 모델을 효율적으로 서빙하기 위해 다음과 같은 주요 기능을 제공합니다.
- 지원되는 측정항목:
KV cache hits: 키-값(KV) 캐시에서 성공한 조회 수입니다.- GPU 또는 TPU 사용률: GPU 또는 TPU가 활발하게 처리하는 시간의 비율입니다.
- 요청 대기열 길이: 처리되기를 기다리는 요청 수입니다.
- 추론을 위한 최적화된 부하 분산: AI 모델 서빙 성능을 최적화하기 위해 요청을 분산합니다. 모델 서버의 측정항목(예:
KV cache hits및queue length of pending requests)을 사용하여 생성형 AI 워크로드에 대해 가속기(예: GPU 및 TPU)를 더 효율적으로 사용합니다. 이를 통해 프리픽스-캐시 인식 라우팅이 사용 설정됩니다. 이 기능은 요청 본문 분석을 통해 식별된 공유 컨텍스트를 가진 요청을 동일한 모델 복제본으로 전송하여 캐시 적중률을 극대화하는 핵심 기능입니다. 이 접근 방식은 중복 계산을 크게 줄이고 첫 번째 토큰까지의 시간을 개선하므로 대화형 AI, 검색 증강 생성 (RAG), 기타 템플릿 기반 생성형 AI 워크로드에 매우 효과적입니다. - 동적 LoRA 미세 조정 모델 서빙: 공통 가속기에서 동적 LoRA 미세 조정 모델 서빙을 지원합니다. 이렇게 하면 공통 기본 모델과 가속기에서 여러 LoRA 미세 조정 모델을 다중화하여 모델을 서빙하는 데 필요한 GPU와 TPU의 수가 줄어듭니다.
- 추론을 위한 자동 확장 최적화: GKE 수평형 포드 자동 확장 처리 (HPA)는 모델 서버 측정항목을 사용하여 자동 확장하므로 효율적인 컴퓨팅 리소스 사용과 최적화된 추론 성능을 보장할 수 있습니다.
- 모델 인식 라우팅: GKE 클러스터 내
OpenAI API사양에 정의된 모델 이름을 기반으로 추론 요청을 라우팅합니다. 트래픽 분할, 요청 미러링과 같은 게이트웨이 라우팅 정책을 정의하여 다양한 모델 버전을 관리하고 모델 출시를 간소화할 수 있습니다. 예를 들어 특정 모델 이름에 대한 요청을 서로 다른 InferencePool 객체로 라우팅할 수 있으며, 각 객체는 서로 다른 버전의 모델을 서빙합니다. 이 기능을 구성하는 방법에 대한 자세한 내용은 본문 기반 라우팅 구성을 참고하세요. - 통합 AI 안전 및 콘텐츠 필터링: GKE Inference Gateway는 Google CloudModel Armor와 통합되어 게이트웨이에서 프롬프트와 응답에 AI 안전 검사와 콘텐츠 필터링을 적용합니다. NVIDIA NeMo Guardrails를 사용할 수도 있습니다. Model Armor는 회고 분석 및 최적화를 위해 요청, 응답, 처리 로그를 제공합니다. GKE Inference Gateway의 개방형 인터페이스를 사용하면 서드 파티 제공업체와 개발자가 추론 요청 프로세스에 커스텀 서비스를 통합할 수 있습니다.
- 모델별 서빙
Priority: AI 모델의 서빙Priority를 지정할 수 있습니다. 지연 시간에 민감한 요청을 지연 시간에 덜 민감한 일괄 추론 작업보다 우선시합니다. 예를 들어, 지연 시간에 민감한 애플리케이션의 요청에 우선순위를 부여하고, 리소스가 제한된 경우에는 시간 민감도가 낮은 태스크를 삭제할 수 있습니다. - 예측된 지연 시간 기반 라우팅: 실시간 트래픽에서 지속적으로 학습된 XGBoost 모델을 사용하여 추론 요청을 라우팅하여 요청별 첫 번째 토큰까지의 시간 (TTFT) 및 출력 토큰당 시간 (TPOT) 목표를 최적화합니다. 분산이 큰 워크로드에서 정적 휴리스틱보다 정확합니다. GKE Inference Gateway에서 예측 지연 시간 기반 라우팅 사용을 참고하세요.
- 추론 모니터링 가능성: 요청률, 지연 시간, 오류, 포화도와 같은 추론 요청의 모니터링 가능성 측정항목을 제공합니다. Cloud Monitoring 및 Cloud Logging을 통해 추론 서비스의 성능과 동작을 모니터링하고, 세부정보를 파악할 수 있는 특화된 사전 빌드 대시보드를 활용하세요. 자세한 내용은 GKE Inference Gateway 대시보드 보기를 참조하세요.
- Apigee를 사용한 고급 API 관리: Apigee와 통합되어 API 보안, 비율 제한, 할당량과 같은 기능으로 추론 게이트웨이를 강화합니다. 자세한 안내는 인증 및 API 관리를 위해 Apigee 구성하기를 참조하세요.
- 확장성: 확장 가능한 오픈소스 Kubernetes Gateway API 추론 확장 프로그램에 기반하여 빌드되며, llm-d로 구동되는 사용자 관리 llm-d 엔드포인트 선택기 (EPP) 알고리즘을 지원합니다. llm-d로 구동되는 llm-d 엔드포인트 선택기 (EPP) 알고리즘은 이 확장 프로그램의 핵심 라우팅 인텔리전스를 제공합니다.
- 멀티포트 지원: 여러 포트를 노출하는 모델 서버를 지원합니다. 이는 데이터 병렬 주의와 같은 고급 서빙 시나리오에 필수적입니다.
- 네트워크 엔드포인트 그룹 (NEG) 한도:Google Cloud 백엔드 서비스당 NEG 50개로 제한됩니다. 다중 포트 InferencePool을 사용하는 경우 각 영역의 각 포트에서 전용 NEG가 생성됩니다. 예를 들어 일반적인 리전 클러스터 (영역 3개)에 포트가 8개인 InferencePool은 NEG 24개를 생성합니다. 따라서 멀티 클러스터 게이트웨이는 50 NEG 한도에 도달하기 전에 최대 2개 클러스터 (2개 클러스터 × 24 NEG = 48 NEG)에서 이러한 InferencePool만 집계할 수 있습니다.
주요 개념 이해
GKE Inference Gateway는 GatewayClass 객체를 사용하는 기존 GKE 게이트웨이를 개선합니다. GKE Inference Gateway는 추론을 위한 OSS Kubernetes Gateway API 확장 프로그램에 맞춰 다음과 같은 새로운 Gateway API 커스텀 리소스 정의 (CRD)를 도입합니다.
- InferencePool 객체: 동일한 컴퓨팅 구성, 가속기 유형, 기본 언어 모델, 모델 서버를 공유하는 포드 (컨테이너) 그룹을 나타냅니다. 이렇게 하면 AI 모델 서빙 리소스가 논리적으로 그룹화되고 관리됩니다. 단일 InferencePool 객체는 여러 GKE 노드에 걸쳐 여러 포드를 포함할 수 있으며 확장성과 고가용성을 제공합니다. 여러 포트가 필요한 모델 서버를 지원하기 위해 InferencePool 리소스에 최대 8개의
targetPorts를 지정할 수 있습니다. - InferenceObjective 객체:
OpenAI API사양에 따라 InferencePool의 서빙 모델 이름을 지정합니다. InferenceObjective 객체는 AI 모델의Priority와 같은 모델의 서빙 속성도 지정합니다. GKE Inference Gateway는 우선순위 값이 높은 워크로드를 우선합니다. 이를 통해 GKE 클러스터에서 지연 시간에 민감한 AI 워크로드와 지연 시간에 허용적인 AI 워크로드를 다중화할 수 있습니다. LoRA 미세 조정 모델을 서빙하도록 InferenceObjective 객체를 구성할 수도 있습니다.
다음 다이어그램은 GKE Inference Gateway와 GKE 클러스터 내의 AI 안전, 모니터링 가능성, 모델 서빙과의 통합을 보여줍니다.
다음 다이어그램은 두 개의 새로운 추론 중심 페르소나와 이들이 관리하는 리소스에 초점을 맞춘 리소스 모델을 보여줍니다.
llm-d 라우터
llm-d 라우터는 추론 게이트웨이가 요청별 엔드포인트를 결정하는 데 사용하는 지능형 요청 라우팅 구성요소입니다. 두 가지 하위 구성요소로 구성됩니다.
| 하위 구성요소 | 설명 |
|---|---|
| `L7 프록시` | 데이터 영역(연결 관리, TLS 종료, 요청 전달)을 처리하는 규정을 준수하는 산업 등급 L7 프록시(일반적으로 Envoy) GKE Inference Gateway (게이트웨이 모드)에서 프록시는 GKE 게이트웨이입니다. |
| `llm-d Endpoint Picker (EPP)` | 프록시가 ext-proc 프로토콜을 사용하여 모든 요청에 대해 참조하는 전문 서비스입니다. EPP에는 라우팅 인텔리전스가 포함되어 있습니다. 모델 서버의 실시간 신호(KV 캐시 사용률, 대기열 길이, 프리픽스 캐시 상태, LoRA 어댑터 선호도)를 사용하여 각 요청에 최적의 모델 서버 포드를 선택합니다. |
게이트웨이 모드
GKE Inference Gateway는 게이트웨이 모드에서 작동하는 llm-d Router입니다. 게이트웨이 모드에서 프록시는 EPP 서비스와 별도로 프로비저닝되고 관리되는 공식 Kubernetes 게이트웨이입니다. 게이트웨이는 ext-proc를 통해 EPP를 호출하여 라우팅 결정을 내린 다음 선택한 모델 서버 포드로 요청을 직접 전달합니다.
게이트웨이 (데이터 플레인)와 EPP (라우팅 인텔리전스)를 분리하면 다음이 가능합니다.
- 공유 인프라: 단일 GKE 게이트웨이가 표준 Kubernetes 서비스와 함께 여러 InferencePool을 제공합니다.
- 고급 트래픽 관리:
HTTPRoute정책은 가중치 기반 분할, 점진적 출시, 요청 미러링을 지원합니다. - 독립적인 확장: EPP 서비스는 게이트웨이와 독립적으로 확장됩니다.
- 클라우드 네이티브 통합: GKE의 관리형 게이트웨이 컨트롤러, Cloud Load Balancing, 기존 모니터링 가능성 도구와 함께 작동합니다.
GKE Inference Gateway 작동 방식
GKE Inference Gateway는 Gateway API 확장 프로그램과 모델별 라우팅 로직을 사용하여 AI 모델에 대한 클라이언트 요청을 처리합니다. 다음 단계에서는 요청 흐름을 설명합니다.
요청 흐름 작동 방식
GKE Inference Gateway는 초기 요청부터 모델 인스턴스까지 클라이언트 요청을 라우팅합니다. 이 섹션에서는 GKE Inference Gateway에서 요청을 처리하는 방법을 설명합니다. 이 요청 흐름은 모든 클라이언트에서 공통적으로 사용됩니다.
- 클라이언트는 OpenAI API 사양에 설명된 대로 형식이 지정된 요청을 GKE에서 실행되는 모델에 전송합니다.
GKE Inference Gateway는 다음 추론 확장 프로그램을 사용하여 요청을 처리합니다.
- 본문 기반 라우팅 확장 프로그램: 클라이언트 요청 본문에서 모델 식별자를 추출하여 GKE Inference Gateway로 전송합니다.
그런 다음 GKE Inference Gateway는 이 식별자를 사용하여 Gateway API
HTTPRoute객체에 정의된 규칙에 따라 요청을 라우팅합니다. 요청 본문 라우팅은 URL 경로를 기반으로 한 라우팅과 유사합니다. 차이점은 요청 본문 라우팅이 요청 본문의 데이터를 사용한다는 것입니다. - 보안 확장 프로그램: Model Armor, NVIDIA NeMo Guardrails 또는 지원되는 서드 파티 솔루션을 사용하여 콘텐츠 필터링, 위협 감지, 삭제, 로깅을 포함한 모델별 보안 정책을 적용합니다. 보안 확장 프로그램은 요청 및 응답 처리 경로 모두에 이러한 정책을 적용합니다.
- llm-d 엔드포인트 선택기 (EPP): InferencePool 내 모델 서버의 주요 측정항목을 모니터링하고 최적의 모델 복제본으로 요청을 라우팅합니다. 자세한 내용은 llm-d 라우터를 참고하세요.
- 본문 기반 라우팅 확장 프로그램: 클라이언트 요청 본문에서 모델 식별자를 추출하여 GKE Inference Gateway로 전송합니다.
그런 다음 GKE Inference Gateway는 이 식별자를 사용하여 Gateway API
GKE Inference Gateway는 엔드포인트 선택기 확장 프로그램에서 반환된 모델 복제본으로 요청을 라우팅합니다.
다음 다이어그램은 GKE Inference Gateway를 통해 클라이언트에서 모델 인스턴스로의 요청 흐름을 보여줍니다.
트래픽 분산 작동 방식
GKE Inference Gateway는 InferencePool 객체 내의 모델 서버에 추론 요청을 동적으로 분산합니다. 이렇게 하면 리소스 활용도를 최적화하고 다양한 부하 조건에서 성능을 유지할 수 있습니다. GKE Inference Gateway는 다음 두 가지 메커니즘을 사용하여 트래픽 분산을 관리합니다.
엔드포인트 선택: 추론 요청을 처리하는 데 가장 적합한 모델 서버를 동적으로 선택합니다. 서버 부하와 가용성을 모니터링한 다음 여러 최적화 휴리스틱을 결합하여 각 서버의
score를 계산하여 최적의 라우팅 결정을 내립니다.- 프리픽스 캐시 인식 라우팅: GKE Inference Gateway는 각 모델 서버에서 사용 가능한 프리픽스 캐시 색인을 추적하고 프리픽스 캐시 일치가 더 긴 서버에 더 높은 점수를 부여합니다.
- 부하 인식 라우팅: GKE Inference Gateway는 서버 부하(KV 캐시 사용률 및 대기 중인 큐 깊이)를 모니터링하고 부하가 낮은 서버에 더 높은 점수를 부여합니다.
- LoRA 인식 라우팅: 동적 LoRA 서빙이 사용 설정된 경우 GKE Inference Gateway는 서버별 활성 LoRA 어댑터를 모니터링하고 요청된 LoRA 어댑터가 활성화되어 있거나 요청된 LoRA 어댑터를 동적으로 로드할 여유 공간이 있는 서버에 더 높은 점수를 부여합니다. 위의 모든 항목의 총점이 가장 높은 서버가 선택됩니다.
대기열 및 셰딩: 요청 흐름을 관리하고 트래픽 과부하를 방지합니다. GKE Inference Gateway는 수신 요청을 큐에 저장하고 정의된 우선순위에 따라 요청의 우선순위를 지정합니다.
GKE Inference Gateway는 숫자 Priority 시스템(Criticality라고도 함)을 사용하여 요청 흐름을 관리하고 과부하를 방지합니다. 이 Priority는 각 InferenceObjective에 대해 사용자가 정의하는 선택적 정수 필드입니다. 값이 클수록 더 중요한 요청임을 의미합니다. 시스템에 부담이 가해지면 Priority가 0보다 작은 요청은 우선순위가 낮은 것으로 간주되어 먼저 삭제되고, 더 중요한 워크로드를 보호하기 위해 429 오류가 반환됩니다. Priority의 기본값은 0입니다. Priority가 0보다 작은 값으로 명시적으로 설정된 경우에만 우선순위로 인해 요청이 삭제됩니다. 이 시스템을 사용하면 시간에 덜 민감한 일괄 작업보다 지연 시간에 민감한 온라인 추론 트래픽을 우선시할 수 있습니다.
GKE Inference Gateway는 지속적인 또는 거의 실시간 업데이트가 필요한 챗봇 및 실시간 번역과 같은 애플리케이션의 스트리밍 추론을 지원합니다. 스트리밍 추론은 단일의 완전한 출력이 아닌 증분 청크 또는 세그먼트로 응답을 제공합니다. 스트리밍 응답 중에 오류가 발생하면 스트림이 종료되고 클라이언트가 오류 메시지를 수신합니다. GKE Inference Gateway는 스트리밍 응답을 재시도하지 않습니다.
애플리케이션 예시 살펴보기
이 섹션에서는 GKE Inference Gateway를 사용하여 다양한 생성형 AI 애플리케이션 시나리오를 해결하는 예시를 보여줍니다.
예 1: GKE 클러스터에서 여러 생성형 AI 모델 서빙
한 회사에서 다양한 워크로드를 서빙하기 위해 여러 대규모 언어 모델 (LLM)을 배포하려고 합니다. 예를 들어 챗봇 인터페이스에는 Gemma3 모델을, 추천 애플리케이션에는 DeepSeek 모델을 배포할 수 있습니다. 회사는 이러한 LLM의 최적의 서빙 성능을 보장해야 합니다.
GKE Inference Gateway를 사용하면 선택한 가속기 구성으로 이러한 LLM을 InferencePool에서 GKE 클러스터에 배포할 수 있습니다. 그런 다음 모델 이름 (예: chatbot 및 recommender)과 Priority 속성을 기반으로 요청을 라우팅할 수 있습니다.
다음 다이어그램은 GKE Inference Gateway가 모델 이름과 Priority에 따라 요청을 다양한 모델로 라우팅하는 방법을 보여줍니다.
이 다이어그램은 example.com/completions의 생성형 AI 서비스에 대한 요청이 GKE Inference Gateway에서 처리되는 방식을 보여줍니다. 요청은 먼저 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 Inference Gateway가 공유 가속기에서 여러 LoRA 어댑터를 서빙하는 방법을 보여줍니다.
다음 단계
- GKE Inference Gateway 배포
- GKE Inference Gateway 구성 맞춤설정
- GKE Inference Gateway를 사용하여 LLM 서빙
- GKE Inference Gateway를 사용하여 예측 지연 시간 기반 라우팅 사용(프리뷰)