[AI]AI 서버의 메모리 구조와 LLM 메모리 동작 원리 (양자화 등)

AI와 LLM을 공부하면서 “GPU 메모리와 시스템 메모리는 각각 어떤 역할을 할까?”라는 의문이 들었다.
처음엔 단순히 처음엔 단순히 “GPU가 빠르니까 무조건 좋겠지”라고 생각했는데,
LLM 모델을 직접 다뤄보면서 이게 그렇게 간단한 게 아니라는 걸 알게 됐다.
공부하면 할수록 두 메모리의 역할이 확실히 다르다는 걸 알게 됐다.

이 글은 내가 공부하면서 직접 정리한 내용들을 중심으로,
AI 서버의 메모리 구조와 LLM이 실제로 어떻게 메모리를 사용하는지 정리한 것이다.

 

1. GPU 메모리(VRAM)와 시스템 메모리(RAM)의 차이

일단 간단하게 말하면,

• VRAM(GPU 메모리) → 계산이 직접 일어나는 공간
• RAM(시스템 메모리) → 계산을 준비하고 관리하는 공간

이렇게 구분할 수 있다.

예를 들어 이미지를 분류하는 AI 모델이 있다고 하자.
데이터를 GPU로 바로 던지는 게 아니라,
CPU에서 먼저 데이터를 읽고 가공해서 GPU로 넘긴다.
이 중간 단계에서 RAM이 역할을 한다.

RAM은 데이터를 GPU가 쓸 수 있게 ‘정리’하고 ‘보관’하는 곳이고,
VRAM은 그걸 받아서 ‘실제로 연산’을 하는 곳이다.

즉,

RAM은 일꾼에게 도구를 정리해 주는 조수 같은 역할,
GPU는 직접 망치질을 하는 기술자 같은 역할이다.

2. 학습(Training) 과정에서 메모리의 역할

모델 학습은 GPU 위에서 돌아가지만,
데이터는 보통 한 번에 다 못 올린다.
그래서 다음처럼 흐른다.

 

[디스크] → [RAM] → [VRAM]

하드디스크(또는 SSD)에서 데이터를 읽어 RAM에 잠시 저장해두고,
RAM에서 GPU VRAM으로 일부씩 옮겨가면서 학습을 진행한다.

이 과정을 배치(batch) 단위로 반복한다.
RAM이 넉넉하면 데이터를 미리 캐싱해둘 수 있어서
GPU가 쉴 틈 없이 계속 연산할 수 있다.

RAM이 부족하면 디스크에서 직접 데이터를 읽게 되는데,
그럼 속도가 느려지고 학습 효율이 떨어진다.

그래서 GPU만큼이나 RAM 용량도 학습 성능에 영향을 준다.

3. 추론 과정에서의 메모리 흐름

학습이 끝나고 추론을 할 때도 비슷한 구조로 움직인다.
모델이 저장되어 있는 경로에서 데이터를 읽어 GPU로 전달하는데,
그 과정이 이렇게 된다.

 

[Disk] → [RAM] → [VRAM] → (결과 계산) → [RAM]

즉, 모델이 처음 로드될 때는 RAM에 올라갔다가
그 다음 GPU로 전달되어 실제 연산이 이루어진다.
GPU가 결과를 계산하면 다시 CPU로 결과가 돌아오고,
RAM에서 후처리를 거쳐 사용자에게 응답을 보낸다.

이 과정에서 RAM이 적으면
모델을 불러오는 속도나 응답이 느려질 수 있다.
특히 LLM 모델처럼 용량이 큰 모델일수록 이 차이가 커진다.

4. 모델을 올릴 때 메모리가 점점 늘어나는 이유

처음 모델을 GPU에 올리면
VRAM에는 기본적으로 “모델 파라미터(가중치)”가 올라간다.
예를 들어 모델 크기가 12GB라면
기본적으로 VRAM 12GB를 차지한다.

그런데 막상 추론을 해보면 12GB 이상을 차지한다.
그 이유는 모델이 계산을 하면서
입력 텐서, 중간 연산 결과, 출력 텐서 등이
추가로 VRAM을 쓰기 때문이다.

즉,

VRAM 사용량 = 모델 파라미터 + (입력 + 중간 계산 + 출력)

이 중간 계산값들은 추론이 끝나면 사라지지만,
요청이 많거나 동시에 여러 요청을 처리할 땐
이 임시 버퍼가 겹쳐져서 VRAM이 급격히 늘어난다.

5. 직관적으로 이해하기 list 예시

이걸 조금 더 쉽게 설명하자면,
마치 list[int] 타입 변수를 만드는 것과 비슷하다.

처음엔 int 하나라서 4byte만 차지하지만,
리스트에 데이터를 추가할수록 4byte씩 계속 늘어난다.

GPU도 이와 비슷하게,
모델을 VRAM에 올려두고 추론을 계속 수행하면
임시 텐서(입력, 출력, 중간값 등)가 늘어나면서 VRAM 사용량이 점점 커진다.

