Ollama 양자화 비교: Q4, Q8, fp16 차이점과 선택 가이드

Ollama 양자화의 변화

Ollama 양자화는 모델의 각 가중치를 원래 학습된 파일보다 적은 비트로 저장합니다. q4_K_M로 끝나는 태그는 가중치당 약 4비트를 유지하는 반면, fp16는 16비트를 유지합니다. 따라서 다운로드 크기는 약 4분의 1로 줄어들며, 기기가 각 토큰을 생성하기 위해 읽어야 하는 바이트 수도 4분의 1로 감소합니다. 가중치는 삭제되는 것이 아니라 거친 격자(coarse grid)에 맞춰 반올림되며, 4비트 환경에서도 대부분의 모델은 전체 정밀도와 거의 유사한 답변을 내놓습니다.

이것이 전체적인 트레이드오프입니다. 메모리 점유율이 훨씬 낮아지고 초당 토큰 생성 속도가 빨라지는 대신, 정확도가 약간 손실됩니다. 아래 내용은 파일이 맞지 않아 20분 동안 다운로드하는 일을 방지하기 위해, 특정 모델과 특정 장비에서 이러한 변화를 예측하는 방법입니다.

Ollama가 아직 실행 중이 아니라면 VPS에 Ollama 설치하기부터 시작하십시오. 이 페이지는 ollama ls이 이미 작동 중임을 가정합니다.

Ollama 양자화 태그(예: q4_K_M) 읽는 법

로컬 모델은 llama.cpp가 디스크에 가중치를 저장할 때 사용하는 형식인 GGUF 파일로 배포됩니다. Ollama는 llama.cpp를 기반으로 구축되었으므로, Ollama 태그는 llama.cpp의 양자화 명칭을 그대로 사용합니다.

숫자는 대상 비트 폭을 의미합니다. q4은 대부분의 가중치 텐서가 4비트로 압축되었음을 뜻합니다. q8은 8비트를 의미합니다. fp16는 양자화되지 않은 상태로, 대부분의 모델이 처음 공개될 때 사용하는 16비트 부동 소수점 정밀도를 유지합니다.

K은 K-quant(K-양자화)를 나타냅니다. 가중치는 작은 블록 단위로 그룹화되며, 각 블록은 압축된 값 옆에 고유한 스케일을 저장합니다. 가중치가 모두 0.01 근처에 있는 블록은 세밀한 스케일을 사용합니다. 반면 큰 이상치가 하나 포함된 블록은 거친 스케일을 사용합니다. 이러한 블록별 스케일 덕분에 4비트 파일도 사용 가능한 수준의 성능을 유지하며, 이 때문에 4비트 파일의 실제 용량이 정확히 가중치당 4비트가 되지 않는 것입니다.

마지막 문자는 혼합 방식을 나타냅니다. S, M, L은 대상 비트 폭보다 더 높은 정밀도로 저장할 텐서의 개수를 결정합니다. q4_K_M에서는 반올림 시 손실이 큰 텐서들을 더 넓은 비트로 저장하고, 나머지 대부분은 4비트로 유지합니다. 이것이 q4_K_M가 이전 방식인 q4_0과 거의 동일한 파일 크기임에도 더 나은 결과물을 생성하는 이유입니다.

입력한 이름만으로 추측하지 말고, Ollama가 디스크에 무엇을 가지고 있는지 직접 확인하십시오.

ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_M

ollama show은 architecture, parameters, quantization, context length 및 embedding length를 출력합니다. quantization 줄은 몇 달 전에 다운로드하여 어떤 것을 선택했는지 기억나지 않는 모델의 실제 상태를 보여주는 기준점입니다.

가중치당 비트 수가 파일 크기를 결정합니다

모든 크기 추정은 하나의 숫자에서 시작합니다. 바로 전체 파일에 걸쳐 평균을 낸, 형식에서 가중치당 사용하는 비트 수입니다. llama.cpp는 quantize 문서에서 Llama 3.1 8B에 대해 측정한 수치를 공개하고 있으며, 이는 비슷한 형태의 모든 밀집(dense) 모델에 잘 적용됩니다.

