배포 방식 고르기¶
TL;DR
모델이 하나라면 01 단일 endpoint를 기본으로 검토하고, latency를 더 줄여야 한다면 07 Triton + TensorRT를 비교합니다. 여러 모델을 배포할 때 GPU가 필요하지 않으면 02 CPU + ONNX, GPU가 필요하면 04 LMI, 모델별 독립 스케일링이 필요하면 03 Inference Component를 검토합니다. 유휴 비용을 줄여야 한다면 GPU 워크로드는 05 Scale to Zero, CPU 워크로드는 06 Serverless Inference를 비교합니다.
선택 기준¶
모델이 하나라면 co-host가 필요하지 않으므로 모델 수를 먼저 확인합니다. 경량 인코더는 CPU에서도 수십 밀리초 수준의 응답 시간을 낼 수 있으므로 GPU 필요 여부는 실제 모델로 측정해야 합니다. 유휴 시간의 비중은 기본 배포 방식을 정한 뒤 스케일링 또는 서버리스 구성을 선택하는 기준으로 사용합니다.
네 가지 방식 비교¶
멀티컨테이너 Direct |
Multi-Model Endpoint | Inference Component | LMI(DJL) | |
|---|---|---|---|---|
| 분리 단위 | 컨테이너 | S3 모델 아티팩트 | 컴포넌트(모델 + 자원) | 컨테이너 내부 모델 |
| GPU | API에서 거부 | Triton 전용 | 장 단위 할당 | 1장 공유 |
| GPU 1장에 모델 3개 | 지원하지 않음 | Triton 필요 | 지원하지 않음 | 지원 |
| 대상 지정 | TargetContainerHostname |
TargetModel |
InferenceComponentName |
TargetModel |
| 모델별 자원 배정 | 미지원 | 미지원 | ComputeResourceRequirements |
required_memory_mb |
| 모델별 스케일 | 미지원 | 미지원 | CopyCount |
워커 수로만 조절 |
| 스케일아웃 단위 | 인스턴스 (컨테이너 전체 복제) | 인스턴스 | 컴포넌트별 | 인스턴스 |
| 0까지 축소 | 미지원 | 미지원 | 모델별 지원 | endpoint 단위 |
| 부하 인식 라우팅 | 미지원 | 미지원 | LEAST_OUTSTANDING_REQUESTS |
서버 내부 대기열 |
| 서로 다른 이미지 | 지원 | 이미지 공유 | 지원 | 이미지 공유 |
| 모델 추가 | endpoint 재생성 | S3 업로드 | 컴포넌트 생성 | S3 업로드 |
| 콜드 스타트 | 없음 | 있음 (동적 로드) | 없음 | 없음 |
비용 비교(모델 3개 기준)¶
| 구성 | 인스턴스 | 시간당 요금 | b=8 throughput | 100만 건 처리 비용 |
|---|---|---|---|---|
| CPU 멀티컨테이너 (ONNX) | ml.c6i.2xlarge × 1 | $0.408 | 27/s | $4.20 |
| LMI co-host | ml.g5.xlarge × 1 | $1.408 | 104/s | $3.76 |
| 모델별 endpoint 3개 | ml.g5.xlarge × 3 | $4.224 | - | - |
| Inference Component co-host | ml.g6.12xlarge × 1 | $5.752 | 78/s | $20.48 |
2026년 8월 7일에 AWS Pricing API로 조회한 us-east-1 온디맨드 호스팅 요금입니다.
co-host가 항상 저렴한 것은 아닙니다
Inference Component의 NumberOfAcceleratorDevicesRequired 최솟값은 1입니다. 이 저장소의 모델 3개를 배포하려면 GPU 4장 인스턴스가 필요했으며, GPU 1장 인스턴스 3대보다 비용이 높았습니다. 자세한 내용은 SageMaker AI Inference Component를 참고하세요.
상황별 권장¶
모델이 하나이고 latency가 가장 중요할 때¶
→ 07 NVIDIA Triton Inference Server + TensorRT FP16
같은 ml.g5.xlarge에서 p50은 01의 26.8 ms에서 15.4 ms로 낮아졌고, batch 8의 throughput은 185 samples/s였습니다. p99는 17.4 ms로 측정됐습니다.
config.pbtxt를 직접 작성해야 하며 기본 구성에서는 클라이언트가 tokenization를 담당합니다. Triton Ensemble로 tokenization를 서버에 포함할 수 있으며, 이 측정에서 추가 지연은 1.2 ms였습니다. 새로운 배치 형태의 첫 요청에서는 TensorRT 컴파일로 47.7초가 걸렸습니다.
경량 인코더에서 수십 밀리초 수준의 latency가 허용될 때¶
→ 02 CPU 멀티컨테이너 + ONNX
ONNX Runtime의 p50은 58 ms로 GPU 구성의 28 ms보다 약 2배 높았지만 인스턴스 비용은 낮았습니다. 이 측정에서는 PyTorch와 ONNX 출력이 소수점 여섯째 자리까지 일치했습니다.
멀티컨테이너 Direct 모드는 GPU 인스턴스를 사용할 수 없었습니다. 같은 CPU 인스턴스에서 PyTorch 런타임의 p50은 약 1.8초였습니다.
GPU가 필요하고 비용이 중요할 때¶
→ 04 LMI
GPU 1장에 모델 3개를 배포했으며 GPU 메모리 사용량은 5.7 GB였습니다. co-host 세 방식 가운데 100만 건 처리 비용이 가장 낮았습니다. payload 형식은 HF DLC와 같습니다.
주의: 첫 호출이 느립니다(요청 시점에 모델 로드). 컨테이너를 공유하므로 모델마다 다른 이미지를 쓸 수 없습니다.
모델별 독립 스케일링이나 부하 인식 라우팅이 필요할 때¶
→ 03 Inference Component
CopyCount로 모델별 사본 수를 조절하고 LEAST_OUTSTANDING_REQUESTS로 처리 중인 요청이 적은 사본에 요청을 전달할 수 있습니다. 컴포넌트마다 다른 컨테이너 이미지도 지정할 수 있습니다.
이 측정에서는 단건 p50이 25.8 ms로 co-host 방식 중 가장 낮았고, concurrency 8에서 61 req/s를 처리했습니다. GPU 4장 인스턴스를 사용한 결과라는 점을 함께 고려해야 합니다.
이 구성의 시간당 요금은 $5.752로 LMI의 약 4배였습니다. 모델이 할당된 GPU를 충분히 사용하지 않는다면 비용 효율이 낮을 수 있습니다.
트래픽이 시간대별로 집중되고 GPU가 필요할 때¶
→ 05 Scale to Zero
MinInstanceCount: 0으로 GPU 인스턴스 수를 0까지 줄일 수 있습니다. Serverless Inference가 GPU를 지원하지 않는다는 점이 두 방식의 주요 차이입니다.
콜드 스타트는 471초였고, 마지막 요청 이후 인스턴스 수가 0이 되기까지 약 27분이 걸렸습니다. 인스턴스가 회수되기 전까지는 요금이 발생하므로, 이 측정 조건에서는 유휴 구간이 30분보다 짧으면 비용 절감 효과가 제한적입니다.
05와 06은 지원하는 워크로드가 다릅니다
두 방식 모두 유휴 비용을 줄일 수 있지만 GPU 지원 여부가 다릅니다. Serverless Inference는 GPU 설정을 제공하지 않습니다.
| 05 Scale to zero | 06 Serverless | |
|---|---|---|
| GPU | 지원 | 미지원 |
| 정상 상태 p50 | 30.5 ms | 116.5 ms |
| 콜드 스타트 | 471초 | 43초 |
| 0이 되기까지 | 27분(그동안 과금) | 즉시 |
| co-host | Inference Component | 미지원 |
GPU가 필요하면 05를, GPU가 필요하지 않은 산발적 트래픽에는 06을 우선 검토합니다.
트래픽이 산발적이고 GPU가 필요하지 않을 때¶
→ 06 Serverless Inference
서버 인스턴스를 직접 관리하지 않으며 요청이 없을 때는 처리 비용이 발생하지 않습니다. 측정한 콜드 스타트는 43.2초였습니다.
서버리스 구성의 p50은 CPU 실시간 endpoint보다 약 2배 높았습니다(116.5 ms 대 58.3 ms). GPU와 co-host를 지원하지 않으며 메모리 상한은 6,144 MB입니다.
모델이 수백~수천 개일 때¶
→ Multi-Model Endpoint(이 저장소에서 다루지 않음)
모델을 S3에서 동적으로 로드하므로 첫 요청에 모델 로드 시간이 포함될 수 있습니다. 이 저장소에서는 해당 방식을 측정하지 않았습니다.
엔진 선택¶
| 상황 | 선택 |
|---|---|
| DeBERTa 계열 | HF DLC 또는 LMI (vLLM 불가) |
| XLM-R 계열 + batch 1 위주 | vLLM이 약간 유리 |
| XLM-R 계열 + 배칭 | HF DLC |
| CPU 배포 | ONNX Runtime(이 저장소에서는 FP32 검증) |
| GPU latency를 더 줄여야 함 | Triton + TensorRT FP16(p50 15.4 ms) |
vLLM의 인코더 적용 범위는 인코더와 디코더의 차이에 정리되어 있습니다.
Triton을 검토할 때¶
07 Triton + TensorRT에서 같은 ml.g5.xlarge와 ONNX 모델을 사용하고 실행 엔진만 변경해 측정했습니다.
| 구성 | p50 | p99 | b=8 samples/s |
|---|---|---|---|
| 01 HF DLC + PyTorch | 26.8 ms | 45.4 ms | 113/s |
| Triton + ORT GPU | 27.3 ms | 28.6 ms | 57/s |
| Triton + TensorRT FP16 | 15.4 ms | 17.4 ms | 185/s |
컨테이너만 HF DLC에서 Triton으로 변경하면 p50은 거의 달라지지 않았고, p99는 45.4 ms에서 28.6 ms로 낮아졌습니다. TensorRT FP16을 적용한 뒤 p50은 27.3 ms에서 15.4 ms로 낮아졌습니다.
적용 시 세 가지를 고려해야 합니다. config.pbtxt를 직접 작성해야 하고, 새로운 배치 형태의 첫 요청에서는 TensorRT 컴파일이 발생하며, 기본 구성에서는 tokenization를 클라이언트가 담당합니다. 측정한 첫 단건 요청은 47.7초였고 /tmp의 캐시는 컨테이너 재시작 시 사라집니다.
Python 백엔드의 전처리와 후처리를 Triton Ensemble로 묶으면 클라이언트는 텍스트를 전송할 수 있습니다. 이 구성에서 batch 1의 추가 지연은 1.2 ms(8%)였습니다.
Triton Ensemble은 앞 단계의 출력을 다음 단계의 입력으로 전달합니다. 07에서는 tokenization, 모델 추론, 후처리를 연결했으며 서로 다른 모델을 순차 실행하는 구성에도 사용할 수 있습니다.
Triton Ensemble은 모델을 독립적으로 선택해 호출하는 co-host과 다릅니다. 여러 단계를 하나의 요청 경로로 연결한다는 점에서 멀티컨테이너 Serial 모드와 유사합니다.
| co-host(02~04) | Triton Ensemble | |
|---|---|---|
| 호출 | 모델을 골라서 각각 | 체인 전체를 한 번 |
| 모델 간 관계 | 독립 | 앞 출력이 뒤 입력 |
| 대상 지정 | TargetModel 등 |
불필요(Ensemble이 라우팅) |
개념과 백엔드별 차이는 Triton Inference Server에 있습니다.
배포 전 확인¶
과금 없이 할 수 있는 검증입니다.
# 1) 이 모델이 vLLM을 지원하는지 확인
uv run python 08_engine_comparison/check_vllm_support.py
# 2) 로컬에서 GPU/CPU latency 비교
uv run python -m common.local_test --all --bench
# 3) 배포 가능 여부(무료 API까지만)
uv run python 01_single_endpoint/deploy.py --dry-run
# 4) 멀티컨테이너 GPU 제약 재현
uv run python 02_cpu_cohost_multicontainer/deploy.py --prove-gpu-fails