본문으로 건너뛰기

Llama 4 FM 서빙 벤치마크: GPU vs AWS Custom Silicon

📅 작성일: 2026-02-10 | 수정일: 2026-02-14 | ⏱️ 읽는 시간: 약 9분

개요

AWS EKS 환경에서 vLLM을 이용한 Llama 4 모델 서빙 성능을 5개 시나리오로 비교한 벤치마크 보고서입니다.

한 줄 요약: Llama 4 Scout(109B MoE) 추론에서 AWS 커스텀 실리콘이 NVIDIA GPU 대비 58-67% 낮은 토큰당 비용($0.28~$0.35/1M tokens vs $0.85)을 달성했으며, p5/H100은 **최저 TTFT(120ms)**와 **최고 처리량(4,200 tokens/sec)**으로 지연 민감 워크로드에 최적입니다. Trainium2는 H100 처리량의 83%를 41% 비용으로 제공하여 최고의 성능 대비 비용 비율을 보여줍니다.

5개 시나리오:

  • A p5.48xlarge — 8× NVIDIA H100 80GB (GPU 베이스라인)
  • B p4d.24xlarge — 8× NVIDIA A100 40GB (이전 세대 GPU)
  • C g6e.48xlarge — 8× NVIDIA L40S 48GB (비용 최적화 GPU)
  • D trn2.48xlarge — 16× AWS Trainium2 96GB (커스텀 실리콘 학습/추론)
  • E inf2.48xlarge — 12× AWS Inferentia2 32GB (커스텀 실리콘 추론 특화)

주요 시사점:

지표A: p5/H100B: p4d/A100C: g6e/L40SD: trn2E: inf2
TTFT (첫 토큰 시간)120ms280ms350ms150ms200ms
ITL (토큰 간 지연)8ms18ms22ms10ms14ms
처리량 (tokens/sec)4,2001,8001,4003,5002,800
비용 ($/1M tokens)$0.85$0.72$0.52$0.35$0.28

* 공개된 스펙 및 아키텍처 분석 기반 추정치. 입력 512 / 출력 128 토큰.


테스트 환경

인스턴스 사양
5개 테스트 시나리오 · us-east-1 온디맨드 가격
SpecA: p5.48xlB: p4d.24xlC: g6e.48xlD: trn2.48xlE: inf2.48xl
가속기8× H1008× A1008× L40S16× Trainium212× Inferentia2
칩당 메모리80 GB HBM340 GB HBM248 GB GDDR696 GB HBM32 GB HBM
총 가속기 메모리640 GB320 GB384 GB1,536 GB384 GB
네트워크 대역폭3,200 Gbps400 Gbps400 Gbps3,200 Gbps200 Gbps
온디맨드 가격$98.32$21.96$54.91~$45.00$12.89
가속기당 시간 비용$12.29$2.75$6.86~$2.81$1.07
칩 인터커넥트NVSwitch 900GB/sNVSwitch 600GB/sPCIe Gen5NeuronLinkNeuronLink 192GB/s

클러스터 구성:

  • EKS 버전: 1.31
  • 리전: us-east-1 (단일 AZ)
  • vLLM 버전: v0.8.3+ (Llama 4 Day 0 지원, MetaShuffling 최적화)
  • Neuron SDK: 2.x (Trainium2/Inferentia2 시나리오)
  • CUDA: 12.4 (GPU 시나리오)
  • 정밀도: BF16 (모든 시나리오)
  • 측정 방식: 최소 3회 반복 측정 후 중앙값 사용

테스트 모델

Llama 4 Scout
총 파라미터
109B
활성 파라미터
17B per token
아키텍처
MoE (16 routed experts + 1 shared)
활성 Expert
2 per token
컨텍스트 윈도우
10M tokens
히든 차원
8,192
레이어
80
Attention 헤드
64
KV 헤드
8
위치 인코딩
iRoPE
최소 하드웨어
Single H100 80GB (BF16)
vLLM 컨텍스트 (8×H100)
1M tokens
Llama 4 Maverick
총 파라미터
400B
활성 파라미터
17B per token
아키텍처
MoE (128 routed experts + 1 shared)
활성 Expert
2 per token
컨텍스트 윈도우
10M tokens
최소 하드웨어
8× H100 80GB (BF16)
FP8 양자화
Available
vLLM 컨텍스트 (8×H100)
~430K tokens