[
  {
    "label": "F16",
    "bits_per_weight": 16,
    "file_gib": 14.96
  },
  {
    "label": "Q8_0",
    "bits_per_weight": 8.5,
    "file_gib": 7.95
  },
  {
    "label": "Q6_K",
    "bits_per_weight": 6.56,
    "file_gib": 6.14
  },
  {
    "label": "Q5_K_M",
    "bits_per_weight": 5.7,
    "file_gib": 5.33
  },
  {
    "label": "Q4_K_M",
    "bits_per_weight": 4.89,
    "file_gib": 4.58
  },
  {
    "label": "Q3_K_M",
    "bits_per_weight": 3.99,
    "file_gib": 3.74
  }
]

해당 표에서 놀라운 점은 두 번째 열입니다. Q4_K_M은 가중치당 4비트가 아닙니다. 블록 스케일과 프로모션된 텐서 모두 실제 공간을 차지하기 때문에 4.89 비트로 측정됩니다. Q8_0 역시 같은 이유로 8비트가 아닌 8.5 비트로 측정됩니다. 측정된 숫자를 사용하면 계산 결과는 실제 파일 크기와 몇 퍼센트 이내의 오차 범위로 일치합니다.

weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB

이것이 두 개의 숫자로 복원한 4.58 GiB Q4_K_M 파일입니다. 또한 이는 가중치가 로드된 후 차지하는 메모리 용량과 거의 일치합니다. Ollama는 로드 시 아무것도 압축 해제하지 않습니다. 양자화된 가중치는 동일한 압축 형태로 메모리에 상주하며, 각 블록은 사용될 때 변환됩니다.

Ollama가 각 모델 크기별로 실제로 제공하는 것

라이브러리는 대부분의 모델 제품군에 대해 q4_K_M, q8_0 및 fp16 태그를 게시합니다. 다음은 2026년 8월 기준 Qwen3 크기이며, 모델 페이지의 태그 목록에서 확인한 내용입니다.

[
  {
    "label": "Qwen3 4B",
    "q4_K_M_gb": 2.6,
    "q8_0_gb": 4.4,
    "fp16_gb": 8.1
  },
  {
    "label": "Qwen3 8B",
    "q4_K_M_gb": 5.2,
    "q8_0_gb": 8.9,
    "fp16_gb": 16
  },
  {
    "label": "Qwen3 14B",
    "q4_K_M_gb": 9.3,
    "q8_0_gb": 16,
    "fp16_gb": 30
  },
  {
    "label": "Qwen3 32B",
    "q4_K_M_gb": 20,
    "q8_0_gb": 35,
    "fp16_gb": 66
  }
]

여기서는 기본 태그가 중요합니다. ollama pull qwen3:8b은 ollama pull qwen3:8b-q4_K_M과 정확히 동일한 5.2 GB를 다운로드합니다. 접미사가 없는 태그가 곧 q4_K_M 빌드이기 때문입니다. Q4_K_M은 라이브러리가 마지못해 제공하는 타협안이 아닙니다. 업스트림에서 선택한 기본값이므로, 직접 테스트하지 않은 모델의 경우 이를 따르는 것이 가장 합리적인 첫걸음입니다. 동일한 논리가 VPS에서 Qwen 3 실행하기의 태그 선택에도 적용됩니다.

이 비율은 모든 행에서 일정하게 유지됩니다. q4_K_M에서 q8_0으로 이동할 때 정확히 두 배가 아닌 약 70%의 비용이 추가되는 이유는 임베딩 및 출력 텐서가 나머지 부분과 동일한 방식으로 확장되지 않기 때문입니다. fp16은 q4_K_M의 약 3배입니다. q4_K_M 기준 32B 모델은 20 GB의 가중치를 가지며, 이는 16 GB 서버에서 어떤 컨텍스트 윈도우로도 수용할 수 없는 크기입니다. 어떤 모델을 직접 호스팅할 수 있는지에 대한 더 자세한 내용은 직접 호스팅 가능한 모델을 참조하십시오.

KV 캐시가 컨텍스트에 의존하는 두 번째 비용인 이유

