이 문서에서는 GKE Inference Gateway 내에서 llm-d가 제공하는 예측 지연 시간 기반 라우팅을 사용 설정하고 사용하는 방법을 설명합니다. 기본적으로 GKE Inference Gateway는 부하 신호와 접두사 캐시 선호도 휴리스틱의 조합을 사용하여 요청을 라우팅합니다. 예측된 지연 시간 기반 라우팅은 정적 휴리스틱 가중치를 실시간 트래픽에서 지속적으로 학습된 XGBoost 모델로 대체하여 워크로드 패턴이 바뀌어도 더 정확한 라우팅 결정을 내립니다.
예측된 지연 시간 기반 라우팅을 사용하는 경우
이 기능은 워크로드에 다음 조건이 적용될 때 가장 효과적입니다.
- 프롬프트 및 완성 길이의 높은 분산: 요청 크기가 크게 다른 경우 큐 깊이만으로는 서버 부하를 제대로 나타낼 수 없습니다. 지연 시간 예측기는 요청당 실제 자동 완성 및 디코딩 비용을 고려합니다.
- 요청별 지연 시간 SLO: 애플리케이션이 개별 요청에 대해 첫 번째 토큰까지의 시간 (TTFT) 또는 토큰당 출력 시간 (TPOT) 타겟을 지정하면 스케줄러는 라우팅 중에 이러한 타겟을 적용합니다. 각 후보 포드의 여유 공간 (예측된 지연 시간에서 SLO 타겟을 뺀 값)을 계산하여 이를 수행합니다.
- 취약한 정적 가중치 조정: 트래픽 패턴이 바뀌면서 캐시 어피니티와 로드 신호 간의 균형을 자주 다시 조정하는 경우 온라인 학습 모델이 자동으로 적응합니다.
예측된 지연 시간 기반 라우팅의 작동 방식
이 섹션에서는 예측 지연 시간 기반 라우팅에서 사용되는 아키텍처와 일정 관리 파이프라인을 자세히 설명합니다.
아키텍처
예측된 지연 시간 기반 예약은 EPP 자체와 함께 EPP 포드 내에 두 개의 추가 사이드카 컨테이너를 배포합니다.
| 구성요소 | 설명 |
|---|---|
| 학습 서버 | EPP에서 수신한 완료된 요청 샘플에 대해 XGBoost TTFT 및 TPOT 모델을 지속적으로 재학습합니다. 드문 트래픽 체제가 잊혀지지 않도록 슬라이딩 윈도우에 걸쳐 계층화된 버킷팅을 사용합니다. 업데이트된 모델을 공유 볼륨에 씁니다. |
| 예측 서버 | 요청 핫 경로에서 TTFT 및 TPOT 예측을 EPP에 제공합니다. 공유 볼륨에서 학습된 최신 모델을 읽습니다. 수평으로 확장 가능: 각 서버 인스턴스는 약 300QPS의 예측 작업을 유지합니다. 여러 인스턴스는 1ms 창 내에서 동시 예측 요청을 일괄 처리하는 EPP의 Go 병합 프록시에 의해 부하 분산됩니다. |
llm-d EPP 일정 파이프라인
예측 지연 시간 기반 예약이 사용 설정되면 EPP는 다음 컴포저블 플러그인 시퀀스를 통해 각 요청을 처리합니다.
predicted-latency-producer:InferencePool의 모든 후보 포드에 대해 TTFT 및 TPOT 추정치를 가져오기 위해 예측 서버를 호출합니다. 각 포드의 현재 KV-cache 사용률, 큐 깊이, 접두사 캐시 일치 점수, 수신 요청 기능을 조건으로 합니다. 응답이 클라이언트에 반환되면 프로듀서는 관찰된 TTFT와 토큰 간 지연 시간을 새로운 학습 샘플로 학습 서버에 다시 전송합니다.- 대체 동작: 예측 서버에 연결할 수 없거나 오류를 반환하는 경우 EPP는 KV-캐시 사용률, 대기열 깊이, 접두사 캐시 일치를 기반으로 하는 복합 점수로 자동 대체됩니다.
prefix-cache-affinity-filter: 이 필터는 포드의 접두사 캐시 일치 점수가 어피니티 임계값 (기본값 0.80)을 초과할 때 후보 집합을 캐시 워밍 포드로 좁힙니다. 이 기준점은 프로덕션에서 관찰되는 두 가지 인구 집단을 구분합니다. 이전 턴에서 캐시된 대화 기록이 이미 있는 포드와 그렇지 않은 포드입니다. 이 필터는 입실론 그리디 익스플로잇 및 탐색 전략을 구현합니다.익스플로잇 (기본 경로): 이 경로는 캐시 재사용이 집중되도록 캐시 워밍 포드로 라우팅됩니다.
탐색 (낮은 확률): 이 경로는 콜드 포드에서 캐시 항목을 시드하여 캐시 조각화를 방지하기 위해 구성 가능한 요청 비율로 필터를 완전히 우회합니다.
TTFT 로드 게이트: 익스플로잇 경로에서도 최적의 캐시 워밍 Pod의 예측 TTFT가 최적의 전체 Pod의 TTFT를 구성 가능한 기준점 (기본값 5,000ms)보다 초과하면 어피니티가 깨지고 전체 후보 집합이 사용됩니다.
slo-headroom-tier-filter(SLO 요청만 해당): 요청에 SLO 헤더가 포함된 경우 후보 포드를 긍정적 등급 (SLO를 충족할 것으로 예상됨)과 부정적 등급 (SLO를 위반할 것으로 예상됨)으로 분할합니다.latency-scorer: 후보 포드의 점수를 매깁니다. SLO 헤더가 없으면 예측된 지연 시간이 가장 낮은 포드가 선택됩니다. SLO 헤더를 사용하면headroomSelectionStrategy를 사용하여 헤드룸 (SLO에서 예측된 지연 시간 제외)을 기반으로 점수가 매겨집니다.least(기본값): 빈 패킹 여유 공간이 가장 작은 포드로 라우팅하여 사용률을 극대화하고 로드되지 않은 포드를 향후 트래픽 급증에 대비해 확보합니다.most: 스프레드 가장 여유 공간이 많은 포드로 라우팅하여 예기치 않은 부하 급증에 더 많은 여유를 남깁니다.
latency-slo-admitter(SLO 요청만 해당): SLO를 충족할 후보 포드가 예측되지 않는 경우 타겟을 놓칠 것으로 예상되는 요청에서 용량을 소비하는 대신 셸딩 가능한 요청(우선순위가 0 미만)을 거부합니다. 이 필터는 SLO 헤더가 없거나 SLO를 충족하는 포드가 있는 경우 아무런 영향을 미치지 않습니다.weighted-random-picker: 점수에 가중치를 적용한 무작위 선택을 통해 최종 포드를 선택합니다. 이렇게 하면 점수가 높은 포드를 선호하면서도 부하가 분산됩니다.
스트리밍 모드
predicted-latency-producer 플러그인은 streamingMode 매개변수를 사용하여 구성된 두 가지 학습 모드를 지원합니다.
streamingMode: false(기본값): 엔드 투 엔드 (E2E) 요청 지연 시간으로 학습합니다. 워크로드에서 스트리밍 응답과 비스트리밍 응답이 혼합되거나 요청별 SLO 적용 없이 지연 시간 인식 라우팅만 필요한 경우 이 모드를 사용합니다.streamingMode: true: 별도의 TTFT 및 TPOT 모델을 학습시킵니다. TTFT는 첫 번째 스트리밍 청크에 기록되고 TPOT는 후속 토큰에서 샘플링됩니다. 워크로드가 완전히 스트리밍되고 의미 있는x-slo-ttft-ms/x-slo-tpot-ms시행이 필요한 경우 이 모드를 사용합니다.
시작하기 전에
시작하기 전에 다음 태스크를 수행했는지 확인합니다.
- Google Kubernetes Engine API를 사용 설정합니다. Google Kubernetes Engine API 사용 설정
- 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치했으면
gcloud components update명령어를 실행하여 최신 버전을 가져옵니다. 이전 gcloud CLI 버전에서는 이 문서의 명령어를 실행하지 못할 수 있습니다.
필요한 경우 Compute Engine API, Network Services API, Model Armor API를 사용 설정합니다.
API 액세스 사용 설정으로 이동하여 안내를 따릅니다.
작동하는 GKE Inference Gateway 배포가 있는지 확인합니다. GKE Inference Gateway 배포를 참고하세요.
InferencePool에서 동일한 GPU 유형, 모델 가중치, 서비스 구성 등 동질적인 포드 집합을 사용하는지 확인합니다.GKE 클러스터가 버전 1.32.3 이상인지 확인합니다.
Helm을 설치합니다. Helm 설치 가이드를 참고하세요.
예측된 지연 시간 기반 예약 사용 설정
다음 단계에서는 GKE Inference Gateway 배포에 예측 지연 시간 기반 스케줄링을 사용 설정하는 방법을 안내합니다.
1단계: 예측된 지연 시간이 사용 설정된 InferencePool 설치 또는 업그레이드
latencyPredictor.enabled=true 플래그는 EPP 포드 내에 학습 서버 및 예측 서버 사이드카를 배포하고 전체 일정 플러그인 파이프라인을 연결합니다.
helm upgrade --install INFERENCE_POOL_NAME \
--set inferencePool.modelServers.matchLabels.app=MODEL_SERVER_LABEL \
--set provider.name=gke \
--set inferenceExtension.monitoring.gke.enabled=true \
--set inferenceExtension.latencyPredictor.enabled=true \
--version LLM_D_VERSION \
oci://LLM_D_REGISTRY_PATH
다음을 바꿉니다.
INFERENCE_POOL_NAME: InferencePool의 이름입니다(예:vllm-llama3-8b-instruct).MODEL_SERVER_LABEL: 모델 서버 포드를 선택하는 데 사용되는 라벨 키입니다.LLM_D_VERSION: 사용할 llm-d Helm 차트 버전입니다.LLM_D_REGISTRY_PATH: llm-d OCI 레지스트리 경로입니다.
2단계: 배포 확인
EPP 포드가 모든 사이드카 컨테이너가 준비된 상태로 실행 중인지 확인합니다.
kubectl get pods -l app=INFERENCE_POOL_NAME-epp
EPP 포드에는 EPP 자체, 학습 서버, 하나 이상의 예측 서버 등 모든 컨테이너가 '실행 중' 또는 '준비' 상태로 표시되어야 합니다.
3단계: 기준 요청 보내기
SLO 헤더를 사용 설정하기 전에 라우팅이 작동하는지 확인하기 위해 표준 추론 요청을 전송합니다.
curl -i -X POST GATEWAY_IP:PORT/v1/completions \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer $(gcloud auth print-access-token)' \
-H 'x-prediction-based-scheduling: true' \
-d '{
"model": "MODEL_NAME",
"prompt": "PROMPT_TEXT",
"max_tokens": MAX_TOKENS,
"temperature": "0"
}'
다음을 바꿉니다.
GATEWAY_IP: 게이트웨이 서비스의 IP 주소입니다.PORT: 게이트웨이 서비스의 포트 번호입니다.MODEL_NAME: 추론에 사용할 모델의 이름입니다.PROMPT_TEXT: 입력 프롬프트MAX_TOKENS: 생성할 최대 토큰 수입니다.
x-prediction-based-scheduling: true 헤더는 이 요청을 예측된 지연 시간 예약 파이프라인에 선택합니다. 예측 변수 워밍업 기간 동안 EPP는 휴리스틱 라우팅으로 대체됩니다.
4단계: SLO 인식 요청 보내기 (선택사항)
요청별 SLO 시행을 사용 설정하려면 TTFT 및 TPOT 지연 시간 목표 헤더를 추가하세요.
curl -i -X POST GATEWAY_IP:PORT/v1/completions \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer $(gcloud auth print-access-token)' \
-H 'x-prediction-based-scheduling: true' \
-H 'x-slo-ttft-ms: 500' \
-H 'x-slo-tpot-ms: 50' \
-d '{
"model": "MODEL_NAME",
"prompt": "PROMPT_TEXT",
"max_tokens": MAX_TOKENS,
"temperature": "0",
"stream": true
}'
다음을 바꿉니다.
GATEWAY_IP: 게이트웨이 서비스의 IP 주소입니다.PORT: 게이트웨이 서비스의 포트 번호입니다.MODEL_NAME: 추론에 사용할 모델의 이름입니다.PROMPT_TEXT: 입력 프롬프트MAX_TOKENS: 생성할 최대 토큰 수입니다.
요청 헤더:
x-prediction-based-scheduling: true: 요청을 예측된 지연 시간 예약 파이프라인으로 선택합니다.x-slo-ttft-ms: 허용되는 최대 최초 토큰 획득 시간(밀리초)입니다.x-slo-tpot-ms: 허용되는 최대 출력 토큰당 시간(밀리초)입니다.
예측된 지연 시간 예약 모니터링
지연 시간 예측기가 사용 설정되면 EPP는 Cloud Monitoring을 통해 추가 측정항목을 노출합니다.
| 측정항목 | 설명 |
|---|---|
inference_objective_request_ttft_seconds |
실제 TTFT 분포 (또는 streamingMode=false인 경우 E2E 지연 시간)입니다. |
inference_objective_request_predicted_ttft_seconds |
예측된 TTFT 분포 (또는 streamingMode=false인 경우 E2E 지연 시간)입니다. |
inference_objective_request_tpot_seconds |
실제 TPOT 분포입니다. |
inference_objective_request_predicted_tpot_seconds |
예측된 TPOT 분포입니다. |
inference_objective_request_ttft_slo_violation_total |
TTFT SLO 위반 횟수입니다. |
예측 서버 확장
EPP는 수신 요청당 후보 포드당 하나의 예측 호출을 실행합니다. 각 예측 서버 인스턴스는 약 300QPS의 예측 작업을 유지합니다.
예측 서버 인스턴스 수에 대한 대략적인 안내:
| 클러스터 QPS (포드 100개) | 예측 서버 필요 |
|---|---|
| 최대 1,000QPS | 서버 1개 |
| 최대 5,000QPS | 서버 2개 |
| 최대 10,000 QPS | 서버 4개 |
latencyPredictor.predictionServerCount Helm 값을 업데이트하여 예측 서버 인스턴스를 추가합니다.
제한사항
- 동질성
InferencePool필요: 단일 풀 내에서 혼합된 GPU 유형, 모델 변형 또는 서빙 구성은 지원되지 않습니다. - 워밍업 기간: XGBoost 모델이 정확하게 예측하려면 충분한 실시간 교통정보 샘플이 필요합니다.
- SLO 시행: 시행은 라우팅 레이어에서만 이루어집니다. 모델 서버는 선택 후 SLO 타겟을 초과하는 요청을 종료하지 않습니다.
- 상태: 이 기능은 미리보기 상태입니다. 철저한 테스트 없이 엄격한 SLA 요구사항이 있는 프로덕션 워크로드에는 권장되지 않습니다.