--- title: "로컬 LLM 돌릴 때 VRAM 계산하는 법: 모델이 GPU에 들어가는지 한 방에 보는 공식" published: 2026-05-20T21:02:11.000Z canonical: https://jeff.news/article/2975 --- # 로컬 LLM 돌릴 때 VRAM 계산하는 법: 모델이 GPU에 들어가는지 한 방에 보는 공식 이 글은 로컬에서 대규모 언어 모델(LLM)을 돌릴 때 필요한 GPU 메모리를 모델 파라미터 수와 가중치 비트 수로 계산하는 실용 공식을 설명한다. 단순히 모델 크기만 보면 부족하고, KV 캐시·컨텍스트 길이·동시성·런타임 오버헤드까지 같이 봐야 실제로 터지지 않는다. ## 로컬 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배 > [!IMPORTANT] > “모델 파일이 몇 GB냐”보다 중요한 건 파라미터 수와 가중치 비트 수임. 이 둘을 곱해야 실제 VRAM 감이 잡힘. ## 모델 크기별로 보면 감이 바로 옴 - 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을 잡으라고 권함 > [!TIP] > 긴 컨텍스트, 높은 동시성, 에이전트 워크플로를 쓴다면 10-30% 여유로도 부족할 수 있음. “가중치가 들어간다”와 “서비스가 안정적으로 돈다”는 다른 얘기임. ## 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를 살지, 샤딩할지, 클라우드로 보낼지 판단할 수 있어요. ## 핵심 포인트 - 기본 공식은 VRAM(GB) ≈ 파라미터 수(십억 단위) × (가중치당 유효 비트 ÷ 8)이다 - FP16은 1B 파라미터당 약 2GB, FP8은 약 1GB, 4비트 양자화는 약 0.5GB가 필요하다 - 가중치가 들어가도 KV 캐시, 긴 컨텍스트, 배치, 프레임워크 오버헤드 때문에 10-30% 이상의 여유 VRAM이 필요하다 ## 인사이트 로컬 LLM 운영에서 ‘이 모델 돌아가요?’라는 질문은 사실 너무 뭉뚱그린 질문이다. 같은 모델도 양자화 방식, 컨텍스트 길이, 런타임, 동시성에 따라 메모리 요구량이 완전히 달라지기 때문이다.