테마 전환

Ollama 모델 양자화 실전: GGUF 형식과 정확도 손실 완전 분석

Easton editorial illustration: one large model cube compressed into one smaller GGUF cube

RTX 3060, VRAM 12GB로 Llama 3 70B를 실행하고 싶으신가요? CUDA out of memory 오류가 발생하며 14B조차 실행하기 어렵습니다. 양자화를 사용하면 70B 모델을 140GB에서 40GB로 압축할 수 있지만, 정확도는 얼마나 떨어질까요?

Red Hat이 수행한 50만 건의 평가가 답을 제시합니다. 8-bit 양자화는 >99%, 4-bit 양자화는 98.9%의 정확도를 복원했습니다. 일상적인 사용에서는 차이를 거의 느낄 수 없고, 극단적인 학술 벤치마크에서만 미세한 격차를 측정할 수 있습니다.

이 글에서는 GGUF 양자화 원리와 양자화 수준별 정확도 비교, 소비자용 그래픽 카드에 맞는 선택 기준을 자세히 설명합니다. VRAM 부족으로 고민하거나 양자화 모델의 품질이 걱정된다면 필요한 답을 여기서 찾을 수 있습니다.

1. 양자화란 무엇인가: 대규모 모델을 가볍게 만드는 기술

먼저 이런 경험이 있을 겁니다. 고해상도 사진 한 장은 수십 MB이지만 메신저로 전송하면 수백 KB까지 압축됩니다. 화질 손실은 있지만 사진을 알아보는 데는 문제가 없습니다.

모델 양자화도 이와 비슷합니다.

1.1 양자화의 본질

대규모 모델의 가중치 파라미터는 저장할 때 FP16(16-bit 부동소수점)을 사용합니다. 7B 파라미터 모델은 FP16 형식으로 약 14GB의 메모리가 필요합니다. 파라미터 하나가 2바이트를 차지하기 때문입니다.

양자화가 하는 일은 간단합니다. 이 고정밀 값을 저정밀 형식으로 변환합니다. 예를 들어 INT4(4-bit 정수)는 파라미터당 0.5바이트만 차지합니다. 따라서 14GB 모델을 약 3.5GB로 압축할 수 있습니다.

비유하자면 FP16은 각 파라미터를 0.12345678처럼 매우 정밀한 소수로 기록하는 방식입니다. INT4로 양자화하면 3처럼 대략적인 정수만 기록합니다. 정밀도는 줄지만 정보는 남습니다.

1.2 압축 효과는 얼마나 큰가?

다음은 Will It Run AI의 실측 데이터를 정리한 것으로, 양자화 수준에 따른 7B 모델의 메모리 사용량을 보여 줍니다.

양자화 수준VRAM 요구량메모리 절감품질 평가
F16(원본)14.0 GB기준최고
Q8_07.4 GB47%매우 우수
Q5_K_M4.8 GB65%우수
Q4_K_M3.9 GB72%무난
Q3_K_M3.1 GB78%낮음
Q2_K2.6 GB81%매우 낮음

Q4_K_M은 메모리 사용량을 72%나 줄입니다. 원래 14GB VRAM이 필요했던 모델을 이제 4GB VRAM 그래픽 카드에서도 실행할 수 있다는 뜻입니다.

제가 RTX 3060에서 7B 모델을 처음 실행했을 때의 기분은 낡은 자동차에 터보차저를 단 것과 같았습니다. 이전에는 3B 소형 모델만 돌릴 수 있었지만, 이제는 7B 중형 모델도 실행할 수 있게 됐습니다.

72%
메모리 절감
Q4_K_M 양자화 수준

1.3 양자화의 대가는 무엇인가?

사진 압축과 마찬가지로 압축에는 대가가 따릅니다. 사진을 지나치게 압축하면 흐릿해지고 노이즈가 생깁니다. 모델 양자화도 마찬가지입니다.

  • 정확도 손실: 저정밀 값은 원래 값을 정확하게 표현할 수 없어 오차가 발생합니다.
  • 연속성 손실: INT4는 이산적인 정수이고 FP16은 연속적인 소수이므로 일부 미세한 변화가 사라질 수 있습니다.

하지만 핵심 질문은 이것입니다. 손실이 얼마나 크며, 감수할 가치가 있을까요?

