GGUF 양자화 등급 정리 — Q4_K_M·IQ4_XS·Q8_0 무엇을 받을까

GGUF 파일은 Q4_K_M부터 받으면 됩니다. llama-server -hf와 Hugging Face의 Ollama 연동은 양자화를 지정하지 않으면 이 파일을 받고, CanRun도 Q4_K_M을 기준으로 판정합니다. IQ4_XS는 대개 10분의 1쯤 작으면서 품질 등급은 같은 ‘균형’입니다. Q8_0은 보통 Q4_K_M보다 1.7배쯤 커서, 컨텍스트에 쓸 메모리까지 남을 때만 고를 만합니다. 예를 들어 Mistral Small 3.2 24B는 Q4_K_M·8k에서 16.2GB가 필요합니다. RTX 5060 Ti 16GB에서 쓸 수 있는 15.4GB를 넘어 일부가 시스템 RAM으로 갑니다. 그래도 CanRun 추정으로는 원활하게 돌아갑니다. IQ4_XS는 14.7GB라서 CanRun 계산으로는 아슬아슬하게 GPU 메모리에 다 들어갑니다(ollama ps로 확인).

양자화 이름 읽는 법 — Q4_K_M·IQ4_XS·Q8_0

GGUF 파일은 모델 가중치의 정밀도를 낮춰 저장합니다. 어떤 방식으로 낮췄는지는 파일 이름 끝의 양자화 이름을 보면 알 수 있고, 종류별 설명은 Hugging Face Hub의 GGUF 문서에 있습니다. 아래 표는 unsloth 저장소에 올라온 Qwen3 14B의 실제 GGUF 파일입니다.

이름의 각 부분

• K-quant(Q4_K_M 등): 가중치를 작은 블록으로 나눠 블록마다 스케일을 두고, 이 블록 여러 개를 다시 슈퍼블록으로 묶는 방식입니다(llama.cpp k-quant PR, Hugging Face GGUF 문서). Q 바로 뒤의 숫자는 가중치 하나에 쓰는 명목상 비트 수입니다.
• _S·_M·_L: 같은 계열 안에서 크기가 다른 조합을 뜻합니다. k-quant PR 설명에 따르면 Q3_K_M·Q4_K_M은 일부 텐서(attention.wv·feed_forward.w2 등)에 더 높은 비트 타입을 씁니다. 어느 텐서에 쓰는지는 이후 PR에서 바뀌었습니다.
• IQ4_XS: i-quant 계열입니다. 이 형식을 추가한 PR에 따르면 IQ4_NL을 가중치 256개짜리 슈퍼블록에 담고, 블록 스케일은 6비트로 저장합니다. IQ4 가운데 IQ4_NL보다 작은 변형입니다. Hugging Face 문서에 따르면 i-quant는 슈퍼블록 스케일과 중요도 행렬(importance matrix)을 써서 가중치 값을 구합니다.
• Q8_0: 가중치 32개를 한 블록으로 묶고 블록마다 스케일을 하나씩 두는 단순한 8비트 양자화입니다.
• MXFP4: 마이크로스케일링 방식의 4비트 부동소수점 형식으로, 값을 블록 단위로 묶어 블록마다 스케일 하나를 공유합니다. gpt-oss 모델은 MoE 가중치를 MXFP4로 양자화한 상태에서 후학습을 거쳤습니다(gpt-oss-20b 모델 카드). CanRun 데이터에 있는 gpt-oss 파일도 모두 MXFP4입니다. gpt-oss-20b 파일은 12.1GB이고, 공개된 정밀도를 그대로 쓰므로 ‘준무손실’로 분류합니다.
• UD- 접두사(예: UD-Q2_K_XL, 품질 손실 큼): Unsloth Dynamic 양자화로, 층마다 양자화 타입을 따로 고릅니다(Unsloth 문서). 크기가 모델마다 제각각이라 가중치당 비트로 환산하지 않고 실제 파일 크기만 적습니다.

단계별 파일 크기

표의 ‘가중치당 비트’ 열은 llama.cpp quantize README가 Llama 3.1 8B 파일로 잰 값입니다. 그래서 모델마다 실제 파일과 조금씩 차이가 납니다. 파일 크기(GB)는 대략 ‘파라미터 수(십억) × 가중치당 비트 ÷ 8’로 어림할 수 있습니다. 다만 네이티브 형식인 MXFP4와 UD 파일에는 이 어림을 쓰지 않습니다.

