Ollama 양자화 비교: Q4, Q8, fp16 성능과 메모리 차이

Ollama 양자화의 변화

Ollama 양자화는 모델의 각 가중치를 원래 학습된 파일보다 적은 비트로 저장합니다. q4_K_M로 끝나는 태그는 가중치당 약 4비트를 유지하는 반면, fp16는 16비트를 유지합니다. 따라서 다운로드 크기는 대략 4분의 1로 줄어들며, 기기가 각 토큰을 생성하기 위해 읽어야 하는 바이트 수도 4분의 1로 감소합니다. 가중치는 삭제되는 것이 아니라 거친 그리드에 맞춰 반올림되며, 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를 나타냅니다. 가중치는 작은 블록으로 그룹화되며, 각 블록은 압축된 값 옆에 자체 스케일을 저장합니다. 가중치가 모두 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 태그를 게시합니다. 일부 최신 제품군은 이러한 패턴을 따르지 않으며, 라이브러리에서 클라우드 전용 태그로만 나타나 어떤 너비로도 가져올 수 없는 경우가 있습니다. 이것이 바로 VPS에서 GLM 5.2 실행을 시도할 때 마주하게 되는 장벽입니다. 다음은 2026년 8월 기준 Qwen3 크기이며, 모델 페이지의 태그 목록에서 읽어온 값입니다. 아래의 모든 수치는 RAM에 로드되기 전의 디스크 점유 용량이며, 이 중 두세 개만 합쳐도 소규모 VPS의 root 볼륨을 가득 채울 수 있습니다. 따라서 태그를 수집하기 전에 Ollama가 다운로드한 모델을 저장하는 위치를 파악해 두는 것이 좋습니다.

[
  {
    "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의 세 배입니다. 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 설정과 그 비용에서 윈도우 자체에 대해 자세히 다룹니다. 캐시는 서버당 한 번이 아니라 동시 요청 슬롯당 한 번씩 크기가 결정됩니다. 따라서 Ollama가 두 개의 프롬프트를 동시에 처리하도록 허용하면 방금 계산한 수치가 두 배가 됩니다. 이것이 병렬 슬롯 수와 대기열 제한 선택의 산술적 근거입니다.

8 GB, 16 GB 또는 32 GB VPS에 적합한 모델

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

8 GB. q4_K_M 양자화 모델을 적용한 4B 모델은 2.6 GB를 차지하며 긴 컨텍스트 윈도우를 사용할 여유가 있습니다. 8B 모델을 q4_K_M으로 실행하면 기본 4k 윈도우에서는 적합하지만 여유 공간이 매우 부족합니다. 8B 모델에 32k 윈도우를 설정할 계획은 세우지 마십시오. 10 GB의 최소 RAM 요구량이 이미 시스템 가용 범위를 넘어서기 때문입니다.

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

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

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

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

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

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

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

메모리가 충분히 여유롭고 구조화된 데이터 추출, 도구 호출(tool calling), 컴파일이 필요한 코드 작성 등 작은 오류조차 허용되지 않는 작업을 수행할 때는 q8_0을 선택하십시오. 이는 모델이 눈에 띄게 똑똑해지는 것이 아니라, 일종의 보험을 드는 것입니다.

fp16를 선택하는 이유는 두 가지뿐입니다. 직접 모델을 양자화(quantize)하기 위해 원본 파일이 필요하거나, 4비트 빌드에서 어느 정도의 성능 손실이 발생하는지 확인하기 위한 기준점(baseline)을 측정할 때입니다. 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 환경에서는 가중치당 비트 수를 절반으로 줄이면 토큰 생성 속도가 대략 두 배로 빨라집니다. 양자화는 GPU가 없는 환경에서 속도를 높일 수 있는 가장 큰 수단입니다. 결과적으로 얻게 되는 속도가 허용 가능한 수준인지는 모델에 따라 다르며, VPS에서의 Nemotron 3.5 Lightning 문서는 특정 빌드, 태그, RAM 수치를 기준으로 해당 계산을 수행합니다. 대기 시간의 나머지 절반은 모델이 얼마나 많은 내용을 작성하느냐에 달려 있습니다. 초당 10 토큰의 속도에서 600 토큰 분량의 답변은 1분 전체를 소모하므로, num_predict로 응답 길이를 제한하는 것이 정밀도를 한 단계 더 낮추는 것보다 대기 시간을 줄이는 데 효과적일 때가 많습니다.

프롬프트 처리 방식은 다릅니다. 긴 프롬프트를 읽는 작업은 대역폭이 아닌 연산 능력의 제한을 받으므로, 생성 속도에는 거의 영향을 주지 않더라도 추가 코어가 도움이 됩니다. 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로 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은 동일한 파일을 가져옵니다. 메모리가 충분하고 도구 호출이나 구조화된 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을 설정하여 캐시를 절반으로 줄이거나, 더 작은 양자화 버전을 선택하십시오.