SageMaker AI inference component

TL;DR

Inference component는 실행 중인 endpoint에 모델을 별도 배포하고, 모델별 자원과 사본 수를 독립적으로 관리하는 기능입니다. 모델 추가와 scale to zero가 가능하지만, GPU 사본마다 최소 GPU 한 장이 필요하므로 경량 모델의 공동 호스팅에서는 비용이 높아질 수 있습니다.

내용은 CreateInferenceComponent API, AWS 블로그, 그리고 이 저장소의 실측 결과를 바탕으로 작성했습니다. 서비스 제약은 변경될 수 있으므로 실제 배포 전에는 공식 문서를 다시 확인해야 합니다.

---

개요

Inference component는 실행 중인 endpoint에 모델을 별도 리소스로 배포하고, 모델별 자원과 사본 수를 관리하는 SageMaker 기능입니다. AWS CreateInferenceComponent API 문서에서는 다음과 같이 설명합니다.

"Creates an inference component, which is a SageMaker AI hosting object that you can use to deploy a model to an endpoint. In the inference component settings, you specify the model, the endpoint, and how the model utilizes the resources that the endpoint hosts."

그림은 inference component가 제공하는 기능을 세 가지로 구분합니다.

• 완전 관리형 모델 배치: 모델별 CPU, 메모리, GPU 또는 AWS Inferentia 요구량을 바탕으로 SageMaker가 endpoint 인스턴스에 컴포넌트 사본을 배치합니다.
• 모델별 독립 스케일링: 다른 모델의 사본 수를 변경하지 않고 특정 컴포넌트의 CopyCount만 조절할 수 있습니다.
• 요청 라우팅: 호출할 모델은 InferenceComponentName으로 지정하고, 같은 컴포넌트의 여러 사본 중에서는 endpoint의 라우팅 설정에 따라 처리할 사본을 선택합니다.

개념도 출처: AWS 블로그 - Reduce model deployment costs by 50% on average

일반 endpoint 배포와의 차이는 다음과 같습니다.

	기존 (single/multi-container)	inference component
endpoint config	variant에 ModelName 포함	모델 없이 인스턴스 구성만 선언
모델 배포 시점	endpoint config를 만들 때 결정	endpoint 생성 후 컴포넌트로 배포
모델 추가	endpoint 재생성	컴포넌트만 생성
자원 배정	인스턴스 단위	모델 단위

도입 배경

AWS 블로그에서 설명하는 주요 도입 배경은 GPU 사용률 개선입니다.

"Foundation models often underutilize available accelerators on instances."

모델마다 endpoint를 하나씩 운영하면 GPU 자원이 충분히 사용되지 않을 수 있습니다. Inference component를 사용하면 여러 모델의 배치 위치와 자원 할당을 SageMaker가 관리하므로, 여러 모델을 같은 인스턴스 집합에서 운영할 수 있습니다.

"optimally place and pack models onto ML instances to maximize utilization"

AWS 블로그는 평균 50%의 배포 비용 절감 가능성을 제시하지만, 실제 절감 폭은 워크로드와 트래픽 패턴에 따라 달라진다고 명시합니다.

"reduce model deployment costs by 50% on average" ... "cost savings will vary depending on your workload and traffic patterns"

⚠️ 이 저장소의 워크로드에서는 비용이 오히려 증가했습니다. 경량 인코더(278M)는 컴포넌트마다 최소 GPU 한 장을 할당해야 하므로, 여러 모델을 inference component로 구성했을 때 비용이 더 높았습니다. 아래 비용 절감 수치는 모델 하나가 GPU를 충분히 사용하는 대형 모델 워크로드를 전제로 해석해야 합니다.

구조

일반 endpoint와 inference component의 구성 차이는 다음과 같습니다.

endpoint를 먼저 InService 상태로 만든 다음 inference component를 생성해야 합니다.

create_model            SageMaker model 생성
      ↓
create_endpoint_config  모델 없이 인스턴스 구성만 선언
      ↓
create_endpoint         ⏳ InService 까지 대기, 실측 180초
      ↓
create_inference_component   endpoint에 모델 배포
      ↓
invoke_endpoint         InferenceComponentName 으로 대상 지정

