LLM optimization integration for Amazon SageMaker Python SDK
Quick Summary
Amazon SageMaker Python SDK v3는 생성형 AI 모델의 추론 구성을 실제 워크로드로 시험하고, 성능·비용 기준의 추천을 생성해 최적 구성을 노트북에서 바로 배포할 수 있도록 통합했습니다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
Amazon SageMaker Python SDK v3는 생성형 AI 모델의 추론 구성을 실제 워크로드로 시험하고, 성능·비용 기준의 추천을 생성해 최적 구성을 노트북에서 바로 배포할 수 있도록 통합했습니다.
📌 핵심 요약
- Amazon SageMaker Python SDK 3.17.0부터 노트북에서 생성형 AI 추론 벤치마크, 배포 추천 생성, 추천 구성 배포를 하나의 흐름으로 실행할 수 있습니다.
- 추천 기능은 합성 또는 실제 트래픽 패턴을 사용해 처리량, 첫 토큰 생성 시간, 전체 요청 지연 시간, 토큰 간 지연 시간 등의 지표를 측정합니다.
- generate_deployment_recommendations 작업은 지정된 인스턴스와 추론 프레임워크 구성을 시험하고, 선택한 성능 목표에 따라 후보를 순위화합니다.
- 제시된 사례에서는 동일한 ml.g6.2xlarge 인스턴스의 두 LMI 컨테이너 버전 가운데 순위 0 구성이 처리량과 지연 시간 지표 모두에서 우세했습니다.
- 완료된 추천 작업은 다른 세션에서 다시 불러와 배포할 수 있으며, 배포 이후 합성 부하 벤치마크를 통해 실제 요구 조건 충족 여부를 검증할 수 있습니다.
🧩 주요 포인트
- 기존 Studio 또는 Boto3 중심 기능이 Python SDK 작업으로 통합됨 → 실험용 노트북과 배포 파이프라인에서 같은 최적화 절차를 이어갈 수 있습니다.
- 추천 순위는 지정한 성능 목표와 실제 워크로드 특성을 반영함 → 대화형 서비스와 처리량 중심 작업이 서로 다른 최적 구성을 선택할 수 있습니다.
- 동일 인스턴스에서도 프레임워크·컨테이너 구성에 따라 성능 차이가 발생함 → 인스턴스 종류만이 아니라 전체 서빙 구성을 함께 비교해야 합니다.
🧠 상세 정리
1. 추론 배포 최적화의 배경
생성형 AI 모델을 실제 서비스에 배포하려면 엔드포인트를 벤치마킹하고, 여러 인스턴스 및 서빙 구성을 평가하며, 설정을 반복적으로 조정해야 합니다. 기존에는 이러한 기능을 Amazon SageMaker Studio에서 사용하거나 Boto3 API 호출을 직접 구성해야 했기 때문에 노트북 기반 실험 흐름과 최적화 절차가 분리될 수 있었습니다. Amazon SageMaker Python SDK v3는 생성형 AI 추론 추천 기능을 노트북 워크플로에 직접 노출해 이 과정을 하나의 Python 인터페이스로 연결합니다. 사용자는 노트북에서 엔드포인트를 시험하고 데이터에 근거한 배포 추천을 생성한 뒤, 선택된 구성을 실시간 엔드포인트로 배포할 수 있습니다.
2. 추론 추천 기능의 역할과 측정 지표
생성형 AI 추론 추천 기능은 현재 실행 중인 Amazon SageMaker 엔드포인트에 합성 워크로드나 실제 트래픽을 반영한 워크로드를 적용해 성능을 측정합니다. 측정 대상에는 초당 요청 처리량, 초당 출력 토큰 처리량, 첫 토큰 생성 시간인 TTFT, 요청부터 전체 응답 완료까지의 지연 시간, 스트리밍 중 토큰 사이의 지연 시간이 포함됩니다. 서비스는 사용 패턴을 토대로 인스턴스 및 프레임워크 구성을 비교하고 비용과 성능의 절충 관계에 따라 추천 결과를 순위화합니다. 가장 높은 순위의 구성은 SDK를 통해 Amazon SageMaker 실시간 엔드포인트에 직접 배포할 수 있어 측정, 비교, 선택, 배포가 연속된 작업으로 구성됩니다.
3. 새로운 Python SDK 인터페이스
새 기능은 Amazon SageMaker Python SDK 3.17.0부터 sagemaker.serve.ai_inference_recommender 패키지 아래에서 제공됩니다. ModelBuilder.from_jumpstart_config는 JumpStart 모델 식별자와 컴퓨팅 설정으로 ModelBuilder를 만들고, start_benchmark는 배포된 엔드포인트에 구성 가능한 합성 부하 테스트를 실행합니다. generate_deployment_recommendations는 워크로드에 맞춰 인스턴스와 프레임워크 설정을 탐색한 후 순위가 지정된 추천 목록을 반환하며, deploy는 최상위 추천 구성을 실시간 엔드포인트로 배포합니다. ModelBuilder.from_recommendation_job은 이미 완료된 추천 작업으로부터 새로운 ModelBuilder를 복원하므로 추천 생성과 배포를 서로 다른 프로세스나 세션에서 수행할 수 있습니다. 사용 전에는 SDK를 3.17.0 이상으로 업그레이드하고, Amazon SageMaker 실행 권한을 가진 IAM 역할과 실시간 엔드포인트 또는 배포할 JumpStart 모델을 준비해야 합니다.
4. 권장되는 전체 작업 흐름
예시의 출발점은 운영 준비가 된 생성형 AI 모델에 적합한 인스턴스 유형, 프레임워크 구성, 서빙 매개변수를 찾는 상황입니다. 전통적인 수동 방식은 여러 인스턴스, 컨테이너 버전, 동시성 설정을 각각 배포하고 시험하는 반복 작업을 요구하지만, SDK 통합은 이를 하나의 노트북에서 자동화합니다. 제시된 흐름은 먼저 워크로드에 맞는 배포 추천을 생성하고, 순위와 지표의 절충 관계를 해석해 구성을 선택한 다음, 선택된 구성을 실시간 엔드포인트로 배포하는 순서입니다. 이후 현실적인 부하 조건으로 엔드포인트를 벤치마킹해 요구 성능을 충족하는지 확인하며, 필요하다면 LMI와 vLLM을 같은 조건에서 비교해 서빙 프레임워크를 선택할 수 있습니다.
5. 워크로드 기반 추천 생성과 배포
generate_deployment_recommendations 호출에는 동시 요청 수, 총 요청 수, 평균 입력·출력 토큰 수, 스트리밍 여부, 후보 인스턴스, 추론 프레임워크, 최적화 대상 지표 등을 지정할 수 있습니다. 서비스는 각 후보 구성에 모델을 배포하고 지정된 트래픽 패턴과 일치하는 부하 테스트를 수행한 뒤, 선택한 성능 목표에 최적화된 추천 목록을 돌려줍니다. 예제는 TTFT를 성능 목표로 지정하고 LMI 프레임워크와 ml.g6.2xlarge 인스턴스를 대상으로 추천 작업이 끝날 때까지 기다립니다. 결과는 mb.recommendations로 전체 비교할 수 있고, mb.recommendations.best를 통해 최상위 항목의 예상 요청 처리량과 TTFT 같은 지표에 접근할 수 있습니다. 최종적으로 mb.deploy를 호출하면 가장 높은 순위의 구성이 지정한 실시간 엔드포인트에 배포되며, auto_approve 옵션은 모델 패키지 승인 상태 검사를 우회하는 용도로 사용됩니다.
6. 추천 결과의 데이터 구조와 사례
추천 결과는 Python 객체로 탐색할 수 있을 뿐 아니라 각 후보의 원시 정보와 예상 성능 항목을 순회해 pandas 데이터 프레임으로 변환할 수도 있습니다. 예시 데이터에는 추천 순위, 추론 사양 이름, 인스턴스 유형, 지표 이름, 통계 구간, 측정값, 단위가 행 단위로 정리됩니다. 두 후보는 모두 ml.g6.2xlarge를 사용하지만 LMI 컨테이너 버전이 각각 26.0.0과 27.0.0으로 다르며, 요청 처리량, 출력 토큰 처리량, 요청 지연, TTFT, 토큰 간 지연, 클라이언트 측 동시성이 함께 제시됩니다. 순위 0 구성은 평균 112.7664건의 초당 요청 처리량과 평균 3608.53개의 초당 출력 토큰 처리량을 기록했고, 순위 1 구성은 각각 96.8522건과 3099.27개를 기록했습니다. 이 구조는 단일 종합 점수만 보여주는 대신 후보별 세부 성능 분포를 직접 비교할 수 있게 합니다.
7. 성능 지표 해석과 구성 선택 기준
요청 처리량과 출력 토큰 처리량은 높을수록 많은 요청과 토큰을 처리할 수 있고, 요청 지연 시간과 TTFT 및 토큰 간 지연 시간은 낮을수록 빠른 응답 경험을 제공합니다. 사례에서 순위 0의 p90 TTFT는 약 983밀리초이고 p90 요청 지연은 약 1000밀리초인 반면, 순위 1은 각각 약 1088밀리초와 1122밀리초입니다. 순위 0은 같은 동시성 64 조건에서 순위 1보다 처리량이 약 16% 높고 지연 시간은 약 10% 낮아 모든 주요 성능 지표에서 우세하며, TTFT 최소화를 목표로 설정한 추천 작업에서도 최상위에 배치됩니다. 챗봇이나 대화형 UI처럼 반응성이 중요한 서비스는 p90 또는 p99 TTFT를 우선하고, 일괄 요약이나 오프라인 처리처럼 처리량이 중요한 작업은 요청 및 출력 토큰 처리량을 우선해야 합니다. 주요 지표가 비슷한 후보끼리는 보조 지표를 비교한 뒤, 비슷한 성능을 내는 더 작은 인스턴스가 있는지 비용까지 검토하는 방식이 제시됩니다.
8. 세션 간 재사용과 배포 후 검증
운영 환경에서는 추천 생성과 실제 배포를 같은 세션에서 수행하지 않을 수 있으며, 예를 들어 데이터 과학자가 실험 단계에서 추천 작업을 실행하고 MLOps 파이프라인이 릴리스 단계에서 결과를 배포할 수 있습니다. ModelBuilder.from_recommendation_job에 완료된 작업 이름을 전달하면 추천 목록이 포함된 ModelBuilder를 새 세션에서 복원하고, 그 상태에서 최상위 추천을 바로 배포할 수 있습니다. 추천 구성을 배포한 뒤에는 제어된 부하로 벤치마크를 실행해 운영 트래픽을 받기 전에 지연 시간과 처리량 요구 조건 충족 여부를 확인합니다. 원문은 JumpStart 모델을 배포하고 start_benchmark를 이용해 합성 부하 테스트를 수행하는 절차를 다음 단계로 제시하지만, 제공된 본문은 해당 코드가 시작되는 지점에서 끝나므로 구체적인 실행 결과까지는 제시하지 않습니다.
🧾 핵심 주장 / 시사점
- 동일한 ml.g6.2xlarge와 동시성 조건에서도 LMI 컨테이너 버전에 따라 처리량과 지연 시간이 달라졌으므로, 하드웨어 유형만으로 최적 배포 구성을 판단할 수 없습니다.
- 추천 순위는 고정된 보편적 우열이 아니라 performance_target으로 지정한 목표에 영향을 받으므로, 대화형 응답성과 대량 처리 중 어떤 요구가 우선인지 먼저 정의해야 합니다.
- 완료된 추천 작업을 다른 세션에서 복원하는 기능은 실험 담당자의 성능 탐색과 배포 파이프라인의 릴리스 단계를 분리하면서도 동일한 추천 결과를 이어서 사용할 수 있게 합니다.
✅ 액션 아이템
- SageMaker Python SDK 3.17.0에서 추론 벤치마크·배포 추천·추천 구성 배포를 한 흐름으로 연결해 실험한다.
- 대화형 지연 시간과 처리량 목표를 구분해 generate_deployment_recommendations 순위 기준을 정의한다.
- 동일 인스턴스에서도 LMI 컨테이너·프레임워크 구성을 함께 비교하고, 배포 후 합성 부하로 지표를 점검한다.
❓ 열린 질문
- 우리 워크로드에 맞는 핵심 성능 목표는 처리량, TTFT, 전체 지연, 토큰 간 지연 중 무엇인가?
- 합성 트래픽과 실제 트래픽 패턴 중 어떤 입력이 추천 순위를 더 안정적으로 만드는가?
- 동일 ml.g6.2xlarge에서도 어떤 서빙 구성 차이가 순위 0 우세를 결정하는가?