Qwen3 14B 파일 크기는 Q4_K_M이 9.0GB, IQ4_XS가 8.1GB, Q8_0이 15.7GB, Q2_K(품질 손실 큼)가 5.8GB입니다. Q4_K_M과 비교하면 IQ4_XS는 10분의 1쯤 작고, Q8_0은 1.7배쯤 크며, Q2_K는 3분의 2 정도입니다. 이 비율은 Qwen3 14B·Mistral Small 3.2 24B·Gemma 3 12B에서 확인했습니다. Kanana 1.5 15.7B-A3B처럼 비율이 다른 모델도 있습니다.

기본값과 원하는 파일 받기

llama-server -hf는 양자화를 지정하지 않으면 Q4_K_M을 받고, 그 파일이 없으면 저장소의 첫 번째 파일을 받습니다(llama.cpp 서버 README). Hugging Face의 Ollama 연동도 저장소에 Q4_K_M이 있으면 그 파일을 씁니다. CanRun도 Q4_K_M을 기준으로 판정하고, gpt-oss만 MXFP4를 기준으로 삼습니다.

다른 파일을 받으려면 ollama run hf.co/{user}/{repo}:IQ4_XS, llama-server -hf {user}/{repo}:IQ4_XS처럼 끝에 양자화 이름을 태그로 붙입니다. 태그는 대소문자를 가리지 않습니다. 두 명령 모두 환경 변수를 쓰지 않으므로 Windows PowerShell에서도 그대로 실행됩니다.

품질 등급 네 가지와 2비트 양자화

CanRun은 양자화 종류마다 네 가지 품질 등급 가운데 하나를 붙입니다.

• 준무손실: Q8_0, Q6_K, Q5_K_M, 네이티브 MXFP4, F16
• 균형: Q4_K_M, IQ4_XS
• 손실 체감: Q3_K_M, IQ3_XS (3비트)
• 손실 큼: Q2_K, IQ2_M, UD-Q2_K_XL, UD-IQ2_M (2비트)

이 등급은 CanRun이 양자화 종류만 보고 정한 기준입니다. 모델마다 품질을 직접 잰 결과는 아닙니다. 이 가이드의 표에 나오는 모델에는 3비트(손실 체감) 파일이 없습니다.

순서의 근거

llama.cpp quantize README에 따르면 양자화는 정확도를 떨어뜨릴 수 있습니다. 이 손실은 퍼플렉서티(perplexity)나 KL 발산으로 재고, 중요도 행렬(imatrix)을 쓰면 줄일 수 있습니다. 2023년 k-quant PR은 LLaMA 7B~65B의 결과를 보고했습니다. 퍼플렉서티는 양자화한 파일 크기에 따라 꽤 매끄럽게 변했고, 6비트의 퍼플렉서티는 fp16과 거의 같았습니다. 그런데 같은 PR에서 상대 양자화 오차는 모델이 커진다고 계속 줄지 않았고, 30B·65B에서는 다시 7B 수준으로 돌아왔습니다. 그래서 CanRun은 큰 모델이라고 2비트를 잘 견딘다고 보지 않습니다.

2비트가 있는 이유

2비트 양자화는 대개 큰 모델을 위한 것입니다. Llama 3.3 70B는 Q4_K_M 파일이 42.5GB입니다. 2비트인 IQ2_M(품질 손실 큼)으로 줄여도 24.1GB라서, 24GB 카드가 쓸 수 있는 23.4GB보다 큽니다.

이 모델을 기본 양자화 Q4_K_M으로 GeForce RTX 3090에 올리면, CanRun 추정으로는 쓸 수 없을 만큼 느립니다. 메모리가 모자라 아예 못 올리는 것은 아닙니다. 필요량 45.8GB가 사용 가능 메모리의 두 배쯤이라 가중치의 절반가량이 시스템 RAM에 놓이고, 그 때문에 너무 느려집니다.

CanRun이 양자화를 제안하는 규칙

