GPU Farm과 ELB: AI 추론 인프라 아키텍처
TL;DR
- GPU Farm은 GPU 서버 여러 대를 대규모로 수용하는 물리적 시설 또는 데이터센터 수준의 인프라이다.
- GPU 노드들을 고속 네트워크로 연결하여 대규모 병렬 연산을 수행한다.
- 원문 전체는 아래 상세 내용에 그대로 포함했다.
1. 개념
GPU Farm은 GPU 서버 여러 대를 대규모로 수용하는 물리적 시설 또는 데이터센터 수준의 인프라이다.
2. 배경
데이터센터 수준의 인프라이다. AI/ML 워크로드를 처리하기 위해
3. 이유
GPU 노드들을 고속 네트워크로 연결하여 대규모 병렬 연산을 수행한다.
4. 특징
CPU는 직렬 처리에 최적화된 소수의 강력한 코어를 가지고 있어,
5. 상세 내용
GPU Farm과 ELB: AI 추론 인프라 아키텍처
1. GPU Farm이란?
1.1 정의
GPU Farm은 GPU 서버 여러 대를 대규모로 수용하는 물리적 시설 또는 데이터센터 수준의 인프라이다. AI/ML 워크로드를 처리하기 위해 GPU 노드들을 고속 네트워크로 연결하여 대규모 병렬 연산을 수행한다.
┌─────────────────────────────────────────────────────────────────────┐
│ GPU Farm Architecture │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ GPU Node 1 │ │ GPU Node 2 │ │ GPU Node N │ │
│ │ 8× H100 │ │ 8× H100 │ │ 8× H100 │ │
│ │ ┌────────┐ │ │ ┌────────┐ │ │ ┌────────┐ │ │
│ │ │ Model │ │ │ │ Model │ │ │ │ Model │ │ │
│ │ │Serving │ │ │ │Serving │ │ │ │Serving │ │ │
│ │ └────────┘ │ │ └────────┘ │ │ └────────┘ │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │ │
│ ───────┴────────────────────┴─────────────────────┴──────── │
│ High-Speed Network (NVLink / InfiniBand / RoCE) │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Management Layer │ │
│ │ ├── Orchestration: Kubernetes / Slurm / Ray │ │
│ │ ├── Monitoring: DCGM + Prometheus + Grafana │ │
│ │ └── Storage: Shared NFS / Lustre / S3 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
1.2 GPU Farm 등장 배경
CPU의 한계와 GPGPU의 등장
CPU는 직렬 처리에 최적화된 소수의 강력한 코어를 가지고 있어, 신경망의 행렬 연산처럼 수백만 개의 병렬 연산이 필요한 딥러닝 워크로드에 본질적으로 부적합했다.
┌─────────────────────────────────────────────────────────────────────┐
│ CPU vs GPU 아키텍처 비교 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ CPU (직렬 처리 최적화) GPU (병렬 처리 최적화) │
│ ┌──┐┌──┐┌──┐┌──┐ ┌┐┌┐┌┐┌┐┌┐┌┐┌┐┌┐┌┐┌┐┌┐┌┐ │
│ │ ││ ││ ││ │ 4~64 코어 ││││││││││││││││││││││││ │
│ │강││력││한││코│ 각 코어가 ├┤├┤├┤├┤├┤├┤├┤├┤├┤├┤├┤├┤ │
│ │ ││ ││ ││어│ 복잡한 연산 ││││││││││││││││││││││││ │
│ └──┘└──┘└──┘└──┘ 순차 처리에 유리 ├┤├┤├┤├┤├┤├┤├┤├┤├┤├┤├┤├┤ │
│ ││││││││││││││││││││││││ │
│ 처리량: ~수십 GFLOPS └┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘ │
│ 수천~수만 코어 │
│ 단순 연산의 대규모 병렬 처리 │
│ 처리량: 수백 TFLOPS │
│ │
│ 딥러닝 행렬 연산: GPU가 CPU 대비 10~100× 빠름 │
│ │
└─────────────────────────────────────────────────────────────────────┘
GPGPU(General-Purpose computing on GPU) 는 GPU의 병렬 연산 능력을 그래픽 외 범용 계산에 활용하려는 시도로 등장했다.
NVIDIA CUDA (2006) 의 출시가 전환점이 되었다:
- 개발자에게 커널 프로그래밍을 위한 안정적인 툴체인 제공
- 메모리 배치와 병렬성에 대한 세밀한 제어 가능
- cuDNN, cuBLAS 등 딥러닝 최적화 라이브러리 생태계 구축
2012년 AlexNet이 ImageNet 대회에서 GPU 가속으로 우승한 이후, 딥러닝의 폭발적 성장과 함께 대규모 GPU 인프라 수요가 급증했다.
1.3 GPU Farm vs GPU Cluster 차이
┌──────────────────┬──────────────────────────┬──────────────────────────────────┐
│ 비교 항목 │ GPU Farm │ GPU Cluster │
├──────────────────┼──────────────────────────┼──────────────────────────────────┤
│ 정의 │ GPU 서버를 대규모 수용하는│ 단일 유닛으로 함께 작동하도록 │
│ │ 물리적 시설/데이터센터 │ 상호 연결된 GPU 노드의 논리적 │
│ │ │ 그룹 │
│ 결합도 │ 느슨하게 결합 또는 독립적 │ 긴밀하게 결합, 조율됨 │
│ 주요 목적 │ GPU 자원의 호스팅 및 │ 특정 AI 워크로드를 위한 │
│ │ 프로비저닝 │ 분산 컴퓨팅 │
│ 오케스트레이션 │ 통합 관리가 있을 수도 │ Kubernetes, Slurm, Ray 등 │
│ │ 없을 수도 있음 │ │
│ 확장성 │ 물리적 하드웨어 확장 │ 노드 동적 추가/제거 │
│ 전형적 맥락 │ 클라우드 공급자, 대형 │ AI/ML 모델 학습, HPC │
│ │ 데이터센터 │ │
│ 비유 │ "아파트 단지" │ "한 세대의 방들" │
└──────────────────┴──────────────────────────┴──────────────────────────────────┘
GPU Farm은 물리적 인프라이고, GPU Cluster는 그 위에 구축된 논리적이고 긴밀하게 통합된 컴퓨팅 단위이다.
1.4 주요 사용 사례
┌──────────────────┬──────────────────────────────────────────────────────────────┐
│ 사용 사례 │ 설명 │
├──────────────────┼──────────────────────────────────────────────────────────────┤
│ ML Training │ 대형 언어 모델(LLM) 학습. 단일 GPU 수개월 걸리는 작업을 │
│ (모델 학습) │ 수천 GPU 클러스터에서 수일 만에 완료. │
│ │ GPT-4 학습에 ~25,000개 A100 GPU 사용으로 추정 │
├──────────────────┼──────────────────────────────────────────────────────────────┤
│ ML Inference │ 학습된 모델로 실시간 예측 수행. GPT-4는 추론 시 │
│ (추론 서빙) │ 128개 GPU가 협력하여 모델 병렬 처리. │
│ │ 지연시간과 처리량이 핵심 KPI │
├──────────────────┼──────────────────────────────────────────────────────────────┤
│ Rendering Farm │ 3D 애니메이션, 영화 VFX의 병렬 렌더링. │
│ (렌더링) │ 픽사, 디즈니 등이 대규모 GPU Farm 운영 │
├──────────────────┼──────────────────────────────────────────────────────────────┤
│ Video │ 대규모 비디오 스트리밍 서비스를 위한 실시간 인코딩/디코딩. │
│ Transcoding │ NVIDIA NVENC/NVDEC 하드웨어 가속 활용 │
└──────────────────┴──────────────────────────────────────────────────────────────┘
1.5 GPU 시장 규모
- 데이터센터 GPU 시장: 2024년 $14.48B → 2033년 $190.1B (35.8% CAGR)
- GPU-as-a-Service: 2025년 $4.96B → 2034년 $31.89B
- AI/ML이 전체 GPU 수요의 70% 이상 차지 (2025년 기준)
2. NVIDIA GPU 세대별 진화
2.1 세대별 스펙 비교
┌──────────────┬───────────────┬───────────────┬───────────────┬───────────────┐
│ 특징 │ V100 (Volta) │ A100 (Ampere) │ H100 (Hopper) │ B200(Blackwell│
├──────────────┼───────────────┼───────────────┼───────────────┼───────────────┤
│ 출시 연도 │ 2017 │ 2020 │ 2022 │ 2024-2025 │
│ 메모리 │ 16-32GB HBM2 │ 80GB HBM2e │ 80GB HBM3 │ 192GB HBM3e │
│ 메모리 대역폭│ ~900 GB/s │ ~2 TB/s │ 3.35 TB/s │ 8 TB/s │
│ 트랜지스터 │ 21.1B │ 54.2B │ 80B │ 208B │
│ NVLink │ 300 GB/s │ 600 GB/s │ 900 GB/s │ ~1.8 TB/s │
│ TDP │ 300W │ ~400W │ ~700W │ ~1,000-1,200W│
│ 핵심 혁신 │ Tensor Core │ BF16/INT8 │ FP8 │ FP4/FP6 │
│ │ 도입 │ 희소 처리 │ Transformer │ 듀얼 칩 설계 │
│ │ │ MIG │ Engine │ NVLink 5 │
│ FP16 성능 │ 125 TFLOPS │ 312 TFLOPS │ 989 TFLOPS │ 2.25 PFLOPS │
└──────────────┴───────────────┴───────────────┴───────────────┴───────────────┘
2.2 세대 간 성능 도약
┌─────────────────────────────────────────────────────────────────────┐
│ 성능 도약 타임라인 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ V100 (2017) │
│ ├── Tensor Core 최초 도입으로 딥러닝 연산 획기적 가속 │
│ └── 딥러닝 학습의 "GPU 시대" 본격 개막 │
│ │ │
│ ▼ A100은 V100 대비 ~20× 추론 성능 │
│ A100 (2020) │
│ ├── Multi-Instance GPU (MIG): 1개 GPU를 최대 7개로 분할 │
│ ├── BF16, TF32 데이터 타입 도입 │
│ └── 희소 행렬(Sparsity) 2:4 패턴 지원 → 연산량 2× 감소 │
│ │ │
│ ▼ H100은 A100 대비 최대 30× LLM 추론 │
│ H100 (2022) │
│ ├── FP8 데이터 타입 → Transformer Engine 자동 정밀도 관리 │
│ ├── 추론 성능: A100 대비 4.5× │
│ ├── LLM 특화: A100 대비 최대 30× 빠른 추론 │
│ └── PCIe Gen5 + NVLink 4세대 │
│ │ │
│ ▼ B200은 H100 대비 최대 15× LLM 처리량 │
│ B200 (2024-2025) │
│ ├── FP4/FP6 → 초저정밀도 추론 최적화 │
│ ├── 듀얼 다이 설계: 2개 GPU 다이를 하나로 통합 │
│ ├── MLPerf 추론: H100 대비 최대 4× │
│ ├── LLM 처리량: H100 대비 최대 11-15× │
│ ├── 메모리 대역폭: 8 TB/s (H100의 2.4×) │
│ └── 5세대 NVLink: ~1.8 TB/s 양방향 │
│ │
└─────────────────────────────────────────────────────────────────────┘
2.3 워크로드별 GPU 선택 가이드 (2025-2026)
┌──────────────┬───────────────────────────────────────────────────────────────┐
│ GPU │ 최적 사용 시나리오 │
├──────────────┼───────────────────────────────────────────────────────────────┤
│ B200 │ 초당 토큰 수(tok/s)가 KPI이고 전력 효율이 중요한 경우. │
│ (Blackwell) │ 최신 대형 모델 추론/학습에 최적. │
│ │ FP4로 기존 FP8 대비 2× 추가 처리량 │
├──────────────┼───────────────────────────────────────────────────────────────┤
│ H200 │ KV 캐시 용량이 주요 병목인 경우. │
│ │ 141GB HBM3e로 H100(80GB) 대비 76% 더 많은 KV 캐시 저장. │
│ │ 긴 컨텍스트 윈도우(128k+) 모델 서빙에 적합 │
├──────────────┼───────────────────────────────────────────────────────────────┤
│ H100 │ 성숙도와 공급 안정성이 중요한 경우. │
│ (Hopper) │ 소프트웨어 생태계 가장 풍부, 대부분의 프레임워크 최적화 완료. │
│ │ 가격 대비 성능 균형이 우수 │
├──────────────┼───────────────────────────────────────────────────────────────┤
│ A100 │ 예산 제약이 있고 호환성이 우선인 경우. │
│ (Ampere) │ VRAM에 모델이 들어가는 중소형 모델(~30B 파라미터). │
│ │ 가격이 가장 합리적, 중고 시장 형성 │
└──────────────┴───────────────────────────────────────────────────────────────┘
2.4 차세대: Rubin 아키텍처 (예고)
NVIDIA의 차세대 데이터센터 GPU 아키텍처:
- 랙당 576개 Rubin GPU 다이
- GPU당 15 EFLOPS FP4 추론 성능
- GPU당 1TB HBM4e 메모리
- 7세대 NVLink, 1.5 PB/s 집계 스위칭 대역폭
- 2026-2027년 출시 예상
3. 왜 GPU Farm에 로드밸런서가 필요한가?
3.1 AI 추론 서빙의 특수성
GPU 기반 추론 워크로드는 일반 웹 서버와 근본적으로 다른 특성을 가진다.
요청 처리 시간의 극단적 불균일성
LLM 추론은 두 단계로 구성된다:
┌─────────────────────────────────────────────────────────────────────┐
│ LLM 추론의 두 단계 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ① Prefill 단계 (컴퓨팅 집약적) │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 입력 프롬프트 전체를 한 번에 병렬 처리 │ │
│ │ 4,000 토큰 프롬프트 → 짧은 프롬프트보다 훨씬 많은 │ │
│ │ GPU 시간 소비. GPU 연산 코어에 바운드 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ② Decode 단계 (메모리 집약적) │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 토큰을 하나씩 자동회귀적으로 순차 생성 │ │
│ │ 각 토큰 생성 시 이전 모든 토큰의 KV 캐시 참조 │ │
│ │ 메모리 대역폭에 바운드 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 문제: 두 단계의 특성이 극단적으로 달라서 │
│ Round Robin은 요청 비용의 차이를 무시 → 불균형한 부하 │
│ │
│ 예시: "Hello" 추론 = 0.1초 vs 4000 토큰 에세이 = 30초 │
│ → 같은 "1개 요청"이지만 GPU 비용이 300배 차이 │
│ │
└─────────────────────────────────────────────────────────────────────┘
VRAM 제약
- Llama 3 70B: FP16 정밀도에서 약 140GB GPU 메모리 필요
- KV 캐시: 128k 토큰 컨텍스트 윈도우에서 약 40GB 추가 소비
- 단일 H100 (80GB)에 모델조차 올리기 어려움 → 텐서 병렬 필요
배치 처리의 복잡성
GPU의 효율적 활용을 위해 요청을 배치로 묶어야 하지만, 배치 내 요청들의 처리 시간이 다르면 전체 배치가 가장 느린 요청을 기다린다.
3.2 웹 서버 vs GPU 추론 비교
┌──────────────────┬──────────────────────────┬──────────────────────────────────┐
│ 특성 │ 웹 서버 │ GPU 추론 │
├──────────────────┼──────────────────────────┼──────────────────────────────────┤
│ 요청 처리 시간 │ 수 ms, 균일 │ 수백 ms ~ 수십 초, 매우 불균일 │
│ 상태 │ 대부분 무상태 │ KV 캐시로 유상태 │
│ 리소스 병목 │ CPU / 네트워크 │ VRAM / GPU 연산 │
│ 요청 비용 차이 │ 요청 간 유사 │ 요청마다 수십~수백 배 차이 │
│ 실패 모드 │ 타임아웃 │ OOM, CUDA 오류, 모델 미로드 │
│ 동시성 │ 수천~수만 요청 │ 수십~수백 요청 (VRAM 제한) │
│ Cold Start │ 밀리초 │ 수십 초~수 분 (모델 로딩) │
│ 비용 │ $0.01-0.1/시간 │ $1-30+/시간 (GPU 인스턴스) │
└──────────────────┴──────────────────────────┴──────────────────────────────────┘
이러한 차이 때문에 GPU 특화 로드밸런싱 전략이 필수적이다.
4. AWS ELB 종류와 GPU Farm에서의 선택
4.1 ELB 개요
┌──────────────────────────────────────────────────────────────────────┐
│ AWS Elastic Load Balancing │
├──────────┬──────────┬──────────┬─────────────────────────────────────┤
│ ALB │ NLB │ GLB │ Classic LB (Legacy) │
│ L7 │ L4 │ L3 │ L4/L7 │
│ HTTP/ │ TCP/UDP │ IP │ (사용 비권장, 2025년 이후 │
│ HTTPS │ TLS │ Packet │ ALB/NLB로 마이그레이션 권고) │
│ │ │ │ │
│ 경로기반 │ 고성능 │ 투명 │ │
│ 라우팅 │ 초저지연 │ 검사 │ │
├──────────┴──────────┴──────────┴─────────────────────────────────────┤
│ 2025 NEW: │
│ ├── ALB Target Optimizer (AI 워크로드 최적화) │
│ ├── LCU 예약 (계획된 트래픽 스파이크 대비) │
│ └── NLB QUIC 패스스루, 가중 타겟 그룹 │
└──────────────────────────────────────────────────────────────────────┘
4.2 ALB (Application Load Balancer) - L7
2025년 기준 GPU 추론 워크로드에 가장 권장되는 선택이다.
Target Optimizer (2025 신기능)
ALB의 가장 중요한 혁신. AI 추론처럼 단일 작업 동시성이 필요한 워크로드를 위해 설계되었다.
┌─────────────────────────────────────────────────────────────────────┐
│ Target Optimizer 없이 vs 있을 때 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 없을 때 (기존): │
│ ┌─────┐ 요청5→ ┌──────────┐ GPU 100% ← 이미 포화! │
│ │ ALB │ 요청6→ │ Target A │ → 5XX 에러 발생 │
│ │ │ └──────────┘ │
│ │ │ ┌──────────┐ GPU 20% ← 놀고 있음 │
│ │ │ │ Target B │ │
│ └─────┘ └──────────┘ │
│ │
│ 있을 때 (Target Optimizer): │
│ ┌─────┐ 요청5→ ┌──────────┐ GPU 60% │
│ │ ALB │ │ Target A │ ← 용량 고려하여 분배 │
│ │ │ 요청6→ ┌──────────┐ GPU 55% │
│ │ │ │ Target B │ ← 균등한 활용률 │
│ └─────┘ └──────────┘ │
│ │
│ 효과: GPU 활용률 균등화, 5XX 오류 감소, 비용 효율 향상 │
│ │
└─────────────────────────────────────────────────────────────────────┘
ALB의 장점 (GPU 추론용)
- HTTP/2, gRPC 지원: LLM API에 적합
- 경로 기반 라우팅:
/v1/chat→ GPT 모델,/v1/embed→ 임베딩 모델 - SSL/TLS 종료: GPU Pod의 부하 감소
- Amazon Cognito/OIDC 인증 통합: API 인증 오프로드
- WebSocket/SSE 지원: 토큰 스트리밍에 필수
4.3 NLB (Network Load Balancer) - L4
다음 경우에 GPU Farm에 적합:
- 추론 API가 비 HTTP 프로토콜을 사용하는 경우
- 절대적으로 최소한의 네트워크 지연시간이 필요한 경우
- 정적 IP 주소가 필요한 경우 (Elastic IP 연결 가능)
- 네이티브 gRPC 스트리밍 또는 WebSocket 서비스
- 예측 불가능한 대규모 트래픽 스파이크 (즉시 수백만 RPS 처리)
2025 신기능:
- QUIC 패스스루: 모바일 클라이언트 지연시간 감소
- 가중 타겟 그룹: 이기종 GPU 인스턴스 간 트래픽 비율 제어
4.4 GLB (Gateway Load Balancer) - L3
GPU Farm에서 직접적인 추론 라우팅보다는 보안 어플라이언스 (방화벽, IDS/IPS, DLP)와 GPU 클러스터 사이에 배치하는 패턴에 활용.
Internet → GLB → 보안 어플라이언스(IDS/IPS) → ALB → GPU Farm
4.5 GPU 워크로드별 ELB 선택 매트릭스
┌───────────────────────────┬────────────────────┬──────────────────────────────┐
│ 사용 사례 │ 권장 ELB │ 이유 │
├───────────────────────────┼────────────────────┼──────────────────────────────┤
│ HTTP/REST LLM API │ ALB + Target │ 단일 작업 동시성 제어, │
│ │ Optimizer │ 경로 기반 모델 라우팅 │
│ gRPC 스트리밍 추론 │ NLB 또는 ALB │ gRPC 네이티브 지원 │
│ │ (HTTP/2) │ │
│ 토큰 스트리밍 (SSE) │ ALB │ HTTP chunked transfer 지원 │
│ 비 HTTP 커스텀 프로토콜 │ NLB │ L4 포워딩 │
│ 고성능 임베딩 서비스 │ ALB or NLB │ 처리량/지연시간 요건에 따라 │
│ 보안 어플라이언스 앞 배치 │ GLB │ 투명한 L3 검사 │
│ 정적 IP 필요 │ NLB │ Elastic IP 연결 가능 │
└───────────────────────────┴────────────────────┴──────────────────────────────┘
4.6 2025 신규 기능: LCU 예약
AWS는 ALB와 NLB 모두에 Load Balancer Capacity Unit(LCU) 예약을 도입했다.
신제품 출시, 세일, 트래픽 마이그레이션 같은 계획된 이벤트에 대비하여 미리 용량을 확보할 수 있어 GPU Farm의 예측 가능한 트래픽 스파이크 처리에 유용하다.
5. GPU 추론 서빙 아키텍처 패턴
5.1 패턴 1: Direct Serving (GPU Instance + ELB)
가장 단순한 형태.
┌──────────┐ ┌─────────────────────────────────────────────┐
│ Internet │────→│ ALB / NLB │
└──────────┘ └─────┬──────────┬──────────┬─────────────────┘
│ │ │
┌─────▼──┐ ┌────▼───┐ ┌────▼───┐
│EC2 GPU │ │EC2 GPU │ │EC2 GPU │
│p5.48xl │ │p5.48xl │ │p5.48xl │
│ vLLM │ │ vLLM │ │ vLLM │
└────────┘ └────────┘ └────────┘
- 장점: 단순성, 낮은 오버헤드, 빠른 구축
- 단점: 수동 관리, 세밀한 스케일링 어려움, 롤링 업데이트 복잡
5.2 패턴 2: Container-based (EKS + GPU Pods)
┌──────────┐ ┌────────────────┐ ┌──────────────────────┐
│ Internet │────→│ ALB (AWS LBC) │────→│ EKS Cluster │
└──────────┘ └────────────────┘ │ ┌─────────────────┐ │
│ │ GPU Node Pool │ │
│ │ (p4d.24xlarge) │ │
│ │ 8× A100 per node │ │
│ │ ┌─────┐ ┌─────┐ │ │
│ │ │vLLM │ │vLLM │ │ │
│ │ │Pod │ │Pod │ │ │
│ │ └─────┘ └─────┘ │ │
│ └─────────────────┘ │
│ ↕ Istio Mesh │
│ ┌─────────────────┐ │
│ │ Shared Storage │ │
│ │ FSx for Lustre │ │
│ └─────────────────┘ │
└──────────────────────┘
핵심 구성 요소:
- P4d.24xlarge 인스턴스 (8× NVIDIA A100 GPU)
- EFA (Elastic Fabric Adapter): 고성능 노드 간 네트워킹
- FSx for Lustre: 모델 가중치 공유 저장소
- Pod Readiness Gates: 모델 로딩 완료 전 트래픽 차단
- AWS Load Balancer Controller: Kubernetes Ingress → ALB 자동 프로비저닝
5.3 패턴 3: Serverless-like (SageMaker, Bedrock)
SageMaker Multi-Model Endpoint (MME):
- NVIDIA Triton Inference Server를 GPU 백엔드로 활용
- S3에서 온디맨드로 모델 동적 로드/언로드 (LRU 정책)
- 최대 75% 비용 절감 (100개 모델: 개별 $218,880/월 vs MME $54,720/월)
- 2025 신기능: EAGLE-3 추론 디코딩, NVMe 캐싱, 동적 멀티 어댑터 추론
Amazon Bedrock:
- 완전 관리형 파운데이션 모델 API (Claude, Llama, Mistral 등)
- 인프라 관리 불필요, API 호출만으로 추론
- Provisioned Throughput으로 전용 용량 확보 가능
5.4 패턴 4: Multi-model Serving Framework
vLLM (UC Berkeley)
┌─────────────────────────────────────────────────────────────────────┐
│ vLLM 핵심 혁신 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ PagedAttention: │
│ ├── KV 캐시 메모리 관리를 OS의 가상 메모리처럼 페이지 단위로 관리 │
│ ├── 메모리 단편화를 거의 제거 → VRAM 활용률 극대화 │
│ └── 결과: 2-4× 처리량 향상 │
│ │
│ Continuous Batching: │
│ ├── 전통적 Static Batching: 배치 내 가장 느린 요청을 기다림 │
│ ├── Continuous: 토큰 생성 완료된 요청 즉시 제거, 새 요청 투입 │
│ └── GPU idle time 최소화 │
│ │
│ 성능: 고동시성(사용자 100명)에서 4,741.62 tokens/s │
│ │
└─────────────────────────────────────────────────────────────────────┘
TGI (Text Generation Inference) - HuggingFace
- 라우터 + 모델 서버 아키텍처 (Rust 기반 라우터)
- TGI v3: 긴 프롬프트에서 vLLM 대비 최대 13× 빠름
- Prefix Caching 활성화 시 vLLM 대비 최대 3× 토큰 처리
- HuggingFace Hub과 완벽 통합 (모델 이름만 지정하면 자동 다운로드)
Triton Inference Server (NVIDIA)
- 프레임워크 무관: PyTorch, TensorFlow, ONNX, TensorRT 모두 지원
- 멀티모달 모델 서빙의 강자 (이미지 + 텍스트 + 오디오)
- 엔터프라이즈급 멀티 모델 환경의 사실상 표준
- SageMaker MME의 공식 GPU 백엔드
추론 서버 비교
┌──────────────┬───────────────┬───────────────┬───────────────────────┐
│ 차원 │ vLLM │ TGI │ Triton │
├──────────────┼───────────────┼───────────────┼───────────────────────┤
│ 주요 강점 │ LLM 처리량 │ 지연시간 + │ 멀티모델/엔터프라이즈 │
│ │ │ HF 통합 │ │
│ 메모리 관리 │ PagedAttention│ Paged-style │ 백엔드 의존적 │
│ │ │ KV + 청킹 │ │
│ 고동시성 │ 최고 │ 중간 │ 백엔드 의존적 │
│ 긴 프롬프트 │ 중간 │ TGI v3 최고 │ TRT-LLM을 통해 │
│ 사용 편의성 │ 높음 │ 높음 │ 보통~복잡 │
│ 프레임워크 │ LLM 집중 │ LLM 집중 │ 모든 프레임워크 │
│ 유연성 │ │ │ │
│ 최적 시나리오│ 단일 LLM │ HF 모델 빠른 │ 여러 모델 동시 서빙, │
│ │ 고처리량 서빙 │ 배포 │ 멀티모달 파이프라인 │
└──────────────┴───────────────┴───────────────┴───────────────────────┘
5.5 패턴 5: KServe / Seldon Core on Kubernetes
KServe v0.15 (2025년 6월)
- CNCF 인큐베이팅 프로젝트 (오픈소스, Apache 2.0)
- H100, H200, A100, AMD MI6 등 이기종 GPU Farm 지원
- Model Cache Controller: 클러스터 전체 모델 로딩 최적화
- LeaderWorkerSet (LWS): 멀티 Pod 대형 모델 추론
- Envoy AI Gateway 확장으로 지능형 라우팅
- llm-d 통합으로 KV 캐시 인식 라우팅
Seldon Core
- 2024년 1월 22일 이후 BSL 1.1 라이선스 전환
- 상용 제품에 연간 $18,000 비용 발생
- 배치 추론과 복잡한 MLOps 파이프라인에 강점
2025 클라우드 네이티브 LLM 추론 표준 스택
┌─────────────────────────────────────────────────┐
│ 2025 Production LLM Stack │
├─────────────────────────────────────────────────┤
│ │
│ KServe - 표준 인터페이스/CRD │
│ + vLLM - 추론 엔진 │
│ + llm-d - KV 캐시 인식 스케줄링 │
│ + WG Serving - 협업 사양/표준 │
│ + KEDA - 이벤트 기반 오토스케일링 │
│ │
└─────────────────────────────────────────────────┘
6. 로드밸런싱 알고리즘 비교 (GPU 워크로드 관점)
6.1 알고리즘 진화
Naive Round Robin ──→ Least Outstanding Requests ──→ KV 캐시 인식 라우팅
(2020 이전) (2022-2024) (2025~)
요청 비용 무시 진행 중 부하 고려 캐시 상태까지 고려
→ 불균형 부하 → 균형 개선 → 최적 성능
6.2 Round Robin의 한계
- 요청 비용이 동일하다는 가정이 LLM에서 깨짐
- 멀티 레플리카 배포에서 KV 캐시 지역성을 파괴
- 결과: 심각한 테일 레이턴시 스파이크
6.3 Least Outstanding Requests (LOR)
LLM 토큰 기반 LOR:
노드 A: current_in_flight_tokens = 2,000
노드 B: current_in_flight_tokens = 500
새 요청: estimated_tokens = 1,000
→ 노드 B로 라우팅 (500 + 1,000 = 1,500 < 2,000 + 1,000 = 3,000)
Amazon SageMaker는 가중 Round Robin으로 단순 RR 대비 15% 더 나은 활용률 달성.
6.4 KV 캐시 인식 라우팅 (2025 최신 기술)
llm-d (Red Hat):
- 지능적 KV 캐시 인식 라우팅
- 16×16 B200 prefill/decode 토폴로지에서 50k output tok/s 달성
- Round Robin 대비 수십 배 TTFT(첫 토큰 시간) 감소
- GPU 추가 없이 최대 50% 첫 토큰 지연시간 감소
Google GKE Inference Gateway:
- KV 캐시 활용률 포함 GPU 특화 메트릭으로 요청 최적 라우팅
6.5 알고리즘 비교 요약
┌──────────────────────┬───────────────────────┬──────────────────────────────┐
│ 전략 │ 장점 │ 단점 │
├──────────────────────┼───────────────────────┼──────────────────────────────┤
│ Round Robin │ 단순, 무상태 │ 요청 비용 무시, │
│ │ │ KV 캐시 지역성 파괴 │
│ Weighted Round Robin │ 이기종 하드웨어 처리 │ 정확한 가중치 교정 필요 │
│ Least Outstanding │ 진행 중 부하와 │ 토큰 수 추정 필요 │
│ Requests │ 토큰 비용 고려 │ │
│ KV Cache Aware │ 캐시 히트 극대화 │ 구현 복잡도 높음, │
│ Routing │ 최저 테일 레이턴시 │ 상태 추적 오버헤드 │
└──────────────────────┴───────────────────────┴──────────────────────────────┘
GPU 워크로드에서 LOR이 적합한 핵심 이유: LLM 추론은 요청 하나가 GPU를 수 초에서 수십 초 동안 독점한다. Round Robin은 이미 포화된 GPU에 새 요청을 보내는 반면, LOR은 실제 가용 용량을 가진 GPU로 라우팅하여 OOM 오류와 불필요한 큐잉을 방지한다.
7. Health Check 전략
7.1 다층적 Health Check
GPU 추론 서버의 헬스 체크는 단순한 HTTP 200 응답 확인을 넘어야 한다:
┌─────────────────────────────────────────────────────────────────────┐
│ GPU 추론 Health Check 계층 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ Layer 1: Liveness Probe (/health/live) │
│ ├── 프로세스 생존 확인 │
│ ├── CUDA 드라이버 응답 확인 │
│ └── 실패 시: Pod 재시작 │
│ │
│ Layer 2: Readiness Probe (/health/ready 또는 /v2/health/ready) │
│ ├── 모델 가중치 완전 로드 확인 │
│ ├── GPU 메모리 초기화 완료 │
│ ├── 첫 번째 추론 웜업(warm-up) 완료 │
│ └── 실패 시: LB에서 트래픽 제거 (Pod은 유지) │
│ │
│ Layer 3: Custom Health (GPU 특화) │
│ ├── VRAM 가용량 확인 (OOM 임박 감지) │
│ ├── GPU 온도 모니터링 │
│ ├── 추론 큐 깊이 확인 │
│ └── CUDA 오류 상태 확인 │
│ │
└─────────────────────────────────────────────────────────────────────┘
7.2 GPU OOM 감지 전략
- NVIDIA DCGM (Data Center GPU Manager) 지표로 VRAM 사용량 지속 모니터링
- OOM 발생 전 VPA(Vertical Pod Autoscaler)로 동적 메모리 제한 조정
- 양자화(INT8/INT4), 텐서 병렬성, 정밀도 감소로 사전 방지
- KV 캐시 제한 설정:
--gpu-memory-utilization 0.90(vLLM)
7.3 CUDA 오류 감지
- CUDAGraph 내부 오류:
--enforce-eager플래그로 CUDAGraph 비활성화 - PyTorch 메모리 단편화:
PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True - CUDA 오류는 프로세스 레벨에서 복구 불가능한 경우가 많아 Pod 재시작이 안전
7.4 Warm-up Period 처리
대형 모델 로딩은 수십 초에서 수 분까지 걸릴 수 있다:
- Kubernetes Pod Readiness Gates: AWS LBC가 Pod의 타겟 상태를 모니터링하고 “Healthy” 상태가 될 때까지 트래픽 차단
- initialDelaySeconds: 모델 크기에 맞는 충분한 지연 설정
- 롤링 업데이트 시 새 Pod가 준비될 때까지 이전 Pod 유지
7.5 2025 권장 모니터링 스택
┌─────────────────────────────────────────────────────────────────────┐
│ GPU 추론 모니터링 스택 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ GPU 레벨: NVIDIA DCGM 익스포터 │
│ │ (GPU 활용률, VRAM, 온도, 전력, ECC 에러) │
│ ▼ │
│ 수집/저장: Prometheus │
│ │ │
│ ├──→ 시각화: Grafana (GPU 대시보드) │
│ │ │
│ └──→ 스케일링: KEDA (Prometheus 메트릭 기반 자동 스케일링) │
│ │
│ 앱 레벨: vLLM/TGI/Triton 자체 메트릭 │
│ (요청 큐잉, 배칭 동작, 모델별 지연시간, │
│ 토큰 처리량, KV 캐시 히트율) │
│ │
└─────────────────────────────────────────────────────────────────────┘
8. Auto Scaling 전략
8.1 GPU 기반 커스텀 메트릭
기존 CPU/메모리 기반 HPA는 GPU 워크로드에 부적합하다.
┌──────────────────────────┬───────────────────────────────────────────────┐
│ 스케일링 신호 │ 설명 │
├──────────────────────────┼───────────────────────────────────────────────┤
│ VRAM 사용률 │ DCGM 익스포터로 수집. 80% 이상 시 경고 │
│ GPU 연산 활용률 │ 컴퓨팅 코어 포화 상태 측정 │
│ In-flight requests │ 현재 처리 중인 요청 수 │
│ Queue depth │ 대기 중인 요청 수 (가장 직관적) │
│ 추론 지연시간 │ P50, P90, P99 응답 시간 │
│ 토큰 처리량 │ 초당 토큰 생성 수 (tok/s) │
└──────────────────────────┴───────────────────────────────────────────────┘
8.2 KEDA와 GPU Scaling
KEDA(Kubernetes Event-Driven Autoscaling)는 GPU 추론에 최적화된 스케일링을 제공:
┌─────────────────────────────────────────────────────────────────────┐
│ KEDA GPU Scaling 구성 예시 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ NVIDIA DCGM + Prometheus + KEDA: │
│ ┌──────────────────────────────────────────────────┐ │
│ │ apiVersion: keda.sh/v1alpha1 │ │
│ │ kind: ScaledObject │ │
│ │ spec: │ │
│ │ scaleTargetRef: │ │
│ │ name: vllm-deployment │ │
│ │ minReplicaCount: 0 ← Scale to Zero! │ │
│ │ maxReplicaCount: 10 │ │
│ │ triggers: │ │
│ │ - type: prometheus │ │
│ │ metadata: │ │
│ │ query: | │ │
│ │ avg(DCGM_FI_DEV_GPU_UTIL) │ │
│ │ threshold: "70" │ │
│ └──────────────────────────────────────────────────┘ │
│ │
│ KEDA의 핵심 차별점: 0 → 1, 1 → 0 스케일링 능력 │
│ (HPA는 최소 1개 레플리카 필요, KEDA는 0까지 가능) │
│ │
└─────────────────────────────────────────────────────────────────────┘
주요 구성 방식:
- NVIDIA DCGM + Azure Managed Prometheus + KEDA: AKS GPU 자동 스케일링
- KServe + vLLM + KEDA: 앱 메트릭 기반 vLLM 스케일링
- Red Hat OpenShift + KEDA + Prometheus: GPU 활용률 기반 스케일링
8.3 Prefill-Decode 분리 (P/D Disaggregation) - 2025 핵심 트렌드
2025년 가장 중요한 GPU 추론 아키텍처 혁신.
┌─────────────────────────────────────────────────────────────────────┐
│ Prefill-Decode 분리 아키텍처 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 기존 (혼합 배치): │
│ ┌──────────────────────────────────────┐ │
│ │ 단일 GPU Pool │ │
│ │ ┌─────────┐ ┌─────────┐ │ │
│ │ │Prefill │ │Decode │ ← 서로 간섭│ │
│ │ │(컴퓨팅) │ │(메모리) │ 8-10× 저하 │ │
│ │ └─────────┘ └─────────┘ │ │
│ └──────────────────────────────────────┘ │
│ │
│ P/D 분리 (2025): │
│ ┌──────────────────┐ ┌───────────────────┐ │
│ │ Prefill Pool │ │ Decode Pool │ │
│ │ (컴퓨팅 집약) │ │ (메모리 집약) │ │
│ │ H100 SXM │→→│ H200 (141GB HBM3e) │ │
│ │ 높은 FLOPS 필요 │KV│ 높은 대역폭 필요 │ │
│ │ │캐│ │ │
│ │ 독립적 스케일링 │시│ 독립적 스케일링 │ │
│ └──────────────────┘전│ └───────────────────┘ │
│ 송│ │
│ │
│ 구현체: │
│ ├── NVIDIA Dynamo: DeepSeek-R1에서 최대 30× 처리량 향상 │
│ ├── llm-d: KV 캐시 인식 P/D 인스턴스 라우팅 │
│ └── SGLang: 96개 H100으로 노드당 52.3k 입력 tok/s │
│ │
└─────────────────────────────────────────────────────────────────────┘
8.4 Predictive Scaling
- SpotServe: LLM 병렬화 구성을 동적 조정, P99 테일 레이턴시 2.4-9.1× 감소
- SkyServe: SpotHedge로 스팟/온디맨드 혼합 배포, 비용 평균 43% 절감
8.5 Scale-to-Zero 패턴
비용 최적화의 가장 강력한 도구:
- KEDA를 통해 유휴 시 GPU 인스턴스를 0으로 스케일 다운
- RunPod FlashBoot: 콜드 스타트를 ~1초로 단축
- 불규칙한 워크로드에서 서버리스 비용 최대 80% 절감
- 자동 스케일링 추가 = 단일 최고 ROI 최적화 (일반적으로 40-50% 절감)
9. 비용 최적화
9.1 Spot Instance 전략
┌─────────────────────────────────────────────────────────────────────┐
│ Spot GPU Instance 비용 절감 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 비용 절감: │
│ ├── 스팟 GPU: 온디맨드 대비 최대 90% 할인 (일반 70-90%) │
│ ├── SpotServe 연구: 온디맨드 전용 대비 54% 비용 절감 │
│ └── SkyServe: 멀티 클라우드 스팟 관리로 평균 43% 절감 │
│ │
│ 2025 시장 변화: │
│ ├── AWS H100 온디맨드 가격 44% 인하 → ~$3.90/hr │
│ └── P4/P5 인스턴스 최대 45% 절감 RI 옵션 (1년/3년 약정) │
│ │
└─────────────────────────────────────────────────────────────────────┘
9.2 워크로드별 Spot 적합성
┌──────────────────────────────────────┬────────────┬──────────────────────────┐
│ 워크로드 │ Spot 적합? │ 이유 │
├──────────────────────────────────────┼────────────┼──────────────────────────┤
│ 체크포인팅 빈번한 학습 │ ✅ 적합 │ 인터럽션 시 체크포인트 │
│ │ │ 에서 재개 가능 │
│ 배치 추론 │ ✅ 적합 │ 재시도 + 공유 스토리지 │
│ 하이퍼파라미터 탐색 │ ✅ 적합 │ 병렬 실행, 일부 실패 허용│
│ 데이터 전처리/평가 │ ✅ 적합 │ 멱등, 재시도 가능 │
│ 고객 대면 실시간 추론 API │ ❌ 부적합 │ SLA 요건, 예측 불가능한 │
│ │ │ 인터럽션으로 UX 저하 │
│ 장기 실행 모델 학습 (체크포인트 없음)│ ⚠️ 주의 │ 인터럽션 시 전체 재시작 │
└──────────────────────────────────────┴────────────┴──────────────────────────┘
9.3 혼합 인스턴스 전략 (3-Tier)
┌──────────────────┬──────────────────────┬──────────────────────────────────┐
│ 계층 │ 인스턴스 유형 │ 용도 │
├──────────────────┼──────────────────────┼──────────────────────────────────┤
│ 핵심 용량 │ RI (H100/A100) │ 24/7 기본 트래픽 처리 │
│ (Base Capacity) │ 1년 또는 3년 약정 │ SLA 보장 워크로드 │
├──────────────────┼──────────────────────┼──────────────────────────────────┤
│ 버스트 용량 │ 온디맨드 인스턴스 │ 예측 가능한 피크 트래픽 │
│ (Burst) │ │ (업무 시간, 이벤트) │
├──────────────────┼──────────────────────┼──────────────────────────────────┤
│ 배치/학습 │ 스팟 인스턴스 │ 비용 민감 비실시간 워크로드 │
│ (Background) │ │ (학습, 배치 추론, 전처리) │
└──────────────────┴──────────────────────┴──────────────────────────────────┘
9.4 GPU Right-sizing
- NVIDIA DCGM으로 실제 VRAM 사용량과 GPU 활용률 측정
- 모델 크기와 실제 배치 크기에 맞는 인스턴스 선택
- 양자화 (INT8/INT4/FP8)로 동일 GPU에서 더 큰 배치 처리 가능
- 예: Llama 3 70B는 FP16→INT4 양자화로 140GB → ~35GB로 축소
9.5 Multi-AZ vs Single-AZ
┌──────────────────┬──────────────────────────┬──────────────────────────────────┐
│ 측면 │ Multi-AZ │ Single-AZ │
├──────────────────┼──────────────────────────┼──────────────────────────────────┤
│ 가용성 │ 높음 (AZ 장애 허용) │ 중간 │
│ 지연시간 │ AZ 간 ~1-2ms 추가 │ 최소 │
│ 비용 │ AZ 간 데이터 전송 비용 │ 낮음 │
│ GPU 가용성 │ 여러 AZ에서 분산 확보 │ 단일 AZ에 집중 │
│ 권장 │ 고가용성 SLA 프로덕션 │ 비용 민감, 지연시간 최우선 │
│ │ 미션 크리티컬 API │ 개발/테스트, 학습 워크로드 │
└──────────────────┴──────────────────────────┴──────────────────────────────────┘
10. 실제 사례
10.1 OpenAI
- GPT-4: 추론 시 128개 GPU가 협력하여 모델 병렬 처리
- 전용 Multi-AZ GPU 클러스터, 고처리량 로드밸런싱
- 추론 인프라는 완전히 독점적이나 Azure 기반으로 알려짐
10.2 HuggingFace Inference Endpoints
- TGI 기반 추론 서비스
- HuggingFace Hub과 통합된 원클릭 배포
- TGI v3: prefix caching으로 vLLM 대비 최대 3× 토큰, 최대 13× 속도
10.3 Replicate
- 사전 학습된 모델의 광범위한 라이브러리를 서버리스 GPU 추론으로 제공
- GPU 리소스를 추상화 → 모델 이름만 지정하면 추론 가능
- Together AI, HuggingFace와 함께 파인튜닝 기능 제공
10.4 Modal
- Python SDK를 통한 서버리스 GPU 인프라 플랫폼
- GPU 요구사항을 애플리케이션 코드와 인라인으로 정의
- 요청 시 자동으로 수천 대의 GPU를 스핀업
- GPU 컨테이너를 1초 미만으로 프로비저닝
10.5 RunPod
- 2025-2026년 기준 30개 이상 GPU SKU, 전 세계 8개 이상 리전
- FlashBoot: 서버리스 콜드 스타트의 48%가 200ms 미만
- Flex Workers (트래픽 스파이크 시 스케일업) + Active Workers (항상 켜진 상태, 최대 30% 할인) 하이브리드 모델
- SOC 2 Type II 준수
10.6 Netflix
- NVIDIA Tensor Core 기술의 딥러닝 추천 시스템
- 매일 수 테라바이트의 사용자 상호작용 데이터 처리
- “Trace” 시스템: 복잡한 비미분 AI 에이전트 워크플로 최적화
10.7 Spotify
- Ray 프레임워크 기반 ML 스택 운영
- 600만 명 이상의 사용자를 위한 개인화 및 발견 서비스
- “Semantic Tokenization”: 아티스트, 에피소드, 오디오북의 구조화된 표현
11. 대안 기술
11.1 AWS PrivateLink vs ELB
- ELB: 퍼블릭 또는 내부 로드밸런싱, 자동 스케일링, 다양한 라우팅 알고리즘
- PrivateLink: VPC 간 프라이빗 연결, 인터넷 노출 없이 서비스 공개 가능
- GPU Farm이 다른 VPC/계정에서 소비될 때 ELB와 보완적으로 사용
11.2 Service Mesh (Istio) for GPU Workloads
2025 혁신: Istio Gateway API Inference Extension
┌─────────────────────────────────────────────────────────────────────┐
│ Istio AI-Aware Traffic Management │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 새로운 Kubernetes CRD: │
│ ├── InferenceModel: 모델 정의 (이름, LoRA 어댑터, 우선순위) │
│ └── InferencePool: GPU 노드 풀 정의 (용량, 메트릭) │
│ │
│ "엔드포인트 피커": │
│ ├── LLM의 실시간 메트릭(KV 캐시, 큐 깊이)을 활용 │
│ ├── 모델 인식 + LoRA 어댑터 인식 라우팅 │
│ └── 이기종 가속기 지원 계획 (GPU, TPU, 특수 AI 칩) │
│ │
└─────────────────────────────────────────────────────────────────────┘
Istio Ambient Mode
- 기존 사이드카에서 노드 공유 L4 프록시(ztunnel)로 전환
- 이중 홉 페널티 제거 → 거의 베어메탈 수준 레이턴시
- GPU Pod에 사이드카 오버헤드 제거 → 더 많은 VRAM을 모델에 할당
Istio vs ELB 비교
┌──────────────────┬──────────────────────────┬──────────────────────────────────┐
│ 기능 │ Istio + Envoy │ 전통 ELB/ALB │
├──────────────────┼──────────────────────────┼──────────────────────────────────┤
│ L7 라우팅 │ 고급 (헤더/경로/가중치) │ 기본적 │
│ GPU/LLM 인식 │ 지원 (InferencePool) │ 미지원 (Target Optimizer만) │
│ mTLS/보안 │ 기본 내장 │ 제한적 │
│ 옵저버빌리티 │ 깊은 텔레메트리 │ 기본 지표 │
│ 동서 트래픽 │ 서비스 메시 │ 미지원 │
│ LoRA 라우팅 │ 지원 (2025 Extension) │ 미지원 │
│ 운영 복잡도 │ 높음 │ 낮음 │
│ 비용 │ 오픈소스 (운영비) │ 사용량 기반 과금 │
└──────────────────┴──────────────────────────┴──────────────────────────────────┘
11.3 API Gateway for Inference
- Envoy AI Gateway: Envoy 위에 구축된 오픈소스 GenAI 트래픽 관리
- Kgateway: AI 및 MCP 게이트웨이를 위한 고급 라우팅
11.4 Kubernetes Ingress vs ELB
AWS EKS에서의 통합 패턴:
- Kubernetes Ingress → AWS LBC → ALB 자동 프로비저닝
- Kubernetes Service (LoadBalancer type) → NLB 자동 프로비저닝
- TargetGroupBinding: 기존 ALB/NLB 타겟 그룹을 EKS Pod에 동적 바인딩
- 단일 ALB가 여러 EKS 클러스터에 걸쳐 트래픽 라우팅 가능
12. 종합 요약 및 선택 가이드
12.1 핵심 선택 원칙 (2025-2026)
1. ELB 선택:
GPU 추론 API에는 ALB + Target Optimizer가 최우선.
gRPC 스트리밍, 정적 IP, 비 HTTP → NLB.
2. 추론 서버:
단일 모델 고처리량 → vLLM
HuggingFace 생태계 → TGI
엔터프라이즈 멀티모달 → Triton
3. 오케스트레이션:
Kubernetes + KServe + KEDA = 2025 표준 스택.
Seldon Core는 라이선스 비용($18K/년) 주의.
4. 로드밸런싱 알고리즘:
LOR 또는 KV 캐시 인식 라우팅 >> Round Robin.
GPU 워크로드에서 RR은 안티패턴.
5. 비용 최적화:
자동 스케일링 (40-50% 절감) + Scale-to-Zero + 스팟 (70-90% 절감).
3-Tier 혼합 전략이 최적.
6. 최신 트렌드:
Prefill-Decode 분리가 2025 기본 패러다임.
NVIDIA Dynamo가 이를 주도.
12.2 아키텍처 결정 플로우차트
┌─────────────────────────────────────────────────────────────────────┐
│ GPU 추론 아키텍처 결정 흐름 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 인프라 직접 관리가 필요한가? │
│ ├── NO → SageMaker / Bedrock (완전 관리형) │
│ └── YES │
│ │ │
│ Kubernetes 사용 중인가? │
│ ├── NO → Direct Serving (EC2 + ELB) │
│ └── YES │
│ │ │
│ 멀티 모델 서빙이 필요한가? │
│ ├── NO → vLLM/TGI + KEDA + ALB │
│ └── YES → KServe + Triton + KEDA + ALB │
│ │ │
│ KV 캐시 인식 라우팅이 필요한가? │
│ ├── NO → ALB Target Optimizer로 충분 │
│ └── YES → llm-d + Istio Inference Extension │
│ │
│ ELB 선택: │
│ ├── HTTP/REST API → ALB │
│ ├── gRPC 스트리밍 → NLB 또는 ALB │
│ ├── 정적 IP 필요 → NLB │
│ └── 보안 어플라이언스 → GLB │
│ │
└─────────────────────────────────────────────────────────────────────┘
12.3 규모별 추천 아키텍처
┌──────────────────┬──────────────────────────────────────────────────────────────┐
│ 규모 │ 추천 구성 │
├──────────────────┼──────────────────────────────────────────────────────────────┤
│ 소규모 │ EC2 GPU (1-3대) + ALB + vLLM │
│ (PoC/스타트업) │ 자동 스케일링 없음, 수동 관리 │
│ │ 월 비용: $3K-$10K │
├──────────────────┼──────────────────────────────────────────────────────────────┤
│ 중규모 │ EKS + GPU Node Pool + ALB (AWS LBC) + vLLM + KEDA │
│ (프로덕션) │ 자동 스케일링, Scale-to-Zero │
│ │ 월 비용: $10K-$50K │
├──────────────────┼──────────────────────────────────────────────────────────────┤
│ 대규모 │ EKS + KServe + Triton/vLLM + llm-d + KEDA + Istio │
│ (엔터프라이즈) │ P/D 분리, KV 캐시 인식 라우팅, Multi-AZ │
│ │ 3-Tier 혼합 인스턴스 + RI │
│ │ 월 비용: $50K+ │
├──────────────────┼──────────────────────────────────────────────────────────────┤
│ 관리형 선호 │ SageMaker Endpoints / Bedrock │
│ │ 인프라 관리 최소화, 빠른 배포 │
│ │ 비용은 높지만 운영 부담 없음 │
└──────────────────┴──────────────────────────────────────────────────────────────┘
13. 참고 자료
- Infrastructure for ML and Generative AI: Evolution
- NVIDIA Data Center GPUs Explained: A100 to B200
- Comparing Blackwell vs Hopper: B200 vs H100
- AWS re:Invent 2025: Deep Dive on ELB
- ALB Target Optimizer for AI Workloads
- Load Balancing for AI Inference on 1000 GPUs
- Beyond Round Robin: Token-Aware LLM Load Balancer
- Alibaba: LLM Load Balancing with 50% TTFT Reduction
- llm-d: Intelligent KV-Cache-Aware Routing on Kubernetes
- vLLM vs TGI vs Triton Comparison
- vLLM vs TensorRT-LLM vs TGI: Deep Technical Comparison
- KServe Autoscaling with vLLM and KEDA
- KEDA 2025 Kubernetes Autoscaling Playbook
- Istio AI-Aware Inference Extension Support
- Deep Dive into the Gateway API Inference Extension (CNCF)
- SageMaker Multi-Model Endpoints with GPU
- NVIDIA Dynamo: Distributed Inference Framework
- Prefill-Decode Disaggregation: 18 Months Later
- Deploy LLMs on Amazon EKS using vLLM
- Netflix: Supporting Diverse ML Systems
- RunPod Serverless GPU Architecture
- GPU Cost Optimization Playbook
- SpotServe: LLM Serving on Preemptible Instances