양자화(Quantization) 뜻과 GGUF, 4비트가 뜻하는 것

🤔 같은 모델인데 파일 크기가 18GB와 56GB로 다를 때

올라마나 허깅페이스에서 모델을 고르다 보면 같은 이름 뒤에 q4_K_M, q8_0, bf16 같은 꼬리표가 붙어 있고 파일 크기가 세 배씩 차이가 납니다. 어느 것을 받아야 내 컴퓨터에 올라가는지, 작은 것을 받으면 답이 얼마나 나빠지는지 판단하기 어렵습니다.

이 꼬리표가 양자화 수준을 뜻합니다. 양자화가 무엇이고 비트 수가 크기와 품질을 어떻게 바꾸는지, GGUF와 Q4_K_M 같은 이름을 어떻게 읽는지, 양자화로도 줄지 않는 경우는 무엇인지를 정리했습니다.

🔑 양자화의 정의

양자화(quantization)는 모델의 가중치를 더 적은 비트로 저장해 파일 크기와 필요한 메모리를 줄이는 압축 방법입니다.

가중치는 모델이 학습하면서 맞춰 둔 숫자 하나하나이고, 27B 모델이면 그 숫자가 273억 개입니다. 학습이 끝난 모델은 보통 숫자 하나를 16비트로 저장하는데, 이것을 8비트나 4비트로 줄이면 파일이 그만큼 작아집니다. 사진을 원본 대신 압축 파일로 저장하면 용량이 줄고 확대해 보면 조금 뭉개지듯, 모델도 비트를 줄이면 메모리가 줄고 답의 정확도가 조금 내려갑니다.

숫자 하나가 차지하는 크기로 계산하면 이렇습니다.

개인 장비에서 대개 4비트판을 쓰는 이유가 이 표에 있습니다. 16비트 원본은 그래픽카드 VRAM 32GB에 들어가지 않지만 4비트로 줄이면 여유 있게 들어갑니다. 하드웨어 기초에서 쓴 어림셈인 파라미터 수 곱하기 0.5바이트가 바로 4비트 기준입니다.

📦 GGUF와 양자화 이름 읽는 법

GGUF는 llama.cpp를 만든 게오르기 게르가노프가 만든 파일 형식으로, 가중치와 함께 모델 정보를 담아 빠르게 읽고 쓰도록 설계됐습니다. 허깅페이스 문서에 따르면 파이토치 같은 프레임워크로 만든 모델을 GGUF로 변환해 llama.cpp 계열 도구에서 쓰고, 올라마와 LM Studio도 이 형식을 읽습니다. 허깅페이스에서 GGUF 태그로 걸러 보면 양자화판이 올라온 저장소를 찾을 수 있습니다.

GGUF 파일 이름 뒤에 붙는 꼬리표는 비트 수와 압축 방식을 뜻합니다. 자주 보는 것을 허깅페이스 문서의 표에서 추리면 이렇습니다.

이름의 K는 가중치를 여러 묶음으로 나눠 묶음마다 배율을 따로 두는 방식이고, M은 그 안에서 중간 크기를 뜻합니다. 그래서 Q4_K_M은 정확히 4비트가 아니라 4.5비트 안팎이고 파일도 계산값보다 조금 큽니다. 엔비디아 블랙웰 GPU에서 하드웨어로 처리하는 4비트 부동소수점 형식인 NVFP4처럼 GGUF 밖의 이름도 있는데, 올라마에서는 27b-nvfp4 같은 태그로 올라옵니다.

⚖️ 비트 수에 따른 크기와 품질

Qwen3.8 27B를 기준으로 실제 크기를 보면 이렇습니다. 올라마 태그 크기와 Unsloth 문서의 필요 메모리를 함께 적었습니다.

품질은 비트가 줄수록 내려가는데 폭이 고르지 않습니다. 8비트는 원본과 거의 구분되지 않고 4비트도 대부분의 작업에서 손실이 작은 편이라는 것이 실행 도구 문서들과 커뮤니티의 공통된 설명이고, 3비트 아래로 내려가면 손실이 눈에 띄게 커지는 편입니다. 제조사가 수치를 밝힌 경우도 있어서, 메타는 뮤즈 글리머 압축판 두 가지의 성능 손실을 각각 0.2%와 1.0%로 발표했습니다. 다만 이런 수치는 만든 쪽이 고른 평가 기준에서 나온 값이라, 쓰려는 작업에서 4비트와 8비트를 나란히 돌려 보는 편이 정확합니다.

정리하면 개인 장비에서 고르는 순서는 이렇습니다.

1. 4비트 Q4_K_M이 메모리에 여유 있게 들어가면 그것을 기본으로 씁니다.
2. 메모리가 남으면 6비트나 8비트로 올려 품질을 확인합니다.
3. 4비트도 안 들어가면 3비트로 내리기보다 더 작은 모델을 고릅니다. 크기 선택은 모델 크기 고르기에 있습니다.

🚫 양자화로도 줄지 않는 경우

양자화가 모든 문제를 풀지는 않습니다. 준이아빠블로그에서 확인한 두 가지입니다.