endpoint가 준비되기 전에 컴포넌트를 생성하면 다음 오류가 발생합니다.

ValidationException: Could not find endpoint "..."

일반 방식은 endpoint config를 만들 때 모델을 지정합니다. Inference component 방식은 모델이 없는 endpoint를 먼저 준비한 후, 각 모델을 별도 컴포넌트로 배포합니다.

관리 API와 호출 API

import boto3

sm = boto3.client("sagemaker")           # 리소스 관리 (생성, 삭제, 조회)
rt = boto3.client("sagemaker-runtime")   # 추론 호출 전용

리소스 생성·조회·삭제에는 sagemaker 클라이언트를 사용하고, 추론 요청에는 sagemaker-runtime 클라이언트를 사용합니다.

코드

# 1) SageMaker model 생성
sm.create_model(
    ModelName="mdeberta-model",
    ExecutionRoleArn=role,
    PrimaryContainer={"Image": image, "Environment": {...}},
)

# 2) endpoint config: ModelName 없이 인스턴스 구성만 선언
sm.create_endpoint_config(
    EndpointConfigName=epc,
    ExecutionRoleArn=role,          # ← config 레벨에 필요 (기존 방식에는 없던 것)
    ProductionVariants=[{
        "VariantName": "AllTraffic",
        "InstanceType": "ml.g6.12xlarge",
        "InitialInstanceCount": 1,
        "RoutingConfig": {"RoutingStrategy": "LEAST_OUTSTANDING_REQUESTS"},
    }],
)

# 3) endpoint 생성 후 InService 까지 대기
sm.create_endpoint(EndpointName=ep, EndpointConfigName=epc)
while sm.describe_endpoint(EndpointName=ep)["EndpointStatus"] == "Creating":
    time.sleep(20)

# 4) inference component 생성: 자원 요구량과 시작 제한 시간 지정
create_response = sm.create_inference_component(
    InferenceComponentName="mdeberta",
    EndpointName=ep,
    VariantName="AllTraffic",
    Specification={
        "ModelName": "mdeberta-model",             # 또는 Container에 직접 정의
        "StartupParameters": {
            # 두 값 모두 API 최댓값입니다. 대형 모델의 시작 시간이 길 때 사용합니다.
            "ModelDataDownloadTimeoutInSeconds": 3600,
            "ContainerStartupHealthCheckTimeoutInSeconds": 3600,
        },
        "ComputeResourceRequirements": {
            "MinMemoryRequiredInMb": 1024,         # 이 구조 안에서 유일한 필수 필드
            "NumberOfAcceleratorDevicesRequired": 1,
            "NumberOfCpuCoresRequired": 2,
        },
    },
    RuntimeConfig={"CopyCount": 1},
    Tags=[{"Key": "Usage", "Value": "encoder-serving-guide"}],
)
# 모델 다운로드와 컨테이너 시작이 끝나야 컴포넌트가 InService 상태가 됩니다(실측 213초).

# 5) 호출: sagemaker-runtime 클라이언트를 씁니다
resp = rt.invoke_endpoint(
    EndpointName=ep,
    InferenceComponentName="mdeberta",   # ← 대상 컴포넌트 지정
    ContentType="application/json",
    Body=json.dumps(payload),
)

전체 배포 코드는 03_gpu_cohost_inference_component/deploy.py에 있습니다.

CreateInferenceComponent 파라미터

create_inference_component는 아래 최상위 파라미터를 받습니다. 현재 botocore 서비스 정의에서 필수인 값은 InferenceComponentName과 EndpointName이고, 나머지는 선택 사항입니다. 모델을 배포할 때는 일반적으로 Specification 또는 Specifications 중 하나로 배포 사양을 지정하며, 두 필드를 함께 사용할 수는 없습니다.