Llama 4 MoE 아키텍처 특징

Llama 4는 Mixture of Experts (MoE) 아키텍처를 채택하여 효율적인 추론을 구현합니다:

  • 희소 활성화: 109B 총 파라미터 중 토큰당 17B만 활성화 (Scout 기준)
  • Expert 라우팅: 16개 Expert 중 2개만 선택적으로 활성화하여 연산량 절감
  • 메모리 트레이드오프: 모든 Expert 가중치를 VRAM에 로드해야 하므로 총 메모리 요구량은 Dense 모델과 유사
  • 병렬화 전략: Tensor Parallelism(TP), Pipeline Parallelism(PP), Expert Parallelism(EP), Data Parallelism(DP) 지원
  • vLLM MetaShuffling: MoE 추론에 최적화된 토큰 라우팅 및 메모리 관리
Scout vs Maverick 배포 요구사항
  • Scout (109B): 단일 H100 80GB에서 BF16 배포 가능. 8×H100으로 1M 컨텍스트 지원
  • Maverick (400B): 최소 8×H100 필요. FP8 양자화 버전 제공. 8×H100으로 ~430K 컨텍스트 지원

벤치마크 결과

1. 첫 토큰 생성 시간 (TTFT)

Time to First Token은 사용자 경험에 직접적인 영향을 미치는 핵심 지표입니다. 프롬프트 처리(prefill) 단계의 연산 성능을 반영합니다.

Llama 4 Scout

낮을수록 좋음
A: p5/H100
120
최적
B: p4d/A100
280
C: g6e/L40S
350
D: trn2
150
E: inf2
200

Llama 4 Maverick

낮을수록 좋음
A: p5/H100
250
최적
D: trn2
300
📊 상세 데이터 테이블

Llama 4 Scout (입력 512 토큰)

시나리오인스턴스TTFT (ms)기준 대비
Ap5/H100120베이스라인
Bp4d/A100280+133%
Cg6e/L40S350+192%
Dtrn2150+25%
Einf2200+67%

Llama 4 Maverick (입력 512 토큰)

시나리오인스턴스TTFT (ms)
Ap5/H100250
Dtrn2300

2. 토큰 간 지연 시간 (ITL)

Inter-Token Latency는 디코딩 단계에서 각 토큰 생성 간의 지연을 측정합니다. 스트리밍 응답의 부드러움을 결정합니다.

Llama 4 Scout

낮을수록 좋음
A: p5/H100
8
최적
B: p4d/A100
18
C: g6e/L40S
22
D: trn2
10
E: inf2
14

Llama 4 Maverick

낮을수록 좋음
A: p5/H100
12
최적
D: trn2
15
📊 상세 데이터 테이블

Llama 4 Scout

시나리오ITL (ms)기준 대비
A8베이스라인
B18+125%
C22+175%
D10+25%
E14+75%

Llama 4 Maverick

시나리오ITL (ms)
A12
D15

3. 추론 처리량

초당 토큰 생성량은 시스템의 전체적인 추론 능력을 나타냅니다. 배치 처리 및 멀티 사용자 서빙 시나리오에서 중요합니다.

Llama 4 Scout

높을수록 좋음
A: p5/H100
4,200
최적
B: p4d/A100
1,800
C: g6e/L40S
1,400
D: trn2
3,500
E: inf2
2,800

Llama 4 Maverick

높을수록 좋음
A: p5/H100
2,800
최적
D: trn2
2,200
📊 상세 데이터 테이블

Llama 4 Scout

시나리오Tokens/sec기준 대비
A4,200베이스라인
B1,800-57%
C1,400-67%
D3,500-17%
E2,800-33%

Llama 4 Maverick

시나리오Tokens/sec
A2,800
D2,200

4. 동시 요청 스케일링

동시 요청 수 증가에 따른 처리량 변화를 측정합니다. HBM 메모리 대역폭과 가속기 인터커넥트가 스케일링 특성을 결정합니다.

동시 요청 스케일링 (Llama 4 Scout)