이후에는 50만 건의 평가 데이터를 통해 그 답을 집중적으로 살펴보겠습니다. 아직 걱정할 필요는 없습니다. 계속 확인해 보겠습니다.

2. GGUF 형식: 양자화 모델의 표준인 이유

양자화 모델을 다운로드하다 보면 파일 확장자가 모두 .gguf라는 점을 발견할 수 있습니다. 이 형식에는 어떤 특별한 점이 있을까요?

2.1 GGUF란 무엇인가?

GGUF의 전체 이름은 GPT-Generated Unified Format입니다. 이름은 조금 복잡하지만, 간단히 말해 추론을 위해 특별히 설계된 모델 패키징 형식입니다.

llama.cpp 팀이 만들었습니다. 학습이 끝난 모델을 실행하려면 편리한 형식이 필요하다는 실용적인 발상에서 GGUF가 탄생했습니다.

이 형식에는 세 가지 핵심 장점이 있습니다.

단일 파일 패키징. 이전에는 Hugging Face에서 모델을 다운로드할 때 가중치 파일, tokenizer, config.json 등 여러 파일을 받아야 했습니다. GGUF는 이 모든 것을 하나의 파일로 묶습니다. .gguf 파일 하나만 다운로드하면 되므로 누락된 파일을 걱정할 필요가 없습니다.

메모리 매핑 로딩(mmap). 복잡하게 들리지만 원리는 단순합니다. 파일을 메모리 주소에 직접 매핑하고 시스템이 필요한 부분만 읽는 방식입니다. 전체 모델을 먼저 메모리에 올리지 않고, 사용할 부분만 그때그때 읽을 수 있다는 장점이 있습니다. 대규모 모델에는 특히 중요합니다. 70B 모델 전체를 로드하려면 수십 초가 걸리지만 mmap을 사용하면 몇 초 만에 추론을 시작할 수도 있습니다.

크로스 플랫폼 호환성. 동일한 GGUF 파일을 Ollama, LM Studio, llama.cpp, KoboldCPP 등 여러 도구에서 실행할 수 있습니다. 도구를 바꿔도 모델을 다시 다운로드할 필요가 없어 편리합니다.

2.2 GGUF와 다른 형식 비교

모델 형식이 여러 가지라 헷갈리기 쉽습니다. 간단히 비교해 보겠습니다.

형식용도특징지원 도구
GGUF추론단일 파일, 양자화에 적합Ollama, LM Studio, llama.cpp
Safetensors학습/파인튜닝안전하며 pickle 위험 없음PyTorch, Hugging Face
GGML추론(구형)사용 중단llama.cpp(구버전)
PyTorch (.pt/.bin)학습유연하지만 안전하지 않음PyTorch

간단히 말해 GGML은 GGUF의 전신으로 이제 사용되지 않습니다. Safetensors는 학습용 형식이므로 추론 전에 변환이 필요합니다. GGUF는 추론에 특화된 형식이며 Ollama도 기본적으로 이를 사용합니다.

모델을 실행해 추론하는 것이 목적이라면 어떤 형식을 고를지 고민할 필요가 없습니다. GGUF가 올바른 선택입니다.

2.3 Ollama와 GGUF의 관계

Ollama는 백그라운드에서 llama.cpp를 사용해 모델을 실행합니다. llama.cpp는 GGUF 형식만 인식합니다. 따라서 Ollama의 모든 모델은 본질적으로 GGUF 형식입니다.

ollama pull llama3를 실행하면 Ollama는 실제로 모델 저장소에서 GGUF 파일을 다운로드합니다. 공식 모델 라이브러리의 모델은 미리 양자화되어 있으며 기본값은 Q4_K_M입니다.

뒤에서 Hugging Face로부터 다른 양자화 수준의 모델을 가져오는 방법도 설명하겠습니다. 먼저 형식을 이해해야 이후 작업도 더 명확하게 파악할 수 있습니다.

3. 양자화 수준 상세 분석: Q2부터 Q8까지, 무엇이 적합한가?

이 부분이 핵심입니다. 어떤 양자화 수준을 선택해야 할까요? Q4_K_M과 Q5_K_M 중 어느 것이 좋을까요? S, M, L 접미사는 무엇이 다를까요? 하나씩 살펴보겠습니다.