필드	필수	설명
InferenceComponentName	필수	생성할 컴포넌트 이름입니다. 같은 리전에서 고유해야 합니다.
EndpointName	필수	컴포넌트를 배포할 endpoint입니다. 먼저 InService 상태여야 합니다.
VariantName	선택	컴포넌트를 배치할 production variant 이름입니다. 이 저장소에서는 AllTraffic을 사용합니다.
Specification	선택	단일 배포 사양을 지정합니다.
Specifications	선택	인스턴스 타입별 사양 목록입니다. 1~5개를 줄 수 있고 Specification과 함께 쓸 수 없습니다.
RuntimeConfig	선택	초기 사본 수를 지정합니다. 이 구조를 사용하면 CopyCount가 필수이며 최솟값은 0입니다.
Tags	선택	inference component에 적용할 태그입니다. Key와 Value 쌍을 최대 50개까지 지정할 수 있습니다.

Specification 내부에는 다음 필드가 있습니다.

필드	설명
ModelName	CreateModel로 미리 생성한 SageMaker model을 참조합니다. 이 저장소에서 사용하는 방식입니다.
Container	ModelName 대신 Image, ArtifactUrl, Environment 등의 컨테이너 사양을 직접 지정합니다.
StartupParameters	모델 다운로드와 컨테이너 상태 확인의 제한 시간을 지정합니다.
ComputeResourceRequirements	컴포넌트 사본 하나에 필요한 CPU, 메모리, GPU 또는 AWS Inferentia 개수를 지정합니다.
InstanceType	Specifications를 쓸 때 이 사양이 적용될 인스턴스 타입을 구분합니다.
BaseInferenceComponentName	base component를 참조하는 inference component adapter용 필드입니다.
DataCacheConfig	이미지와 모델 아티팩트 캐시 사용 여부를 지정합니다. EnableCaching이 필수입니다.
SchedulingConfig	배치 전략을 SPREAD 또는 BINPACK으로 지정하고, 필요하면 가용 영역 간 균형 조건을 설정합니다.

StartupParameters의 두 필드는 모두 선택 사항이며, 값의 단위는 초이고 허용 범위는 60~3600초입니다.

필드	적용 구간
ModelDataDownloadTimeoutInSeconds	모델 데이터 다운로드 제한 시간
ContainerStartupHealthCheckTimeoutInSeconds	컨테이너 시작 및 상태 확인 제한 시간

24B급 모델처럼 다운로드와 초기화에 시간이 오래 걸리는 경우에는 두 값을 최대 3600초로 설정할 수 있습니다. 이 값은 추론 요청 처리 시간이 아니라 컴포넌트 사본을 시작할 때 적용되는 제한 시간입니다.

"StartupParameters": {
    "ModelDataDownloadTimeoutInSeconds": 3600,
    "ContainerStartupHealthCheckTimeoutInSeconds": 3600,
}

하나의 endpoint가 여러 인스턴스 타입을 사용한다면 단일 Specification 대신 Specifications에 인스턴스 타입별 사양을 정의할 수 있습니다.

Specifications=[
    {
        "InstanceType": "ml.g6.12xlarge",
        "ModelName": model_name,
        "ComputeResourceRequirements": {
            "MinMemoryRequiredInMb": 1024,
            "NumberOfAcceleratorDevicesRequired": 4,
        },
    },
    {
        "InstanceType": "ml.g6e.12xlarge",
        "ModelName": model_name,
        "ComputeResourceRequirements": {
            "MinMemoryRequiredInMb": 1024,
            "NumberOfAcceleratorDevicesRequired": 4,
        },
    },
]

Specification과 Specifications

단일 인스턴스 타입으로 구성한 endpoint는 일반적으로 Specification을 사용합니다. Specifications는 같은 컴포넌트에 인스턴스 타입별 요구사항을 따로 정의할 때 사용합니다.

리소스 삭제 순서

Inference component가 연결된 endpoint는 바로 삭제할 수 없습니다. 다음 순서대로 리소스를 삭제해야 합니다.

delete_inference_component  →  delete_endpoint  →  delete_endpoint_config  →  delete_model

common/cleanup.py도 이 순서로 리소스를 삭제합니다.

자원 배정 (ComputeResourceRequirements)

필드 정의는 AWS InferenceComponentComputeResourceRequirements 문서에 있습니다. 아래 최솟값과 타입은 botocore 서비스 정의에서도 확인했습니다.

필드	타입	최솟값	필수
MinMemoryRequiredInMb	integer	128	✅ 필수
MaxMemoryRequiredInMb	integer	128	optional
NumberOfCpuCoresRequired	float	0.25	optional
NumberOfAcceleratorDevicesRequired	float	1	optional

