LLM 서버용 GPU를 비교하면 가장 먼저 눈에 들어오는 숫자는 FLOPS다.
새 세대 GPU일수록 연산 성능이 높고 벤치마크 그래프도 화려하다. 그래서 자연스럽게 “가장 빠른 GPU가 가장 좋은 선택”이라고 생각하기 쉽다.
하지만 실제 추론 서버에서는 그보다 먼저 물어야 할 질문이 있다.
모델이 VRAM에 들어가는가?
원하는 context length를 감당하는가?
동시 요청을 몇 개 처리해야 하는가?
decode가 memory bandwidth에 묶이지 않는가?
24시간 운영 조건을 만족하는가?이 질문에 답하지 않은 채 FLOPS만 비교하면 실제 workload와 맞지 않는 GPU를 고를 수 있다.
1. 가장 먼저 모델 메모리부터 계산한다
모델 weight가 차지하는 메모리는 대략 다음 요소의 영향을 받는다.
parameter count
×
precision하지만 실제 inference 메모리는 weight만으로 끝나지 않는다.
추가로 다음이 필요하다.
- KV cache
- CUDA context
- runtime workspace
- batching buffer
- allocator fragmentation
- framework overhead
즉:
VRAM requirement
=
model weight
+ KV cache
+ runtime overhead
+ safety margin으로 생각하는 편이 낫다.
2. KV Cache는 context와 concurrency에 따라 커진다
LLM 서버에서 예상보다 빨리 VRAM이 부족해지는 대표 원인이 KV cache다.
KV cache는 대략 다음 요소에 영향을 받는다.
context length
×
batch/concurrency
×
model architecture실제 메모리 사용량은 GQA/MQA 같은 attention 구조, KV cache dtype, paged attention 구현, serving framework에 따라 크게 달라질 수 있다. 따라서 이 식은 용량을 가늠하는 방향성이지 정확한 산식으로 사용하면 안 된다.
예를 들어 한 명이 긴 context를 쓰는 환경과 여러 사용자가 동시에 짧은 요청을 보내는 환경은 같은 모델이어도 메모리 요구량이 다르다.
따라서 GPU 선택 전에 workload를 먼저 정해야 한다.
Single-user long context?
Multi-user chat?
Batch inference?
Agent workload?3. 모델이 한 장에 들어가는 것이 생각보다 큰 장점이다
큰 모델을 한 GPU에 올릴 수 있으면 운영이 단순해진다.
Tensor Parallel 필요 감소
Interconnect 의존성 감소
프로세스 구성 단순화
장애 지점 감소그래서 경우에 따라 최신 고성능 GPU 두 장보다 대용량 VRAM GPU 한 장이 더 실용적일 수 있다.
특히 개발·연구 환경에서는 구성 단순성이 상당한 장점이다.
4. Prefill과 Decode는 병목이 다르다
LLM inference는 크게 보면 두 단계로 생각할 수 있다.
Prefill
입력 prompt를 처리한다.
상대적으로 연산량이 많고 compute 성능의 영향을 크게 받을 수 있다.
Decode
토큰을 한 개씩 생성한다.
이 단계는 모델 weight를 계속 읽기 때문에 memory bandwidth 영향을 크게 받을 수 있다.
따라서 peak FLOPS가 높다고 decode throughput까지 같은 비율로 높아지는 것은 아니다.
5. Memory Bandwidth를 같이 봐야 하는 이유
토큰 생성 단계에서는 모델 parameter를 메모리에서 반복적으로 읽는다.
그래서 비교 시 다음도 중요하다.
HBM / GDDR bandwidth
memory bus
VRAM capacity특히 큰 모델과 낮은 batch size에서는 memory bandwidth가 성능을 좌우하는 경우가 많다.
6. Datacenter GPU와 Workstation GPU의 기준은 다르다
단순 성능만 보면 workstation GPU가 매우 매력적인 경우가 있다.
하지만 datacenter GPU는 다른 가치를 가진다.
장시간 연속 운영
서버용 cooling과 폼팩터
driver lifecycle
virtualization / MIG 파티셔닝
multi-user 환경
고대역 interconnect
지원 체계여기서 ECC를 datacenter의 차별점으로 꼽지 않은 것은 의도적이다. ECC가 갈리는 선은 datacenter와 workstation 사이가 아니라 프로용과 소비자용 사이다. 프로용 workstation 카드도 ECC 메모리를 다는 경우가 많다. ECC 유무로 등급을 판단하려면 카드 등급이 아니라 그 카드의 실제 스펙시트를 봐야 한다.
반면 workstation GPU는:
큰 단일 VRAM
상대적으로 단순한 구축
개발/추론 겸용
워크스테이션 활용에 강점이 있다.
어느 쪽이 “더 좋다”가 아니라 workload에 따라 기준이 달라진다.
7. Peak benchmark보다 실제 workload benchmark
GPU 구매 전에 가능하면 실제 모델로 측정하는 편이 가장 좋다.
확인할 항목은 단순 token/s 하나가 아니다.
model load 성공 여부
first-token latency
decode tokens/s
동시 요청 처리량
VRAM peak
GPU utilization
전력 소비
장시간 안정성특히 Agent나 RAG 서버라면 평균 token/s보다 first-token latency와 동시성이 더 중요할 수 있다.
8. GPU 선택 순서
실무적으로는 다음 순서가 유용하다.
1. 운영할 모델과 quantization 결정
2. 최대 context 결정
3. 목표 concurrency 결정
4. 필요한 VRAM 계산
5. memory bandwidth 비교
6. 운영 안정성 조건 확인
7. 실제 inference benchmark
8. 가격/전력/확장성 비교FLOPS는 이 과정의 한 항목일 뿐이다.
흔한 실수
“VRAM이 모델 파일보다 크면 된다”
KV cache와 runtime overhead를 빼먹은 계산이다.
“새 GPU니까 무조건 빠르다”
workload에 따라 memory bandwidth와 software stack이 더 중요할 수 있다.
“token/s가 가장 높은 GPU가 최고다”
동시성, latency, 안정성, 전력까지 함께 봐야 한다.
결론
LLM 서버용 GPU 선택은 “가장 빠른 GPU”를 고르는 문제가 아니다.
정확한 질문은 이것이다.
내가 운영하려는 모델, context, concurrency, latency 목표를 가장 안정적으로 만족하는 GPU는 무엇인가?
그래서 비교 순서는 보통 다음이 맞다.
VRAM
→ KV cache
→ Memory Bandwidth
→ Concurrency
→ 운영 안정성
→ ComputeFLOPS는 중요하지만 첫 번째 질문은 아니다.