Day 3 - 비용·고급 추론: 멀티모델, 멀티컨테이너, 추론 파이프라인, Inferentia

네 가지 패턴 한눈에 구분하기

실시간 엔드포인트는 강력하지만 항상 켜져 있어 비용이 나간다. 모델이 수백 개면 각각 엔드포인트를 띄우는 순간 인스턴스 비용이 폭발한다. MLA-C01은 "수백 개 모델", "전처리+추론을 한 엔드포인트에", "딥러닝 추론 비용 절감" 같은 키워드로 이 주제를 묻는다.

MME  : 요청 ─TargetModel=A─▶ [컨테이너 1개] ─▶ 메모리에 A 로드(없으면 S3에서)
                                  ▲ 모델 A,B,C … 1000개가 S3에 대기
 
MCE  : 요청 ─TargetContainerHostname=tf─▶ ┌ [TF 컨테이너]  ← 이 중 하나만 실행
                                          └ [PyTorch 컨테이너]
 
파이프라인: 요청 ─▶ [전처리] ─▶ [모델] ─▶ [후처리] ─▶ 응답  ← 전부 순차로 통과

멀티모델 엔드포인트(MME) — 수많은 모델을 한 엔드포인트로

멀티모델 엔드포인트는 같은 프레임워크/컨테이너를 쓰는 다수의 모델을 단일 엔드포인트 뒤에서 공유 인스턴스로 서빙한다.

• 모델 아티팩트들을 S3 한 경로(prefix)에 모아 둔다.
• 호출이 오면 해당 모델을 메모리로 동적 로드하고, 안 쓰는 모델은 언로드한다.
• 모델 수백~수천 개를 소수 인스턴스에 얹어 비용을 극적으로 줄인다.

# 호출 시 TargetModel로 어떤 모델을 쓸지 지정
response = runtime.invoke_endpoint(
    EndpointName="mme-endpoint",
    TargetModel="customer-segment-A.tar.gz",   # S3의 특정 모델 지정
    ContentType="text/csv",
    Body="5.1,3.5,1.4,0.2",
)

대표 사례는 "고객사별/지역별/사용자별로 모델이 다른" 경우다. 1,000개 매장에 각각 수요 예측 모델이 있다면, 1,000개 엔드포인트 대신 MME 하나로 처리한다.

배포 쪽 코드는 컨테이너를 MultiModel 모드로 만들고 모델들이 놓인 S3 prefix를 가리키는 것이 전부다.

from sagemaker.multidatamodel import MultiDataModel
 
mme = MultiDataModel(
    name="store-forecast-mme",
    model_data_prefix="s3://bkt/models/",   # 이 아래 모든 .tar.gz가 서빙 대상
    image_uri=xgboost_image_uri,            # 모든 모델이 공유하는 단일 컨테이너
    role=role,
)
predictor = mme.deploy(initial_instance_count=2, instance_type="ml.m5.xlarge")
 
# 모델을 추가할 때 엔드포인트를 다시 만들 필요가 없다 — S3에 올리면 끝
mme.add_model(model_data_source="s3://bkt/new/store-1501.tar.gz",
              model_data_path="store-1501.tar.gz")

MME는 메모리에 모델을 캐싱한다. 자주 쓰는 모델은 메모리에 머물러 빠르고, 메모리에 없는 모델을 처음 호출하면 S3에서 로드하는 동안 지연(콜드 로드)이 생긴다. 따라서 MME는 모델이 많지만 개별 모델 호출 빈도가 고르거나 낮을 때 비용 효율이 극대화된다. 모든 모델이 동시에 고빈도로 호출되면 메모리 스래싱(thrashing)이 일어나 부적합하다. 또 MME의 모든 모델은 동일한 프레임워크/컨테이너를 써야 한다는 제약이 핵심이다.

MME가 잘 맞는 조건과 그렇지 않은 조건을 갈라 보면 다음과 같다.

멀티컨테이너 엔드포인트(MCE) — 다른 프레임워크를 한 엔드포인트로

