본문으로 건너뛰기
Kreath Archive
TechProjectsBooksAbout
TechProjectsBooksAbout

내비게이션

  • Tech
  • Projects
  • Books
  • About
  • Tags

카테고리

  • AI / ML
  • 웹 개발
  • 프로그래밍
  • 개발 도구

연결

  • GitHub
  • Email
  • RSS
© 2026 Kreath Archive. All rights reserved.Built with Next.js + MDX
홈TechProjectsBooksAbout
//
  1. 홈
  2. 테크
  3. 9장: 비용 vs 지연시간 트레이드오프
2026년 4월 1일·AI / ML·

9장: 비용 vs 지연시간 트레이드오프

GPU 선택, 클라우드 vs 온프레미스, 배칭 전략이 비용과 지연시간에 미치는 영향을 분석하고, SLO 기반 최적화와 비용 모델링 방법을 다룹니다.

16분359자9개 섹션
llmaiperformancemlops
공유
llm-inference9 / 10
12345678910
이전8장: 모델 병렬화와 분산 추론다음10장: 프로덕션 추론 최적화 실전

이 장에서 배우는 것

  • GPU 세대별 성능과 비용 특성 비교
  • 클라우드 vs 온프레미스 의사결정 프레임워크
  • 배칭 전략이 비용과 지연시간에 미치는 영향
  • 모델 크기 선택의 경제학
  • 비용 모델링과 SLO 기반 최적화

추론 비용의 구조

LLM 추론 비용은 크게 세 가지 요소로 구성됩니다.

총 비용=GPU 비용+인프라 비용+운영 비용\text{총 비용} = \text{GPU 비용} + \text{인프라 비용} + \text{운영 비용}총 비용=GPU 비용+인프라 비용+운영 비용

이 중 GPU 비용이 70-80%를 차지하며, GPU 선택과 활용률이 전체 비용을 좌우합니다.

비용 효율의 핵심 지표

비용 효율 지표
text
$/1M tokens  = GPU 시간당 비용 / (시간당 처리 토큰 수 / 1,000,000)
tokens/$/hr  = 시간당 처리 토큰 수 / GPU 시간당 비용
TCO/token    = 총소유비용 / 전체 기간 처리 토큰 수

GPU 선택: A100 / H100 / H200 / B200

세대별 스펙 비교

스펙A100H100H200B200
HBM 용량80 GB HBM2e80 GB HBM3141 GB HBM3e192 GB HBM3e
HBM 대역폭2.0 TB/s3.35 TB/s4.8 TB/s8.0 TB/s
FP16 TFLOPS312990990~2,250
FP8 TFLOPS-1,9791,979~4,500
FP4 지원없음없음없음네이티브

추론 성능 분석

Decode 단계는 메모리 바운드이므로, HBM 대역폭이 추론 성능의 핵심 결정 요인입니다.

Decode 토큰 생성 속도 (이론적 상한)
text
모델 가중치 크기 / 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
Info

위 수치는 단일 요청, 배치 크기 1에서의 이론적 상한입니다. 실제로는 커널 오버헤드, 통신 지연 등으로 이론값의 60-80% 수준을 달성합니다. 배치 크기가 커지면 메모리 바운드에서 컴퓨트 바운드로 전환되어 다른 수치가 적용됩니다.

비용 대비 성능

GPU 성능만으로는 최적의 선택을 할 수 없습니다. 비용까지 고려해야 합니다.

클라우드 GPU 비용 대비 성능 (2026년 기준, 근사치)
text
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,300

B200은 절대 비용은 가장 높지만, tokens/$ 기준으로는 가장 효율적입니다. 하지만 이 분석은 배치 크기 1 기준이며, 높은 처리량 시나리오에서는 결과가 달라질 수 있습니다.

클라우드 vs 온프레미스

클라우드의 장점

  • 초기 투자 없음: CapEx 없이 OpEx로 시작 가능
  • 탄력적 스케일링: 트래픽에 따라 GPU 수를 조절
  • 최신 GPU 접근: 새로운 GPU 세대를 즉시 사용 가능
  • 관리 부담 감소: 하드웨어 유지보수 불필요