• 판정은 기본 양자화로 냅니다. 기본은 Q4_K_M이고, gpt-oss만 MXFP4입니다.
• 더 작은 양자화는 그 파일로 판정이 좋아질 때만 제안합니다.
• 2비트는 2비트가 아닌 파일로는 어느 것도 돌릴 수 없을 때만 추천합니다. 그 밖에는 추천 양자화보다 판정이 좋을 때만 ‘최후 수단’으로 따로 보여 줍니다. 어느 쪽이든 ‘품질 손실 큼’ 표시를 붙입니다.
• 판정이 같다면 더 큰 양자화는 권하지 않습니다. 속도가 느려지고 컨텍스트에 쓸 메모리가 줄어들기 때문입니다.

한 단계 낮추기 — RTX 5060 Ti 16GB·RTX 4060에서 달라지는 것

Q4_K_M에서 IQ4_XS로 한 단계 낮췄을 때 모델이 GPU에 모두 들어갈지는 간단히 계산해 볼 수 있습니다. Q4_K_M 필요량이 사용 가능 메모리를 넘는 양이 두 파일의 크기 차이보다 작으면 들어갑니다. 이 크기 차이는 대개 Q4_K_M 파일의 10분의 1쯤입니다. 그보다 더 넘치더라도 가중치의 90% 넘게 GPU에 올라가면 판정이 좋아질 수 있습니다(아래 Gemma 3 12B). 한참 넘치면 한 단계로는 부족합니다(아래 Qwen3 14B). 흔히 쓰는 16GB 카드와 8GB 카드로 하나씩 살펴봅니다.

16GB 카드: Mistral Small 3.2 24B

Mistral Small 3.2 24B를 GeForce RTX 5060 Ti 16GB에 올리면, Q4_K_M·8k에서 16.2GB가 필요해 사용 가능 메모리 15.4GB를 넘습니다. 넘친 부분이 시스템 RAM으로 가는데, 이를 부분 오프로드라고 합니다. 그래도 가중치의 90% 이상이 GPU에 올라가므로 Q4_K_M 그대로도 원활하게 돌아갈 것으로 봅니다. IQ4_XS는 14.7GB라서 CanRun 계산으로는 아슬아슬하게 GPU 메모리에 모두 들어갑니다(ollama ps로 확인). 아래 표에서 IQ4_XS 행은 판정이 한 단계 좋게 계산됩니다(보정된 추정). Q8_0 행은 가중치의 상당 부분이 시스템 RAM으로 넘어갑니다.

컨텍스트 길이도 함께 봐야 합니다. Ollama는 감지한 GPU 메모리가 24GiB 미만이면 4k, 24~48GiB면 32k, 48GiB 이상이면 256k 토큰을 기본 컨텍스트 길이로 씁니다 (Ollama 문서, 2026-09-29 확인). 그래서 16GB 카드에서는 Ollama가 4k로 시작합니다. 16k로 늘리면 IQ4_XS도 16.1GB가 필요해 사용 가능 메모리를 넘습니다. 이때 KV 캐시(컨텍스트를 담아 두는 메모리)를 q8_0으로 양자화하면 14.8GB로 줄어, CanRun 계산으로는 아슬아슬하게 들어갑니다(ollama ps로 확인). KV 캐시 양자화는 ‘KV 캐시와 컨텍스트 길이 — 컨텍스트를 늘리면 VRAM이 얼마나 더 필요할까’ 가이드에서 자세히 다룹니다.

이 조합에서 CanRun이 보여 주는 실행 명령은 기본 양자화인 Q4_K_M 파일을 내려받습니다. IQ4_XS를 쓰려면 명령의 태그를 직접 바꿔야 합니다. CanRun은 기본 양자화로 돌릴 수 없을 때만 추천 양자화로 명령을 만들어 줍니다.

ollama run hf.co/bartowski/mistralai_Mistral-Small-3.2-24B-Instruct-2506-GGUF:IQ4_XS

8GB 카드: Gemma 3 12B

GeForce RTX 4060에서 Gemma 3 12B를 돌리면 Q4_K_M·8k에서 8.4GB가 필요한데, 사용 가능 메모리는 7.4GB입니다. GPU에 올라가는 가중치가 90%에 못 미쳐서, CanRun 추정으로는 겨우 돌아가는 정도입니다. IQ4_XS도 7.7GB로 사용 가능 메모리를 넘기 때문에 여전히 부분 오프로드입니다. 하지만 GPU에 올라가는 가중치가 90%를 넘어서, 아래 표의 IQ4_XS 행은 판정이 한 단계 좋아집니다. 모델이 GPU 메모리에 다 들어가서 좋아지는 것은 아닙니다. Q2_K 행(5.9GB)은 GPU에 모두 들어가지만 품질 손실이 큰 2비트입니다. 그래서 CanRun은 이 파일에 ‘품질 손실 큼’을 붙여 최후 수단으로만 보여 줍니다.