멀티컨테이너 엔드포인트는 서로 다른 컨테이너(다른 프레임워크)를 한 엔드포인트에 최대 15개까지 배치한다. 예를 들어 TensorFlow 모델 하나와 PyTorch 모델 하나를 같은 엔드포인트에 두고, 호출 시 어떤 컨테이너를 쓸지 지정한다(직접 호출 모드). MME가 "같은 컨테이너 + 많은 모델"이라면, MCE는 "다른 컨테이너 + 소수 모델"이다.

# 직접 호출 모드: TargetContainerHostname으로 컨테이너 지정
response = runtime.invoke_endpoint(
    EndpointName="mce-endpoint",
    TargetContainerHostname="tensorflow-container",
    ContentType="application/json",
    Body='{"instances": [[1.0, 2.0, 3.0]]}',
)

⚠️ 함정: MME와 MCE를 헷갈리면 시험에서 틀린다. MME = 같은 컨테이너로 매우 많은(수백~수천) 모델, TargetModel로 지정, S3에서 동적 로드. MCE = 서로 다른 프레임워크 컨테이너 최대 15개, TargetContainerHostname로 지정. "프레임워크가 다른 모델 여러 개를 한 엔드포인트에" → MCE. "같은 종류 모델이 수백 개라 엔드포인트 비용을 줄이고 싶다" → MME.

추론 파이프라인 — 전처리·추론·후처리를 체인으로

추론 파이프라인(Inference Pipeline)은 2~15개 컨테이너를 선형 시퀀스로 묶는다.

• 첫 컨테이너의 출력이 다음 컨테이너의 입력이 된다.
• 한 번의 InvokeEndpoint 호출로 전처리→추론→후처리가 같은 인스턴스 안에서 순차 실행된다.
• 컨테이너 간 통신이 로컬이라 네트워크 왕복이 없다.
• 전형적 구성: SparkML/scikit-learn 전처리 컨테이너 → XGBoost 모델 컨테이너.
• 학습 때 쓴 전처리(스케일링·인코딩)를 추론 때도 그대로 써서 학습/추론 불일치(training-serving skew)를 막는다.

한 인스턴스 안에서 벌어지는 일
 
 원본 요청(raw CSV)
        │
        ▼
 [ 컨테이너 1: sklearn 전처리 ]  결측 대체 · 스케일링 · 원핫 인코딩
        │  변환된 피처
        ▼
 [ 컨테이너 2: XGBoost 모델 ]    예측 수행
        │  예측값
        ▼
 [ 컨테이너 3: 후처리(선택) ]     임계값 적용 · 라벨 매핑
        │
        ▼
 최종 응답 — 호출은 단 한 번(InvokeEndpoint)

from sagemaker.pipeline import PipelineModel
 
pipeline_model = PipelineModel(
    name="preprocess-predict-pipeline",
    role=role,
    models=[sklearn_preprocessor_model, xgboost_model],  # 순서가 곧 실행 순서
)
pipeline_model.deploy(initial_instance_count=1, instance_type="ml.m5.xlarge")

추론 파이프라인의 가치는 학습/서빙 일관성이다. 전처리를 애플리케이션 코드로 따로 구현하면 학습 때와 추론 때 미묘하게 달라져 성능이 조용히 떨어진다(training-serving skew). 전처리를 파이프라인 컨테이너로 모델과 함께 패키징하면, 같은 코드가 양쪽에서 보장된다. 또 모든 컨테이너가 한 인스턴스에서 실행되므로 컨테이너 간 통신은 로컬이라 빠르다. "전처리 로직을 추론 시에도 일관되게 적용하고 싶다"는 시나리오의 답이 추론 파이프라인이다.

Inferentia — 딥러닝 추론 비용을 낮추는 전용 칩

AWS Inferentia(ml.inf1, ml.inf2)는 AWS가 추론 전용으로 설계한 가속 칩이다. 딥러닝 추론에서 동급 GPU 대비 추론당 비용과 지연을 크게 낮춘다. 모델을 Inferentia에서 돌리려면 AWS Neuron SDK로 컴파일해야 하며, SageMaker Neo가 이 과정을 자동화해준다.

Inferentia 배포는 한 단계가 더 있다
 
