Day 3 - 추론 최적화: SageMaker Neo·Elastic Inference·Inferentia·추론 파이프라인

추론 최적화의 세 갈래

엔드포인트를 운영하는 것과 효율적으로 운영하는 것은 다르다. 학습 비용은 한 번이지만 추론 비용은 모델이 살아 있는 내내 나가므로, 최적화가 곧 총비용 절감이다. SageMaker는 모델을 더 빠르게(지연↓), 더 싸게(비용↓), 더 가볍게(리소스↓) 만드는 여러 수단을 제공한다.

SageMaker Neo: 한 번 학습, 어디서든 최적 배포

Neo는 학습된 모델을 특정 하드웨어(인스턴스 또는 엣지 디바이스)에 맞게 컴파일·최적화한다. 프레임워크 모델을 분석해 대상 하드웨어에 맞게 연산 그래프를 재구성하고, 의존성을 걷어낸 경량 런타임으로 변환한다.

compiled = model.compile(
    target_instance_family="ml_c5",   # 또는 ml_inf1, 엣지: jetson_nano 등
    input_shape={"data": [1, 3, 224, 224]},
    output_path="s3://my-bucket/neo-output/",
    framework="pytorch",
)

[학습된 모델 아티팩트]  (PyTorch / TF / MXNet / XGBoost / ONNX …)
        │
        │  compile(target_instance_family=..., input_shape=..., framework=...)
        ▼
[Neo 컴파일]  연산 그래프 재구성 → 의존성 제거 → 경량 런타임
        │
        ├─→ 클라우드 인스턴스(ml_c5, ml_inf1 …)에 배포
        └─→ ARM 기반 엣지 디바이스에 배포 (IoT Greengrass 연동)

• 효과: 정확도를 유지하면서 추론 속도를 높이고 메모리 사용을 줄인다.
• 대상: 클라우드 인스턴스부터 ARM 기반 엣지 디바이스까지(IoT Greengrass와 연동).
• 프레임워크: TensorFlow, PyTorch, MXNet, XGBoost, ONNX 등 주요 프레임워크.
• 필수 입력: input_shape — 대상 하드웨어에 맞춰 그래프를 고정하려면 입력 형상을 알려줘야 한다.

Neo의 핵심 가치는 "익숙한 프레임워크로 학습하고, 하드웨어에 최적화된 코드로 배포한다"는 것이다. 모델 자체를 건드리지 않는 컴파일 단계 최적화(양자화·프루닝이 아니다)라서 정확도 손실 없이 속도를 얻는다. 지문에 "엣지 디바이스 배포 + 지연 감소"가 보이면 Neo를 떠올린다.

Elastic Inference (EI): 필요한 만큼의 GPU만 붙인다

풀 GPU 인스턴스는 비싸지만, 대부분의 추론 워크로드는 GPU를 100% 쓰지 않는다. Elastic Inference는 CPU 인스턴스에 필요한 만큼의 GPU 가속(액셀러레이터)만 부착해 비용을 낮춘다.

predictor = model.deploy(
    initial_instance_count=1,
    instance_type="ml.m5.large",          # 저렴한 CPU 인스턴스
    accelerator_type="ml.eia2.medium",    # 부분 GPU 가속기 부착
)

• 언제: 풀 GPU 인스턴스(ml.p3 등)는 과하고 CPU만으로는 느린 딥러닝 추론.
• 효과: 풀 GPU 대비 추론 비용을 크게 낮춘다.
• 참고: AWS는 신규 워크로드를 EI보다 Inferentia/Neo 쪽으로 이동시켜 왔다. 시험에서는 "CPU 인스턴스에 부분 GPU 가속을 붙여 비용 절감"이라는 형태로 나온다.

EI의 장점은 별도 칩용 컴파일 없이 기존 배포 코드에 accelerator_type 한 줄을 더해 비용을 줄인다는 점이다. Inferentia는 Neuron SDK 컴파일 단계가 추가로 필요하다 — "전통적/간편한 비용 절감"이라는 뉘앙스면 EI 쪽이다.

AWS Inferentia (Inf1/Inf2): 추론 전용 커스텀 실리콘

Inferentia는 AWS가 추론용으로 설계한 커스텀 가속기다. Inf1/Inf2 인스턴스에 탑재되며, 동등한 처리량에서 GPU보다 낮은 비용과 지연을 목표로 한다.

GPU 인스턴스 (p3)      : 범용 학습/추론, 비싸다
Inferentia (Inf1/Inf2) : 추론 전용, 고처리량/비용 효율. AWS Neuron SDK로 컴파일
Trainium (Trn1)        : 학습 전용 커스텀 칩 (추론용 아님 — 오답 보기로 자주 등장)

• 작업 흐름: Neuron SDK(또는 Neo)로 Inferentia용 컴파일 → Inf 인스턴스에 배포.
• 언제: 대규모·고처리량 추론에서 GPU보다 비용/전력 효율이 중요할 때.
• 혼동 주의: Trainium = 학습, Inferentia = 추론. 시험은 둘을 나란히 놓고 묻는다.

⚠️ 함정: "AWS가 설계한 추론 전용 칩"을 묻는데 ml.trn1을 고르면 오답이다. Trainium은 학습 전용이다. ml.p4는 범용 GPU, ml.m5는 일반 CPU다.

최적화 수단 선택표

모델 수준 최적화: 양자화·프루닝·증류

하드웨어를 바꾸기 전에 모델 자체를 작게 만든다.

양자화(Quantization) : 정밀도 축소(FP32 → INT8). 크기↓, 속도↑, 약간의 정확도 손실 가능
프루닝(Pruning)      : 기여도가 낮은 가중치/뉴런을 제거해 경량화
증류(Distillation)   : 큰 teacher 모델의 지식을 작은 student 모델로 이전

