허깅페이스(Hugging Face)에서 로컬 LLM을 받아보면 이상한 점이 눈에 들어옵니다. 분명 같은 이름의 모델인데 어떤 파일은 4GB, 어떤 파일은 15GB입니다. 파일 이름 끝에는 Q4_K_M, Q8_0, 4bit 같은 암호가 붙어 있고, 어떤 건 .gguf 파일 하나인데 어떤 건 폴더 통째로 내려받아야 합니다. 이 글에서는 그 파일들의 정체가 무엇이고, 용량이 왜 그렇게 제각각인지 정리합니다.
목차
다운로드한 그 파일은 프로그램이 아니라 ‘숫자 뭉치’입니다
가장 먼저 바로잡아야 할 오해가 있습니다. GGUF나 MLX 파일은 실행 파일이 아닙니다. 더블클릭한다고 AI가 켜지지 않습니다. 이 파일들은 모델의 가중치(weight), 즉 학습으로 얻어진 수십억 개의 숫자와, 그 숫자를 어떻게 해석해야 하는지 알려주는 설정값·토크나이저 사전을 함께 담아둔 데이터 컨테이너입니다.
비유하자면 GGUF 파일은 MP4 영상 파일에 가깝습니다. MP4 자체는 아무것도 못 하지만, 재생기(플레이어)에 물리면 영상이 나옵니다. 마찬가지로 GGUF 파일도 llama.cpp, LM Studio, Ollama 같은 추론 엔진에 물려야 비로소 대화가 시작됩니다. 파일은 악보이고, 엔진이 연주자인 셈입니다.
그래서 로컬 LLM을 돌리려면 항상 두 가지가 필요합니다. 모델 파일(GGUF·MLX)과 그 파일을 읽을 줄 아는 엔진입니다. 파일 하나만 받아놓고 왜 안 되냐고 묻는 경우가 많은데, 재생기 없이 영상 파일만 가진 상태와 같습니다.
GGUF, MLX, safetensors — 포장 방식이 다를 뿐입니다
같은 모델이 여러 형식으로 배포되는 이유는 간단합니다. 돌릴 하드웨어가 다르기 때문입니다. 현재 개인이 마주치는 형식은 사실상 세 가지입니다.
| 형식 | 정체 | 주 사용처 | 생김새 |
|---|---|---|---|
| GGUF | 가중치·토크나이저·메타데이터를 한 파일에 몰아넣은 단일 바이너리 형식. llama.cpp 계열의 표준 | 윈도우·리눅스·맥 전부. CPU만으로도 구동 가능, 엔비디아·AMD GPU 및 애플 실리콘 모두 지원 | 모델명-Q4_K_M.gguf 파일 1개(대형 모델은 여러 조각으로 분할) |
| MLX | 애플이 만든 머신러닝 프레임워크 MLX가 읽는 형태. 파일 형식이라기보다 safetensors + 설정 파일 묶음 | 애플 실리콘(M 시리즈) 맥 전용. 통합 메모리 구조에 최적화 | model.safetensors + config.json 등이 든 폴더 |
| safetensors | 허깅페이스가 만든 안전한 텐서 저장 형식. 원본(무손실) 모델의 기본 배포 형태 | 파인튜닝·연구·GPU 서버. GGUF·MLX로 변환하는 출발점 | 대개 여러 개로 쪼개진 .safetensors 묶음 |
정리하면 safetensors가 원본, GGUF와 MLX는 각각의 목적지에 맞게 다시 포장한 결과물입니다. GGUF는 “어디서든 돌아간다”는 이식성을, MLX는 “맥에서 가장 빠르다”는 최적화를 택했습니다. 맥 사용자라면 같은 모델의 MLX 버전이 GGUF 버전보다 체감상 빠른 경우가 많은데, 애플 실리콘의 통합 메모리와 GPU를 직접 겨냥해 만들어졌기 때문입니다. 반대로 윈도우·리눅스 사용자나 CPU만으로 돌려야 하는 환경이라면 선택지는 사실상 GGUF뿐입니다.
참고로 예전에 흔하던 .bin(파이토치 pickle) 형식이 safetensors로 대체된 데는 보안 이유가 큽니다. pickle 형식은 파일을 여는 것만으로 임의 코드가 실행될 수 있었지만, safetensors와 GGUF는 순수 데이터만 담기 때문에 그 위험이 없습니다.
파일 이름 읽는 법
Qwen3-8B-Instruct-Q4_K_M.gguf 같은 이름은 암호가 아니라 규칙입니다. 하이픈 단위로 끊어 읽으면 됩니다.
| 토막 | 의미 | 고를 때 기준 |
|---|---|---|
| Qwen3 | 모델 이름(제작사·계열) | 용도별 강점이 다름 |
| 8B | 파라미터 수 80억 개. 용량과 성능을 좌우하는 1차 변수 | 숫자가 클수록 똑똑하지만 무겁고 느림 |
| Instruct | 지시를 따르도록 추가 학습된 대화용 모델. Base는 문장 이어쓰기용 원석 | 챗봇 용도라면 Instruct(또는 Chat) |
| Q4_K_M | 양자화 방식. 가중치를 4비트로 압축하되 중요한 층은 더 높은 정밀도로 남긴 혼합 방식 | 용량과 품질의 균형점. 대부분의 경우 무난한 기본값 |
| .gguf | 파일 형식 | 엔진이 읽을 수 있는지 확인 |
여기서 용량을 결정하는 건 8B와 Q4_K_M 두 토막입니다. 나머지는 용량과 무관합니다.
용량은 곱셈 하나로 정해집니다
모델 파일 크기는 신비한 값이 아니라 다음 곱셈의 결과입니다.
파일 용량(GB) ≈ 파라미터 수(십억 단위) × 가중치당 비트 수(bpw) ÷ 8
파라미터 하나를 몇 비트로 저장하느냐가 전부입니다. 8로 나누는 건 8비트가 1바이트이기 때문입니다. 원본 모델은 파라미터 하나를 16비트(2바이트)로 저장하므로, 70억 개짜리 모델이면 곧바로 14GB가 나옵니다. 양자화(quantization)는 이 16비트를 8비트, 5비트, 4비트로 줄여 파일을 가볍게 만드는 작업입니다.
7B(70억) 모델을 예로 들면 대략 이런 표가 나옵니다.
| 양자화 | 가중치당 비트(대략) | 7B 모델 용량(대략) | 성격 |
|---|---|---|---|
| F16(원본) | 16 | 13~14GB | 압축 없음. 품질 기준선 |
| Q8_0 | 8.5 | 7~8GB | 거의 무손실. 여유 있을 때 선택 |
| Q6_K | 6.6 | 5.5~6GB | 품질 우선의 현실적 타협 |
| Q5_K_M | 5.7 | 4.8~5.2GB | Q4보다 조금 더 안전한 선택 |
| Q4_K_M | 4.8~5.0 | 4~4.5GB | 가장 널리 쓰이는 기본값 |
| Q3_K_M | 3.9 | 3.3~3.5GB | 품질 저하가 눈에 띄기 시작 |
| Q2_K | 3.3 | 2.8~3GB | 돌아는 가지만 성능 손실이 큼 |
표를 보면 Q4_K_M이 왜 사실상의 표준이 됐는지 보입니다. 원본 대비 용량을 3분의 1 이하로 줄이면서도 품질 하락은 대부분의 일상적 사용에서 체감하기 어려운 수준에 머무릅니다. 반면 3비트 아래로 내려가면 문장이 어색해지거나 지시를 놓치는 일이 눈에 띄게 늘어납니다.
여기서 한 가지 짚을 점이 있습니다. Q4_K_M의 이름에는 4가 붙어 있지만 실제 가중치당 비트는 4가 아니라 4.8 안팎입니다. 모든 가중치를 똑같이 4비트로 뭉개는 게 아니라, 출력 품질에 민감한 층(어텐션 일부와 피드포워드의 특정 구간)은 6비트로 남기고 나머지를 4비트로 줄이는 혼합 정밀도 방식이기 때문입니다. 이름 뒤의 _K는 이 K-양자화 계열을 뜻하고, _S·_M·_L은 각각 작게·중간·크게 남긴 정도를 뜻합니다.
같은 모델인데 용량이 제각각인 다섯 가지 이유
1. 파라미터 수가 다릅니다
가장 큰 변수입니다. 같은 계열이라도 3B·8B·32B·70B가 따로 배포됩니다. 같은 Q4_K_M이라도 3B는 2GB 남짓, 70B는 40GB를 넘어갑니다. 파일 목록에서 용량 차이가 열 배 이상 벌어진다면 십중팔구 파라미터 수가 다른 형제 모델입니다.
2. 양자화 단계가 다릅니다
같은 8B 모델 하나에도 Q2부터 F16까지 열 개 이상의 파일이 함께 올라옵니다. 업로더가 “당신의 램에 맞춰 골라 가라”는 뜻으로 전 라인업을 뽑아 올린 것입니다. 파일 목록이 길게 늘어선 이유의 대부분이 이것입니다.
3. 같은 4비트라도 방식이 다릅니다
Q4_0, Q4_K_S, Q4_K_M, IQ4_XS는 모두 “4비트”지만 용량과 품질이 조금씩 다릅니다. 특히 앞에 I가 붙은 IQ 계열은 대표 데이터로 어떤 가중치가 중요한지 미리 측정한 정보(importance matrix)를 반영해 압축한 것으로, 같은 비트에서 품질을 더 붙잡거나 더 낮은 비트에서도 버티도록 만든 변형입니다. 이름이 비슷해도 결과 파일 크기는 몇백 MB씩 차이가 납니다.
4. 전문가 혼합(MoE) 모델은 계산이 다릅니다
최근 늘어난 MoE 구조 모델은 “총 파라미터”와 “실제로 매번 쓰이는 활성 파라미터”가 다릅니다. 예컨대 총 30B에 활성 3B인 모델은 속도는 3B급인데 파일 용량과 메모리 요구량은 30B급입니다. 활성 파라미터만 보고 “가볍겠지” 하고 받았다가 램이 터지는 흔한 함정입니다. 용량을 결정하는 건 언제나 총 파라미터입니다.
5. 어휘 사전 크기와 파일 분할
같은 7B라고 표기돼도 실제 파라미터는 6.7B일 수도, 7.6B일 수도 있습니다. 여기에 다국어 지원으로 토크나이저 어휘(vocab)가 커지면 임베딩 층이 통째로 커지면서 수백 MB가 더 붙습니다. 같은 Q4_K_M인데 모델마다 4.1GB, 4.4GB, 4.9GB로 미묘하게 어긋나는 이유가 이것입니다. 또 대형 모델은 -00001-of-00003.gguf처럼 조각으로 나뉘어 올라오는데, 이때는 조각 전부를 같은 폴더에 받아야 제대로 로드됩니다. 하나만 받아서 열리지 않는다고 오해하기 쉬운 지점입니다.
내 컴퓨터에 맞는 파일 고르기
기준은 하나입니다. 모델 파일이 메모리에 통째로 올라갈 수 있어야 합니다. 그것도 딱 맞게가 아니라 여유를 두고 올라가야 합니다. 대화 내용을 기억하는 KV 캐시가 컨텍스트 길이에 비례해 추가로 메모리를 먹고, 운영체제와 다른 앱도 메모리를 쓰기 때문입니다.
실무적인 어림셈은 필요 메모리 ≈ 파일 크기 + 2~3GB 정도입니다. 긴 문서를 통째로 넣고 쓸 계획이라면 여유분을 더 잡아야 합니다.
| 메모리(RAM/VRAM) | 현실적인 선택 | 비고 |
|---|---|---|
| 8GB | 3B~4B급 Q4_K_M | 7B Q4도 아슬아슬하게 되지만 여유가 없음 |
| 16GB | 7B~9B급 Q4_K_M, 여유되면 Q5 | 가장 흔한 구간. 무난한 일상 사용 가능 |
| 24GB | 14B급 Q4~Q5, 7B급은 Q8까지 | 품질을 올릴 여지가 생김 |
| 32GB | 24B~32B급 Q4_K_M | 코딩 보조까지 실용권 |
| 64GB 이상 | 70B급 Q4_K_M | 맥의 통합 메모리라면 특히 유리한 구간 |
맥(애플 실리콘)에서는 램과 그래픽 메모리가 나뉘어 있지 않고 통합 메모리를 함께 쓰기 때문에, 같은 64GB라도 별도 그래픽카드를 쓰는 PC보다 큰 모델을 올리기 유리합니다. 다만 시스템이 GPU에 할당할 수 있는 몫에 한계가 있으므로 전체 메모리를 100% 모델에 쓸 수 있다고 가정하면 안 됩니다.
형식 선택은 더 단순합니다. 애플 실리콘 맥이면 MLX 버전을 우선 시도하고(속도 이점), 그 외 환경이거나 여러 기기에서 같은 파일을 돌려야 한다면 GGUF를 고르면 됩니다. 무엇을 골라야 할지 모르겠다면 Q4_K_M GGUF가 가장 실패 확률이 낮은 출발점입니다.
자주 묻는 질문
양자화하면 모델이 바보가 되나요?
정도의 문제입니다. 8비트는 원본과 구별하기 어려운 수준이고, Q4_K_M도 일상적인 요약·번역·대화에서는 차이를 체감하기 어렵습니다. 다만 코딩이나 수학처럼 한 토큰만 틀려도 결과가 무너지는 작업, 그리고 애초에 파라미터가 적은 소형 모델일수록 압축 손실이 더 잘 드러납니다. 이런 용도라면 같은 용량 예산에서 “큰 모델을 4비트로”가 “작은 모델을 8비트로”보다 대체로 유리합니다.
GGUF 파일을 열면 컴퓨터가 감염될 수 있나요?
GGUF와 safetensors는 코드가 아닌 데이터만 담는 구조라 파일 자체가 프로그램을 실행하지는 않습니다. 다만 파일이 어떤 성향으로 학습됐는지는 별개 문제이므로, 모델은 업로더가 신뢰할 만한 곳에서 받는 편이 좋습니다.
MLX와 GGUF, 같은 모델을 둘 다 받아야 하나요?
아닙니다. 쓰는 엔진이 읽는 형식 하나면 충분합니다. 둘 다 받으면 디스크만 두 배로 씁니다.
파일을 받았는데 엔진이 인식하지 못합니다
세 가지를 확인하면 대부분 해결됩니다. 분할 파일 중 일부만 받지 않았는지, MLX 폴더에서 config.json 등 설정 파일을 빼놓지 않았는지, 그리고 모델이 최신 아키텍처라 엔진 버전이 아직 지원하지 못하는 상태는 아닌지입니다. 마지막 경우는 엔진을 최신 버전으로 올리면 풀리는 일이 많습니다.
마무리
정리하면 이렇습니다. 인터넷에 공개된 GGUF·MLX 파일은 실행 프로그램이 아니라 모델의 가중치를 담아 포장한 데이터 파일이고, 용량은 파라미터 수 × 가중치당 비트 ÷ 8이라는 곱셈으로 거의 결정됩니다. 파일 목록의 용량이 제각각인 건 업로더가 파라미터 수와 압축 강도를 조합해 여러 벌을 만들어 두었기 때문입니다.
그러니 다운로드 페이지에서 헤맬 필요가 없습니다. 내 메모리에서 파일 크기 + 여유 2~3GB가 감당되는 선을 정하고, 그 안에서 파라미터가 가장 큰 모델의 Q4_K_M을 고르면 됩니다. 모델 파일은 허깅페이스에서 받을 수 있고, 실행 엔진은 llama.cpp나 Ollama, LM Studio 중 편한 것을 고르면 됩니다. 맥에서 속도를 끌어올리고 싶다면 MLX 쪽 배포본을 함께 살펴볼 만합니다.