일반 GPU 배포 :  학습된 모델 ─────────────────────▶ 엔드포인트(ml.g5)
Inferentia 배포:  학습된 모델 ─▶ Neuron 컴파일 ─▶ 엔드포인트(ml.inf1/inf2)
                                (SageMaker Neo가 자동화)

Inferentia는 "딥러닝 추론을 대규모로, 저비용으로" 돌릴 때의 정답이다. 트랜스포머·CNN 추론 워크로드에서 처리량당 비용이 GPU보다 유리하다. 단, 모델을 Neuron으로 컴파일하는 단계가 필요하므로 "그냥 배포"보다 한 단계 더 거친다. 시험에서 "딥러닝 추론인데 GPU 비용이 너무 높다, 처리량은 유지하며 비용을 낮추고 싶다"는 조건이면 Inferentia(inf1/inf2)가 정답이다.

Elastic Inference — (레거시) GPU 일부만 붙이기

Elastic Inference(EI)는 CPU 인스턴스에 GPU 가속의 일부(분수)만 가속기로 붙여, 전체 GPU 인스턴스보다 싸게 딥러닝 추론을 가속하던 기능이다. "full GPU는 과하지만 CPU만으론 느린" 중간 지대를 메웠다.

⚠️ 함정: Elastic Inference는 현재 신규 사용이 권장되지 않으며 AWS가 Inferentia로 대체할 것을 안내한다. 오래된 학습 자료나 기출에는 EI가 정답으로 나오지만, 최신 시나리오에서 "딥러닝 추론 비용 절감"의 일차 답은 Inferentia다. EI는 개념(분수 GPU 가속)만 알아 두고, 실무·최신 시험에서는 Inferentia를 우선 고려한다.

비용 절감 패턴 정리

비용 측면에서 고급 추론을 한 줄로 매핑하면 다음과 같다.

• 같은 종류 모델이 매우 많다 → MME(엔드포인트·인스턴스 비용 통합)
• 트래픽이 간헐적이다 → 서버리스/비동기(0까지 스케일, Day1·4 참고)
• 딥러닝 추론 비용이 높다 → Inferentia(inf1/inf2)
• 전처리/후처리를 한 엔드포인트로 묶고 싶다 → 추론 파이프라인(비용보다 일관성·단순화 목적)
• 서로 다른 프레임워크를 한 엔드포인트로 → MCE

증상 → 원인 → 조치

다음 글에서는 배치 변환과 서버리스 추론을 더 깊이 파고들어 대량 처리 튜닝과 동시성·비용 트레이드오프를 본다.

📖 용어

• 멀티모델 엔드포인트(MME) : 같은 컨테이너를 공유하며 S3에 둔 모델 수백~수천 개를 한 주소로 서빙하는 방식.
• 멀티컨테이너 엔드포인트(MCE) : 프레임워크가 서로 다른 컨테이너 여러 개를 한 엔드포인트에 함께 두는 방식.
• 추론 파이프라인 : 전처리→추론→후처리 컨테이너를 순서대로 이어 붙여 한 번의 호출로 처리하는 구조.
• 동적 로드/언로드 : 필요한 모델만 그때그때 메모리에 올리고, 안 쓰는 모델은 내려서 자리를 비우는 동작.
• 캐시 스래싱(Thrashing) : 메모리가 모자라 올렸다 내렸다를 반복하느라 오히려 느려지는 현상.
• training-serving skew : 학습 때와 추론 때 전처리가 달라 성능이 조용히 떨어지는 문제.
• AWS Inferentia : AWS가 추론 전용으로 만든 칩. 딥러닝 추론에서 GPU보다 추론당 비용이 유리하다.
• AWS Neuron SDK : 모델을 Inferentia에서 돌 수 있게 컴파일·실행해 주는 개발 도구 모음.
• SageMaker Neo : 모델을 목표 하드웨어에 맞춰 자동으로 컴파일·최적화해 주는 기능.
• Elastic Inference : CPU 인스턴스에 GPU 성능 일부만 붙여 쓰던 옛 기능. 지금은 Inferentia로 대체 권장.