로컬 LLM 사양 가이드: RAM 16GB·32GB·64GB에서 모델 고르는 법

로컬 LLM 사양은 ‘몇 B 모델까지 된다’ 한 줄로 정할 수 없다. 먼저 내려받을 양자화 파일이 RAM 또는 VRAM에 들어가는지 보고, 여기에 컨텍스트용 메모리와 실행 여유를 더해야 한다. 16GB에서는 작은 양자화 모델과 짧은 컨텍스트부터, 32GB에서는 중간 크기 모델을 신중하게, 64GB에서는 더 큰 파일과 긴 컨텍스트를 시험할 수 있지만 어떤 경우도 모델 파일 크기만 보고 꽉 채우면 안전하지 않다.

모델명보다 파일 크기를 먼저 보자

7B, 14B, 32B는 대체로 파라미터 규모를 말하지만 실제 다운로드와 실행 메모리는 정밀도와 양자화에 따라 달라진다. 같은 8B 계열도 FP16과 4비트 GGUF의 파일 크기가 크게 다르다. Ollama 모델 라이브러리와 Hugging Face의 GGUF 파일 목록에는 태그 또는 파일별 크기가 표시되므로 설치 전에 그 숫자를 확인해야 한다.

양자화는 가중치를 더 적은 비트로 표현해 파일과 메모리 부담을 줄이는 방법이다. 대신 양자화 방식과 정도에 따라 출력 품질과 실행 특성이 달라질 수 있다. Q4, Q5, Q8이라는 이름만 보고 항상 같은 품질·속도라고 단정할 수도 없다. 구현과 세부 변형이 다르기 때문이다. 모델 제작자가 권장한 파일과 llama.cpp 호환 여부를 모델 카드에서 확인하자.

안전한 판단식은 다음과 같다.

필요한 메모리 = 모델 가중치 + KV cache 등 컨텍스트 메모리 + 런타임 버퍼 + 운영체제와 다른 프로그램의 몫

정확한 합계는 모델 구조, 백엔드, 컨텍스트 길이, 배치, CPU/GPU 분할에 따라 달라진다. 그래서 ‘파일이 15GB이니 RAM 16GB에서 된다’는 계산은 위험하다. 로딩에 성공해도 브라우저와 IDE를 함께 켜면 스왑이 늘고 체감 속도가 급격히 떨어질 수 있다.

RAM 16GB: 작은 파일과 짧은 컨텍스트부터

16GB 시스템에서는 운영체제 몫을 뺀 뒤 모델을 올려야 한다. 시작점은 3B~8B급에서 제공되는 작은 양자화 파일처럼, 파일 크기가 메모리보다 충분히 작은 모델이다. 이 범위는 절대 보장치가 아니라 탐색 방향이다. 실제 모델 페이지의 파일 크기와 실행 중 메모리를 확인해야 한다.

권장 순서는 이렇다.

1. 브라우저 탭과 무거운 앱을 닫는다.
2. 모델 라이브러리에서 작은 양자화 태그의 실제 용량을 확인한다.
3. 컨텍스트를 기본값 또는 짧은 값으로 시작한다.
4. 짧은 프롬프트로 로딩과 생성 속도를 확인한다.
5. 작업 관리자나 Activity Monitor에서 메모리 압력과 스왑을 본다.

16GB에서 긴 PDF 여러 개를 한 요청에 넣거나 큰 컨텍스트를 미리 잡는 것은 모델 파일이 작아도 부담이 된다. 문서는 청크로 나누고, 필요한 부분만 검색해 프롬프트에 넣는 방식이 현실적이다.

RAM 32GB: 선택 폭은 넓지만 여유를 남겨야 한다

32GB에서는 더 큰 7B~14B급 양자화 파일과 일부 그보다 큰 모델을 검토할 수 있다. 그러나 파라미터 수만으로 확정하지 말자. MoE 모델은 이름의 활성 파라미터와 전체 저장 파라미터가 다를 수 있고, 멀티모달 모델은 추가 구성요소가 있을 수 있다. 다운로드 용량이 실제 판단의 출발점이다.

코딩 보조처럼 IDE, 브라우저, 로컬 서버를 동시에 쓰는 작업은 LLM에 32GB 전부를 줄 수 없다. 모델 하나만 띄운 벤치마크에서 성공한 것과 하루 종일 안정적으로 사용하는 것은 다른 문제다. 메모리 압력이 계속 높거나 스왑 사용량이 증가하면 더 작은 태그로 내리는 것이 컨텍스트를 억지로 줄이는 것보다 나을 수 있다.