CPU는 0.25코어 단위로 할당할 수 있지만 GPU와 AWS Inferentia 같은 가속 장치는 최소 1개를 할당해야 합니다. 이 저장소는 GPU 인스턴스를 사용하므로 사본마다 GPU를 최소 한 장 할당해야 하며, 작은 모델 여러 개를 GPU 한 장에 inference component로 공동 호스팅할 수 없습니다.

NumberOfAcceleratorDevicesRequired는 float 타입이므로 1.5나 2.5도 API 입력 검증을 통과하지만, 1보다 작은 값은 ParamValidationError로 거부됩니다.

자원 요구량과 사본 배치

이 개념도는 모델별 자원 요구량과 트래픽이 배치 결과에 함께 반영되는 과정을 보여 줍니다.

• 그림의 각 칸은 GPU 또는 AWS Inferentia 같은 가속 장치 하나를 나타냅니다.
• 각 분홍색 테두리는 장치 네 개가 있는 관리형 인스턴스입니다.
• FM1처럼 사본 하나가 여러 장치를 요구하는 모델은 연속된 자원을 함께 사용합니다.
• FM2와 FM3처럼 사본당 요구량이 작은 모델은 남은 자원에 함께 배치될 수 있습니다.
• 모델별 트래픽에 따라 사본 수를 독립적으로 늘리거나 줄입니다. 그림에서는 트래픽이 높은 FM3의 사본이 가장 많습니다.

따라서 실제 배치는 ComputeResourceRequirements, CopyCount, 사용 가능한 인스턴스 자원의 조합으로 결정됩니다. 이 그림은 여러 크기의 모델을 설명하기 위한 개념도입니다. 이 저장소의 GPU 실측에서는 모든 컴포넌트가 NumberOfAcceleratorDevicesRequired=1을 사용하므로 GPU 한 장에 컴포넌트 사본 하나만 배치할 수 있었습니다.

개념도 출처: AWS 블로그 - Reduce model deployment costs by 50% on average

사본 수와 요청 라우팅

CopyCount는 컴포넌트별 사본 수를 지정합니다. 최솟값은 0이므로 특정 모델의 사본만 중지하고 해당 자원을 다른 모델에 할당할 수 있습니다.

"scale down to zero copies of a model to free up resources for other models"

AWS 블로그에서는 유럽 사용자용 모델과 미국 사용자용 모델을 같은 endpoint에 배포한 뒤, 시간대에 따라 사용하지 않는 모델의 CopyCount를 0으로 변경하는 사례를 소개합니다.

sm.update_inference_component_runtime_config(
    InferenceComponentName="mdeberta",
    DesiredRuntimeConfig={"CopyCount": 2},
)

endpoint config의 RoutingConfig에 LEAST_OUTSTANDING_REQUESTS를 설정하면 SageMaker가 처리 중인 요청이 가장 적은 사본으로 요청을 전달합니다. 멀티컨테이너 endpoint에는 같은 라우팅 옵션이 없습니다.

오토스케일링

컴포넌트 사본 수와 endpoint 인스턴스 수는 서로 다른 설정으로 관리합니다. Application Auto Scaling은 inference component의 CopyCount를 조절하고, endpoint config의 ManagedInstanceScaling은 인스턴스 수의 범위를 지정합니다.

	Application Auto Scaling	ManagedInstanceScaling
조절 대상	컴포넌트 사본 수	인스턴스 수
설정 위치	register_scalable_target	endpoint config
파라미터	MinCapacity / MaxCapacity	MinInstanceCount / MaxInstanceCount
0까지 축소	✅ MinCapacity=0	✅ MinInstanceCount=0
과금 영향	사본 수만 변경	인스턴스 수에 따라 과금

Scale to zero를 구성하려면 두 설정이 모두 필요합니다. 사본 수만 0으로 줄이고 인스턴스를 유지하면 과금이 계속됩니다. 반대로 인스턴스 수의 범위만 설정하고 사본 수를 고정하면 컴포넌트 부하에 따른 scale-out이 발생하지 않습니다.

스케일링 지표