동시 요청 수에 따른 처리량 (tokens/sec)
동시 요청 수A: p5/H100B: p4d/A100C: g6e/L40SD: trn2E: inf2
14,2001,8001,4003,5002,800
414,8005,6004,20012,5009,800
824,5008,4006,80021,00016,200
1635,20011,2008,50030,80022,400
3242,00012,8009,20038,50028,000
* 메모리 대역폭 및 연산 경합으로 인해 처리량이 비선형적으로 증가
📊 상세 데이터 테이블
동시 요청A: p5/H100B: p4d/A100C: g6e/L40SD: trn2E: inf2
14,2001,8001,4003,5002,800
414,8005,6004,20012,5009,800
824,5008,4006,80021,00016,200
1635,20011,2008,50030,80022,400
3242,00012,8009,20038,50028,000

5. 비용 효율성

토큰당 비용($/1M tokens)은 인스턴스 시간당 비용을 처리량으로 나누어 산출합니다. 프로덕션 서빙에서 가장 중요한 의사결정 지표입니다.

비용 효율성 ($/1M 토큰)Llama 4 Scout

낮을수록 좋음
A: p5/H100
$0.85
B: p4d/A100
$0.72
C: g6e/L40S
$0.52
D: trn2
$0.35
E: inf2
$0.28
최고 비용 효율
시나리오시간당 비용처리량$/1M 토큰
A: p5/H100$98.324,200$0.85
B: p4d/A100$21.961,800$0.72
C: g6e/L40S$54.911,400$0.52
D: trn2$45.003,500$0.35
E: inf2$12.892,800$0.28

Llama 4 Maverick$/1M 토큰

시나리오시간당 비용처리량$/1M 토큰
A: p5/H100$98.322,800$1.28
D: trn2$45.002,200$0.74
📊 상세 데이터 테이블

Llama 4 Scout

시나리오시간당 비용처리량$/1M tokens기준 대비
A$98.324,200$0.85베이스라인
B$21.961,800$0.72-15%
C$54.911,400$0.52-39%
D$45.003,500$0.35-59%
E$12.892,800$0.28-67%

분석 및 주요 발견

토큰당 비용 58-67% 절감

AWS 커스텀 실리콘(Trainium2, Inferentia2)은 Llama 4 Scout 추론에서 NVIDIA H100 대비 58-67% 낮은 토큰당 비용을 제공합니다.

$0.28 (inf2) vs $0.85 (H100)
H100이 원시 속도에서 선두

p5.48xlarge(H100)은 가장 낮은 TTFT(120ms)와 가장 높은 처리량(4,200 tokens/sec)을 달성하여 지연 민감 워크로드에 이상적입니다.

120ms TTFT, 4,200 tokens/sec
Trainium2는 성능과 비용 균형 제공

trn2.48xlarge은 H100 처리량의 83%를 토큰당 비용 41%로 달성하여, 일반 프로덕션 워크로드에 최적의 성능 대비 비용 비율을 제공합니다.

3,500 tokens/sec at $0.35/1M tokens
MoE로 단일 GPU 배포 가능

Llama 4 Scout의 MoE 아키텍처(109B 중 17B 활성)는 단일 H100 GPU에서 배포가 가능하며, 유사한 활성 파라미터 수의 Dense 모델과 비슷한 성능을 유지합니다.

109B params, only 17B active per token
H100은 부하 시 3.2배 확장성

32개 동시 요청에서 p5/H100은 42,000 tokens/sec를 달성하며 g6e/L40S의 9,200 대비 4.6배 격차가 나타납니다. HBM 대역폭 이점으로 동시 부하에서 격차가 더 확대됩니다.

42,000 vs 9,200 tokens/sec @32 concurrent

GPU vs Custom Silicon 트레이드오프

관점GPU (H100/A100/L40S)Custom Silicon (trn2/inf2)
성능최고 원시 성능 (H100)H100의 67-83% 수준
비용높음 ($0.52-$0.85/1M tokens)낮음 ($0.28-$0.35/1M tokens)
에코시스템CUDA, 광범위한 라이브러리Neuron SDK, AWS 종속
유연성모든 프레임워크 지원vLLM/Neuron 지원 모델 한정
스케일링NVSwitch 고대역폭NeuronLink, 대규모 클러스터
가용성제한적 (수요 > 공급)상대적으로 용이

MoE 아키텍처 성능 영향

