이 권장사항 가이드에서는 사용 가능한 측정항목과 GKE에서 TPU를 사용하는 단일 호스트 JetStream 추론 워크로드에 대해 수평형 포드 자동 확장 처리(HPA)를 설정하는 데 적절한 측정항목을 선택하는 방법을 보여줍니다. HPA는 모델 서버가 부하에 따라 적절하게 확장되도록 하는 효율적인 방법입니다. HPA 설정을 미세 조정하는 것은 추론 서버 성능 목표를 달성하기 위해 프로비저닝된 하드웨어 비용을 트래픽 수요에 맞추는 기본적인 방법입니다.
이러한 권장사항을 구현하는 방법의 예시는 GKE에서 TPU의 LLM 워크로드 자동 확장 구성을 참조하세요.
목표
이 가이드는 Kubernetes에서 TPU를 사용하여 단일 호스트 JetStream 워크로드를 최적화하는 데 관심이 있는 생성형 AI 고객, 신규 또는 기존 GKE 사용자, ML 엔지니어, LLMOps(DevOps) 엔지니어를 대상으로 합니다.
이 가이드를 참고하면 다음을 수행할 수 있습니다.
- 단일 호스트 JetStream 추론에 대한 주요 자동 확장 측정항목을 이해합니다.
- 자동 확장할 측정항목을 고려할 때 비교할 대략적인 장단점을 파악합니다.
JetStream 추론을 위한 자동 확장 측정항목 개요
다음 측정항목을 사용하는 것이 좋습니다.
서버 측정항목
다른 많은 LLM 추론 서버와 마찬가지로 JetStream은 성능 측정항목을 제공합니다. GKE는 이러한 서버 수준 측정항목을 기반으로 JetStream의 모니터링 및 자동 확장을 단순화합니다. 자동 확장을 구성하려면 먼저 JetStreams 요청 파이프라인이 핵심성과지표에 미치는 영향을 이해해야 합니다. 모든 수신 요청은 사전 작성 큐, 전송 큐, 생성 큐를 통과한 후 디코딩 요청이 됩니다. JetStream은 디코딩 요청을 순차적으로 수락하고 고정된 수의 디코딩 스레드를 사용하여 동시에 처리합니다. 특정 지점에서 디코딩 요청을 처리하는 데 사용된 디코딩 엔진의 비율은 jetstream_slots_used_percentage 측정항목으로 측정됩니다.
단일 호스트 JetStream을 확장하는 경우 지연 시간과 처리량에 영향을 미칩니다.
- 들어오는 요청의 비율이 디코딩 슬롯이 요청을 처리할 수 있는 비율보다 낮으면 요청이 대기열에 백로그되지 않습니다. JetStream에 백로그가 없으면 처리량은 수신 요청 비율에 비례합니다. 지연 시간은 대부분 일정하게 유지되지만 새로 수락된 디코딩 요청이 디코딩을 중단하므로 동시 디코딩 요청 수에 비례하여 약간 증가합니다.
- 들어오는 요청 수가 디코딩 슬롯이 요청을 처리할 수 있는 속도를 초과하면 요청이 큐에 백로그됩니다. JetStream에 백로그가 있으면 처리량은 일정하게 유지되는 반면 요청 지연 시간은 백로그된 요청 수에 비례하여 더 크게 증가합니다.
다음 서버 측정항목은 이러한 관련 성능 지표와 가장 밀접한 상관관계를 가지므로 자동 확장에 사용하는 것이 좋습니다.
jetstream_prefill_backlog_size: 서버 큐에서 처리를 기다리는 요청 수(백로그)입니다. 이 측정항목은 지연 시간과 밀접한 상관관계가 있습니다. 자세한 내용은 관련 권장사항 섹션을 참고하세요.jetstream_slots_used_percentage: JetStream에서 처리할 수 있는 총 요청 수의 백분율로 추론이 진행 중인 요청 수입니다. 이 측정항목은 처리량과 밀접한 관련이 있습니다. 자세한 내용은 관련 권장사항 섹션을 참고하세요.
이러한 측정항목은 성능 및 트래픽 변동에 대해 복원력이 우수하므로 다양한 TPU 하드웨어 설정의 자동 확장을 위한 안정적인 시작점으로 사용됩니다.
TPU 측정항목
LLM 서빙에 컴퓨팅이 아닌 메모리에 의해 병목 현상이 발생하는 경우, 하드웨어의 리소스 사용률을 가장 잘 반영하므로 다른 TPU 측정항목 대신 메모리 사용량으로 JetStream을 확장하는 것이 좋습니다. 자세한 내용은 관련 권장사항 섹션을 참고하세요.
자동 확장 측정항목 선택 시 고려사항
다음 고려사항과 권장사항에 따라 GKE에서 추론 워크로드 성능 목표를 달성하기 위한 자동 확장에 가장 적합한 측정항목을 선택하세요.
권장사항: 사전 입력 백로그(큐) 크기를 사용하여 특정 목표 지연 시간 기준 내에서 처리량을 극대화하고 비용을 최소화합니다.
처리량과 비용을 최적화할 때 및 모델 서버의 기기당 배치 크기의 최대 처리량으로 지연 시간 목표를 달성할 수 있는 경우 사전 입력 큐 크기 자동 확장을 사용하는 것이 좋습니다.
사전 입력 큐 크기는 요청 지연 시간과 직접적인 관련이 있습니다. 수신 요청은 처리되기 전 모델 서버의 사전 입력 큐에 추가되고 이 큐 시간이 전체 지연 시간에 추가됩니다. 증가된 부하가 큐를 빠르게 채우므로 큐 크기는 부하 급증을 나타내는 민감한 지표입니다.
사전 입력 큐 크기에 따른 자동 확장 기능은 부하 시 확장되고 큐가 비어 있을 때 축소하여 큐 시간을 최소화합니다. 큐 크기는 요청 크기, 모델, 하드웨어와 독립적이므로 이 방법은 구현하기 쉽습니다.
각 모델 서버 복제본의 처리량을 극대화하려면 사전 입력 큐 크기에 집중하는 것이 좋습니다. 사전 입력 큐 크기는 처리되지 않은 대기 중인 요청을 추적합니다. JetStream은 연속 일괄 처리를 사용하여 동시 요청을 극대화하고 일괄 처리 공간을 사용할 수 있을 때 큐를 적게 유지합니다. 일괄 처리 공간이 제한되어 있으면 큐가 눈에 띄게 늘어나므로 증가 지점을 확장 시작 신호로 사용합니다. 큐 크기 자동 확장과 최적화된 일괄 처리량을 결합하면 요청 처리량을 극대화할 수 있습니다.
HPA에 최적화된 큐 크기 기준점 결정
올바른 큐 크기 기준점을 선택하려면 3~5 사이의 값으로 시작하고 요청이 원하는 지연 시간에 도달할 때까지 점진적으로 늘립니다. 테스트에 locust-load-inference 도구를 사용합니다. 기준점이 10 미만인 경우 HPA 수직 확장 설정을 미세 조정하여 트래픽 급증을 처리합니다.
Cloud Monitoring 커스텀 대시보드를 만들어 측정항목 동작을 시각화할 수도 있습니다.
제한사항
변동을 줄이기 위해 목표 값에 대해 0.1 작업 없음 범위가 기본값으로 설정되는 HPA 톨러레이션(toleration)에 유의해야 합니다.
사전 입력 큐 크기는 동시 요청을 직접 제어하지 않으므로 기준점으로 기기당 배치 크기가 허용하는 것보다 낮은 지연 시간을 보장할 수 없습니다. 이 문제를 해결하려면 기기당 배치 크기를 수동으로 줄이거나 배치 크기 자동 확장을 수행하면 됩니다.
권장사항: slots_used 비율을 사용하여 큐 크기보다 낮은 목표 지연 시간 기준점에 도달
큐 기반 확장이 요구사항을 충족하기에 충분히 빠르지 않은 지연 시간에 민감한 워크로드가 있는 경우 slot_used 기반 자동 확장을 선택하는 것이 좋습니다.
slots_used 자동 확장을 사용하면 동시에 처리되는 요청 수가 극대화되도록 워크로드 처리량이 확장되고 동시에 처리되는 요청이 적을 때는 축소됩니다. 이는 지연 시간에 두 가지 영향을 미칩니다. 첫째, slots_used 기반 자동 확장은 수신되는 각 요청에 슬롯을 보장하기 위해 확장되므로 임곗값이 1에 얼마나 가깝게 설정되는지 여부는 요청이 큐에 추가되어 지연 시간이 길어질 가능성이 있습니다. 둘째, 배치 크기가 클수록 처리량이 늘어나지만, 일부 요청의 사전 입력 단계가 연속 일괄 처리 모델 서버에서 다른 요청의 디코딩 단계를 방해하기 때문에 지연 시간도 늘어납니다. 배치 크기 패턴을 모니터링하고 자동 확장을 사용하여 부하 급증 시 동시 요청을 최소화할 수 있습니다.
큐 크기가 이미 지연 시간 목표를 충족하면 이를 확장의 우선순위에 둡니다. 이렇게 하면 처리량과 비용 효율성이 모두 극대화됩니다. 그러나 slot_used는 지연 시간에 민감한 워크로드에 유용합니다.
또한 slots_used 기반 자동 확장을 살펴보기 전에 기기당 배치 크기를 적절한 값으로 조정하는 것이 좋습니다. 원하는 경우 이를 큐 기반 자동 확장과 페어링할 수도 있습니다.
HPA에 최적화된 slots_used 백분율 기준점 결정
적절한 배치 크기 기준점을 선택하려면 서버의 부하를 실험적으로 늘리고 일괄 처리 크기가 최대가 되는 지점을 관찰하세요. 또한 테스트에 locust-load-inference 도구를 사용하는 것이 좋습니다. 메모리 사용량이 최대화되는 기기별 최적의 배치 크기를 파악한 후 slots_used 비율 목표를 구성할 수 있습니다. 초기 목표 값을 1보다 약간 낮게 설정하고 원하는 지연 시간이 달성될 때까지 줄입니다.
Cloud Monitoring 커스텀 대시보드를 만들어 측정항목 동작을 시각화할 수도 있습니다.
제한사항
변동을 줄이기 위해 목표 값에 대해 0.1 작업 없음 범위가 기본값으로 설정되는 HPA 톨러레이션(toleration)에 유의해야 합니다.
slots_used 비율에 대한 자동 확장은 지연 시간 제어에 유용하지만 제한사항이 있습니다. 다양한 요청 크기와 하드웨어 제약조건으로 인해 올바른 slots_used 비율 기준점을 찾기가 어렵습니다. 확장 규칙에서 평균 slots_used 비율을 100% 미만으로 유지하려고 하면 확장 규칙이 사용 가능한 슬롯 수를 0이 아닌 상태로 유지하려고 시도한다는 의미입니다. 이러한 사용 가능한 슬롯은 사용 가능한 처리량이 사용되지 않음에 해당하며, 사용 가능한 TPU를 최대한 활용하려는 경우에는 적합하지 않습니다.
권장사항: TPU 고대역폭 메모리(HBM)를 사용하여 하드웨어 사용률 극대화
TPU 고대역폭 메모리(HBM) 사용은 요청 크기를 고려하지 않으므로 시스템 측정항목과 비교해도 하드웨어 사용량과 가장 직접적인 연관이 있습니다. 큐 크기로 확장하면 하드웨어 사용률을 더 효과적으로 극대화할 수 있지만 지연 시간이 늘어납니다. 서버 측정항목 대신 시스템 측정항목을 사용하려면 처리량과 관련이 있는 slots_used를 사용한 HBM 사용량을 자동 확장의 대안으로 사용하는 것이 좋습니다. TPU 메모리에 관한 자세한 내용은 TPU 작동 방식을 참고하세요.
배치 크기를 최적 지점 이상으로 늘리면 처리량이 향상되지만 메모리 부족(OOM) 오류 위험이 증가합니다. 처리량과 안정성의 균형을 맞추려면 HBM 측정항목을 기반으로 확장하는 것이 좋습니다. 부하가 증가하면 HBM 사용량이 증가하여 먼저 확장이 트리거되므로 사전 입력 큐 크기와 HBM 사용량을 동시에 확장하지 않는 것이 좋습니다.
HPA에 가장 적합한 TPU HBM 사용량 임곗값 확인
메모리 사용 임곗값을 선택하기 전에 기기당 배치 크기를 예상 최대 부하에서 작동할 때 사용되는 메모리를 최대화하는 값으로 설정하는 것이 좋습니다. 이 값은 실험적으로 결정해야 하며 총 HBM과 예상 프롬프트 및 응답 길이에 따라 크게 달라집니다. 실험 및 테스트에는 locust-load-inference 도구를 사용하는 것이 좋습니다.
기기별 배치 크기와 마찬가지로 TPU 메모리 사용률을 극대화하면서 OOM 동작의 위험을 최소화하도록 임곗값을 설정합니다.
Cloud Monitoring 커스텀 대시보드를 만들어 측정항목 동작을 시각화할 수도 있습니다.
제한사항
지연 시간과 처리량이 HBM 사용량과 일치하는 정도를 약화시키는 두 가지 주의사항이 있습니다. HBM 사용량의 변동성과 TPU 측정항목의 일반적인 낮은 샘플링 레이트입니다. 또한 HBM 사용과 지연 시간 간에 여전히 상관관계가 있지만 HBM 사용량이 증가해도 큐에 추가된 요청 수가 증가하는 것보다 지연 시간에 미치는 영향이 훨씬 적습니다.
권장사항: HPA 구성 최적화
다음 HPA 구성 옵션을 설정하는 것이 좋습니다.
- 안정화 기간: 측정항목 변동으로 인해 복제본 수가 빠르게 변경되지 않도록 하려면 이 HPA 구성 옵션을 사용합니다. 기본값은 축소(조기 축소 방지)의 경우 5분, 수직 확장(대응력 보장)의 경우 0입니다. 워크로드의 변동성과 원하는 대응력에 따라 값을 조정합니다.
- 확장 정책: 이 HPA 구성 옵션을 사용하여 확장 및 축소 동작을 미세 조정합니다. '포드' 정책 한도를 설정하여 시간 단위별로 변경되는 복제본의 절대 수를 지정하고 '비율' 정책 한도를 설정하여 비율 변동에 따라 지정할 수 있습니다.
이러한 옵션에 대한 자세한 내용은 오픈소스 Kubernetes 문서의 수평형 포드 자동 확장을 참고하세요.
다음 단계
- TPU에서 LLM 워크로드 자동 확장 구성 방법 알아보기