Inference component에 사용할 수 있는 미리 정의된 지표는 두 개입니다. 목록은 botocore의 MetricType enum에서도 확인할 수 있습니다.

지표	해상도	용도
SageMakerInferenceComponentInvocationsPerCopy	1분	호출량 기반 스케일링
SageMakerInferenceComponentConcurrentRequestsPerCopyHighResolution	10초	동시 요청 기반, 반응이 빠름

aas.put_scaling_policy(
    PolicyType="TargetTrackingScaling",
    ResourceId=f"inference-component/{ic_name}",
    ScalableDimension="sagemaker:inference-component:DesiredCopyCount",
    TargetTrackingScalingPolicyConfiguration={
        "PredefinedMetricSpecification": {
            "PredefinedMetricType": "SageMakerInferenceComponentConcurrentRequestsPerCopyHighResolution",
        },
        "TargetValue": 5,
        "ScaleInCooldown": 300,    # 기본값
        "ScaleOutCooldown": 300,
    },
)

반응 시간

Target Tracking 정책은 CloudWatch 경보를 자동으로 생성합니다. Scale-out과 scale-in에 적용되는 평가 조건은 서로 다릅니다.

방향	평가 조건	실측
scale-out	짧은 평가 기간	-
scale-in	10초 × 90 = 15분 동안 낮은 값 유지	트래픽 중단 후 13분에 CopyCount=0

CloudWatch 지표 발행 지연까지 포함하면 축소 완료에 1~2분이 더 걸릴 수 있습니다. 전체 실측은 05 Scale to zero에 있습니다.

사본 수가 0일 때는 별도의 scale-out 경보가 필요합니다

사본이 0이면 요청이 들어와도 ConcurrentRequestsPerCopy 지표가 증가하지 않습니다. 요청을 처리할 사본이 없기 때문에 Target Tracking 정책만으로는 사본 수를 다시 늘릴 수 없습니다.

NoCapacityInvocationFailures 지표에 Step Scaling 정책을 연결해야 합니다. 사본이 없는 상태에서 요청이 들어오면 이 지표가 증가하고, 경보가 scale-out을 시작합니다. 자세한 코드는 05 Scale to zero에 있습니다.

Inference component를 먼저 삭제해야 합니다

endpoint를 삭제하기 전에 연결된 inference component를 모두 삭제해야 합니다. common.cleanup은 Application Auto Scaling 등록과 CloudWatch 경보를 해제한 후, inference component → endpoint → endpoint config → model 순서로 리소스를 정리합니다.

실제 배포에서 확인한 제약

GPU 수가 배치 가능한 사본 수를 제한합니다

NumberOfAcceleratorDevicesRequired의 최솟값은 1입니다. 따라서 사본마다 GPU를 최소 한 장 할당해야 하며, 다음 조건을 만족해야 합니다.

GPU 수 ≥ Σ(CopyCount × NumberOfAcceleratorDevicesRequired)

ml.g6.12xlarge(GPU 4장)에서 다음 구성을 확인했습니다.

시도	결과
모델 3개 (각 사본 1)	✅ 성공, GPU 3장 사용
그중 하나를 사본 2개로	✅ 성공, GPU 4장 사용
사본을 하나 더 (총 5)	❌ deployed 1 out of 2 requested copies

이 제한은 모델의 실제 GPU 메모리 사용량과 별개입니다. 이 저장소의 모델 세 개는 fp16 기준 합계가 1.9GB이지만, GPU 한 장짜리 인스턴스에는 inference component 사본을 하나만 배치할 수 있습니다. A10G의 나머지 GPU 메모리는 다른 컴포넌트에 할당할 수 없습니다.

GPU 인스턴스에서 NumberOfAcceleratorDevicesRequired를 생략하면 생성 요청이 거부됩니다.

Number of accelerator devices required must be specified for ml.g5.xlarge

일부 사본의 배치 실패가 상태만으로 드러나지 않습니다

요청한 사본 수가 GPU 수를 초과해도 컴포넌트 상태는 InService로 유지될 수 있습니다. 이때 RuntimeConfig는 desired=2, current=1처럼 표시됩니다. 실제 실패 원인은 describe_inference_component 응답의 FailureReason에서 확인해야 합니다.

