70B 모델 서빙에 GPU가 몇 장 필요할까? VRAM·KV Cache 산정 가이드
핵심 요약: LLM 서빙 GPU 산정의 출발점은 연산 속도가 아니라 메모리(VRAM)예요. 모델 가중치는 BF16 기준 파라미터당 2바이트로 어림하면 70B 모델은 가중치만 약 140GB고, 여기에 동시 사용자 수와 문맥 길이에 비례해 커지는 KV Cache를 더해야 해요. 산정은 어디까지나 어림이라, 실제 워크로드 기준 검증이 꼭 필요해요.
"70B 모델을 사내에 띄우려면 GPU가 몇 장 필요한가요?" 저희가 AI 인프라 상담에서 가장 자주 받는 질문이에요. 그런데 이 질문에 바로 숫자로 답하기는 어려워요. 같은 70B 모델이라도 동시 사용자가 10명인지 1,000명인지, 문맥 길이가 4K인지 128K인지에 따라 필요한 GPU 수가 완전히 달라지거든요.
이 글에서는 LLM 서빙 GPU를 산정할 때 무엇을 계산해야 하는지, 기초부터 차근차근 정리했어요. 수식은 최소한으로 줄이고, 어림 계산 감각을 잡는 데 집중할게요.
왜 연산 속도가 아니라 메모리부터 보나요?
GPU를 고를 때 흔히 연산 성능(FLOPS)부터 비교하지만, LLM 추론에서는 메모리가 먼저예요.
식당에 비유하면 이해가 쉬워요. 주방(연산 능력)이 아무리 빨라도 좌석(메모리)이 없으면 손님을 받을 수 없어요. LLM 추론은 모델 전체가 GPU 메모리에 올라가 있어야 시작할 수 있고, 손님(사용자)이 한 명 올 때마다 좌석(KV Cache)이 추가로 필요해요. 좌석이 다 차면 주방이 놀고 있어도 손님은 줄을 서야 하죠.
그래서 LLM 서빙 사이징의 첫 질문은 "이 GPU가 얼마나 빠른가"가 아니라 "이 GPU에 무엇이 얼마나 들어가는가"예요.
VRAM을 차지하는 세 가지
GPU 메모리에는 크게 세 가지가 올라가요.
| 항목 | 성격 | 크기를 결정하는 것 |
|---|---|---|
| 모델 가중치 | 고정. 보통 가장 큼 | 파라미터 수 × 정밀도(파라미터당 바이트) |
| KV Cache | 변동. 트래픽 따라 증감 | 동시 사용자 수 × 문맥 길이 |
| Activation·오버헤드 | 고정에 가까움 | 프레임워크 버퍼, CUDA 컨텍스트 등 |
집으로 비유하면 가중치는 붙박이 가구예요. 입주할 때 한 번 들어가면 자리를 계속 차지해요. KV Cache는 손님이 올 때마다 늘어나는 짐이에요. 손님이 많아지고 머무는 시간(문맥)이 길어질수록 계속 쌓여요. Activation과 오버헤드는 복도나 창고처럼 기본으로 빠져나가는 공간이고요.
산정할 때는 이 세 가지를 더한 값이 GPU 메모리 총량 안에 여유 있게 들어가야 해요.
가중치 메모리 어림 계산: 파라미터당 2바이트
모델 가중치 메모리는 의외로 간단하게 어림할 수 있어요. 요즘 서빙에서 기본으로 쓰는 BF16(16비트) 정밀도 기준으로 파라미터 하나가 2바이트를 차지해요.
- 7B 모델: 7B × 2바이트 = 약 14GB
- 13B 모델: 13B × 2바이트 = 약 26GB
- 70B 모델: 70B × 2바이트 = 약 140GB
70B 모델은 가중치만 약 140GB예요. 메모리가 가장 큰 축에 드는 H200(141GB)에 겨우 들어가는 크기인데, 가중치만으로 꽉 차면 KV Cache를 둘 공간이 없어서 실제 서빙은 불가능해요. 그래서 여유분을 고려하면 H200 2장에 나눠 싣는 식의 구성이 어림 계산의 출발점이 돼요. 2장이면 합계 282GB니까, 가중치 140GB를 빼고도 KV Cache와 오버헤드에 쓸 공간이 남죠.
이게 "70B는 GPU 몇 장?"이라는 질문에 대한 첫 번째 어림 답이에요. 다만 어디까지나 최소 기준선이고, 실제 장수는 다음 항목인 KV Cache가 결정해요.
KV Cache: 동시 사용자와 문맥 길이가 메모리를 먹어요
LLM은 토큰을 하나씩 생성하면서 이전 토큰들의 Key·Value 값을 계속 참조해요. 매번 처음부터 다시 계산하면 너무 느리니까, 한 번 계산한 값을 GPU 메모리에 저장해 두는데 이게 KV Cache예요.
회의록에 비유하면, 참석자(사용자)마다 자기 회의의 회의록(KV Cache)을 한 권씩 펼쳐 두는 셈이에요. 회의가 길어질수록(문맥 길이) 회의록이 두꺼워지고, 동시에 진행되는 회의가 많아질수록(동시 사용자) 펼쳐 둘 회의록 수가 늘어나요.
그래서 KV Cache 크기는 대략 이렇게 움직여요.
- 동시 사용자가 2배가 되면 KV Cache도 대략 2배
- 문맥 길이가 2배가 되면 사용자당 KV Cache도 대략 2배
- 모델이 클수록(레이어 수·히든 크기) 토큰당 KV Cache도 커짐
문맥이 수만 토큰을 넘는 장문맥 서비스에서는 KV Cache가 모델 가중치에 맞먹는 수준까지 커지기도 해요. "모델은 올라갔는데 사용자를 몇 명 못 받는" 상황은 대부분 여기서 생겨요.
여기서 감각을 잡아 두면 좋은 게 하나 있어요. 가중치는 사용자가 0명이든 1,000명이든 크기가 같지만, KV Cache는 트래픽이 몰리는 시간대에만 급격히 커져요. 그래서 사이징을 할 때는 평균 트래픽이 아니라 피크 시간대의 동시 요청 수를 기준으로 잡아야 해요. 평균만 보고 좌석을 준비하면 점심시간마다 손님을 돌려보내는 식당이 되는 거죠.
장문맥·고동시성이면 병목은 메모리예요
정리하면, LLM 서빙에서 GPU 장수를 결정하는 건 연산 능력보다 메모리 총량인 경우가 많아요. 특히 문서 요약, RAG, 사내 Assistant처럼 긴 문맥을 다루는 서비스나 동시 접속이 많은 서비스라면 연산은 남는데 메모리가 모자라 동시 처리 수가 제한되는 그림이 나와요.
메모리가 부족하면 요청이 대기열에 쌓이고, 사용자 입장에서는 첫 토큰이 나올 때까지의 대기 시간이 길어져요. GPU 사용률 그래프만 보면 여유가 있어 보이는데 체감 품질은 나쁜, 진단하기 까다로운 상태가 되죠.
저희는 이런 이유로 "GPU 몇 장"보다 먼저 서비스의 동시 사용자 수, 문맥 길이, 응답 속도 목표를 확인해요. 이 값들이 잡혀야 메모리 소요가 나오고, 그다음에 장수가 나오거든요. 이런 접근 방식은 AI·GPU 인프라 사업 소개에서 더 자세히 확인할 수 있어요.
메모리가 부족할 때의 대응 방향
필요한 메모리가 GPU 한 장을 넘어가면, 크게 두 가지 방향으로 대응해요. 여기서는 개념만 잡을게요.
양자화(Quantization): 파라미터당 바이트 수를 줄이는 방법이에요. BF16(2바이트)을 FP8(1바이트)이나 INT4(0.5바이트)로 낮추면 같은 모델의 가중치 메모리가 절반, 4분의 1로 줄어요. 짐을 압축팩에 넣어 부피를 줄이는 셈이죠. 다만 압축 과정에서 품질이 미세하게 달라질 수 있어서, 서비스 품질 기준으로 검증한 뒤 적용하는 게 안전해요.
Tensor Parallel(모델 병렬화): 모델 하나를 여러 GPU에 쪼개 싣는 방법이에요. 위에서 본 "70B를 H200 2장에 분산"이 바로 이 방식이죠. 대신 GPU끼리 매 토큰마다 데이터를 주고받아야 해서, GPU 간 연결 속도(서버 내부의 NVLink 같은 고속 인터커넥트)가 성능을 좌우해요. 쪼개는 장수가 늘수록 통신 부담도 커지고요.
이 밖에 vLLM의 PagedAttention처럼 KV Cache를 잘게 나눠 낭비 없이 쓰는 프레임워크 기법도 있어요. 같은 GPU로도 프레임워크에 따라 수용 가능한 동시 사용자 수가 달라지는 이유예요.
GPU 메모리 스펙 비교
추론 서빙에서 자주 검토되는 GPU들의 메모리 스펙을 정리하면 이래요.
| GPU | 메모리 | 메모리 종류 | 참고 |
|---|---|---|---|
| H100 | 80GB | HBM3 | 검증된 생태계, 기존 클러스터 증설·호환에 강점 |
| H200 | 141GB | HBM3e | H100 호환 + 메모리 확대, 장문맥·메모리 집약 추론 |
| B200 | GPU당 180GB급 | HBM3e | 대형 모델 학습과 고처리량 추론을 함께 커버 |
| RTX PRO 6000 | 96GB | GDDR7 | PCIe 구성, 96GB 안에 적재되는 모델의 부서형·기업 추론 |
주의할 점이 하나 있어요. H100·H200·B200의 HGX 구성(SXM + NVSwitch)과 RTX PRO 6000 같은 PCIe 구성은 GPU 간 연결 구조가 달라서 동급으로 비교하면 안 돼요. 학습용과 추론용이라는 구분도 절대 기준이 아니고, 어디까지나 워크로드 기준으로 선택하는 거예요. 모델이 96GB 안에 들어가고 GPU 간 통신이 적은 추론이라면 PCIe 구성이 충분할 수 있고, 여러 장에 걸친 분산 추론이라면 고속 인터커넥트가 있는 구성이 필요해요.
마치며: 산정은 어림이고, 검증은 워크로드로
지금까지의 계산을 다시 정리하면 이래요.
- 가중치: 파라미터 수 × 2바이트(BF16 기준)로 어림
- KV Cache: 동시 사용자 수 × 문맥 길이에 비례해 가산
- 여유분: Activation·오버헤드와 트래픽 피크 대비 여유 확보
- 부족하면: 양자화로 줄이거나 Tensor Parallel로 나누기
다만 이 계산은 어디까지나 어림이에요. 실제 메모리 소요와 처리량은 모델 구조, 서빙 프레임워크, 트래픽 패턴에 따라 달라져서, 최종 장수는 실제 워크로드 기준의 부하 테스트로 검증해야 해요. 저희도 GPU 장수를 먼저 정하지 않고, 고객의 AI 서비스 목적과 운영 조건을 분석한 뒤에 온프레미스 GPU 서버, 클라우드, 데이터베이스, 구축·운영까지 하나의 제안으로 묶어 드리고 있어요.
사내 데이터로 LLM을 운영해야 하는 환경이라면, 보안 요건까지 함께 반영한 대기업·금융권 프라이빗 AI 페이지도 참고해 보세요.