3.1 양자화 수준 비교표

먼저 다음 표를 보세요. Will It Run AI가 Llama 3 8B 모델을 실제로 측정한 데이터입니다.

양자화 수준VRAM 요구량품질 평가적합한 용도
Q8_0~8.5 GB매우 우수VRAM이 충분하고 최고 품질이 필요할 때
Q6_K~6.1 GB우수원본에 가까운 품질을 원할 때의 균형 잡힌 선택
Q5_K_M~5.3 GB양호최적의 균형점, 첫 번째 추천
Q5_K_S~5.0 GB양호Q5_K_M보다 약간 공격적이며 메모리를 절감
Q4_K_M~4.4 GB무난주류 선택, 높은 가성비
Q4_K_S~4.1 GB무난더 공격적이며 품질이 다소 낮음
Q3_K_M~3.5 GB낮음최후의 수단, 품질 손실이 뚜렷함
Q3_K_S~3.2 GB낮음VRAM이 정말 부족한 경우가 아니라면 비추천
Q2_K~2.7 GB매우 낮음품질 손실이 뚜렷해 거의 권장하지 않음

굵게 표시한 Q5_K_M과 Q4_K_M이 제가 가장 권장하는 두 수준입니다. 그 이유는 뒤에서 설명하겠습니다.

3.2 K-quant란? S/M/L 접미사는 어떻게 선택할까?

양자화 수준에 K라는 글자가 들어간 것을 볼 수 있습니다. K는 혼합 정밀도 양자화 전략인 k-quant를 뜻합니다.

원리는 다소 복잡하게 들리지만 핵심 아이디어는 단순합니다. 모든 파라미터를 같은 정밀도로 양자화하지 않습니다. attention 레이어처럼 정확도에 민감한 레이어는 조금 더 높은 정밀도를 사용하고, FFN 레이어처럼 덜 민감한 레이어는 낮은 정밀도로 압축합니다.

S, M, L 접미사는 서로 다른 세 가지 압축 강도를 나타냅니다.

  • S(Small): 가장 공격적이며 압축률과 품질 손실이 가장 큽니다.
  • M(Medium): 균형 잡힌 선택으로 권장합니다.
  • L(Large): 보수적이며 품질은 가장 좋지만 파일이 더 큽니다.

따라서 Q5_K_M과 Q5_K_S는 모두 Q5 수준이지만 Q5_K_M의 품질이 더 좋고 파일도 더 큽니다.

어떻게 선택하면 될까요? 제 의견은 다음과 같습니다.

대부분의 경우 M 접미사를 사용하세요. S는 너무 공격적이라 문제가 생기기 쉽고 L은 너무 보수적이라 메모리를 낭비합니다. M은 충분한 품질을 유지하면서 메모리도 많이 차지하지 않는 균형점입니다.

3.3 작업에 따른 양자화 민감도

모델로 어떤 작업을 할지도 고려해야 합니다.

작업마다 모델 정확도에 대한 민감도가 다릅니다. Will It Run AI는 가장 민감한 작업부터 덜 민감한 작업까지 다음과 같이 정리했습니다.

  1. Coding(프로그래밍): 가장 민감합니다. 코드는 엄격한 논리가 필요하고 파라미터 하나가 잘못되면 전체 코드가 실행되지 않을 수 있습니다. Q5_K_M 이상을 권장합니다.
  2. Reasoning/Math(추론/수학): 매우 민감합니다. 논리적 추론과 수학 계산에는 높은 정확도가 필요합니다. Q5_K_M 이상을 권장합니다.
  3. Creative writing(창작): 중간 정도로 민감합니다. 어느 정도의 오차를 허용할 수 있어 Q4_K_M도 괜찮습니다.
  4. Chat(채팅 대화): 가장 덜 민감합니다. 일상 대화는 정확도 요구가 가장 낮으므로 Q4_K_M으로도 충분합니다.
  5. Summarization(요약): 가장 덜 민감합니다. 요약은 주로 이해 능력에 의존하며 정밀도에 덜 민감하므로 Q4_K_M을 사용할 수 있습니다.

요약하면 코딩과 수학 추론에는 고정밀(Q5 이상)을 사용하고, 채팅과 요약에는 저정밀(Q4)을 사용해도 괜찮습니다.