이 기법들은 Neo 컴파일과 결합하면 더 빠르고 더 작은 모델이 된다. 엣지 배포처럼 리소스 제약이 큰 환경에서 특히 중요하다.

⚠️ 함정: Neo와 양자화를 같은 것으로 묶으면 안 된다. Neo는 모델을 바꾸지 않는 컴파일 최적화라 정확도가 유지되고, 양자화는 정밀도를 낮추는 모델 변경이라 정확도 손실이 생길 수 있다. "정확도는 유지하면서"라는 조건이 붙으면 Neo다.

추론 파이프라인과 처리량 최적화

어제 본 추론 파이프라인은 정합성 유지만이 아니라 처리량 측면에서도 의미가 있다.

클라이언트 ──1회 요청──▶ [전처리 컨테이너] ─▶ [예측 컨테이너] ─▶ [후처리 컨테이너] ─▶ 응답
                         └──────── 같은 엔드포인트 내부, 네트워크 왕복 없음 ────────┘

추론 파이프라인   : 전처리/예측/후처리 컨테이너를 연결해 네트워크 왕복 제거
배치 추론        : 요청을 묶어 한 번에 처리(처리량↑, 개별 요청 지연은 일부 희생)
모델 캐싱(MME)   : 자주 쓰는 모델을 메모리에 상주시켜 콜드 스타트 지연 제거

지연은 Neo/Inferentia/EI + 모델 압축으로 줄이고, 처리량은 배치·파이프라인·적절한 수평 확장으로 높인다.

여기서 말하는 배치 추론(요청을 묶어 한 엔드포인트에서 처리)과 Batch Transform(오프라인 일괄 처리 작업)은 다르다. 온라인 실시간 요청 시나리오에 Batch Transform을 고르는 보기는 오답이다.

목표별 처방: 지연 · 비용 · 처리량

시험 시나리오는 "지연을 줄여라" / "비용을 줄여라" / "처리량을 높여라"에 따라 서로 다른 처방을 요구한다. 지연↓: Neo 컴파일, 더 빠른 인스턴스. 비용↓: Elastic Inference, Inferentia, Serverless. 처리량↑: 배치 추론, 오토스케일 아웃, Inferentia. 키워드와 도구를 짝지으면 점수가 된다.

무엇을 개선해야 하나?
├─ 개별 요청이 느리다(지연)
│    ├─ 대상 하드웨어가 정해져 있다 → Neo 컴파일
│    ├─ 엣지 등 리소스 제약이 크다 → 양자화·프루닝·증류 (+ Neo)
│    └─ 그래도 느리다 → 더 빠른 인스턴스로 상향
├─ 비용이 과하다
│    ├─ 풀 GPU 사용률이 낮다 → Elastic Inference (부분 GPU 부착)
│    └─ 대규모 추론, 컴파일 감수 가능 → Inferentia (Inf1/Inf2)
└─ 단위 시간당 처리량이 부족하다
     ├─ 요청을 묶을 수 있다 → 배치 추론
     └─ 묶을 수 없다 → 오토스케일 아웃 / Inferentia

인스턴스 선택 정리

ml.m5 / ml.c5       : CPU. 가벼운 추론, Neo와 궁합이 좋다
ml.g4dn / ml.g5     : GPU. 딥러닝 추론의 표준
ml.p3 / ml.p4       : 고사양 GPU. 주로 학습, 무거운 추론
ml.inf1 / ml.inf2   : Inferentia. 고처리량·비용 효율 추론
+ Elastic Inference : CPU 인스턴스에 부분 GPU 부착

인스턴스 계열을 고르는 문제에서 ml.p3/ml.p4는 "고사양 GPU = 정답"이 아니다. 주 용도가 학습 쪽이고 비싸므로, 추론 비용 효율을 묻는 지문에서는 Inferentia나 EI가 답이 된다.

지문 단서 → 정답 매핑

다음 글에서는 안전한 배포 — A/B 테스트, Blue/Green, 카나리, 섀도, 롤백을 다룬다.

📖 용어

• SageMaker Neo : 학습된 모델을 대상 하드웨어에 맞게 컴파일해 더 빠르고 가볍게 만드는 도구. 모델 자체는 바꾸지 않는다.
• 컴파일 단계 최적화 : 연산 그래프를 대상 칩에 맞게 재구성하는 것. 정밀도를 낮추지 않으므로 정확도가 유지된다.
• input_shape : Neo 컴파일 시 알려주는 입력 텐서 형상. 그래프를 고정해 최적화하기 위해 필요하다.
• Elastic Inference : 저렴한 CPU 인스턴스에 필요한 만큼의 GPU 가속기만 부착해 비용을 낮추는 방식.
• Inferentia (Inf1/Inf2) : AWS가 추론용으로 만든 커스텀 칩과 그것을 탑재한 인스턴스 계열.
• Trainium (Trn1) : AWS의 학습 전용 커스텀 칩. Inferentia와 헷갈리기 쉬운 오답 보기.
• AWS Neuron SDK : Inferentia에서 돌릴 수 있도록 모델을 컴파일해주는 개발 키트.
• 양자화(quantization) : FP32 같은 높은 정밀도를 INT8 등으로 낮춰 모델을 작고 빠르게 만드는 기법.
• 프루닝(pruning) : 기여도가 낮은 가중치나 뉴런을 잘라내 모델을 가볍게 만드는 기법.
• 지식 증류(distillation) : 큰 teacher 모델이 배운 것을 작은 student 모델에 옮겨 담는 기법.