Local LLM 구축하기 · 04/30 · 입문
로컬 LLM용 PC 사양을 볼 때는 모델이 메모리에 들어가는지부터 확인합니다. GPU가 빨라도 VRAM이 모자라면 일부 가중치를 시스템 RAM으로 옮겨야 해요. 그때 생기는 병목은 게임 성능표만으로 판단하기 어렵습니다.
작업 관리자와 2편에서 받은 모델을 준비합니다. 가중치, KV 캐시, 실행에 남겨 둘 메모리를 구분해 보겠습니다.
가중치 메모리 계산
가중치 크기를 가늠하는 출발점은 파라미터 수 × 비트 수 ÷ 8입니다. 8B 모델의 가중치를 4비트로 저장하면 약 40억 바이트, 약 3.73GiB가 됩니다. 여기에 양자화의 블록별 스케일과 혼합 정밀도 정보 등이 더해집니다. 계산값을 그대로 필요한 최소 VRAM으로 사용하면 안 됩니다.
| 추가로 필요한 공간 | 왜 필요한가 |
|---|---|
| KV 캐시 | 이미 읽은 토큰의 attention 계산 결과를 재사용 |
| 실행 버퍼 | 행렬 연산과 임시 텐서 처리 |
| 그래픽 화면·다른 앱 | Windows와 브라우저도 GPU 메모리를 사용 |
| 동시 요청 | 여러 문맥을 함께 유지할 때 캐시 증가 |
$parameters = 8e9
$bits = 4
[math]::Round(($parameters * $bits / 8) / 1GB, 2)
여기서 PowerShell의 1GB는 2의 30제곱 바이트를 뜻합니다. 제품 사양의 GB와 GiB를 섞으면 같은 용량도 숫자가 다르게 보여요. 장비를 고를 때는 단위를 맞춰 보고, 실제 런타임의 적재량에 여유를 더해 판단합니다.
CPU·GPU와 메모리 대역폭
CPU 추론은 시스템 RAM을 쓸 수 있어 큰 모델 파일을 다루기에 유리한 면이 있습니다. 대신 토큰을 차례로 만드는 decode 단계에서는 메모리 대역폭이 병목이 될 수 있어요. GPU는 병렬 연산과 전용 메모리 대역폭을 활용하지만, 먼저 VRAM 용량 안에 들어가는지 확인해야 합니다. CPU 코어 수만 늘려도 응답이 비례해서 빨라지는 것은 아닙니다.
긴 입력을 읽는 prefill과 답변을 이어 쓰는 decode는 나눠서 살펴봅니다. 첫 글자가 늦게 나오는 경우와, 출력이 시작된 뒤 토큰이 느리게 이어지는 경우는 원인이 다를 수 있어요. 두 구간을 따로 측정하는 방법은 26편에서 다룹니다.
장비별 GPU 지원 조건
ollama run qwen3:4b-instruct
ollama ps
# NVIDIA 드라이버가 설치된 장비에서만 실행
nvidia-smi
Ollama의 GPU 지원표에서는 정확한 제품과 운영체제, 드라이버 조건을 확인합니다. 같은 NVIDIA·AMD 제품군 안에서도 지원 조건이 다르고 Windows와 Linux의 표도 같지 않을 수 있습니다. 통합 GPU의 “공유 GPU 메모리 16GB”는 전용 VRAM 16GB와 같은 자원이 아닙니다.
업그레이드 전에 확인할 것
현재 PC에서 작은 모델을 문맥 4096으로 실행해 봅니다. RAM이 모자라는지, 모델 전체가 GPU에 올라가는지, 답변 품질이 부족한지를 따로 기록하세요. RAM을 늘리면 메모리 압박은 줄일 수 있지만 GPU 연산 자체가 빨라지지는 않습니다.
부분 오프로딩은 일부 레이어를 GPU에, 나머지를 CPU 쪽에 두는 방법입니다. 용량 때문에 실행하지 못하던 모델을 돌릴 수 있지만 두 장치의 경계를 오가는 비용도 생겨요. 구매를 고민한다면 먼저 목표 모델과 문맥 길이, 동시에 사용할 인원을 적어 두는 편이 비교에 도움이 됩니다.
참고 자료
문서·모델 태그 확인 기준: 2026년 10월 18일. 기본 실습 환경: Windows 11 x64.




답글 남기기