GPU가 몇 장 필요한지 묻기 전에
AI 인프라 구성에 관한 발표 자료를 검토하면서, 모델에 따라 GPU 자원을 어떻게 산정하는지 설명하는 부분이 필요하다고 느꼈다. CPU, GPU, 스토리지 같은 구성 요소를 나열하는 것에서 한 걸음 더 나아가, 실제 사용할 모델과 서비스 조건을 연결해 설명하면 좋겠다는 생각이었다.
LLM 추론 환경을 준비할 때 먼저 떠오르는 질문도 비슷하다.
이 모델을 쓰려면 GPU가 몇 장 필요한가요?
모델 이름과 파라미터 수만으로는 답하기 어렵다. 모델을 메모리에 올릴 수 있는지, 여러 사람이 사용할 때 원하는 속도가 나오는지는 각각 확인해야 하기 때문이다.
이 글에서는 이미 학습된 LLM을 실행하는 추론 서비스를 기준으로, GPU 산정에 필요한 항목을 정리한다. 학습이나 파인튜닝에는 추가 메모리가 필요하므로 아래 계산을 그대로 적용하지 않는다.
먼저 서비스 조건을 적어보기
GPU 제품을 비교하기 전에 다음과 같은 조건부터 정리한다. 아래 값은 설명을 위한 가상 사례다.
| 항목 | 예시 | 필요한 이유 |
|---|---|---|
| 업무 | 내부 문서 질의응답 | 요구되는 답변 품질과 입력 형태를 정하기 위해 |
| 모델 | 70B 파라미터 모델 | 가중치 메모리를 추정하기 위해 |
| 가중치 형식 | BF16 또는 4bit 양자화 | 용량·품질·실행 지원 여부를 비교하기 위해 |
| 입력 길이 | 보통 2,000토큰, 긴 요청 8,000토큰 | 문서와 대화 이력이 차지하는 부하를 보기 위해 |
| 출력 길이 | 보통 500토큰 | 생성 시간과 처리량을 추정하기 위해 |
| 동시 처리 | 최대 8개 요청 | 한 번에 유지할 요청 상태를 산정하기 위해 |
| 응답 목표 | 첫 응답 3초 이내 | 실제 사용성을 판단하기 위해 |
여기서 동시 처리는 가입자 수와 다르다. 사용자가 100명이어도 동시에 생성 중인 요청은 적을 수 있고, 반대로 Agent 하나가 여러 모델 요청을 발생시킬 수도 있다. 산정에는 서비스에서 실제로 발생할 요청 패턴을 사용해야 한다.
NVIDIA의 추론 참조 아키텍처도 워크로드별로 모델, 동시성, 입력·출력 형태, 캐시 정책과 하드웨어 구성을 함께 기록하도록 안내한다. NVIDIA Inference Reference Architecture
1. 모델 가중치 메모리부터 계산하기
가장 간단한 출발점은 다음 식이다.
1
가중치 메모리 ≈ 파라미터 수 × 파라미터당 저장 바이트
FP32는 값 하나에 4바이트, FP16과 BF16은 2바이트를 사용한다. 8bit는 1바이트, 4bit는 이론적으로 0.5바이트다. 모델 크기 추정 도구에서도 데이터 형식에 따른 메모리를 비교할 수 있다. Hugging Face 모델 크기 추정 문서
| 파라미터 수 | FP32 | FP16 / BF16 | 8bit | 4bit |
|---|---|---|---|---|
| 8B | 32GB | 16GB | 8GB | 4GB |
| 32B | 128GB | 64GB | 32GB | 16GB |
| 70B | 280GB | 140GB | 70GB | 35GB |
이 표는 가중치만 계산한 이론값이다. 단위는 10억 바이트를 1GB로 계산했다. 도구에서 사용하는 GiB는 2³⁰바이트이므로 같은 바이트 수라도 표시되는 숫자가 다르다.
예를 들어 70B 모델을 FP16으로 저장하면 다음과 같다.
1
2
3
4
70,000,000,000 × 2바이트
= 140,000,000,000바이트
= 140GB
≈ 130.4GiB
실제 모델에는 양자화 스케일 등의 부가 정보와 다른 정밀도로 유지되는 부분이 있을 수 있다. 따라서 “70B 4bit이므로 정확히 35GB만 있으면 된다”는 의미는 아니다. 실제 배포할 모델 파일과 런타임의 로딩 결과로 확인해야 한다.
2. 모델 외에 KV Cache와 실행 공간이 필요하다
추론 시에는 다음 토큰을 생성하기 위한 상태와 연산 공간도 메모리에 들어간다.
1
2
3
4
5
GPU 메모리 사용량
≈ 모델 가중치
+ KV Cache
+ 활성값과 연산용 임시 공간
+ 런타임 메모리
KV Cache는 이전 토큰에서 계산한 Key와 Value를 저장해 재사용하는 공간이다. 일반적인 전체 어텐션 모델에서는 유지하는 토큰이 많아질수록 캐시도 커진다. 캐시의 양자화나 CPU 오프로딩 같은 전략도 있지만, 메모리 절약과 처리 성능 사이의 영향을 함께 살펴야 한다. Hugging Face KV Cache 문서
그래서 같은 모델이라도 다음 조건에 따라 메모리 사용량이 달라진다.
- 짧은 질문과 긴 문서를 포함한 질문
- 대화 이력이 거의 없는 요청과 긴 대화를 유지하는 요청
- 하나의 요청과 여러 요청을 동시에 생성하는 경우
- 가중치와 KV Cache에 적용하는 각각의 저장 형식
특히 가중치를 4bit로 바꿨다고 KV Cache도 자동으로 4bit가 되는 것은 아니다. 둘은 별도 설정과 지원 여부를 확인해야 한다.
단순한 KV Cache 계산 예시
일반적인 Transformer가 모든 레이어의 Key와 Value를 저장한다고 가정하면, 다음 식으로 대략적인 크기를 계산할 수 있다.
1
2
3
KV Cache 바이트
≈ 2 × 레이어 수 × KV 헤드 수 × 헤드 차원
× 저장 토큰 수 × 동시 시퀀스 수 × 원소당 바이트
여기서 헤드 수는 전체 Query 헤드 수가 아니라 KV 헤드 수다. 다음은 특정 제품의 실측이 아닌 가상의 모델 구조다.
| 항목 | 가정 |
|---|---|
| 레이어 수 | 32 |
| KV 헤드 수 | 8 |
| 헤드 차원 | 128 |
| 요청당 저장 토큰 수 | 8,192 |
| 동시 시퀀스 수 | 8 |
| KV 저장 형식 | FP16, 2바이트 |
1
2
3
2 × 32 × 8 × 128 × 8192 × 8 × 2
= 8,589,934,592바이트
= 8GiB
이 가정에서 시퀀스 하나는 1GiB, 8개는 8GiB다. 요청마다 길이가 다르면 각 요청의 토큰 수를 합산해서 계산한다. 입력뿐 아니라 생성되어 캐시에 남는 출력 토큰도 포함한다.
실제 엔진의 캐시 예약 방식, 공유되는 프리픽스, 슬라이딩 윈도우, 모델의 어텐션 구조 등에 따라 달라질 수 있으므로 이 식은 구조를 이해하기 위한 근사치로 사용한다. 앞의 70B 모델에 이 가상 구조를 그대로 대입해서는 안 된다.
3. GPU 메모리 용량과 대역폭을 나눠서 보기
HBM은 여러 데이터센터 GPU에서 사용하는 고대역폭 메모리다. 모든 GPU가 HBM을 사용하는 것은 아니며, 제품에 따라 GDDR 계열 메모리를 사용하기도 한다.
메모리 사양을 볼 때는 용량과 대역폭을 구분한다.
| 항목 | 확인할 질문 |
|---|---|
| 메모리 용량 | 모델, 캐시, 실행 공간을 담을 수 있는가? |
| 메모리 대역폭 | 연산에 필요한 데이터를 얼마나 빠르게 공급할 수 있는가? |
| 연산 성능 | 해당 정밀도의 계산을 얼마나 빠르게 처리하는가? |
추론 과정에서도 입력을 처리하는 Prefill과 토큰을 이어서 생성하는 Decode의 특성이 다르다. 긴 입력의 Prefill은 많은 연산을 요구하고, 작은 배치의 Decode에서는 가중치를 읽는 메모리 대역폭이 중요한 병목이 될 수 있다. 배치 크기와 모델 구조에 따라 병목은 바뀌므로, 용량이나 연산 성능 한 가지 수치로 속도를 단정하지 않는다. NVIDIA LLM Inference Sizing 자료
4. 여러 GPU를 쓴다면 연결 구조도 확인하기
70B FP16 가중치의 이론값은 140GB다. GPU당 메모리가 80GB라면 한 장에 가중치를 모두 올릴 수 없으므로 모델 분산이나 오프로딩 같은 방식을 검토하게 된다.
하지만 “80GB 두 장이면 총 160GB이니 충분하다”로 결론 내리면 곤란하다. 각 GPU에 실제로 배치되는 가중치, 캐시, 임시 공간을 확인해야 하고, 모델과 엔진이 해당 분산 구성을 지원해야 한다.
1
2
3
4
5
6
7
모델을 여러 GPU에 분산
↓
각 GPU에 모델의 일부 배치
↓
추론 중 GPU 사이에 데이터 전달
↓
연결 대역폭과 지연이 성능에 영향
| 연결 요소 | 역할 |
|---|---|
| PCIe | CPU·GPU 등 장치 사이의 데이터 전송 경로 |
| NVLink | 지원되는 GPU 등의 장치 사이에 고대역폭 연결 제공 |
| NVSwitch | 여러 GPU의 NVLink 통신을 연결하는 스위치 |
Tensor Parallelism처럼 모델 계산을 분할하는 방식은 GPU 사이에 통신을 발생시킨다. 따라서 GPU 수뿐 아니라 서버의 연결 구조와 병렬화 방식이 중요하다. NVIDIA NVLink·NVSwitch 추론 설명
NVLink가 있다고 GPU 메모리가 모든 프로그램에서 자동으로 하나의 메모리처럼 사용되는 것은 아니다. 실제 메모리 배치와 통신은 소프트웨어의 지원에 달려 있다. 반대로 PCIe만으로도 실행 가능한 구성이 있으며, 원하는 처리량과 지연을 만족하는지는 측정으로 판단한다.
또한 모델을 분할하는 것과 완전한 모델을 여러 벌 복제하는 것은 다르다. 모델이 한 GPU에 들어간다면 여러 GPU에 복제본을 두고 요청을 분산하는 구성도 비교할 수 있다.
5. 모델이 올라간 다음에는 서비스 부하를 측정하기
한 명이 짧게 질문했을 때 답이 나오는 것만으로 운영 규모를 정할 수는 없다. 서비스에서 예상하는 입력 길이와 요청 수를 넣어 측정한다.
| 지표 | 의미 | 확인할 부분 |
|---|---|---|
| TTFT | 요청 후 첫 토큰을 받기까지의 시간 | 처음 응답이 나타나는 속도 |
| ITL | 생성되는 토큰 사이의 시간 간격 | 답변이 이어지는 속도 |
| 전체 응답 시간 | 요청부터 생성 완료까지의 시간 | 업무 한 건을 끝내는 시간 |
| 처리량 | 단위 시간당 처리 요청 또는 토큰 수 | 전체 서비스가 감당하는 양 |
| 메모리 사용량·실패율 | 피크 사용량, OOM과 요청 실패 | 부하가 몰렸을 때의 안정성 |
측정 도구마다 집계 방식이 다를 수 있으므로 정의도 함께 기록한다. NVIDIA 추론 벤치마크 지표 문서
예를 들어 다음과 같은 조합을 시험할 수 있다. 아래는 측정 계획 예시이며 성능 결과가 아니다.
| 구분 | 입력 토큰 | 최대 출력 토큰 | 동시 요청 |
|---|---|---|---|
| 짧은 질의 | 1,000 | 300 | 1 / 4 / 8 |
| 문서 질의 | 4,000 | 500 | 1 / 4 / 8 |
| 긴 문서 질의 | 8,000 | 1,000 | 1 / 4 / 8 |
최대 출력 설정만 기록하지 말고 실제 생성된 토큰 수도 남긴다. 평균 외에 p95처럼 느린 요청을 보여주는 지표를 함께 보면, 일부 사용자가 오래 기다리는 상황을 파악하기 쉽다.
캐시가 없는 첫 요청과 캐시를 활용하는 요청, 서버 준비 직후와 안정화 이후도 구분한다. 가능하다면 일정 동시성 테스트 외에 피크 시간대의 요청 도착 패턴도 재현해본다.
실제 산정은 이렇게 진행하면 된다
- 업무와 품질 기준을 정한다. 사용할 모델과 양자화 수준에서 원하는 답변 품질이 나오는지 확인한다.
- 가중치 메모리를 계산한다. 파라미터 수와 저장 형식으로 초기 후보를 좁힌다.
- 캐시와 실행 공간을 더한다. 입력·출력 길이, 동시 시퀀스, 런타임 조건을 반영한다.
- 단일 GPU·분산·복제 구성을 비교한다. 실제 GPU별 메모리 배치와 연결 구조를 확인한다.
- 대표 업무로 부하를 측정한다. 첫 응답, 생성 속도, 처리량, 실패율을 함께 본다.
- 운영 여유를 반영한다. 피크 부하, 다른 프로세스, 모델 변경, 장애·점검 시 필요한 용량을 포함한다.
메모리 여유를 무조건 일정 비율로 더하는 것보다, 실제 최대 길이 요청과 피크 부하에서 어느 정도를 사용하는지 확인하는 편이 산정 근거를 설명하기 좋다.
GPU 산정에서 처음 계산하는 것은 모델의 크기지만, 최종적으로 결정해야 하는 것은 원하는 품질과 응답 속도로 업무를 처리할 수 있는 구성이다. 모델과 정밀도에서 시작해 메모리, 연결 구조, 실제 서비스 부하까지 이어서 확인해야 GPU 수량의 근거를 만들 수 있다.