온프레미스의 장점

  • 장기 비용 절감: 1-2년 이상 지속 사용 시 클라우드 대비 40-60% 저렴
  • 데이터 통제: 민감 데이터의 외부 전송 불필요
  • 안정적 성능: 멀티테넌트 환경의 성능 변동 없음
  • 커스터마이징: 네트워크 토폴로지, 스토리지 등 자유 설정

의사결정 프레임워크

클라우드 vs 온프레미스 결정 기준
text
GPU 활용률이 70%+ 이상으로 예상되는가?
  → 예: 온프레미스 검토 가치 있음
  → 아니오: 클라우드 유리
 
사용 기간이 18개월 이상인가?
  → 예: 온프레미스의 TCO 우위 가능성
  → 아니오: 클라우드 유리
 
데이터 규제가 있는가?
  → 예: 온프레미스 또는 전용 클라우드
  → 아니오: 퍼블릭 클라우드 가능
 
GPU 전문 인력이 있는가?
  → 예: 온프레미스 운영 가능
  → 아니오: 클라우드 관리형 서비스 권장

스팟 인스턴스 활용

클라우드의 **스팟 인스턴스(Spot Instance)**는 온디맨드 대비 60-80% 저렴한 가격으로 GPU를 사용할 수 있습니다. 단, 사전 통보 없이 회수될 수 있으므로 적합한 시나리오가 제한됩니다.

스팟 인스턴스 적합 시나리오
text
적합:
  - 배치 처리 (재시도 가능한 워크로드)
  - 벤치마크 / 평가 실행
  - 개발 / 실험 환경
 
부적합:
  - 실시간 서빙 (중단 불가)
  - SLO가 엄격한 프로덕션 서비스
Tip

하이브리드 전략이 효과적인 경우가 많습니다. 기본 트래픽은 온프레미스 또는 예약 인스턴스로 처리하고, 트래픽 피크는 온디맨드 클라우드로 흡수하는 방식입니다. 이를 통해 기본 비용을 낮추면서도 탄력적 확장이 가능합니다.

배칭 전략과 비용-지연시간 트레이드오프

4장에서 다룬 배칭은 비용과 지연시간 사이의 근본적인 트레이드오프를 결정합니다.

트레이드오프 곡선

배치 크기에 따른 비용-지연시간 곡선
text
       높은 비용
          |
          |  * 배치=1 (최소 지연, 최고 비용)
          |
          |     * 배치=4
          |
          |        * 배치=16
          |
          |           * 배치=64 (높은 지연, 최저 비용)
          |
       낮은 비용
          +-----------------------------→
             낮은 지연          높은 지연
  • 배치 크기 1: TPOT 최소, 하지만 GPU 활용률이 낮아 tokens/$가 최악
  • 배치 크기 64: tokens/$는 최적이지만, TPOT가 크게 증가

워크로드별 최적 배치 크기

워크로드TPOT SLO권장 배치비용 효율
실시간 챗봇30ms 이하4-8중간
코드 어시스턴트50ms 이하8-16높음
문서 요약 (배치)제한 없음64-256최고
RAG 파이프라인100ms 이하16-32높음

모델 크기 선택의 경제학

같은 품질을 달성할 수 있다면, 작은 모델을 사용하는 것이 항상 비용 효율적입니다.

큰 모델 vs 작은 모델 + 최적화

비용 비교 예시
text
옵션 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배 유리

모델 선택 의사결정

모델 크기 결정 흐름
text
1. 타겟 태스크에서 작은 모델(8-13B)로 충분한 품질이 나오는가?
   → 예: 작은 모델 선택 (비용 최적)
   → 아니오: 2단계
 
2. 파인튜닝으로 작은 모델의 품질을 올릴 수 있는가?
   → 예: 파인튜닝 + 작은 모델 (중기 비용 최적)
   → 아니오: 3단계
 
3. 70B 모델이 필요
   → FP8 양자화 + Continuous Batching + Speculative Decoding
   → 비용 최적화 스택 전체 적용
Warning