32GB의 장점은 같은 계열에서 Q4와 Q5처럼 파일을 바꾸며 품질과 속도를 비교할 여지가 생긴다는 것이다. 단, 두 파일을 동시에 메모리에 올려 비교하지 말고 한 모델을 내린 뒤 다음 모델을 로드한다.

RAM 64GB: 큰 모델보다 긴 작업의 비용을 함께 본다

64GB에서는 더 큰 양자화 모델을 시도할 수 있고, 긴 컨텍스트나 여러 도구를 병행할 여유도 커진다. 그래도 70B라는 숫자만 보고 가능하다고 판단해서는 안 된다. 선택한 양자화 파일, 컨텍스트, 런타임 오버헤드가 모두 들어와야 한다. 특히 ‘로드 가능’과 ‘기다릴 만한 속도’는 별개다. 메모리에 들어가도 CPU 위주 추론이면 대화가 불편할 정도로 느릴 수 있다.

64GB에서 확인할 항목은 세 가지다.

• 모델 로드 직후가 아니라 긴 프롬프트를 처리한 뒤 최대 메모리
• 첫 토큰이 나오기까지 걸리는 시간
• 생성 구간의 초당 토큰과 시스템 스왑

큰 모델 하나가 작은 모델보다 항상 업무 성능이 좋은 것도 아니다. 코딩, 한국어 요약, 도구 호출처럼 자신의 작업 샘플로 정답률을 함께 봐야 한다.

VRAM과 Apple 통합 메모리는 같은 표로 보면 안 된다

NVIDIA·AMD GPU의 전용 VRAM을 사용하는 PC에서는 가중치와 캐시를 GPU에 얼마나 올리는지가 속도에 큰 영향을 준다. VRAM에 다 들어가지 않으면 일부 레이어를 CPU/RAM으로 넘길 수 있는 백엔드도 있지만 속도 저하 폭은 하드웨어와 설정마다 다르다. Ollama 공식 Hardware support 문서는 지원 GPU 계열과 요구 드라이버를 별도로 안내하므로 구매 전 정확한 GPU 모델을 대조해야 한다.

Apple Silicon은 CPU와 GPU가 통합 메모리를 공유한다. ‘통합 메모리 32GB = 전용 VRAM 32GB’라고 단순 치환하면 안 된다. 운영체제와 앱도 같은 풀을 사용한다. 반대로 CPU 메모리와 VRAM 사이 복사가 없는 통합 구조의 장점도 있어, Windows GPU 결과를 Mac에 그대로 적용할 수 없다.

GPU 이름만 같아도 드라이버, 지원되는 연산, 백엔드 버전에 따라 결과가 바뀐다. 공식 지원 목록에 없거나 실험적 지원으로 표시된 GPU는 ‘VRAM 용량이 충분하다’만으로 구매 근거가 되지 않는다.

컨텍스트 길이가 메모리를 먹는 이유

컨텍스트는 모델이 한 요청에서 참고하는 토큰 범위다. 길게 잡을수록 프롬프트와 생성 과정의 중간 상태를 저장하는 KV cache가 커진다. 모델이 128K를 지원한다는 것과 자신의 컴퓨터에서 128K를 빠르게 처리할 수 있다는 것은 다른 주장이다.

Ollama는 컨텍스트 길이를 별도 문서에서 설명하고, 실행 환경에 따라 기본값과 설정 방법이 바뀔 수 있으므로 현재 설치 버전의 문서를 확인하는 것이 안전하다. 처음부터 최대치를 넣지 말고 실제 문서 길이에 맞춰 단계적으로 올린다. 4K에서 정상인 모델이 32K에서 메모리 부족을 내는 것은 모순이 아니다.

사양별 안전한 선택 절차

1. 정확한 파일 확인: 모델 계열명이 아니라 다운로드할 태그·GGUF 파일의 GB를 기록한다.
2. 여유 확보: RAM/VRAM에서 운영체제, IDE, 브라우저가 쓸 몫을 남긴다.
3. 짧은 컨텍스트로 시작: 로딩 성공과 짧은 생성 속도를 먼저 확인한다.
4. 실제 입력으로 확대: 사용할 PDF, 코드 파일, 대화 길이까지 늘려 최대 메모리를 본다.
5. 품질과 속도를 같이 기록: 더 큰 모델이 자신의 질문에서 실제로 더 정확한지 확인한다.

16GB·32GB·64GB라는 숫자는 출발점일 뿐이다. 최종 선택은 ‘정확한 양자화 파일 크기, 목표 컨텍스트에서의 최대 메모리, 기다릴 수 있는 생성 속도’ 세 값으로 결정하는 것이 가장 안전하다.

출처: Ollama 모델 라이브러리, Ollama Hardware support, Ollama Context length, Hugging Face Transformers Quantization, Hugging Face GGUF, llama.cpp 공식 저장소