가중치는 고정 비용입니다. KV 캐시(key and value cache)는 가변 비용입니다. 컨텍스트 윈도우의 모든 토큰은 각 레이어마다 키와 값 벡터를 유지하므로, 캐시는 허용된 윈도우 크기에 비례하여 선형적으로 증가합니다. 이 캐시는 대화가 진행되면서 채워지는 것이 아니라 모델이 로드될 때 전체 윈도우 크기만큼 할당됩니다. 이것이 단 한 단어만 입력하더라도 긴 윈도우 설정이 메모리를 소모하는 이유입니다.

KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16:  2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token

이러한 모델 수치는 모델 자체 설정에서 나옵니다. 36개의 레이어, 8개의 키/값 헤드, 128의 헤드 차원이 그 예입니다. ollama show는 아키텍처와 파라미터 수를 제공하며, Hugging Face의 모델 config.json 페이지에서 나머지를 확인할 수 있습니다. 토큰당 비용에 윈도우 크기를 곱하면 캐시는 더 이상 무시할 수 없는 수준이 됩니다.

[
  {
    "label": "4k",
    "kv_cache_gb": 0.6,
    "floor_ram_gb": 5.8
  },
  {
    "label": "8k",
    "kv_cache_gb": 1.21,
    "floor_ram_gb": 6.4
  },
  {
    "label": "16k",
    "kv_cache_gb": 2.42,
    "floor_ram_gb": 7.6
  },
  {
    "label": "32k",
    "kv_cache_gb": 4.83,
    "floor_ram_gb": 10
  }
]

Ollama의 기본 윈도우인 4096 토큰에서 캐시는 가중치 외에 0.6 GB를 추가로 소모합니다. 윈도우를 32k로 올리면 캐시만으로 4.83 GB에 도달하는데, 이는 양자화된 가중치만큼의 메모리를 차지하며 전체 모델의 최소 메모리 요구량은 10 GB가 됩니다. 이를 최소 요구량이라고 부르는 이유는 연산 버퍼와 운영체제가 그 위에 추가로 메모리를 점유하기 때문입니다. 모델 로드 후 ollama ps의 SIZE 열에서 실제 수치를 확인하십시오.

Ollama를 서비스로 실행할 때 윈도우는 요청별이 아닌 서버 단위로 설정됩니다.

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

systemd 설치의 경우, drop-in 파일을 사용하여 설정하십시오.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

sudo systemctl restart ollama으로 재시작한 뒤, ollama ps의 CONTEXT 열을 확인하여 실행 중인 모델이 실제로 어떤 윈도우 크기로 로드되었는지 확인하십시오. OLLAMA_KV_CACHE_TYPE은 캐시 자체를 양자화합니다. f16이 기본값이며, q8_0은 f16 대비 약 절반의 메모리를, q4_0은 약 4분의 1의 메모리를 사용합니다. 이는 전역 옵션이므로 해당 서버의 모든 모델에 동일하게 적용됩니다. 긴 윈도우를 사용하는 소형 장비에서는 캐시를 절반으로 줄이는 것이 다른 어떤 단일 변경보다 더 많은 메모리를 확보해 줍니다. num_ctx 설정과 그 비용에서 윈도우 자체에 대해 자세히 다룹니다.

8 GB, 16 GB, 32 GB VPS에서 구동 가능한 모델

모델 가중치, KV 캐시, 그리고 운영체제 및 기타 실행 중인 프로세스를 위한 여유 공간을 고려해야 합니다. 소형 VPS에서는 2 GB 정도의 여유 공간을 확보하는 것이 안정적입니다.

8 GB. q4_K_M 양자화가 적용된 4B 모델은 2.6 GB를 차지하며, 긴 컨텍스트 윈도우를 사용할 여유가 있습니다. q4_K_M의 8B 모델은 기본 4k 윈도우 설정으로 간신히 구동 가능하며 여유 공간이 거의 없습니다. 10 GB의 최소 메모리 요구량이 이미 시스템 한계치를 넘어서므로, 8B 모델에 32k 윈도우를 설정하는 것은 권장하지 않습니다.