한 단계로는 부족한 경우

한 단계 낮춘다고 늘 해결되지는 않습니다. CanRun 추정으로는 GeForce RTX 4060에서 Qwen3 14B도 Q4_K_M으로 겨우 돌아가는 정도입니다. IQ4_XS로 낮춰도 10.1GB가 필요해 사용 가능 메모리 7.4GB를 한참 넘습니다. CanRun 계산으로는 한 단계 낮춰도 판정이 그대로입니다. 가장 작은 파일인 2비트 Q2_K(품질 손실 큼)도 7.7GB로 여전히 사용 가능 메모리를 넘습니다. 그래도 가중치의 90% 이상이 GPU에 올라가 판정이 좋아지므로, CanRun은 이 조합에서 Q2_K에 ‘품질 손실 큼’을 붙여 최후 수단으로 따로 보여 줍니다.

MoE 모델은 따로 봐야 합니다. 한국 모델인 Kanana 1.5 15.7B-A3B를 RTX 3060 12GB에서 Q4_K_M으로 쓰면 12.1GB가 필요해 사용 가능 메모리 11.4GB를 넘습니다. IQ4_XS로 낮추면 10.4GB라서 CanRun 계산으로는 그 안에 들어가지만, 여유는 크지 않습니다. 다만 MoE 전문가를 시스템 RAM에 두는 경우의 속도는 이론 추정(±30%)이고, 실제보다 느리게 나올 가능성이 큽니다. 이 조합을 Q4_K_M으로 쓸 때와 16GB 카드에서 Qwen3 30B-A3B (2507)를 쓸 때가 여기에 해당합니다. 그래서 이런 경우에 생기는 판정 차이는 결론으로 삼지 않습니다.

Q8_0·Q6_K로 올릴 때 드는 비용

준무손실 등급인 Q8_0·Q6_K는 파일이 큰 만큼 메모리를 더 쓰고, 추정 속도도 느려집니다. GeForce RTX 5060 Ti 16GB에서 Qwen3 14B는 기본 양자화 Q4_K_M으로 쾌적하게 돌릴 수 있다고 봅니다. 같은 모델을 Q8_0으로 받으면 8k에서 17.6GB가 필요해 이 카드의 사용 가능 메모리 15.4GB를 넘습니다. 그래서 아래 표의 Q8_0 행은 부분 오프로드로 계산됩니다.

24GB 카드라면 사정이 다릅니다. GeForce RTX 3090에서 Qwen3 14B는 Q4_K_M으로 쾌적하게 돌릴 수 있고, Q8_0 필요량 17.6GB도 사용 가능 메모리 23.4GB 안에 들어갑니다. 이렇게 기본 양자화도, 더 큰 양자화도 쾌적하게 돌아가는 것으로 계산되면 CanRun은 큰 파일을 ‘다른 선택지’에 보여 주기만 합니다. 자동으로 권하지는 않습니다.

대가 1: 속도

dense 모델은 토큰을 하나 만들 때마다 가중치 전체를 읽습니다. 그래서 Qwen3 14B의 Q8_0처럼 Q4_K_M보다 1.7배쯤 큰 파일은 눈에 띄게 느릴 것으로 추정합니다. llama.cpp quantize README의 Llama 3.1 8B 표에서도 Q8_0이 Q4_K_M보다 생성 속도가 낮습니다. 앞에서 본 RTX 5060 Ti 16GB 표에서는 Q8_0 행이 부분 오프로드까지 겹쳐 더 크게 떨어집니다. 부분 오프로드 없이 파일 크기만 달라질 때의 차이는 GeForce RTX 3090에서 Qwen3 14B를 다룬 페이지의 양자화 표에서 볼 수 있습니다. 이 카드에서는 두 파일 모두 GPU 메모리에 다 들어가는 것으로 계산됩니다.