제 경험상 Q4_K_M 모델로 코드를 작성하면 함수 이름을 잘못 쓰거나 논리가 흐트러지는 등 가끔 이상한 오류가 발생했습니다. Q5_K_M으로 바꾸자 이런 문제가 확실히 줄었습니다. 하지만 채팅에서는 Q4와 Q5의 차이를 크게 느끼기 어려웠습니다.

4. 정확도 손실의 실상: 50만 건 이상 평가 데이터가 알려 주는 답

이제 구체적인 데이터를 살펴보겠습니다. 양자화하면 모델이 멍청해질까 걱정하는 사람이 많고 저도 예전에는 같은 우려가 있었습니다. 하지만 Red Hat의 평가 보고서를 본 뒤에는 그런 걱정이 거의 사라졌습니다.

4.1 Red Hat은 무엇을 했나?

Red Hat은 2024년 10월에 《We ran over half a million evaluations on quantized LLMs》라는 보고서를 발표했습니다. 양자화 모델과 원본 모델의 성능을 비교하기 위해 50만 건이 넘는 평가를 수행했습니다.

"여러 벤치마크와 실제 작업에서 양자화가 모델 품질에 미치는 영향을 확인하기 위해 양자화된 LLM을 50만 회 이상 평가했습니다."

몇 번의 테스트만으로 결론을 낸 것이 아니라 체계적인 대규모 평가였습니다. 여러 평가 프레임워크를 사용했습니다.

  • 학술 벤치마크: OpenLLM Leaderboard v1/v2(MMLU, HellaSwag, ARC 등)
  • 실제 작업: Arena-Hard(실제 사용자 대화 시뮬레이션), HumanEval(코드 생성), HumanEval+(코드 테스트)
  • 텍스트 유사도: ROUGE, BERTScore, STS(의미 유사도)

테스트 모델의 크기도 다양했습니다. Llama 2 7B, 13B, 70B, Mixtral 8x7B MoE, Qwen 시리즈 등이 포함됐습니다.

4.2 핵심 결과: 정확도 복원율

결론은 명확합니다. 다음은 llama.cpp 양자화 방법의 결과입니다.

양자화 수준평균 정확도 복원평가 신뢰도
8-bit>99%95% CI가 BF16과 겹침
4-bit98.9%기준선보다 약간 낮지만 차이가 매우 작음
3-bit~96%확실히 낮아지지만 여전히 사용 가능

핵심 결론은 8-bit 양자화는 사실상 무손실이고, 4-bit 양자화는 평균 98.9%의 정확도를 복원한다는 것입니다.

98.9%
정확도 복원
4-bit 양자화 수준

‘95% CI가 BF16과 겹친다’는 것은 무엇을 의미할까요? 통계적으로 8-bit 양자화 모델과 원본 BF16 모델의 성능에 유의미한 차이가 없다는 뜻입니다. 테스트를 여러 번 실행해도 결과 분포가 거의 같습니다.

4.3 큰 모델과 작은 모델: 양자화의 영향은 다르다

보고서에는 흥미로운 결과가 하나 있습니다. 모델이 클수록 양자화가 정확도에 미치는 영향이 작았습니다.

70B 대규모 모델은 4-bit로 양자화해도 원본과 거의 같은 성능을 보였습니다. 반면 7B 모델은 4-bit 양자화 시 체감할 수 있는 성능 저하가 발생합니다.

이유는 간단합니다. 큰 모델은 파라미터가 많고 중복성이 높습니다. 정밀도를 일부 줄여도 손실을 보완할 파라미터가 충분합니다. 작은 모델은 원래 파라미터가 적기 때문에 압축한 뒤 문제가 생기기 쉽습니다.

여기서 얻을 수 있는 교훈은 다음과 같습니다.

  • 큰 모델은 Q4로도 충분합니다: 70B Q4_K_M은 원본과 차이가 매우 작습니다.
  • 작은 모델은 Q5 이상을 권장합니다: VRAM이 충분하다면 7B 모델은 Q5_K_M이나 Q6_K가 더 안정적입니다.

4.4 커뮤니티의 오해: 양자화하면 멍청해진다는 말이 많은 이유