16 GB. q4_K_M의 8B 모델에 16k 또는 32k 윈도우를 설정하여 쾌적하게 사용할 수 있습니다. q4_K_M의 14B 모델은 가중치 크기가 9.3 GB이며 적절한 크기의 윈도우와 함께 구동 가능합니다. q8_0의 8B 모델은 8.9 GB를 차지하므로 이 또한 구동 가능합니다. 직접 프롬프트를 입력하며 두 모델을 비교해보는 것이 이 주제를 이해하는 데 가장 유익한 시간이 될 것입니다.

32 GB. q8_0의 14B 모델(16 GB)과 q4_K_M의 32B 모델(20 GB) 모두 로드할 수 있습니다. 32B 모델에 큰 윈도우를 설정하면 메모리 한계치에 도달할 수 있으므로, 단순히 가능할 것이라고 가정하기보다는 ollama ps를 모니터링하십시오.

양자화 시 가장 먼저 저하되는 요소

양자화 오류는 모델의 모든 기능에 균일하게 나타나지 않습니다. 유창함은 가장 마지막까지 유지되는데, 바로 이 때문에 손상을 간과하기 쉽습니다. 심하게 양자화된 모델이라도 여전히 매끄러운 문장을 작성하기 때문입니다. 가장 먼저 저하되는 것은 정확성입니다. 버전 번호, API 시그니처, 날짜 등을 정확하게 기억하는 능력이 떨어집니다. 2단계에서 발생한 작은 오류가 8단계에서 오답으로 이어지는 긴 추론 과정도 마찬가지입니다. 괄호 하나만 잘못되어도 도구 호출이 실패하는 엄격한 출력 형식 역시 취약합니다.

마지막 항목은 실무적인 테스트가 됩니다. 모델이 코드가 파싱할 JSON을 반환해야 할 때, 양자화로 인한 손상은 모호하게 나빠진 문장이 아니라 파싱 오류로 나타나므로 즉시 확인할 수 있습니다. 코딩 에이전트는 이 테스트의 가장 가혹한 형태입니다. 에이전트는 모델을 계속해서 도구 호출로 몰아붙이기 때문에, Ollama 서버에 에이전트를 연결해보면 과도한 양자화가 적용되었을 때 오후가 지나기 전에 바로 문제가 드러납니다.

4비트 미만으로 내려가면 손실이 급격히 커집니다. q3 및 2비트 유형은 작은 하드웨어에 큰 모델을 억지로 구겨 넣어야 하는 상황을 위한 것이며, 모델을 아예 실행하지 못하는 것보다는 나은 선택지일 뿐입니다. 이를 기본값으로 사용하는 것은 권장하지 않습니다. q4_K_M과 q8_0 사이의 격차는 작아서 공개된 퍼플렉서티(perplexity) 표만으로는 본인의 작업 부하에 적합한지 판단할 수 없으므로, 그런 방식으로 결정하지 마십시오. 직접 작성한 프롬프트 30개를 두 모델에 모두 실행해보고 출력 결과를 확인하십시오.

q8_0 또는 fp16이 RAM을 사용할 가치가 있는 경우

메모리가 충분히 여유롭고 구조화된 추출, 도구 호출, 컴파일이 필요한 코드 작성과 같이 작은 오류도 허용되지 않는 작업이라면 q8_0을 선택하십시오. 이는 모델이 눈에 띄게 똑똑해지는 것이 아니라, 일종의 보험을 드는 것과 같습니다.

fp16를 선택하는 이유는 두 가지뿐입니다. 직접 모델을 양자화하여 소스 파일이 필요하거나, 4비트 빌드에서 어느 정도의 성능 손실이 발생하는지 확인하기 위한 기준점을 측정하는 경우입니다. fp16으로 서비스를 운영하면 q4_K_M보다 3배 많은 메모리를 소비하지만, 대부분의 사용자는 블라인드 테스트에서 그 차이를 구분하지 못합니다. CPU만 사용하는 환경에서는 토큰 생성 속도 또한 3분의 1로 줄어듭니다.