대가 2: 컨텍스트에 쓸 메모리

GeForce RTX 3060 12GB에서 Llama 3.1 8B는 기본 양자화 Q4_K_M·8k에서 쾌적하게 돌아갈 것으로 예상합니다. Q8_0으로 올리면 8k에서는 10.2GB로 사용 가능 메모리 11.4GB 안에 들어갑니다. 16k에서는 11.3GB가 필요해, CanRun 계산으로는 아슬아슬하게 들어갑니다(ollama ps로 확인). 32k에서는 13.6GB가 필요해 넘칩니다. Q4_K_M이라면 32k에서도 10.0GB로 들어갑니다. 같은 메모리에서 Q8_0을 고르면 그만큼 쓸 수 있는 컨텍스트가 짧아집니다.

한국 모델도 마찬가지입니다. Kanana 1.5 8B를 Q8_0으로 받으면 8k에서 10.2GB가 필요합니다. RTX 3060 12GB의 사용 가능 메모리 11.4GB 안에는 들어가지만, RTX 4060의 7.4GB는 넘습니다. Q4_K_M이라면 두 카드 모두에서 쾌적하게 돌릴 수 있다고 봅니다.

무엇을 고를까

메모리를 보고 고르면 됩니다. 실제로 쓰는 컨텍스트에서 Q8_0·Q6_K 필요량이 사용 가능 메모리보다 작을 때만 이 파일들을 고르고, 아니면 Q4_K_M을 씁니다. Q4_K_M이 넘치면 IQ4_XS를 검토합니다. 넘치는 양이 두 파일의 크기 차이보다 작으면, CanRun 계산으로는 IQ4_XS가 GPU에 모두 들어갑니다. 그보다 많이 넘치더라도 카드·모델별 페이지의 양자화 표에서 IQ4_XS 행의 판정이 좋아지는지 확인해 보면 됩니다. 하드웨어를 고를 때도 기준은 같습니다. 쓰려는 양자화와 컨텍스트의 필요량보다 사용 가능 메모리가 큰 구성을 목표로 잡습니다.

함께 보면 좋은 가이드:

• 메모리 구간별로 돌릴 수 있는 모델: 로컬 LLM 사양 — VRAM 8~32GB로 돌릴 수 있는 모델 (2026)
• 컨텍스트가 쓰는 메모리: KV 캐시와 컨텍스트 길이 — 컨텍스트를 늘리면 VRAM이 얼마나 더 필요할까
• 한국 모델의 파일과 사양: 한국 오픈 LLM 정리 — EXAONE·Kanana·HyperCLOVA X·Solar 구동 사양

이 숫자는 얼마나 확실한가

파일 크기는 Hugging Face 저장소에 올라온 실제 GGUF 파일의 크기이고, 단위는 10진 GB입니다. 필요 메모리는 파일, KV 캐시, 연산 버퍼(계산 중간값을 담는 작업 메모리)를 더한 것으로, 추정이 아니라 공식으로 계산한 값입니다. 품질 등급은 양자화 종류마다 정해 둔 것이고, 모델마다 잰 것이 아닙니다. 실제 손실은 모델과 작업에 따라 다릅니다.

속도와 판정은 오차 범위와 신뢰 라벨을 붙인 추정치입니다. 보정된 추정의 오차 범위는 NVIDIA·AMD 그래픽카드에서 dense 모델을 GPU에만 올릴 때 ±12%입니다. 부분 오프로드, MoE, 그 밖의 하드웨어에서는 ±20%입니다. 이론 추정은 ±30%이며, MoE 전문가를 시스템 RAM에 두는 경우가 대표적입니다. 이 경우는 실제보다 느리게 나올 가능성이 큽니다. 이 가이드에 나온 양자화별 판정 표 세 개는 모든 행이 보정된 추정입니다.

공개 벤치마크에서 실제로 잰 속도는 양자화가 정확히 같을 때만 보여 줍니다. 예를 들어 Q4_K_XL로 잰 값을 Q4_K_M의 속도로 쓰지 않습니다. 이 가이드에서 공개 벤치마크 결과가 있는 것은 GeForce RTX 5060 Ti 16GB에서 gpt-oss-20b의 MXFP4 한 건입니다. llama.cpp GitHub 토론에 올라온 값으로, Ollama가 아니라 llama.cpp로 2k 컨텍스트에서 쟀습니다. 조건이 달라서 CanRun의 8k 추정 범위와 나란히 보여 줍니다. CanRun 추정으로는 쾌적하게 돌아가는 조합입니다.

