SageMaker Python SDK v3의 추론 추천 자동화

인스턴스 유형과 프레임워크 설정을 찾기 위해 수동으로 반복하던 시행착오 과정이 단일 노트북 워크플로우로 자동화됐다. Amazon SageMaker Python SDK v3.17.0부터 `sagemaker.serve.ai_inference_recommender` 패키지를 통해 추론 추천 및 벤치마킹 기능을 제공한다. 엔지니어는 여러 설정을 일일이 대조하는 대신 데이터 기반의 자동 추천 방식으로 인프라를 선택할 수 있다.

기존에는 추론 최적화를 위해 Amazon SageMaker Studio UI를 사용하거나 Boto3 API를 직접 호출해야 했다. UI 방식은 반복 실험을 자동화하기 어려웠고, Boto3 방식은 설정 변경 시마다 많은 양의 보일러플레이트 코드를 작성해야 했다. 이번 업데이트로 해당 기능들이 Python SDK 오퍼레이션으로 전환되어 노트북 환경이나 파이프라인 워크플로우에 통합됐다.

최신 기능을 사용하려면 Amazon SageMaker Python SDK를 최신 버전으로 업데이트해야 한다.

pip install -U sagemaker

이제 개발자는 노트북 내에서 엔드포인트를 벤치마킹하고, 측정된 지표를 바탕으로 최적의 인스턴스와 소프트웨어 설정을 제안받아 즉시 배포하는 전 과정을 수행할 수 있다. UI에서 확인한 추천 설정을 다시 코드로 옮겨 적던 수동 단계를 없앴으며, 모델 업데이트 시마다 최적 인스턴스를 자동으로 추천받아 배포하는 파이프라인 구축이 가능해졌다.

`generate_deployment_recommendations`를 통한 최적 설정 도출

`mb.generate_deployment_recommendations(...)` 메서드는 사용자가 정의한 워크로드 프로필(예상 요청량과 토큰 길이)을 바탕으로 최적의 인스턴스 유형과 프레임워크 설정을 탐색한다. 사용자는 `PerformanceTarget.TTFT_MS`와 같은 성능 타겟을 설정해 추천 결과의 순위를 결정한다. TTFT(Time To First Token)는 요청 후 첫 번째 글자가 출력될 때까지 걸리는 시간으로, 실시간 채팅 서비스라면 TTFT 최소화를, 배치 처리라면 전체 처리량을 우선순위로 설정한다.

추천 결과는 파이썬 데이터프레임(DataFrame) 형태로 제공된다. 데이터프레임에는 탐색 대상 인스턴스 목록과 각 프레임워크 구성에 따른 성능 수치가 나열되어, 컨테이너 버전이나 동시성 설정 변경에 따른 지표 변화를 수치로 확인할 수 있다.

최적 설정을 확정한 후에는 `ModelBuilder.from_recommendation_job(job_name)` 메서드로 결과값을 불러온다. 이 메서드는 추천 작업에서 도출된 최적 인스턴스 유형과 서빙 파라미터를 ModelBuilder 객체에 자동으로 주입하는 하이드레이션(Hydration)을 수행한다. 이를 통해 데이터 과학자가 찾은 최적 설정을 MLOps 엔지니어가 작업 이름만으로 복원하여 배포 파이프라인에 즉시 적용할 수 있다.

전체적인 추천 및 배포 워크플로우의 실제 구현 사례는 공식 예제 노트북에서 확인 가능하다.

python

추천 작업 결과를 기반으로 모델 빌더를 생성하고 배포하는 과정

model = ModelBuilder.from_recommendation_job(job_name="recommendation-job-2026-08-07")

model.deploy()

실행 가능한 전체 노트북 예제와 세부 설정 방법은 GitHub 저장소 https://github.com/aws-samples/amazon-sagemaker-python-sdk-generative-ai-inference-recommendations 에서 제공한다. 추천 작업으로 생성된 엔드포인트는 비용 발생을 방지하기 위해 검증 후 즉시 삭제해야 한다.

p90 TTFT와 처리량 기반의 LMI 및 vLLM 성능 비교

이렇게 도출된 추천 설정의 실제 성능은 구체적인 지표를 통해 비교 검증할 수 있다. ml.g6.2xlarge 인스턴스에서 LMI(Large Model Inference) 컨테이너 버전에 따라 처리량은 약 16%, 지연 시간은 약 10%의 성능 차이가 발생했다. LMI 버전 `lmi-26-0-0`은 초당 112.8회의 요청 처리량(RequestThroughput)과 초당 3,609개의 출력 토큰 처리량(OutputTokenThroughput)을 기록하며 Rank 0로 선정됐다. 이때 p90 TTFT(상위 10% 지점의 첫 토큰 생성 시간)는 983ms, p90 Latency는 1,000ms였다. 반면 Rank 1인 `lmi-27-0-0` 버전은 처리량 96.9 req/s, 출력 토큰 3,099 tokens/s, p90 TTFT 1,088ms, p90 Latency 1,122ms를 기록했다.