• 더 작은 태그가 없는 모델: 24GB 맥에서 Qwen3.8 27B가 CPU로 떨어졌을 때 양자화를 낮춰 맞추려 했는데, 올라마의 27B 계열 태그는 기본이 이미 Q4_K_M이라 더 줄인 태그가 없었습니다. 직접 변환하는 방법은 있지만 처음 시작하는 단계에서 할 일은 아닙니다.
• 가중치 말고 다른 부분이 큰 모델: Qwen3.8-Flash-Next는 계산에 참여하지 않는 N-gram 임베딩 표가 510억 개 파라미터라, Unsloth 문서 기준으로 1비트로 줄여도 75GB가 필요하고 4비트는 112GB입니다. 비트를 줄여도 표 자체가 남아서입니다.

양자화는 가중치를 줄이는 것이고, 대화 내용을 저장하는 KV 캐시는 컨텍스트 길이에 따라 따로 늘어납니다. 컨텍스트를 길게 잡을 계획이면 가중치 크기에 그 여유를 더해 계산합니다.

🔬 양자화와 증류의 차이

비슷해 보이는 말로 증류(distillation)가 있는데 하는 일이 다릅니다. 양자화는 같은 모델의 숫자를 더 거칠게 저장하는 것이라 파라미터 수가 그대로이고, 증류는 큰 모델에 문제를 대량으로 풀린 뒤 그 답으로 파라미터 수가 적은 새 모델을 학습시키는 것입니다. 27B를 4비트로 줄이면 여전히 27B 모델이고, 671B를 증류해 만든 32B는 파라미터 자체가 다른 모델입니다. 증류가 어떻게 이뤄지는지는 AI 모델 증류 정리에 있고, 개인 장비에서 돌릴 만한 작은 모델이 빠르게 좋아지는 이유가 거기에 있습니다.

⚠️ 자주 하는 실수

• BF16을 받습니다: 원본 정밀도라 가장 좋아 보이지만 27B가 56GB라 개인 장비 대부분에 들어가지 않습니다. 4비트부터 봅니다.
• 비트를 최대한 낮춰 큰 모델을 억지로 올립니다: 2비트 70B보다 4비트 27B가 나은 경우가 많습니다.
• 양자화 이름을 모델 이름으로 봅니다: 27b-q8_0과 27b는 같은 모델의 다른 저장 방식입니다.
• 파일 크기만 보고 메모리를 계산합니다: 컨텍스트용 KV 캐시와 실행 도구 버퍼가 더 붙습니다.

❓ 자주 묻는 질문

양자화한 모델은 원본보다 얼마나 나빠지나요?

비트 수와 작업에 따라 다릅니다. 8비트는 원본과 거의 같고 4비트도 대부분의 작업에서 손실이 작다는 것이 도구 문서들의 공통된 설명이며, 제조사가 밝힌 예로는 메타 뮤즈 글리머 압축판의 손실이 1% 안팎이었습니다. 3비트 아래는 손실이 커지는 편입니다. 수학이나 코드처럼 정확도가 중요한 작업이라면 4비트와 8비트를 같은 문제로 돌려 보고 정합니다.

GGUF 말고 다른 형식도 있나요?

있습니다. 허깅페이스가 함께 권하는 safetensors는 가중치만 담는 형식이라 vLLM 같은 서빙 도구가 씁니다. 애플 실리콘용 MLX 형식, 엔비디아용 NVFP4와 FP8 판도 따로 올라옵니다. llama.cpp와 올라마와 LM Studio로 시작한다면 GGUF만 알아도 됩니다.

직접 양자화할 수 있나요?

할 수 있습니다. llama.cpp에 변환과 양자화 도구가 들어 있고, 허깅페이스에는 저장소 주소를 넣으면 GGUF로 변환해 주는 도구도 있습니다. 다만 인기 있는 모델은 공개 며칠 안에 양자화판이 여러 개 올라오므로, 처음에는 만들어진 것을 받는 편이 빠릅니다.

양자화한 모델은 속도도 빨라지나요?

대체로 빨라집니다. 토큰을 만들 때마다 가중치를 메모리에서 읽어야 하는데, 4비트는 16비트보다 읽을 양이 4분의 1이라 대역폭이 같은 장비에서 초당 토큰이 늘어납니다. 블랙웰 GPU의 NVFP4처럼 하드웨어가 4비트를 직접 처리하는 경우에는 이득이 더 큽니다.

📋 3줄 요약

1. 양자화는 모델의 가중치를 16비트 대신 8비트나 4비트처럼 더 적은 비트로 저장해 파일 크기와 필요한 메모리를 줄이는 압축 방법입니다.

2. 같은 Qwen3.8 27B가 BF16으로는 56GB, 8비트로는 30GB, 4비트 Q4_K_M으로는 18GB이므로 개인 장비에서는 대개 4비트판을 쓰고 3비트 아래로 내려가면 품질 손실이 커지는 편입니다.

3. GGUF는 llama.cpp가 읽는 파일 형식이고 Q4_K_M 같은 이름은 비트 수와 압축 방식을 뜻하며, Flash-Next처럼 임베딩 표가 큰 모델은 1비트로 줄여도 75GB가 남아 양자화가 만능은 아닙니다.

참고 자료

• GGUF 형식과 양자화 종류 (Hugging Face 문서)
• llama.cpp 공식 저장소 (GitHub)
• Ollama Qwen3.8 라이브러리
• Qwen3.8 실행 문서 (Unsloth)
• Qwen3.8-Flash-Next 실행 문서 (Unsloth)
• NVIDIA 기술 블로그: Introducing NVFP4