로컬 LLM 돌릴 때 VRAM 계산하는 법: 모델이 GPU에 들어가는지 한 방에 보는 공식

로컬 LLM VRAM 계산은 이 공식에서 시작함

• 글의 핵심 공식은 꽤 단순함

  • VRAM(GB) ≈ 파라미터 수(십억 단위) × (가중치당 유효 비트 ÷ 8)
  • 예를 들어 7B 모델을 4비트로 올리면 대략 7 × 4 ÷ 8 = 3.5GB가 가중치에 필요하다는 계산이 나옴

• 이 공식이 FP16, BF16, FP8, INT8, GPTQ, AWQ, NF4, GGUF 변형까지 큰 틀에서 설명해줌

  • FP16/BF16은 16비트라 1B 파라미터당 약 2GB
  • FP8/INT8은 8비트라 1B 파라미터당 약 1GB
  • 4비트 양자화는 1B 파라미터당 약 0.5GB

• 기억할 건 세 줄이면 됨

  • FP16은 모델 파라미터 크기의 대략 2배
  • FP8은 대략 1배
  • 4비트는 대략 0.5배

모델 크기별로 보면 감이 바로 옴

• 7B 모델은 소비자 GPU에서도 꽤 현실적인 축에 들어감

  • FP16이면 약 14GB
  • FP8이면 약 7GB
  • 4비트면 약 3.5-4GB

• 13B 모델부터는 선택지가 갈리기 시작함

  • FP16은 약 26GB라 24GB 카드에서도 빠듯하거나 안 맞을 수 있음
  • FP8은 약 13GB
  • 4비트는 약 6-7GB

• 70B 모델은 본격적으로 고용량 GPU나 다중 GPU 영역임

  • FP16은 약 140GB
  • FP8은 약 70GB
  • 4비트도 약 35-40GB가 필요함

• 405B급 모델은 로컬 개인 장비로는 사실상 다른 게임임

  • FP16은 약 810GB
  • FP8은 약 405GB
  • 4비트도 200GB 이상이 필요함

실제 GPU에 뭐가 들어가나

• 8GB VRAM에서는 작은 모델이나 강한 양자화가 필요함

  • FP16은 약 3B
  • FP8은 약 6-7B
  • 4비트는 약 12-13B까지가 가중치 기준 추정치임

• 12GB VRAM은 입문형 로컬 LLM에서 꽤 많이 쓰이는 구간임

  • FP16은 약 5B
  • FP8은 약 10B
  • 4비트는 약 18-20B

• 16GB와 24GB는 선택지가 넓어짐

  • 16GB는 FP16 약 7B, FP8 약 13B, 4비트 약 25B
  • 24GB는 FP16 약 10-12B, FP8 약 20B, 4비트 약 35-40B

• 48GB와 80GB부터는 70B급 모델이 현실권에 들어옴

  • 48GB는 4비트 기준 약 70-80B
  • 80GB는 FP8 기준 약 70B, 4비트 기준 140B급까지 볼 수 있음

그래도 터지는 이유는 가중치가 전부가 아니라서임

• 공식은 가중치 메모리 계산이지 전체 추론 메모리 계산이 아님

  • KV 캐시는 컨텍스트 길이에 따라 커지고, 32K나 128K 같은 긴 문맥에서는 조용히 VRAM을 잡아먹음
  • activation은 런타임과 최적화 수준에 따라 달라지고, 특정 실행 경로에서 튈 수 있음

• 배치와 동시성도 메모리를 빠르게 늘림

  • 에이전트형 워크로드처럼 동시에 여러 요청이 돌거나 내부 호출이 많으면 메모리 사용량이 곱으로 불어남
  • Transformers, vLLM, TensorRT-LLM, llama.cpp 같은 런타임마다 오버헤드도 다름

• CUDA Graphs 같은 최적화도 공짜가 아님

  • 지연시간과 처리량 안정성을 얻는 대신 추가 예약 메모리를 쓸 수 있음
  • 그래서 글은 안전하게 돌리려면 10-30% 추가 VRAM을 잡으라고 권함

MoE와 GGUF에서 많이 헷갈림

• Mixture-of-Experts 모델은 계산 비용과 메모리 비용을 분리해서 봐야 함

  • 예를 들어 “8x7B”는 이름만 보면 56B처럼 보임
  • 하지만 토큰마다 모든 전문가가 도는 게 아니라 일부 전문가만 활성화됨

• MoE에서 중요한 값은 두 개임

  • 전체 파라미터는 메모리 풋프린트에 영향을 줌
  • 활성 파라미터는 속도와 계산량에 영향을 줌
  • 로딩 방식에 따라 모든 전문가를 메모리에 올려야 할 수도 있고, 여러 GPU에 나눌 수도 있음

• GGUF도 치트키는 아님

  • GGUF는 llama.cpp식 추론, CPU+GPU 하이브리드, 효율적인 메모리 사용에 맞춘 컨테이너와 양자화 전략임
  • Q6_K는 1B당 약 0.82GB, Q5_K는 약 0.69GB, Q4_K는 약 0.56GB, Q3_K는 약 0.43GB, Q2_K는 약 0.33GB 수준으로 제시됨

• “6GB에 들어간다”는 말은 런타임까지 포함한 문장이어야 함

  • 어떤 프레임워크에서는 가중치가 dequantize되면서 메모리 사용량이 크게 뛸 수 있음
  • 따라서 GGUF에서 맞는 숫자가 Transformers나 다른 추론 서버에서도 그대로 맞는다고 보면 위험함

질문을 바꿔야 함

• 이 글의 결론은 “이 모델 돌릴 수 있나요?”에서 끝나지 않음

  • 먼저 파라미터 × 비트 ÷ 8로 가중치 메모리를 계산함
  • 그다음 런타임 오버헤드, KV 캐시, 컨텍스트 길이, 동시성을 더함

• 그렇게 보면 단순 호환성 표를 외울 필요가 줄어듦

  • 4비트로 타협할지, FP8을 쓸지, 여러 GPU에 샤딩할지, 클라우드로 갈지 판단할 수 있음
  • 결국 질문은 “돌아가냐”가 아니라 “어떤 품질·속도·비용 조건으로 돌릴 거냐”가 됨

---

기술 맥락

• 이 글에서 하는 기술적 선택은 모델을 어떤 정밀도와 런타임으로 올릴지 정하는 거예요. 왜냐하면 같은 70B 모델이라도 FP16이면 약 140GB가 필요하고, 4비트면 약 35-40GB로 줄어드니까요.

• 양자화는 VRAM을 아끼는 가장 직접적인 방법이에요. 다만 비트를 낮출수록 품질 손실 가능성이 커지기 때문에, 개인 실험인지 서비스 추론인지에 따라 적당한 지점을 골라야 해요.

• KV 캐시가 중요한 이유는 긴 컨텍스트에서 메모리를 계속 먹기 때문이에요. 모델 가중치만 겨우 들어가는 구성으로 32K나 128K 문맥을 쓰면, 실제 요청 단계에서 바로 메모리 부족이 날 수 있어요.

• 런타임 선택도 숫자를 바꿔요. llama.cpp와 GGUF 조합에서는 작게 들어가던 모델이 다른 프레임워크에서는 dequantize되거나 오버헤드가 붙어서 훨씬 커질 수 있거든요.

• 그래서 운영 관점에서는 가중치 계산에 10-30% 여유를 더하고, 동시성이나 에이전트 워크로드가 있으면 그 이상을 잡는 게 현실적이에요. 이 계산을 해야 GPU를 살지, 샤딩할지, 클라우드로 보낼지 판단할 수 있어요.