서비스 목적에 따라 선택 지표가 달라진다. 채팅봇처럼 실시간 응답이 중요한 서비스는 p90 또는 p99 TTFT 수치를 낮추는 설정을 선택한다. 사용자가 첫 글자가 나타나는 속도로 반응성을 체감하기 때문이다. 반대로 배치 요약이나 오프라인 데이터 처리 워크로드는 RequestThroughput과 OutputTokenThroughput을 극대화하여 투입 비용 대비 처리 토큰 수를 늘리는 설정을 선택한다.

모델별로 최적의 성능을 내는 프레임워크가 다르므로 LMI와 vLLM(고성능 LLM 추론 엔진)을 병렬로 비교해야 한다. 두 프레임워크에 대해 추천 작업을 동시에 실행하고 도출된 수치를 대조하여 최종 설정을 결정한다. LMI와 vLLM은 서로 다른 최적화 기법과 메모리 관리 방식을 사용하므로, 실제 측정된 벤치마크 수치를 바탕으로 가장 적합한 프레임워크를 선택해 배포한다.

`benchmark_endpoint`를 이용한 배포 후 성능 검증

`benchmark_endpoint` 메서드는 추천 설정을 적용해 배포한 엔드포인트가 실제 서비스 수준 목표(SLO)를 충족하는지 검증한다. 가상 트래픽을 생성해 시스템 한계를 측정하는 합성 부하 테스트(Synthetic load test)를 수행하여, 프로덕션 트래픽 수용 전 지연 시간과 처리량 요구 사항을 확인한다.

테스트 결과 객체는 `metrics` 액세서(Accessor)를 통해 세부 성능 지표에 접근하는 경로를 제공한다. 이를 통해 처리량과 지연 시간 백분위수(Latency Percentiles)를 수치로 확인해 성능 병목 지점을 찾는다. 특히 p90이나 p99 지표를 통해 일부 느린 요청이 사용자 경험에 미치는 영향을 분석하며, 이를 추천 단계의 예상 성능과 대조해 SLO 달성 여부를 판가름한다.

토큰 레벨 타이밍(Token-level timing)까지 측정하여 모델의 응답 속도를 분석할 수 있다. 결과 객체는 타입 지정(Type Hinting)이 적용되어 제공되므로, IDE의 자동 완성 기능을 통해 지표 목록을 즉시 확인할 수 있다. 이는 API 문서 검색 시간을 줄이고 오타로 인한 런타임 에러를 방지한다.

프로그램 방식의 검증은 수동으로 요청을 보내고 로그를 수집하던 파편화된 흐름을 통합한다. 배포 직후 자동으로 성능을 측정하고 기준치 미달 시 설정을 변경하는 자동화 파이프라인 구축이 가능해지며, 모델 업데이트나 인스턴스 변경 시 발생할 수 있는 성능 저하 리스크를 배포 전 단계에서 제거한다.

노트북 통합 워크플로우의 실무 적용 이점

콘솔 UI와 API 호출 사이를 오가며 발생하는 화면 전환은 실험 속도를 늦추는 제약이다. SageMaker Python SDK는 벤치마킹, 추천 생성, 배포 과정을 단일 노트북 환경으로 통합해 실험부터 배포까지의 사이클을 단축한다. 이는 인프라 전문가와 모델 개발자가 분리된 조직에서 소통 비용을 줄이고 의사결정 속도를 높이는 효과를 준다.

데이터 과학자의 추천 생성 세션과 MLOps 엔지니어의 배포 세션을 분리하여 운영할 수 있다. 추천 결과가 데이터프레임 형태로 제공되므로 특정 지표를 근거로 인스턴스 사양을 합의하기 쉽다. 특히 인스턴스 크기를 줄이면서도 유사한 성능을 내는 프레임워크 설정을 찾아내면 토큰당 비용을 직접적으로 절감할 수 있다. 이는 제한된 예산 내에서 최대 처리량을 확보해야 하는 기업 환경에서 오버프로비저닝을 방지하는 실질적인 수단이 된다.

실험 과정에서 생성된 테스트 엔드포인트는 사용하지 않을 때 즉시 제거해야 불필요한 과금을 막을 수 있다. SDK 내 삭제 메서드를 통해 노트북 세션 종료 전 자원을 정리하는 절차가 필수적이다.

mb.delete_endpoint()

이 명령은 배포된 추론 엔드포인트를 삭제하여 시간당 발생하는 인스턴스 비용을 즉시 중단시킨다. 벤치마킹을 위해 여러 인스턴스를 교체하며 테스트하는 워크플로우 특성상, 코드 레벨에서 삭제 명령을 명시함으로써 실험 횟수를 늘리면서도 전체 프로젝트 예산을 효율적으로 통제할 수 있다.

서비스 성격에 따라 응답 속도가 중요한 대화형 UI는 p90 TTFT를 최소화하는 구성을, 대량의 데이터를 처리하는 배치 작업은 초당 토큰 처리량이 가장 높은 인스턴스를 선택하는 것이 최적의 실행 기준이다.