인터넷에서는 양자화 후 모델 품질이 크게 떨어졌다는 이야기를 자주 볼 수 있습니다. Red Hat 보고서가 이 현상을 분석한 결과, 문제는 양자화 자체가 아니라 평가 방법에 있었습니다.

많은 사람이 MMLU 같은 단일 학술 벤치마크로 테스트한 뒤 ‘양자화 후 MMLU 점수가 5% 떨어졌으니 모델이 멍청해졌다’고 말합니다. 하지만 단일 벤치마크는 실제 사용 환경을 대표할 수 없습니다.

Red Hat은 Arena-Hard와 HumanEval 같은 실제 작업을 포함해 여러 평가 프레임워크를 사용했습니다. 이런 실제 작업에서는 양자화 모델이 원본과 거의 같은 성능을 보였습니다.

다시 말해 채팅, 코딩, 요약 등 일상적인 사용에서는 양자화로 인한 품질 손실을 거의 느낄 수 없습니다. 일부 극단적인 학술 벤치마크에서만 차이를 측정할 수 있습니다.

제 테스트 경험도 비슷합니다. Q4_K_M 모델은 채팅과 요약을 유창하게 수행하고, 코딩에서 가끔 문제가 생깁니다. 그렇다고 모델이 멍청해진 것은 아니며 세부적인 논리 오류가 조금 늘어나는 정도입니다. Q5_K_M으로 바꾸면 이런 문제도 크게 줄었습니다.

5. Ollama 실전: 양자화 모델 선택과 실행 방법

이론을 살펴봤으니 이제 실제 사용법을 알아보겠습니다. Ollama에서 서로 다른 양자화 수준의 모델을 어떻게 선택할까요?

5.1 Ollama의 기본 동작

ollama pull이나 ollama run으로 공식 모델을 가져오면 기본 양자화 수준은 Q4_K_M입니다.

예를 들면 다음과 같습니다.

ollama pull llama3

이 명령은 Llama 3 8B의 Q4_K_M 버전을 다운로드합니다. Ollama는 Q4_K_M을 가장 가성비가 높은 선택으로 봅니다. 메모리 사용량은 합리적이고 품질도 무난하기 때문입니다.

기본 Q4_K_M이 만족스럽지 않고 다른 양자화 수준을 사용하고 싶다면 어떻게 해야 할까요?

5.2 Hugging Face에서 특정 양자화 모델 가져오기

Ollama는 Hugging Face에서 GGUF 형식 모델을 직접 가져올 수 있습니다. 문법은 다음과 같습니다.

ollama run hf.co/{사용자명}/{저장소}:{양자화 수준}

예를 들어 Llama 3.2 3B의 Q8_0 버전을 가져오려면 다음 명령을 실행합니다.

ollama run hf.co/bartowski/Llama-3.2-3B-Instruct-GGUF:Q8_0

이 명령은 bartowski의 Hugging Face 저장소에서 Q8_0 양자화 버전을 다운로드합니다. bartowski는 Hugging Face에서 활발하게 활동하는 양자화 모델 게시자로, 다양한 모델과 양자화 수준을 제공합니다.

Hugging Face에서 GGUF 모델을 찾을 때는 GGUF를 검색어로 사용하세요. 예를 들어 Llama-3 GGUF를 검색하면 여러 양자화 버전을 찾을 수 있습니다.

자주 사용되는 양자화 모델 저장소는 다음과 같습니다.

  • bartowski: 업데이트가 빠르고 모델이 다양합니다.
  • MaziyarPanahi: 대규모 모델(70B 이상)이 많습니다.
  • TheBloke: 오래 활동한 양자화 모델 게시자입니다(일부 모델은 업데이트 중단).

5.3 하드웨어 구성별 권장 사항

VRAM 용량은 양자화 수준을 결정하는 핵심 요소입니다. NVIDIA 그래픽 카드를 기준으로 VRAM 용량별 권장 구성을 정리하면 다음과 같습니다.

VRAM 용량권장 모델권장 양자화비고
4 GB3B 모델Q4_K_M작은 모델의 저비트 양자화, 가까스로 사용 가능
6 GB7B 모델Q4_K_M(빠듯함)3B에는 Q5_K_M이 더 안정적
8 GB7B 모델Q5_K_M8B에는 Q4_K_M을 사용하고 여유 공간 확보
12 GB7B 모델Q6_K / Q8_014B에는 Q5_K_M 사용
16 GB14B 모델Q6_K7B에는 Q8_0, 30B MoE에는 Q4_K_M 사용
24 GB30B 이상 모델Q5_K_M70B에는 Q4_K_M 사용(양자화 필요)