고정된 메모리 예산 내에서 적용되는 더 강력한 규칙은 다음과 같습니다. 일반적으로 q4_K_M의 더 큰 모델이 q8_0의 더 작은 모델보다 성능이 우수합니다. 9.3 GB의 14B 가중치 모델과 8.9 GB의 8B 가중치 모델은 RAM(random access memory) 사용량이 거의 비슷하지만, 더 큰 모델이 더 많은 정보를 알고 있습니다. 이를 맹목적으로 신뢰하기보다는 직접 프롬프트를 입력하여 테스트해 보십시오.

CPU 전용 추론은 메모리 대역폭의 제한을 받습니다

대부분의 VPS 플랜에는 GPU가 없으므로 모델은 호스트 CPU의 시스템 메모리에서 실행됩니다. 토큰 하나를 생성할 때마다 모든 가중치를 한 번씩 읽어야 하므로, 생성 속도는 연산 능력이 아닌 메모리 대역폭에 의해 결정됩니다. 따라서 구매한 CPU 코어 수와는 무관한 성능 상한선이 존재합니다.

tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB  =  9.6 tokens/s    qwen3 8B q4_K_M
50 GB/s / 8.9 GB  =  5.6 tokens/s    qwen3 8B q8_0
50 GB/s / 16 GB   =  3.1 tokens/s    qwen3 8B fp16

50 GB/s는 듀얼 채널 DDR4-3200 호스트의 대략적인 이론상 수치입니다. VPS는 해당 버스를 머신 내의 다른 모든 테넌트와 공유하므로 실제 가용 대역폭은 이보다 작습니다. 따라서 이 수치는 도달할 수 없는 최대치로 간주해야 합니다. 여기서 중요한 것은 경향성입니다. CPU 환경에서는 가중치당 비트 수를 절반으로 줄이면 토큰 생성 속도가 대략 두 배로 빨라집니다. 양자화(Quantization)는 GPU가 없는 환경에서 속도를 높일 수 있는 가장 큰 수단입니다.

프롬프트 처리 방식은 다릅니다. 긴 프롬프트를 읽는 작업은 대역폭이 아닌 연산 능력에 제한을 받으므로, 생성 속도에는 거의 영향을 주지 않더라도 코어 수가 많을수록 처리 속도가 향상됩니다. 4k 프롬프트를 빠르게 입력받은 뒤 생성 속도가 느려지는 것은 정상적인 동작입니다.

이러한 연산 수치를 그대로 받아들이지 마십시오. 자신의 서버에서 직접 토큰 생성 속도를 측정하고, 각 양자화 단계별로 동일한 프롬프트를 사용하여 얻은 실제 수치를 기준으로 판단하십시오.

직접 모델 양자화하기

Ollama는 fp16 또는 fp32 소스에서 양자화된 모델을 빌드할 수 있습니다. 이는 모델을 파인튜닝했으나 라이브러리 태그가 존재하지 않을 때 유용합니다. Modelfile이 양자화되지 않은 가중치를 가리키도록 설정하십시오.

FROM /path/to/my/model/f16

그런 다음 빌드하고 확인하십시오.

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize는 q8_0, q4_K_S 및 q4_K_M을 허용합니다. 여기에는 q6_K 또는 q5_K_M 옵션이 없으므로, 해당 방식이 필요한 경우 llama.cpp의 자체 도구로 양자화한 뒤 완성된 GGUF 파일을 가져와야 합니다. ollama show의 quantization 줄은 빌드가 요청대로 수행되었는지 확인하는 방법입니다.

오류 발생 시 확인 사항

GPU를 예상했으나 모든 작업이 CPU에서 실행되는 경우. PROCESSOR 열을 확인하십시오.

ollama ps

이 열에는 100% GPU, 100% CPU 또는 48%/52% CPU/GPU와 같은 분할 상태가 출력됩니다. 분할 상태는 가중치와 KV 캐시가 VRAM(그래픽 카드의 메모리)에 모두 적재되지 않아 모델의 일부가 시스템 메모리에 배치되었음을 의미합니다. 모든 토큰이 느린 쪽의 처리를 기다려야 하므로 속도는 CPU 전용 속도와 비슷해집니다. 컨텍스트 윈도우를 줄이거나, 캐시를 양자화하거나, 더 작은 빌드를 가져오십시오. 코어를 추가해도 해결되지 않습니다.

