Comprehensive Guide to Encoder Model Serving on SageMaker AI¶

Transformer 인코더 모델(BERT 계열 분류, NLI, reranking)을 Amazon SageMaker AI에 배포하는 방법을 시나리오별로 구현하고 비교한 실습 가이드입니다.

이 가이드가 필요한 이유¶

인코더 모델을 서빙할 때는 "CPU로도 충분한가?", "한 endpoint에 여러 모델을 올리면 비용을 줄일 수 있는가?", "요청이 없을 때 비용을 없앨 수 있는가?" 같은 질문이 자주 나옵니다.

대형 LLM은 모델 크기 때문에 고사양 GPU가 필요한 경우가 많습니다. 반면 인코더 모델은 GPU 사용률이 낮을 수 있어 CPU로 배포하거나 여러 모델이 GPU를 공유하도록 구성할 수 있습니다. 적합한 방식은 latency, throughput, 모델 수, 트래픽 패턴, 운영 비용에 따라 달라집니다.

SageMaker AI에는 real-time endpoint, Serverless Inference, inference component, multi-model endpoint 등 여러 배포 옵션이 있습니다. 각 방식을 직접 구성하고 같은 조건으로 비교하려면 시간과 비용이 필요합니다.

이 가이드는 일곱 가지 배포 방식을 실제 endpoint에서 실행하고, 같은 조건으로 측정한 결과를 정리합니다. 성공한 구성뿐 아니라 실패 조건과 원인도 재현할 수 있도록 남겼습니다.

실측 결과 아홉 가지: co-host 비용, vLLM의 batch 성능, Provisioned Concurrency 적용 후 cold start 등 직접 측정한 결과를 정리했습니다.
트러블슈팅 34건: quota를 충족했지만 endpoint 생성이 실패하거나, Worker died가 반복된 뒤 호출이 timeout되는 사례를 오류 메시지별로 찾을 수 있습니다.
재현 가능한 코드: 각 시나리오는 --dry-run과 로컬 Docker 모드를 제공합니다. 실제 endpoint를 생성하기 전에 요청 구성과 container 동작을 확인할 수 있습니다.

이 가이드는 각 배포 방식의 trade-off를 비교하고 요구사항에 맞는 구성을 선택하는 데 필요한 근거를 제공합니다.

배포 방식 결정 트리. 모델이 하나면 latency 우선 여부로 07 Triton과 01 단일 endpoint가 갈립니다. 여러 개면 GPU 필요 여부로 02 CPU 멀티컨테이너가 갈리고, GPU가 필요하면 모델별 스케일링 필요 여부로 03 inference component와 04 LMI가 갈립니다. 유휴 시간이 많으면 GPU는 05 scale to zero, CPU는 06 Serverless를 위 선택에 얹습니다

판단 기준은 배포 방식 고르기에, 측정값은 아래 실측 요약에 있습니다. SageMaker endpoint가 처음이라면 endpoint 기초부터, 바로 실습하려면 시작하기로 가세요.

과금 주의

Real-time endpoint는 삭제할 때까지 시간당 비용이 발생합니다. 요청이 없어도 인스턴스 비용이 청구됩니다. 실습을 마치면 uv run python -m common.cleanup --delete-all을 실행하세요.

이 가이드가 답하는 질문¶

질문	답	근거
가장 단순한 구성	one model, one container. 01을 baseline으로 사용	01 단일 endpoint
여러 모델을 endpoint 하나에 배포하는 방법	네 가지 방식이 있으며 우선순위에 따라 선택	배포 방식 고르기
경량 인코더에 GPU가 필요한가	이 실험에서는 ONNX Runtime과 CPU로 58ms 측정	실측 결과
여러 모델이 GPU 한 장을 공유할 수 있는가	LMI에서는 가능, inference component에서는 GPU 단위로 할당	LMI 내부 구조
co-host가 항상 비용을 줄이는가	구성에 따라 다르며 inference component는 이 실험에서 더 비쌌음	배포 방식 고르기
요청이 없을 때 비용을 없앨 수 있는가	GPU는 scale to zero, CPU는 Serverless Inference 검토	05, 06
Serverless Inference의 cold start	on-demand 43초, Provisioned Concurrency 적용 후 9.7초 측정	06 Serverless
vLLM이 인코더 모델을 빠르게 하는가	이 실험에서는 batch가 커질수록 성능이 낮아짐	인코더는 왜 다른가
batching 효과가 보이지 않는 경우	payload의 `batch_size`와 worker 설정 확인	트러블슈팅

실측 요약¶

모델과 측정 조건을 고정해 배포 방식에 따른 차이를 비교했습니다.

모델: mDeBERTa (278M) (MIT, ungated), 모든 시나리오 동일
max_seq_len: 512 고정 (실제 문장 길이로 재면 낙관적인 값이 나옵니다)
latency: batch=1, concurrency=1 기준
throughput: batch=8에서 초당 처리한 sample 수
리전: us-east-1
Use case: LLM 답변 검증. RAG chunk를 premise, 답변을 hypothesis로 입력하는 NLI 판정

