내 컴퓨터에서 30B LLM 모델을 돌리고 싶다고 해보자. 내 그래픽카드가 나름 상위권 스펙인 RTX5080이라면, VRAM 16기가로 비교적 넉넉하지. 근데 30B 모델 파일만 해도 20기가가 넘어서 VRAM을 초과해버리면 어떻게 해야 할까?
더 비싼 그래픽카드를 사는 방법도 있겠지만, 모델을 더 작은 숫자로 저장하는 방법도 있어. 바로 양자화야. 모델이 배워 둔 수많은 숫자를 더 적은 비트로 표현해 파일 크기와 메모리 사용량을 줄이는 거지.
예전에는 양자화 기술이 보편화되지 않아서 VRAM을 한참 초과하는 크기의 모델들은 돌려보는 것 자체가 힘들었지만, 양자화 덕분에 이 문제를 극복하는 게 가능해졌어.
✦ 핵심 업데이트
Ollama v0.40.6
| 항목 | 내용 |
|---|---|
| 버전 | Ollama v0.40.6 |
| 공개일 | 2026년 10월 16일 |
| 변경 내용 | GGUF Q2_0 텐서·파일 형식 지원 추가 |
| 수정된 문제 | llama.cpp는 먼저 지원했지만 Ollama의 GGUF 판독기가 tensor type 42 / file type 41을 읽지 못하던 문제 |
10월 16일 공개된 Ollama v0.40.6도 이와 관련된 업데이트를 진행했어. 새로 지원하는 형식은 Q2_0. 모델 가중치를 매우 작은 단위로 압축하는 GGUF 형식 중 하나야.
물론 llama.cpp에서는 이미 Q2_0 GGUF를 실행할 수 있었지만, Ollama의 파일 판독기가 해당 형식을 제대로 읽지 못했거든. 이번 업데이트로 Ollama에서도 그 형식의 모델을 깔끔하게 불러오고 실행할 수 있게 된 거야.
양자화는 모델을 어떻게 작게 만들까?
언어 모델은 수십억 개의 가중치로 이루어져 있어. 가중치는 모델이 문장을 이해하고 다음 단어를 고르는 데 사용하는 숫자라고 생각하면 돼.
"수많은 단어들 중에 어떤 단어를 선택하는게 확률적으로 더 우수한지 찾아나기 위한 참고용 숫자"라고 하면 좀 이해가 쉬울까? 원래 이 숫자들을 32비트 부동소수점, 즉 FP32로 저장했다면 숫자 하나에 4바이트가 필요해.
숫자 하나는 작아 보여도, 수십억 개가 모이면 파일 하나가 수십 기가바이트로 커지게 되지.
✦ 양자화가 일어나는 과정
숫자를 줄이면 생기는 일
양자화는 이런 숫자들의 양을 합리적인 방식으로 줄여나가는 거야. 세밀한 눈금이 그려진 자를 사용해서 도면을 그리다가 눈금이 굵은 자로 바꾼다고 생각하면 이해가 될 듯.
눈금이 굵어질수록 작업을 하기는 수월해지지만, 아주 정밀한 도면을 완벽하게 그리기는 어려워지겠지. 분명 약간의 틈새가 발생할 거야.
그래서 양자화에는 늘 맞바꿈이 있어. 파일과 메모리를 줄이는 대신 원래 모델의 답변 품질을 조금 포기하는 거야. 대신 메모리에서 읽어야 할 데이터가 줄어드니까 추론이 빨라지겠지. 다만, 무조건 빨라지는 건 아니야.
실행 장치(주로 그래픽카드)가 해당 형식을 효율적으로 처리하지 못하면, 압축된 숫자를 계산용으로 풀어내는 데 시간이 들어 속도 이점이 줄어들 수 있거든.
전쟁을 할 때 암호해독가가 아군에 있으면 암호로 빠르게 메시지를 주고받으면서 전세를 유리하게 이끌 수 있겠지만, 암호해독가가 없는데 괜히 암호로 메시지를 주고받다간 그거 해독하다가 날새겠지.
이럴 때는 차라리 평문으로 메시지를 보내는 게 효율적일 수 있다는 거야. 바로 이 부분이 엔비디아의 RTX 그래픽카드가 대중들에게 사랑받는 이유이기도 해. 이런 형식들을 가장 우수하게 지원해주거든.
FP32부터 BF16, FP16까지: 숫자를 저장하는 기본 형식
✦ 형식 계열 구분
이름이 비슷해도 계열이 달라
| 계열 | 형식 |
|---|---|
| 부동소수점 정밀도 | FP32, FP16, BF16, FP8 |
| 정수 양자화 | INT8 |
| 블록 스케일 형식 | MXFP8, NVFP4 |
| GGUF 가중치 양자화 | Q8_0, Q4_K_M, Q2_0 |
먼저 FP32는 고정밀 기준점이라고 보면 돼. 숫자 하나에 32비트, 즉 4바이트를 써서 세밀하게 표현하지. 모델 가중치가 FP32라면 크기가 큰 대신 양자화로 생기는 손실이 거의 없는 기준 모델로 쓰기 좋아.
FP16과 BF16은 둘 다 16비트라 숫자 하나에 2바이트가 들어가. 하지만 내부 배분이 달라. FP16은 소수 부분을 더 세밀하게 표현할 수 있는 대신 표현 가능한 숫자의 범위가 상대적으로 좁아.
BF16은 FP32와 비슷한 넓은 범위를 유지하는 대신 소수의 세밀함을 덜어냈지. 그래서 둘 다 16비트여도 같은 형식은 아니고, 어떤 작업을 하느냐에 따라 선택이 달라져. 그래서 각각의 모델별로 둘 다 써보는 게 좋아.
어느 쪽이 원하는 결과에 가까운 값을 주는지 테스트해보는 거지. 명확히 둘 중에 누가 우위라고 보기 어렵거든.
INT8과 FP8은 8비트, 즉 대략 1바이트급이야. INT8은 정수 몇 단계와 스케일 값을 조합해 원래 가중치를 근사하는 방식이고, FP8은 아주 작은 부동소수점 숫자 체계를 사용해.
FP8에는 소수 표현을 조금 더 세밀하게 하는 E4M3, 더 넓은 값의 범위를 다루는 E5M2 같은 형식이 있어. 이름에 모두 ‘8’이 들어간다고 해도 INT8과 FP8은 숫자를 담는 방법부터 다르지.
여기에 MXFP8도 있어. 이건 FP8 숫자만 쓰는 게 아니라, 연속된 32개 값마다 별도의 스케일을 붙이는 블록 단위 방식이야. 한 덩어리 전체에 하나의 눈금을 억지로 맞추는 것보다, 작은 구간마다 알맞은 눈금을 쓰는 셈이지.
숫자 하나당 8비트만으로 끝나는 단순 FP8과 달리 스케일 정보도 필요하지만, 값의 범위가 구간마다 달라지는 데이터를 더 알맞게 표현할 수 있어.
NVFP4는 이름 그대로 4비트 부동소수점 형식이야. 16개 값마다 블록 스케일을 붙이고 전체 스케일도 함께 사용해, 값 자체는 작게 저장하면서 표현 범위를 조절해.
NVIDIA의 저정밀 연산 기술에서 다루는 형식이지만, Ollama도 Apple Silicon용 MLX 엔진에서 NVFP4 모델 실행을 지원한다고 발표했어.
다만 이런 FP 계열 형식은 모델 파일과 실행 엔진, 하드웨어의 지원 여부를 함께 봐야 해. 이름만 보고 모든 Ollama 환경에서 그대로 쓸 수 있다고 생각하면 곤란하지.
위에 언급한 양자화 방식들은 엔비디아 그래픽카드 사용자가 아니라면, 사용하는 데에 불편함이 많아. 그래서 AMD, 인텔 그래픽카드를 사용하거나 MAC을 이용하는 사용자들은 이름에 "Q"가 들어간 GGUF 양자화 방식을 찾게 돼.
하지만 GGUF 양자화 방식은 기본적으로 속도가 좀 느려. 물론 엔비디아 그래픽카드 사용자 중에도 VRAM의 크기가 너무 작은 경우에는 작은 VRAM에서도 잘 돌아가는 GGUF를 사용하기도 하지만, 속도에서 손해를 보는 건 어쩔 수 없어.
마치 FP16이나 BF16같은 방식이 윈도우에서 실행파일을 바로 실행하는 느낌이라면, GGUF는 압축파일 속에 들어있는 실행파일을 실행하는 느낌이랄까? 직접 실행해서 비교해보면 딱 그런 느낌이 들 거야.
MAC 이용자들은 MAC에 최적화된 MLX 양자화 방식을 찾기도 하지만, 아무래도 보편적인 방식은 아니다보니 내가 쓰고 싶은 모델에 MLX 방식이 없는 경우가 꽤 많아. 이게 엔비디아가 AI 시장에서 강력한 지위를 가지는 이유지.
엔비디아 그래픽카드 사용자들은 어떤 양자화 방식이든 다 지원될 거라는 생각으로 일단 실행하고 보지만, AMD, 인텔, MAC 이용자들은 "이 양자화 방식이 내 그래픽카드에서 지원이 되나?"부터 따져봐야 하는 불편함이 있거든.
Q8_0, Q4_K_M, Q2_0: Ollama에서 자주 보는 이름
✦ 방식별 특징 한눈에 보기
FP 계열부터 GGUF까지
| 형식 | 특징 |
|---|---|
| FP32 | 고정밀·대용량 |
| FP16 | 소수 정밀도 상대적 우수, 지수 범위 좁음 |
| BF16 | 넓은 지수 범위, 소수 정밀도 낮음 |
| INT8 | 정수와 스케일 |
| FP8 | 부동소수점 8비트 |
| MXFP8 | 값 32개당 스케일 |
| NVFP4 | 4비트 부동소수점과 블록 스케일 |
| Q8_0 | 고품질 경향, 큰 용량 |
| Q4_K_M | 용량과 품질의 절충 |
| Q2_0 | 극단 압축, 품질 저하 위험 증가 |
이제 Ollama에서 모델을 찾을 때 자주 보게 되는 Q8_0, Q4_K_M, Q2_0를 보자. 여기의 Q는 GGUF에서 쓰는 특정 양자화 방식 계열을 가리켜. 앞에서 설명한 INT8이나 FP8과 숫자만 비교해 같은 종류라고 보면 안 돼.
Q8_0은 8비트 값에 블록별 스케일을 붙이는 GGUF 양자화 방식이야. 32개 가중치를 34바이트에 담기 때문에 스케일까지 포함하면 평균 약 8.5비트가 들어가.
파일은 꽤 큰 편이지만, 낮은 비트 양자화보다 원래 모델의 성능을 잘 유지하려는 선택지지.
Q4_K_M은 로컬 언어 모델에서 많이 쓰이는 절충안이야. K 계열의 블록 양자화를 바탕으로 하면서 일부 가중치에는 더 높은 정밀도를 배정하는 혼합 구성이 들어가.
그래서 이름은 Q4지만 실제 평균은 모델과 구현에 따라 대략 4.8~4.9비트/가중치 수준이야. Q4라는 이름이 모든 가중치가 정확히 4비트로 저장된다는 뜻은 아니거든.
파일 크기와 답변 품질 사이의 균형을 잡으려는 사람들이 Q4_K_M을 자주 고르는 이유야.
이번에 Ollama가 지원한 Q2_0은 더 과감해. 64개 가중치를 18바이트 블록에 저장하므로 스케일까지 합친 평균이 2.25비트/가중치야.
같은 수의 가중치를 Q4_K_M보다 훨씬 작게 담을 수 있지만, 원래 숫자를 표현할 수 있는 단계도 크게 줄어들지. 긴 추론이나 코딩에서 답이 흐트러지거나, 모델 특유의 능력이 더 많이 손상될 가능성도 커져.
Q2_0과 Q2_K, IQ2는 이름이 비슷해도 서로 다른 양자화 방식이야. 잘 모르겠으면 일단 Q8_0, Q4_K_M, Q2_0 방식부터 우선 시도해보자.
숫자로 보면 차이가 더 잘 보여
✦ 가중치 10억 개의 대략적인 용량
메타데이터·비가중치 텐서 제외, 가중치 데이터 기준
| 형식 | 용량 | 비고 |
|---|---|---|
| FP32 | 약 4GB | 숫자 하나당 4바이트 |
| FP16 / BF16 | 약 2GB | 숫자 하나당 2바이트 |
| INT8 / FP8 | 약 1GB | 대략 1바이트급 |
| Q8_0 | 약 1.06GB | 평균 8.5비트/가중치 |
| Q4_K_M | 약 0.61GB | 평균 약 4.9비트/가중치 |
| Q2_0 | 약 0.28GB | 2.25비트/가중치 |
| NVFP4 | 약 0.5GB | 4비트 값만 계산, 스케일 정보 추가 |
가중치가 10억 개라고 가정하면 FP32는 가중치 데이터만 약 4GB, FP16과 BF16은 약 2GB, INT8과 FP8은 대략 1GB가 필요해.
GGUF Q8_0은 스케일 오버헤드 때문에 약 1.06GB, Q4_K_M은 평균 비트 수를 기준으로 약 0.61GB, Q2_0은 약 0.28GB 수준으로 계산할 수 있지.
실제 모델 파일에는 메타데이터와 다른 형식으로 저장된 일부 텐서도 들어가므로 최종 파일이 이 숫자와 정확히 같지는 않아.
이 숫자만 보면 Q2_0이 무조건 최고처럼 보일 수 있어. 하지만 크기를 4분의 1로 줄였다고 지능을 그대로 보존한 채 공짜로 얻은 결과는 아니야.
양자화는 모델 크기를 줄이는 기술이지, 모델의 능력을 같은 수준으로 유지하면서 모든 비용을 없애는 마법은 아니거든.
내 그래픽카드가 엔비디아가 아니라면.. 어떤 형식을 고르면 좋을까?
✦ 형식 선택 가이드
일반적인 로컬 추론 기준
일반적인 로컬 추론이라면 Q4_K_M부터 시도해 보는 게 좋은 출발점이야. 메모리 사용량을 낮추면서도 쓸 만한 품질을 기대할 수 있거든.
메모리가 넉넉하고 답변 품질이 더 중요하다면 Q5_K_M이나 Q6_K, 더 큰 파일을 감수할 수 있다면 Q8_0도 후보가 돼.
반대로 모델이 메모리에 들어오지 않아 아예 실행조차 할 수 없다면 Q2_0처럼 더 강한 양자화를 시도해 볼 수 있어. 그때는 크기가 줄어드는 만큼 품질도 함께 비교해 봐야 하지.
이번 Ollama 업데이트의 의미도 여기에 있어. 사실 Q2_0은 누구나 가장 먼저 선택할 기본값은 아니야. 큰 모델을 어떻게든 로컬에서 실행해야 할 때 꺼내 드는 작은 배낭 같은 옵션이야.
평소에는 Q4_K_M이나 그보다 높은 형식으로 품질과 용량을 맞추고, 정말 메모리가 모자랄 때 Q2_0을 시험해 보는 편이 현명해.
이번 글은 여기서 마칠게. 또 만나자.
- 4K 이미지 한 장에 약 150원.. 구글 나노바나나 2.1 출시! 쓸만할까?
- 원본을 지키는 AI, 이미지들을 자연스럽게 연결하는 AI… FLUX 3 Image Klein과 Qwen Image 2.1의 차이
- Comfyui에 새 이미지 생성 모델 등장! MOSS-Image는 뭐가 특별할까? (feat.상업적 이용 가능)
🌐 영어 버전: Ollama's New Q2 Quantization Support: Quantization Explained
💬 댓글
아직 댓글이 없어. 첫 댓글을 남겨줄래?
댓글 쓰기