모델 로딩 중 프로세스가 강제 종료되는 경우. 커널 로그와 서비스 로그를 확인하십시오.

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50

Out of memory: Killed process 문구가 포함된 줄은 가중치, KV 캐시, 버퍼의 총합이 서버의 메모리 용량을 초과했음을 의미합니다. 스왑이 설정되지 않은 VPS에서는 해당 줄이 나타나기 전까지 시스템 전체가 수 초간 멈출 수 있습니다.

설정을 변경하지 않았는데 답변 품질이 저하된 경우. 동일한 모델의 두 빌드가 서로 다른 태그로 ollama ls에 공존할 수 있으며, 접미사가 없는 이름을 가져오는 스크립트는 라이브러리가 현재 가리키는 대상을 따라갑니다. 설정 파일의 이름만 신뢰하지 말고, 클라이언트가 요청하는 정확한 태그를 대상으로 ollama show를 실행하여 quantization 줄을 확인하십시오.

FAQ

어떤 Ollama 양자화 버전을 받아야 합니까?

q4_K_M로 시작하십시오. 이는 Ollama 라이브러리가 대부분의 모델에 대해 기본 태그로 제공하는 버전이므로, ollama pull qwen3:8b와 ollama pull qwen3:8b-q4_K_M은 동일한 파일을 가져옵니다. 메모리가 충분하고 도구 호출(tool calling)이나 구조화된 JSON 출력처럼 작은 오차도 허용되지 않는 작업일 때만 q8_0로 이동하십시오. 메모리 예산이 정해져 있다면, 일반적으로 q8_0을 적용한 작은 모델보다 q4_K_M을 적용한 큰 모델의 성능이 더 우수합니다. 따라서 정밀도를 위해 RAM을 추가하기 전에 이 조합을 먼저 테스트하십시오.

q4_K_M은 정말 가중치당 4비트를 의미합니까?

아닙니다. Llama 3.1 8B 모델에서 측정된 값은 가중치당 4.89 비트입니다. 이는 가중치 블록마다 고유한 스케일 값을 저장하고, 가장 민감한 텐서는 더 넓은 데이터 타입으로 처리하기 때문입니다. Q8_0 역시 같은 이유로 8비트가 아닌 8.5 비트로 측정됩니다. 용량을 추정할 때는 측정된 수치를 사용하십시오. 파라미터 수에 가중치당 비트 수를 곱하고 8로 나누면 파일 크기(바이트 단위)가 나옵니다.

CPU 전용 VPS에서 8B 모델을 구동하려면 RAM이 얼마나 필요합니까?

가중치, KV 캐시, 그리고 여유 공간을 합산해야 합니다. Qwen3 8B 모델의 q4_K_M 버전은 가중치만 5.2 GB입니다. 기본 4096 토큰 윈도우에서 캐시는 0.6 GB를 추가로 점유하며, 연산 버퍼와 운영체제를 제외하고도 최소 5.8 GB가 필요합니다. 32k 윈도우를 사용할 경우 캐시만으로 4.83 GB가 소요됩니다. 짧은 윈도우라면 8 GB를, 긴 윈도우를 원한다면 16 GB를 계획하십시오.

GPU가 있는 서버인데 왜 모델이 CPU 100%를 점유합니까?

ollama ps를 실행하여 PROCESSOR 열을 확인하십시오. 100% CPU 또는 48%/52% CPU/GPU과 같은 분할 수치가 표시된다면, 가중치와 KV 캐시가 VRAM에 모두 들어가지 않아 Ollama가 모델의 일부 또는 전체를 시스템 메모리에 배치했다는 의미입니다. 모델 로드 시 전체 윈도우에 대한 캐시가 할당되므로, 그래픽 카드가 수용할 수 있는 것보다 큰 컨텍스트 윈도우를 설정했을 때 주로 발생합니다. OLLAMA_CONTEXT_LENGTH로 윈도우 크기를 줄이거나, OLLAMA_KV_CACHE_TYPE=q8_0을 설정하여 캐시를 절반으로 줄이거나, 더 작은 양자화 버전을 사용하십시오.