몇 가지 주의할 점이 있습니다.

  • VRAM 사용량은 변동됩니다: 추론 중에는 모델뿐 아니라 KV cache와 컨텍스트 buffer도 필요합니다. 10~20% 정도 여유를 남겨 두는 것이 안정적입니다.
  • 컨텍스트 길이는 메모리에 영향을 줍니다: 긴 컨텍스트는 더 많은 KV cache를 필요로 합니다. 긴 컨텍스트를 자주 사용한다면 VRAM 예산에 더 넉넉한 여유를 두세요.
  • MoE 모델은 특별합니다: Mixtral 8x7B 같은 MoE 모델은 전체 파라미터가 47B이지만 추론마다 일부 파라미터만 사용하므로 같은 파라미터 수의 dense 모델보다 메모리를 적게 사용합니다.

5.4 핵심 원칙: 작은 모델의 고비트 양자화가 큰 모델의 저비트 양자화보다 낫다

이 원칙은 매우 중요합니다. 예를 들어 보겠습니다.

VRAM이 8GB라고 가정하면 다음 구성을 실행할 수 있습니다.

  • 7B 모델 Q5_K_M(~5.3 GB)
  • 13B 모델 Q2_K(~5.0 GB)

어느 쪽의 성능이 더 좋을까요?

정답은 7B Q5_K_M > 13B Q2_K입니다.

이유는 13B Q2_K의 양자화가 너무 공격적이라 정확도 손실이 뚜렷하기 때문입니다. 파라미터가 더 많더라도 압축으로 품질이 크게 훼손됩니다. 7B Q5_K_M은 파라미터가 적지만 정확도를 잘 유지하므로 전체 성능이 오히려 더 좋습니다.

따라서 모델 크기를 고려하기 전에 양자화 수준을 먼저 확보하세요. Q5를 실행할 수 있다면 Q3까지 낮추지 말고, 7B Q5를 실행할 수 있다면 13B Q2를 무리하게 시도하지 마세요.

5.5 실측: 제 RTX 3060 구성

제 그래픽 카드는 RTX 3060 12GB이며, 자주 사용하는 구성은 다음과 같습니다.

  • 일상 채팅: Llama 3.2 3B Q8_0(메모리가 충분하므로 품질 우선)
  • 코딩: Llama 3 8B Q5_K_M(품질 우선)
  • 대규모 모델 테스트: Mixtral 8x7B Q4_K_M(MoE 아키텍처, 12GB에 딱 맞음)

실제로 사용해 보면 꽤 만족스럽습니다. Q8_0 3B 모델의 채팅 유창성이 Q4_K_M 8B보다 조금 더 좋았습니다. 작은 모델의 고비트 양자화가 갖는 이점일 수 있습니다. 코딩에는 Q5_K_M을 사용했으며 오류율이 Q4보다 확실히 낮았습니다.

결론

지금까지 설명한 핵심 내용을 정리해 보겠습니다.

양자화의 본질은 소비자용 하드웨어에서 대규모 모델을 실행할 수 있게 하는 것입니다. 원래 140GB VRAM이 필요했던 70B 모델을 양자화하면 약 40GB로 압축할 수 있습니다. 일반 사용자도 대규모 모델을 활용할 수 있게 만드는 핵심 기술입니다.

정확도 손실에 대한 걱정은 내려놓아도 됩니다. Red Hat의 50만 건 평가 결과, 8-bit는 사실상 무손실(>99% 정확도 복원)이었고 4-bit의 손실도 제어 가능한 수준(98.9%)이었습니다. 일상적인 사용에서는 차이를 거의 느낄 수 없습니다.

양자화 수준을 선택할 때의 핵심 원칙은 다음과 같습니다.

  • VRAM 예산 안에서 고비트 양자화를 우선하세요: Q5를 실행할 수 있다면 Q3까지 낮추지 마세요.
  • 작업 민감도에 맞춰 조정하세요: 코딩에는 Q5 이상, 채팅에는 Q4도 괜찮습니다.
  • 큰 모델은 더 낮은 비트로 양자화해도 됩니다: 70B Q4는 7B Q4보다 훨씬 안정적입니다.