시나리오	컴퓨트	p50	p90	p95	p99	b=8 samples/s	시간당 요금
01 GPU 단일 endpoint	ml.g5.xlarge	26.8 ms	29.8 ms	32.7 ms	45.4 ms	113/s	$1.408
02 CPU + ONNX	ml.c6i.2xlarge	58.3 ms	63.0 ms	63.5 ms	64.2 ms	27/s	$0.408
03 inference component	ml.g6.12xlarge	25.8 ms	27.4 ms	28.3 ms	28.4 ms	78/s	$5.752
04 GPU LMI	ml.g5.xlarge	49.7 ms	50.9 ms	51.5 ms	52.8 ms	104/s	$1.408
06 Serverless	메모리 6144MB (인스턴스 없음)	116.5 ms	137.1 ms	171.7 ms	253.3 ms	13/s	요청당 과금
07 Triton + TensorRT	ml.g5.xlarge	15.4 ms	16.4 ms	16.8 ms	17.4 ms	185/s	$1.408

모델 하나를 배포할 때는 01이 가장 단순합니다. 여러 모델이 GPU 한 장을 공유해야 한다면 04(LMI)를 검토할 수 있습니다. 두 방식은 같은 ml.g5.xlarge를 사용했으며, 01은 batch=8에서 113 samples/s, LMI는 모델 3개를 함께 배포한 상태에서 104 samples/s를 기록했습니다. 03(inference component)은 비용이 더 높지만 모델별 copy 조절과 load-aware routing을 제공합니다.

Serverless Inference는 유휴 인스턴스 비용이 없는 대신 이 실험에서 CPU real-time보다 약 두 배 높은 latency를 보였습니다. 같은 ONNX 모델을 사용했지만 worker 수와 메모리 기반 자원 배정이 다릅니다. cold start는 on-demand에서 43초, Provisioned Concurrency 적용 후 9.7초였습니다.

더 낮은 latency가 필요하면 07(NVIDIA Triton Inference Server와 TensorRT)을 검토할 수 있습니다. 같은 ml.g5.xlarge에서 p50은 01의 26.8ms보다 낮은 15.4ms였고, batch=8 throughput은 185 samples/s였습니다. 대신 config.pbtxt를 관리해야 하며 첫 호출에서 TensorRT compile에 47초가 걸렸습니다.

요금 기준

us-east-1 on-demand hosting 요금이며 2026-08-07에 AWS Pricing API로 조회했습니다. 리전, 시점, Savings Plans 적용 여부에 따라 달라지므로 배포 전에 재확인하세요.

aws pricing get-products --service-code AmazonSageMaker --region us-east-1 \
    --filters Type=TERM_MATCH,Field=instanceName,Value=ml.g5.xlarge \
              Type=TERM_MATCH,Field=regionCode,Value=us-east-1

전체 수치는 벤치마크 결과에 있습니다.

CPU도 유효한 선택입니다¶

비용 외에도 CPU를 고를 수 있는 이유가 있습니다.

GPU capacity를 확보하지 못할 수 있습니다. quota가 있어도 해당 Region에 capacity가 부족하면 배포가 실패합니다. 이 실험에서는 ml.g5.12xlarge가 50분 뒤 Failed 상태가 되었고, ml.g6.12xlarge는 약 3분 만에 생성됐습니다.
CPU는 scale-out capacity를 확보하기 쉬울 수 있습니다. 실제 가용성은 Region과 시점에 따라 다르므로 배포 전에 확인해야 합니다.
경량 모델은 GPU 사용률이 낮을 수 있습니다. 278M 모델을 단독 배포하면 GPU 연산 자원이 남을 수 있으므로 latency 요구와 비용을 함께 비교해야 합니다.

하이브리드로 쓸 수 있을까요?

가능합니다. 평시에는 GPU로 처리하고, 트래픽이 몰리거나 GPU capacity 확보에 실패하면 CPU로 넘기는 구성을 검토할 수 있습니다.

이 실험에서 ONNX fp32와 PyTorch 출력은 소수점 6자리까지 일치했습니다. 따라서 측정한 모델과 입력에서는 배포 경로를 바꿔도 NLI 판정이 같았습니다.

다만 이 repository의 mDeBERTa 모델은 INT8 quantization 후 모든 예측이 neutral로 바뀌었습니다. 자세한 내용은 ONNX Runtime으로 CPU 배포에 있습니다.

제작 과정¶

설계, 시나리오 구성, 기본 code snippet은 직접 작성했습니다. 반복 구현과 문서 초안에는 Claude Code를 사용했고, SageMaker AI 실습에서 확인한 기준으로 결과를 검토했습니다.

표의 수치는 모두 실제 실행 결과입니다. 멀티컨테이너 GPU 제한, inference component의 GPU 할당 단위, MinInstanceCount: 0만으로 scale to zero가 시작되지 않는 조건도 재현 명령과 함께 정리했습니다.

각 시나리오는 로컬 Docker 모드와 --dry-run을 제공합니다. --dry-run은 endpoint 인스턴스를 만들지 않고 create_model과 create_endpoint_config 요청 구성을 확인합니다. 실제 container 기동, 모델 로드, capacity 확보 여부는 검증하지 않습니다.

저자¶

김대근 (Daekeun Kim) / AWS Principal AI Specialist Solutions Architect

LinkedIn | GitHub | Hugging Face | 기술 블로그

Disclaimer¶

저자의 개인 실측 결과를 정리한 자료이며, 재직 중인 회사의 공식 문서나 입장을 대변하지 않습니다. 내용이 공식 문서와 다를 경우 공식 문서가 우선합니다. DLC image tag, Region 지원, 서비스 제약은 자주 바뀌므로 배포 전에 재확인하세요.

가이드북	범위
이 가이드북	인코더 모델 서빙: 배포 방식 비교, ONNX, co-host, benchmark
SageMaker AI Fine-tuning & Serving E2E	생성 LLM fine-tuning E2E: 합성 데이터, 학습, 서빙, 평가, agentic loop