gpt-oss-20b는 추론(reasoning) 모델이라 속도 기준을 1.5배 엄격하게 적용합니다. 이 카드에서 다른 모델들이 어떤지는 GeForce RTX 5060 Ti 16GB 페이지에서 볼 수 있습니다.

표의 값은 다음 환경을 가정합니다. Windows에서 그 카드가 화면 출력도 맡고, 시스템 RAM은 32GB(DDR5), 컨텍스트는 8k, KV 캐시는 f16입니다. 모델은 하나만 올리고, 요청도 한 번에 하나만 처리합니다. 메모리 수치의 파일 크기에는 언어 모델 파일만 넣고, 비전 프로젝터(mmproj) 파일은 넣지 않았습니다. llama-server -hf는 저장소에 비전 프로젝터가 있으면 함께 내려받아 불러옵니다(끄려면 --no-mmproj). 그래서 Gemma 3·Mistral Small 같은 비전 모델은 실제로 메모리를 이보다 더 쓸 수 있습니다. 본문에서 말한 판정은 모두 기본 양자화(Q4_K_M, gpt-oss는 MXFP4)·8k·f16 KV 기준입니다. 다른 양자화의 결과는 양자화별 판정 표에서 해당 행을 보면 됩니다.

자주 묻는 질문

GGUF 양자화는 어떤 것을 받아야 하나요?

Q4_K_M부터 받으면 됩니다. llama-server -hf와 Hugging Face의 Ollama 연동이 기본으로 받는 파일이고, CanRun도 이 파일을 기준으로 판정합니다. 다른 파일로 바꿀지는 메모리를 보고 정합니다. 쓰려는 컨텍스트에서 Q4_K_M 필요량이 사용 가능 메모리를 넘으면 IQ4_XS를 검토할 만합니다. 대개 10분의 1쯤 작고, 품질 등급도 같은 ‘균형’입니다. 예를 들어 Mistral Small 3.2 24B는 8k에서 Q4_K_M으로 16.2GB, IQ4_XS로 14.7GB가 필요하고, 16GB 카드의 사용 가능 메모리는 15.4GB입니다. Q8_0·Q6_K는 쓰려는 컨텍스트까지 메모리에 들어갈 때만 고릅니다. 들어가더라도 추정 속도가 느려지고 컨텍스트에 쓸 메모리가 줄어듭니다. 원하는 파일은 ollama run hf.co/{user}/{repo}:IQ4_XS처럼 태그로 지정하고, 태그는 대소문자를 가리지 않습니다.

IQ4_XS는 Q4_K_M보다 품질이 떨어지나요?

정밀도는 조금 낮을 수 있지만, CanRun은 둘을 같은 ‘균형’ 등급으로 봅니다. 대신 IQ4_XS는 파일이 대개 10분의 1쯤 작습니다. Qwen3 14B라면 IQ4_XS가 8.1GB, Q4_K_M이 9.0GB입니다. IQ4_XS를 추가한 llama.cpp PR 작성자는 이 형식이 크기에 비해 오차가 작은 편이라고 보고했습니다. 다만 CanRun은 모델별 품질을 따로 재지 않았고, 실제 차이는 모델과 작업에 따라 다릅니다. 결국 IQ4_XS를 고르는 이유는 메모리입니다. Q4_K_M 필요량이 사용 가능 메모리를 넘는 양이 두 파일의 크기 차이보다 작으면, CanRun 계산으로는 IQ4_XS에서 모델이 GPU에 모두 올라갑니다.

Q8_0은 Q4_K_M보다 받을 가치가 있나요?

쓰려는 컨텍스트까지 메모리에 들어간다면 그렇습니다. Q8_0은 보통 Q4_K_M보다 1.7배쯤 크고, 품질 등급은 ‘준무손실’입니다. Qwen3 14B를 Q8_0·8k로 쓰려면 17.6GB가 필요합니다. 16GB 카드의 15.4GB는 넘고, 24GB 카드의 23.4GB 안에는 들어갑니다. 들어가더라도 토큰마다 더 큰 파일을 읽어야 해서 추정 속도가 느려지고, 컨텍스트에 쓸 메모리도 줄어듭니다.