모델 크기 선택에서 흔한 실수는 "더 큰 모델이 더 좋다"는 가정입니다. 특정 도메인에서는 잘 파인튜닝된 8B 모델이 범용 70B 모델보다 우수한 성능을 보이는 경우가 많습니다. 반드시 타겟 태스크에서의 실제 평가에 기반해 결정해야 합니다.

비용 모델링

프로덕션 LLM 서비스의 비용을 모델링하는 프레임워크를 정리합니다.

핵심 변수

cost_model.py
python
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 기반 최적화

프로덕션 서비스에서는 **SLO(Service Level Objective)**를 먼저 정의하고, 그 안에서 비용을 최소화하는 접근이 올바릅니다.

핵심 SLO 지표

SLO설명전형적 타겟
TTFT P9595번째 백분위 첫 토큰 시간200-500ms
TPOT P9595번째 백분위 토큰당 시간30-100ms
가용성서비스 정상 동작 비율99.9%
오류율실패 요청 비율0.1% 미만

SLO를 만족하는 최저 비용 구성 찾기

SLO 기반 최적화 프로세스
text
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를 충족하는 구성 중 최저 비용 선택

정리

이 장에서는 비용과 지연시간의 트레이드오프를 다각도로 분석했습니다.

  • GPU 선택은 HBM 대역폭과 tokens/$ 비율로 판단하며, B200이 최신 세대에서 가장 비용 효율적입니다
  • 클라우드와 온프레미스의 선택은 사용 기간, 활용률, 데이터 규제에 따라 결정합니다
  • 배칭 전략은 비용과 지연시간의 직접적인 트레이드오프이며, SLO에 맞추어 조절합니다
  • 모델 크기 선택에서 파인튜닝된 작은 모델이 범용 큰 모델보다 비용 효율적일 수 있습니다

마지막 장에서는 이 시리즈에서 다룬 모든 최적화 기법을 조합해 프로덕션에 배포하는 실전 가이드를 다룹니다. FP8 + FlashAttention 3 + Continuous Batching + Speculative Decoding의 조합으로 5-8배의 비용 효율 개선을 달성하는 방법을 알아보겠습니다.

이 글이 도움이 되셨나요?

관련 주제 더 보기

#llm#ai#performance#mlops

관련 글

AI / ML

10장: 프로덕션 추론 최적화 실전

FP8, FlashAttention 3, Continuous Batching, Speculative Decoding을 조합해 5-8배 비용 효율을 달성하는 실전 배포 파이프라인과 모니터링 전략을 다룹니다.

2026년 4월 3일·20분
AI / ML

8장: 모델 병렬화와 분산 추론

텐서 병렬화, 파이프라인 병렬화, 시퀀스 병렬화, Expert 병렬화의 원리를 분석하고, 멀티 GPU 추론 전략과 클러스터 수준 최적화를 다룹니다.

2026년 3월 30일·17분
AI / ML

7장: 양자화 추론 — FP8, INT8, INT4

양자화의 기초 개념부터 FP8의 부상, W8A8/W4A16 전략, GPTQ/AWQ/SmoothQuant 기법, KV 캐시 양자화까지 정확도와 성능의 트레이드오프를 분석합니다.

2026년 3월 28일·16분
이전 글8장: 모델 병렬화와 분산 추론
다음 글10장: 프로덕션 추론 최적화 실전

댓글

목차

약 16분 남음
  • 이 장에서 배우는 것
  • 추론 비용의 구조
    • 비용 효율의 핵심 지표
  • GPU 선택: A100 / H100 / H200 / B200
    • 세대별 스펙 비교
    • 추론 성능 분석
    • 비용 대비 성능
  • 클라우드 vs 온프레미스
    • 클라우드의 장점
    • 온프레미스의 장점
    • 의사결정 프레임워크
    • 스팟 인스턴스 활용
  • 배칭 전략과 비용-지연시간 트레이드오프
    • 트레이드오프 곡선
    • 워크로드별 최적 배치 크기
  • 모델 크기 선택의 경제학
    • 큰 모델 vs 작은 모델 + 최적화
    • 모델 선택 의사결정
  • 비용 모델링
    • 핵심 변수
  • SLO 기반 최적화
    • 핵심 SLO 지표
    • SLO를 만족하는 최저 비용 구성 찾기
  • 정리