GPU 선택, 클라우드 vs 온프레미스, 배칭 전략이 비용과 지연시간에 미치는 영향을 분석하고, SLO 기반 최적화와 비용 모델링 방법을 다룹니다.
LLM 추론 비용은 크게 세 가지 요소로 구성됩니다.
이 중 GPU 비용이 70-80%를 차지하며, GPU 선택과 활용률이 전체 비용을 좌우합니다.
$/1M tokens = GPU 시간당 비용 / (시간당 처리 토큰 수 / 1,000,000)
tokens/$/hr = 시간당 처리 토큰 수 / GPU 시간당 비용
TCO/token = 총소유비용 / 전체 기간 처리 토큰 수| 스펙 | A100 | H100 | H200 | B200 |
|---|---|---|---|---|
| HBM 용량 | 80 GB HBM2e | 80 GB HBM3 | 141 GB HBM3e | 192 GB HBM3e |
| HBM 대역폭 | 2.0 TB/s | 3.35 TB/s | 4.8 TB/s | 8.0 TB/s |
| FP16 TFLOPS | 312 | 990 | 990 | ~2,250 |
| FP8 TFLOPS | - | 1,979 | 1,979 | ~4,500 |
| FP4 지원 | 없음 | 없음 | 없음 | 네이티브 |
Decode 단계는 메모리 바운드이므로, HBM 대역폭이 추론 성능의 핵심 결정 요인입니다.
모델 가중치 크기 / HBM 대역폭 = 토큰당 최소 시간
Llama 3 70B (FP8 = 70GB):
A100: 70GB / 2.0 TB/s = 35ms/token → ~28 TPS
H100: 70GB / 3.35 TB/s = 20.9ms/token → ~48 TPS
H200: 70GB / 4.8 TB/s = 14.6ms/token → ~68 TPS
B200: 70GB / 8.0 TB/s = 8.75ms/token → ~114 TPS위 수치는 단일 요청, 배치 크기 1에서의 이론적 상한입니다. 실제로는 커널 오버헤드, 통신 지연 등으로 이론값의 60-80% 수준을 달성합니다. 배치 크기가 커지면 메모리 바운드에서 컴퓨트 바운드로 전환되어 다른 수치가 적용됩니다.
GPU 성능만으로는 최적의 선택을 할 수 없습니다. 비용까지 고려해야 합니다.
GPU | 시간당 비용 | 70B FP8 TPS | tokens/$
A100 | ~$2.5 | ~28 | ~40,320
H100 | ~$4.0 | ~48 | ~43,200
H200 | ~$5.5 | ~68 | ~44,509
B200 | ~$8.0 | ~114 | ~51,300B200은 절대 비용은 가장 높지만, tokens/$ 기준으로는 가장 효율적입니다. 하지만 이 분석은 배치 크기 1 기준이며, 높은 처리량 시나리오에서는 결과가 달라질 수 있습니다.
GPU 활용률이 70%+ 이상으로 예상되는가?
→ 예: 온프레미스 검토 가치 있음
→ 아니오: 클라우드 유리
사용 기간이 18개월 이상인가?
→ 예: 온프레미스의 TCO 우위 가능성
→ 아니오: 클라우드 유리
데이터 규제가 있는가?
→ 예: 온프레미스 또는 전용 클라우드
→ 아니오: 퍼블릭 클라우드 가능
GPU 전문 인력이 있는가?
→ 예: 온프레미스 운영 가능
→ 아니오: 클라우드 관리형 서비스 권장클라우드의 **스팟 인스턴스(Spot Instance)**는 온디맨드 대비 60-80% 저렴한 가격으로 GPU를 사용할 수 있습니다. 단, 사전 통보 없이 회수될 수 있으므로 적합한 시나리오가 제한됩니다.
적합:
- 배치 처리 (재시도 가능한 워크로드)
- 벤치마크 / 평가 실행
- 개발 / 실험 환경
부적합:
- 실시간 서빙 (중단 불가)
- SLO가 엄격한 프로덕션 서비스하이브리드 전략이 효과적인 경우가 많습니다. 기본 트래픽은 온프레미스 또는 예약 인스턴스로 처리하고, 트래픽 피크는 온디맨드 클라우드로 흡수하는 방식입니다. 이를 통해 기본 비용을 낮추면서도 탄력적 확장이 가능합니다.
4장에서 다룬 배칭은 비용과 지연시간 사이의 근본적인 트레이드오프를 결정합니다.
높은 비용
|
| * 배치=1 (최소 지연, 최고 비용)
|
| * 배치=4
|
| * 배치=16
|
| * 배치=64 (높은 지연, 최저 비용)
|
낮은 비용
+-----------------------------→
낮은 지연 높은 지연| 워크로드 | TPOT SLO | 권장 배치 | 비용 효율 |
|---|---|---|---|
| 실시간 챗봇 | 30ms 이하 | 4-8 | 중간 |
| 코드 어시스턴트 | 50ms 이하 | 8-16 | 높음 |
| 문서 요약 (배치) | 제한 없음 | 64-256 | 최고 |
| RAG 파이프라인 | 100ms 이하 | 16-32 | 높음 |
같은 품질을 달성할 수 있다면, 작은 모델을 사용하는 것이 항상 비용 효율적입니다.
옵션 A: 70B 모델 (FP8) — H100 x 1
비용: ~$4/hr
성능: ~48 TPS (배치=1)
품질: 벤치마크 85점
옵션 B: 8B 모델 (FP8) + 파인튜닝 — H100 x 1
비용: ~$4/hr (동일 GPU, 하지만 배치를 크게 키울 수 있음)
성능: ~380 TPS (배치=1), 동시 처리량 훨씬 높음
품질: 도메인 특화 파인튜닝으로 80-85점 가능
비용 효율: 옵션 B가 tokens/$ 기준으로 8-10배 유리1. 타겟 태스크에서 작은 모델(8-13B)로 충분한 품질이 나오는가?
→ 예: 작은 모델 선택 (비용 최적)
→ 아니오: 2단계
2. 파인튜닝으로 작은 모델의 품질을 올릴 수 있는가?
→ 예: 파인튜닝 + 작은 모델 (중기 비용 최적)
→ 아니오: 3단계
3. 70B 모델이 필요
→ FP8 양자화 + Continuous Batching + Speculative Decoding
→ 비용 최적화 스택 전체 적용모델 크기 선택에서 흔한 실수는 "더 큰 모델이 더 좋다"는 가정입니다. 특정 도메인에서는 잘 파인튜닝된 8B 모델이 범용 70B 모델보다 우수한 성능을 보이는 경우가 많습니다. 반드시 타겟 태스크에서의 실제 평가에 기반해 결정해야 합니다.
프로덕션 LLM 서비스의 비용을 모델링하는 프레임워크를 정리합니다.
def estimate_monthly_cost(
requests_per_day: int,
avg_input_tokens: int,
avg_output_tokens: int,
gpu_cost_per_hour: float,
tokens_per_second_per_gpu: float,
target_utilization: float = 0.7,
) -> dict:
"""월간 추론 비용 추정"""
total_tokens_per_day = requests_per_day * (avg_input_tokens + avg_output_tokens)
# 시간당 처리 가능 토큰 (실효)
effective_tps = tokens_per_second_per_gpu * target_utilization
tokens_per_hour = effective_tps * 3600
# 필요 GPU 시간
gpu_hours_per_day = total_tokens_per_day / tokens_per_hour
# 월간 비용
monthly_gpu_hours = gpu_hours_per_day * 30
monthly_cost = monthly_gpu_hours * gpu_cost_per_hour
cost_per_million_tokens = (gpu_cost_per_hour / tokens_per_hour) * 1_000_000
return {
"monthly_cost": monthly_cost,
"gpu_hours_per_day": gpu_hours_per_day,
"cost_per_million_tokens": cost_per_million_tokens,
"gpus_needed": gpu_hours_per_day / 24, # 상시 운영 기준
}
# 예시: 챗봇 서비스
result = estimate_monthly_cost(
requests_per_day=100_000,
avg_input_tokens=500,
avg_output_tokens=200,
gpu_cost_per_hour=4.0, # H100
tokens_per_second_per_gpu=2000, # 배치 처리 기준
target_utilization=0.7,
)
# 결과:
# monthly_cost: ~$1,428
# cost_per_million_tokens: ~$0.79
# gpus_needed: ~0.50 (1개 GPU로 충분)프로덕션 서비스에서는 **SLO(Service Level Objective)**를 먼저 정의하고, 그 안에서 비용을 최소화하는 접근이 올바릅니다.
| SLO | 설명 | 전형적 타겟 |
|---|---|---|
| TTFT P95 | 95번째 백분위 첫 토큰 시간 | 200-500ms |
| TPOT P95 | 95번째 백분위 토큰당 시간 | 30-100ms |
| 가용성 | 서비스 정상 동작 비율 | 99.9% |
| 오류율 | 실패 요청 비율 | 0.1% 미만 |
1. SLO 정의: TTFT P95 < 300ms, TPOT P95 < 50ms
2. 부하 프로파일: 피크 RPS, 평균 RPS, 입출력 토큰 분포
3. 후보 구성 나열:
- 70B FP8, H100 x 1, 배치 8-16
- 70B FP8, H200 x 1, 배치 16-32
- 8B FP8 파인튜닝, H100 x 1, 배치 32-64
4. 벤치마크: 각 구성에서 SLO 충족 여부 확인
5. 비용 비교: SLO를 충족하는 구성 중 최저 비용 선택이 장에서는 비용과 지연시간의 트레이드오프를 다각도로 분석했습니다.
마지막 장에서는 이 시리즈에서 다룬 모든 최적화 기법을 조합해 프로덕션에 배포하는 실전 가이드를 다룹니다. FP8 + FlashAttention 3 + Continuous Batching + Speculative Decoding의 조합으로 5-8배의 비용 효율 개선을 달성하는 방법을 알아보겠습니다.
이 글이 도움이 되셨나요?
관련 주제 더 보기
FP8, FlashAttention 3, Continuous Batching, Speculative Decoding을 조합해 5-8배 비용 효율을 달성하는 실전 배포 파이프라인과 모니터링 전략을 다룹니다.
텐서 병렬화, 파이프라인 병렬화, 시퀀스 병렬화, Expert 병렬화의 원리를 분석하고, 멀티 GPU 추론 전략과 클러스터 수준 최적화를 다룹니다.
양자화의 기초 개념부터 FP8의 부상, W8A8/W4A16 전략, GPTQ/AWQ/SmoothQuant 기법, KV 캐시 양자화까지 정확도와 성능의 트레이드오프를 분석합니다.