제 권장 사항은 먼저 Q5_K_M을 사용해 보는 것입니다. 메모리는 Q4보다 20%만 더 필요하지만 품질은 확실히 높은 최적의 균형점입니다. 양자화 효과를 직접 경험한 뒤 실제 요구 사항에 맞춰 조정하세요.

더 자세히 배우고 싶다면 이 시리즈의 다른 글인 Ollama 입문 가이드Modelfile 파라미터 상세 설명도 참고하세요. Modelfile에서도 양자화 수준을 직접 설정할 수 있으므로, 이 글의 내용을 활용하면 모델을 더 유연하게 구성할 수 있습니다.

양자화는 마법이 아니라 메모리와 품질 사이에서 최적점을 찾는 균형의 기술입니다. 이 기술을 익히면 그래픽 카드로 더 큰 모델을 실행하고 더 많은 작업을 할 수 있습니다.

FAQ

양자화하면 모델이 멍청해지나요?
아닙니다. Red Hat의 50만 건 이상 평가 데이터에 따르면 8-bit 양자화는 >99%, 4-bit 양자화는 98.9%의 정확도를 복원합니다. 일상적인 사용에서는 차이를 거의 느낄 수 없으며, 극단적인 학술 벤치마크에서만 미세한 격차를 측정할 수 있습니다.
Q4_K_M과 Q5_K_M 중 어느 쪽이 더 좋은가요?
Q5_K_M을 최적의 균형점으로 권장합니다.

• 메모리는 Q4보다 약 20%만 더 필요합니다.
• 품질이 확실히 좋고 코딩 오류율도 낮습니다.
• 대부분의 상황에 적합하며 가성비가 높습니다.

VRAM이 부족하다면 Q4_K_M도 괜찮으며, 채팅 용도로는 전혀 문제가 없습니다.
그래픽 카드별로 어떤 양자화 수준을 사용해야 하나요?
VRAM 용량에 따라 선택하세요.

• 4~6GB: 3B 모델 Q4_K_M 또는 Q5_K_M
• 8GB: 7B 모델 Q5_K_M
• 12GB: 7B 모델 Q6_K/Q8_0 또는 14B Q5_K_M
• 24GB 이상: 70B 모델 Q4_K_M 시도 가능

KV cache와 컨텍스트를 위해 VRAM의 10~20%를 여유로 남겨 두세요.
작은 모델의 고비트 양자화와 큰 모델의 저비트 양자화 중 어느 쪽이 더 좋은가요?
일반적으로 작은 모델의 고비트 양자화가 더 좋습니다. 예를 들어 7B Q5_K_M은 13B Q2_K보다 성능이 좋습니다. 저비트 양자화(Q2)는 정확도 손실이 너무 커서 파라미터가 많아도 품질이 크게 떨어지기 때문입니다. 모델 크기를 고려하기 전에 양자화 수준을 먼저 확보하세요.
K-quant의 S/M/L 접미사는 무엇이 다른가요?
S/M/L은 혼합 정밀도의 압축 강도를 나타냅니다.

• S(Small): 가장 공격적이며 압축률과 품질 손실이 가장 큽니다.
• M(Medium): 균형 잡힌 선택으로 권장합니다.
• L(Large): 보수적이며 품질은 가장 좋지만 파일이 더 큽니다.

대부분의 경우 M 접미사를 사용하면 충분한 품질을 유지하면서 메모리를 많이 차지하지 않습니다.
Hugging Face에서 특정 양자화 수준의 모델을 어떻게 가져오나요?
Ollama의 hf.co 문법을 사용합니다.

```bash
ollama run hf.co/bartowski/Llama-3.2-3B-Instruct-GGUF:Q8_0
```

{양자화 수준}을 원하는 수준(Q4_K_M, Q5_K_M, Q8_0 등)으로 바꾸세요.

3분 읽기 · 게시일: 2026년 4월 22일 · 수정일: 2026년 9월 4일

댓글

GitHub로 로그인하여 댓글을 남기세요

Easton BlogEaston Blog