MinMemoryRequiredInMb에는 런타임 오버헤드를 반영해야 합니다

MinMemoryRequiredInMb를 인스턴스 전체 메모리에 가깝게 설정하면 컨테이너와 모델 서버가 사용할 메모리가 부족해질 수 있습니다. ml.g5.xlarge(16GB) 실측에서는 6144MB와 2048MB 설정이 실패했고, 1024MB로 변경한 후 배포에 성공했습니다.

There is not enough memory available for this Inference Component.

대형 GPU 인스턴스는 가용 용량 확보에 실패할 수 있습니다

ml.g5.12xlarge는 서비스 쿼터가 충분했지만, 인스턴스 용량을 확보하지 못해 50분 후 Failed 상태가 되었습니다. 같은 환경에서 ml.g6.12xlarge는 약 3분 후 InService 상태가 되었습니다.

사용 기준

Inference component가 적합한 경우

• 모델 하나가 할당된 GPU를 충분히 활용할 때
• 모델별 사본 수를 독립적으로 조절해야 할 때
• 모델마다 트래픽이 집중되는 시간대가 달라, 사용하지 않는 모델의 사본 수를 0으로 줄일 수 있을 때
• 처리 중인 요청 수를 기준으로 사본을 선택하는 라우팅이 필요할 때
• 컴포넌트마다 다른 컨테이너 이미지가 필요할 때
• endpoint를 다시 생성하지 않고 모델을 추가하거나 제거해야 할 때

다른 배포 방식이 더 적합한 경우

상황	대안
경량 모델 여러 개를 GPU 1장에	LMI (컨테이너가 GPU 메모리를 공유)
경량 모델이며 latency 요구가 높지 않음	CPU 멀티컨테이너 + ONNX
모델 수백~수천 개를 동적으로 적재	multi-model endpoint
모델 하나	일반 endpoint

다음은 이 저장소에서 모델 세 개를 배포했을 때의 비용 비교입니다.

구성	인스턴스	시간당 요금
CPU 멀티컨테이너 (ONNX)	ml.c6i.2xlarge × 1	$0.408
LMI co-host	ml.g5.xlarge × 1	$1.408
모델별 endpoint 3개	ml.g5.xlarge × 3	$4.224
inference component	ml.g6.12xlarge × 1	$5.752

us-east-1 온디맨드 SageMaker hosting 요금이며, 2026-08-07에 AWS Pricing API로 조회했습니다.

공동 호스팅 방식 비교

	inference component	LMI (DJL)	multi-model endpoint	멀티컨테이너
GPU	✅ 장 단위	✅ 메모리 공유	Triton 전용	❌
모델별 자원 배정	✅ 세밀함	메모리 힌트만	❌	❌
모델별 스케일	✅ CopyCount	워커 수로만	❌	❌
스케일아웃 단위	컴포넌트별	인스턴스	인스턴스	인스턴스 (전체 복제)
0까지 축소	✅ 모델별	endpoint 단위	❌	❌
부하 인식 라우팅	✅	서버 내부 큐	❌	❌
다른 이미지	✅	❌ 공유	❌ 공유	✅
모델 추가	컴포넌트 생성	S3 업로드	S3 업로드	endpoint 재생성
콜드 스타트	없음	없음	있음	없음

Inference component는 모델별 자원, 사본 수, 라우팅을 가장 세밀하게 제어할 수 있습니다. 다만 경량 모델에서는 GPU를 한 장 단위로 할당해야 하므로 다른 공동 호스팅 방식보다 비용이 높아질 수 있습니다.

참고 자료

• CreateInferenceComponent API
• InferenceComponentSpecification
• InferenceComponentStartupParameters
• InferenceComponentComputeResourceRequirements
• InferenceComponentDataCacheConfig
• InferenceComponentSchedulingConfig
• AWS 블로그: Reduce model deployment costs by 50% on average
• SageMaker AI 문서: 엔드포인트를 0 인스턴스로 축소
• AWS 샘플: inference component scale to zero 노트북
• 이 저장소의 실습: 03 GPU co-host (inference component), 05 Scale to zero
• 문제 해결: 트러블슈팅