2비트 양자화(Q2_K·IQ2_M)도 쓸 만한가요?

CanRun은 최후 수단으로만 봅니다. ‘손실 큼’ 등급이라, 2비트가 아닌 파일로는 어느 것도 돌릴 수 없을 때만 추천하고 항상 ‘품질 손실 큼’을 붙입니다. 2비트는 대개 큰 모델을 위한 것이지만, Llama 3.3 70B의 IQ2_M 파일(품질 손실 큼, 24.1GB)도 24GB 카드가 쓸 수 있는 23.4GB보다 큽니다. 2023년 k-quant 측정에서는 모델이 커져도 상대 양자화 오차가 계속 줄지 않았습니다. 그래서 모델이 크다고 2비트를 잘 견딘다고 보지 않습니다.

q8_0 KV 캐시와 Q8_0 모델 파일은 같은 건가요?

아닙니다. 모델 양자화(Q8_0, Q4_K_M)는 가중치 파일의 크기를 정합니다. KV 캐시 타입(f16, q8_0, q4_0)은 컨텍스트를 담는 메모리의 형식을 정하는 실행 설정이고, 모델 파일과는 따로 정합니다. Ollama는 서버를 띄울 때 OLLAMA_KV_CACHE_TYPE(f16·q8_0·q4_0)을 지정하고 플래시 어텐션을 켜야만 KV 캐시를 양자화합니다. 이 설정은 그 서버가 돌리는 모든 모델에 적용됩니다 (Ollama 문서, 2026-09-29 확인). 필요량에는 두 설정이 함께 반영됩니다. Mistral Small 3.2 24B를 IQ4_XS·16k로 쓰면 KV 캐시가 f16일 때 16.1GB, q8_0일 때 14.8GB가 필요합니다. 자세한 내용은 ‘KV 캐시와 컨텍스트 길이 — 컨텍스트를 늘리면 VRAM이 얼마나 더 필요할까’ 가이드에 있습니다.

출처

• llama.cpp quantize README: Llama 3.1 8B 기준 가중치당 비트·크기·속도 표(양자화 표의 비트 열), 퍼플렉서티·KL 발산으로 재는 손실과 imatrix
• llama.cpp PR #1684 (k-quants): 슈퍼블록 구조, _S·_M·_L 조합, 파일 크기와 퍼플렉서티의 관계, 모델 크기별 상대 오차
• llama.cpp PR #5747 (IQ4_XS): IQ4_XS 구조(IQ4_NL·슈퍼블록·블록 스케일), 크기 대비 오차에 대한 작성자 평가
• Hugging Face Hub 문서: GGUF: 양자화 종류(K-quant, i-quant, Q8_0 블록 스케일, MXFP4 마이크로스케일링 블록 부동소수점)
• Hugging Face 문서: Ollama: 저장소에 Q4_K_M이 있으면 기본으로 받는 동작, 대소문자를 가리지 않는 양자화 태그
• llama.cpp 서버 README: llama-server -hf의 양자화 태그(생략 가능·대소문자 무관, 기본 Q4_K_M, 없으면 첫 파일)와 mmproj 자동 다운로드(--no-mmproj로 끄기)
• gpt-oss-20b 모델 카드: MoE 가중치를 MXFP4로 양자화한 상태의 후학습
• Unsloth 문서: Dynamic GGUF: 층마다 양자화 타입을 고르는 UD- 파일
• Ollama FAQ: OLLAMA_KV_CACHE_TYPE로 켜는 KV 캐시 양자화(플래시 어텐션 필요, 서버 전체 적용)
• unsloth/Qwen3-14B-GGUF: 양자화 표와 양자화별 판정 표의 Qwen3 14B 파일 크기
• bartowski/Llama-3.3-70B-Instruct-GGUF: 2비트 파일을 포함한 Llama 3.3 70B 파일 크기
• bartowski/mistralai_Mistral-Small-3.2-24B-Instruct-2506-GGUF: Mistral Small 3.2 24B의 Q4_K_M·IQ4_XS·Q8_0·Q2_K 파일 크기
• bartowski/google_gemma-3-12b-it-GGUF: Gemma 3 12B 파일 크기