물론 실제 GPU는 이렇게 단순히 선형적으로 증가하진 않지만,
개념적으로는 이렇게 생각하면 훨씬 이해하기 쉽다.

6. max_length, batch_size, torch_dtype가 메모리에 미치는 영향

VLLM을 사용하거나 모델을 로드할 때
max_length, batch_size, torch_dtype(양자화 옵션) 값을 조정하면
메모리 사용량이 눈에 띄게 달라진다.

• max_length : 한 번에 처리할 최대 토큰 수 → 커질수록 VRAM 폭증
• batch_size : 동시에 처리할 입력 샘플 수 → 커질수록 VRAM 크게 증가
• torch_dtype : 모델 가중치 정밀도 (fp32, fp16, int8 등)

GPU는 모델을 올릴 때 단순히 가중치(weight) 만 올리는 게 아니라,
추론 중에 사용할 버퍼 공간(buffer) 도 미리 확보한다.
그래서 이런 설정값들이 VRAM 사용량에 직접적인 영향을 미친다.

7. Billion 단위 모델과 양자화(Quantization)의 이해

모델에는 3B, 8B, 16B 같은 단위가 붙는다.
여기서 B(Billion) 은 “가중치의 개수”를 뜻한다.
즉, 3B 모델은 약 30억 개의 weight를 가지고 있다는 의미다.

이제 본격적으로 양자화(Quantization) 를 살펴보자.
양자화는 단순한 압축이 아니라 정밀도(precision)를 낮춰 계산량과 메모리 사용량을 줄이는 기술이다.

딥러닝 모델은 사실상

입력 × 가중치(weight) = 출력
으로 작동하는 거대한 수치 계산기다.

그래서 가중치를 다루는 비트 수를 줄이면
모델 크기와 메모리 사용량이 함께 줄어든다.

예를 들어,
fp32 가중치는 4byte이고,
3B 모델이라면 4byte × 3,000,000,000 = 12GB를 차지한다.
하지만 GPU VRAM이 10GB밖에 없다면 로드가 불가능하다.
이럴 때 양자화를 사용하면 된다.

fp16으로 바꾸면 2byte가 되어 크기가 절반으로 줄고,
int8이면 1byte, int4면 0.5byte로 더 작아진다.

 

타입	크기	절감	비교
FP32	4byte	1x	가장 정확하지만 무거움
FP16	2byte	2x 감소	학습용으로 많이 사용
INT8	1byte	4x 감소	추론용으로 자주 사용
INT4	0.5byte	8x 감소	LLM 서빙용, 극단적 압축

8. 정밀도가 줄어드는데 정확도는 괜찮을까?

처음엔 “숫자를 줄이면 정확도가 떨어지는 거 아닌가?” 싶었는데,
실제로는 거의 차이가 없다고 한다.

예를 들어 0.8723151과 0.87231의 차이는
추론 결과에 거의 영향을 주지 않는다.
그래서 fp16, int8로 줄여도 결과값은 거의 동일하게 나온다.

9. 가중치는 -1 ~ 1인데, 어떻게 양자화시 int로 동작하지?

이 부분도 궁금해서 찾아봤는데,
정답은 스케일(scale) 이었다.

가중치를 일정한 스케일로 변환해서,
실제로는 0~255 같은 정수를 쓰지만
이를 실수 범위로 다시 환산해 근사값으로 계산한다.

예를 들어 아래처럼 계산된다고 한다.

 

scale = (float_max - float_min) / (int8_max - int8_min) = (1.0 - (-1.0)) / (127 - (-128)) = 2.0 / 255 ≈ 0.007843

이런 방식으로 int 값도 실수처럼 근사 동작하게 되는 것이다.

결국 양자화의 본질은

“모델의 수를 적은 비트로 근사 표현해서 VRAM과 계산량을 줄이는 기술”
이라고 정리할 수 있다.

---

10. 근데 왜 같은 7B 모델인데 크기가 다르지?

허깅페이스 같은 곳에서 모델을 보면
7B 모델인데 어떤 건 13GB, 어떤 건 20GB다.

앞에서 B과 모델 크기는 7B에 flaut32일 경우 28GB에 해당할 것 이다. 
이건 단순히 파라미터 수가 같다고 해서 크기도 같지 않기 때문이다.

이유는 크게 두 가지다.

1. 저장 포맷의 차이 — .safetensors, .gguf 등 저장 방식이 다르다.
2. 구조적 요소의 차이 — 레이어 개수, hidden size, embedding 구조 등이 모델마다 다르다.

또한 모델 파일에는 weight 외에도

• 옵티마이저 상태
• 학습 통계 (running mean, variance)
• 토크나이저 정보
• 메타데이터(config, dtype, version 등)
  이런 정보들이 함께 포함되기 때문에 실제 크기는 달라질 수 있다.