AWS, SageMaker AI 인퍼런스 엔드포인트에 'Capacity-Aware Instance Pool' 도입… 우선순위 인스턴스 폴백·CloudWatch InstanceType 차원·p5/g6 가중 스케일링

Amazon SageMaker AI가 신규 및 기존 인퍼런스 엔드포인트에 capacity-aware instance pool 기능을 도입했다. 사용자가 우선순위가 매겨진 인스턴스 타입 리스트를 정의해두면, SageMaker AI가 엔드포인트 생성·스케일아웃·스케일인 시점에 용량이 부족할 때마다 리스트를 따라 자동으로 다음 인스턴스로 폴백한다. 이 기능은 Single Model Endpoints, Inference Component-based endpoints, Asynchronous Inference endpoints에서 사용할 수 있다.

기존에는 SageMaker AI 인퍼런스 엔드포인트를 만들 때 단일 인스턴스 타입을 지정해야 했고, 해당 타입에 가용 용량이 없으면 Insufficient Capacity 오류와 함께 엔드포인트가 running 상태로 진입하지 못했다. 운영자는 다른 인스턴스 타입으로 설정을 바꿔 수동으로 재시도해야 했고, 오토스케일러는 같은 타입을 무한 재시도해 트래픽 증가에도 플릿이 늘지 않았다. 스케일다운 단계에서도 우선/폴백 하드웨어 구분이 없어 모든 인스턴스가 동일한 제거 후보였다.

새 instance pool 방식에서는 SageMaker AI가 1순위 인스턴스 타입을 먼저 시도하고, 용량이 없으면 즉시 2순위, 3순위로 넘어가 가장 먼저 가용한 AI 인프라 위에서 InService 상태로 올라간다. 오토스케일링이 트리거됐을 때 우선 인스턴스가 제약 상태면 다음 우선순위 타입으로 스케일아웃이 진행돼 트래픽이 끊기지 않는다. 스케일인 시에는 가장 낮은 우선순위(폴백) 인스턴스부터 먼저 제거되며, 이후 스케일아웃에서 다시 최상위 타입을 시도하기 때문에 시간이 지날수록 플릿이 선호 하드웨어 쪽으로 자연스럽게 수렴한다.

관측성도 강화됐다. 기존 모든 Amazon CloudWatch 메트릭에 InstanceType 차원이 추가돼 단일 엔드포인트 안에서도 인스턴스 타입별 latency, throughput, GPU utilization, instance count를 분리해 추적할 수 있다. 종전에는 메트릭이 엔드포인트 단위로 집계돼 어떤 인스턴스 타입이 문제의 원인인지 식별하기 어려웠다.

폴백 인스턴스는 GPU 메모리·연산 성능·아키텍처가 다르기 때문에 풀에 속한 각 인스턴스 타입에 맞는 모델 설정이 필요하다. 첫 번째 옵션은 사용자가 직접 최적화된 모델 아티팩트를 준비하는 방식이다. 1순위 고성능 인스턴스에는 다중 GPU 텐서 병렬화를, 중급 폴백에는 speculative decoding을, 최저 우선순위 폴백에는 INT4 양자화를 적용하는 식이다. 각 구성마다 별도의 SageMaker AI 모델을 만들고 InstancePools 항목 또는 인스턴스 타입별 Specifications에 ModelNameOverride로 연결하면, 폴백이 발생했을 때 SageMaker AI가 해당 하드웨어용으로 준비한 모델을 배포한다.

두 번째 옵션은 SageMaker AI inference recommendations를 사용해 하드웨어별 최적화 구성을 자동으로 생성하는 방법이다. 기본 모델을 제공하면 SageMaker AI가 speculative decoding과 quantization 같은 기법을 적용해 타겟 인스턴스 타입별로 최적 구성을 산출한다. 추천 작업 결과는 인스턴스 타입마다 ModelPackageArn과 InferenceSpecificationName을 AIRecommendationModelDetails 응답으로 돌려주며, 이를 사용해 인스턴스 타입별 SageMaker AI 모델을 만들고 ModelNameOverride로 연결하는 흐름은 옵션 1과 동일하다.

플릿 안에 처리량 특성이 다른 인스턴스 타입이 섞여 있으면 단순 집계 메트릭은 실제 부하를 왜곡할 수 있다. 예컨대 동시 요청 18개를 처리하는 p5와 7개를 처리하는 g6를 단순 평균하면 12.5라는 숫자가 나오지만 어느 쪽 부하도 정확히 반영하지 못한다. 새 기능은 CloudWatch metric math로 가중 메트릭을 만들 수 있게 해, 각 타입의 관측 동시성을 그 타입의 최대 용량으로 나눠 0.0~1.0 사이 비율을 산출하고 이를 평균해 플릿 단위 사용률 신호로 사용한다. TargetValue를 0.7로 설정하면 가중 평균이 전체 플릿 용량의 70%를 넘을 때 스케일아웃이 트리거된다.

AWS가 제시한 예시에서 p5 한 대당 최대 동시 요청은 20, g6는 8로 측정됐고 사용자는 자신의 모델로 부하 테스트를 통해 이 최댓값을 측정해 식에 넣어야 한다. 풀 구성원의 처리 능력 차이가 클수록 가중 사용률 메트릭의 가치가 크며, 모든 인스턴스 타입의 처리량이 비슷한 워크로드라면 기존 스케일링 정책을 수정하지 않고도 동일하게 동작한다.