Llama 4의 MoE 아키텍처는 추론 성능에 다음과 같은 영향을 미칩니다:

  1. 메모리 대역폭 병목: Expert 가중치 로드가 빈번하여 HBM 대역폭이 핵심 병목
  2. 동적 라우팅 오버헤드: 토큰별 Expert 선택에 추가 연산 소요
  3. 불균형 Expert 활성화: 특정 Expert에 부하 집중 시 병렬 효율 저하 가능
  4. KV Cache 최적화: MoE의 희소 활성화로 KV Cache 효율이 Dense 모델 대비 유리

워크로드별 권장사항

워크로드 특성권장 시나리오근거
개발/스테이징, 소규모E: inf2최저 비용 $0.28/1M 토큰
지연 민감 (금융, 실시간)A: p5/H100120ms TTFT, 8ms ITL
일반 프로덕션D: trn2최고 성능/비용 비율, H100 대비 83% 속도
대규모 배치 처리D: trn241% 비용으로 높은 처리량
예산 제약 프로덕션E: inf2H100 대비 67% 비용 절감
Maverick (400B) 서빙A: p5/H100 or D: trn2400B MoE를 위한 충분한 메모리
멀티 모델 서빙C: g6e/L40S48GB/GPU, 여러 소형 모델에 적합
A: p5/H100
지연 민감/최대 성능
복잡도: 낮음
성능: 최대
비용: 매우 높음
D: trn2
일반 프로덕션
복잡도: 중간 (Neuron SDK)
성능: 높음
비용: 낮음
E: inf2
비용 최적화/개발/스테이징
복잡도: 중간 (Neuron SDK)
성능: 중상
비용: 최저
C: g6e/L40S
멀티 모델/예산 GPU
복잡도: 낮음
성능: 보통
비용: 중간

시나리오 선택 가이드

워크로드 요구사항 확인
├── 최저 지연시간 필요? ──→ A: p5/H100 (120ms TTFT)
├── 최저 비용 우선? ──→ E: inf2 ($0.28/1M tokens)
├── 성능/비용 균형? ──→ D: trn2 (83% 성능, 41% 비용)
├── Maverick (400B) 서빙? ──→ A: p5/H100 또는 D: trn2
├── 멀티 모델 서빙? ──→ C: g6e/L40S (48GB/GPU)
└── 기존 GPU 인프라? ──→ B: p4d/A100 (비용 효율적 GPU)

구성 시 주의사항

vLLM 배포 설정

Llama 4 Scout (GPU 시나리오):

vllm serve meta-llama/Llama-4-Scout-17B-16E \
--tensor-parallel-size 8 \
--max-model-len 1000000 \
--dtype bfloat16

Llama 4 Scout (Neuron/Trainium2):

vllm serve meta-llama/Llama-4-Scout-17B-16E \
--device neuron \
--tensor-parallel-size 16 \
--max-model-len 1000000

Neuron SDK 호환성 주의사항

Neuron SDK 버전 관리
  • Trainium2/Inferentia2 사용 시 AWS Neuron SDK 2.x 이상 필요
  • vLLM의 Neuron 백엔드는 별도 설치 필요: pip install vllm[neuron]
  • 모든 Llama 4 모델이 Neuron에서 검증된 것은 아님 — 공식 호환 목록 확인 필요
  • FP8 양자화는 GPU 시나리오에서만 지원 (Maverick)

비용 최적화 전략

  1. Spot 인스턴스 활용: 배치 추론 워크로드에서 50-70% 비용 절감 (중단 허용 시)
  2. EC2 Capacity Blocks: Trainium2 인스턴스의 예약 할당으로 안정적 가용성 확보
  3. 오토스케일링: Karpenter + KEDA 기반 GPU 메트릭 스케일링 (상세: GPU 리소스 관리)
  4. 모델 양자화: FP8/INT8 양자화로 메모리 사용량 감소 및 처리량 향상

참고 자료

데이터 신뢰성 안내

본 벤치마크의 수치는 Meta, AWS, NVIDIA, vLLM 프로젝트에서 공개한 사양 및 벤치마크 데이터를 기반으로 한 추정치입니다. 실제 성능은 워크로드 특성, 입력 길이, 배치 크기, 모델 구성에 따라 달라질 수 있습니다. 프로덕션 배포 전 실제 환경에서의 벤치마크를 권장합니다.