로컬 AI 양자화 Q4 vs Q8 실측 — 메모리 1.6배 더 내줬는데 한국어는 안 나아졌습니다 (2026.7)

같은 모델을 두 벌 받았습니다. 한 벌은 4.7GB짜리 Q4_K_M, 다른 한 벌은 8.1GB짜리 Q8_0. 메모리를 1.6배 내주고 생성 속도를 40% 깎아먹은 대가로 한국어 정확도가 얼마나 오르는지 보려던 건데, 결론부터 말하면 그 여분의 8GB는 헛수고에 가까웠습니다. 고생한 건 그래픽카드뿐이었어요.

안녕하세요, 그래픽카드 한 장으로 AI 일꾼을 몇 명까지 굴릴 수 있나 계산하는 게 취미인 1인 기업가 시네입니다. 지난번 모델 크기별 GPU 사다리에서는 "몇 B까지 올라가나"를 쟀는데, 그때 못 건드린 축이 하나 남아 있었습니다. 크기는 그대로 두고 양자화만 바꾸면 무엇이 달라지는가.

결과부터 — Q4_K_M vs Q8_0 한눈에

측정 환경은 그래픽카드 RTX 4070 Ti SUPER(VRAM 16GB) 한 장, ollama 로컬 구동, 모델은 qwen2.5:7b-instruct입니다. 2026년 7월 26일 측정값입니다.

항목	Q4_K_M	Q8_0	FP16
ollama 표기 파일 크기	4.7GB	8.1GB	15GB
레지스트리 실측 바이트	4,683,073,952	8.10GB	15.24GB
파라미터당 바이트(7.62B 기준)	약 0.61	약 1.06	약 2.0
VRAM 점유 증가분	4,671 MiB	7,556 MiB	실행 안 함
생성 속도(예열 후 평균)	118.7 tok/s (n=5)	74.0 tok/s (n=5)	실행 안 함
첫 호출 tok/s(콜드 로딩 포함)	56.0	73.4	실행 안 함
코드 생성 후 실제 실행(TXT-02)	2회 모두 성공	2회 모두 성공	실행 안 함
한국사 사실 3문항 정답(TXT-04)	1회차 1 · 2회차 1	1회차 1 · 2회차 1	실행 안 함
함정 2문항 정직 거르기	1회차 2 · 2회차 2	1회차 2 · 2회차 0	실행 안 함

숫자 세 개만 기억하면 됩니다. VRAM은 1.62배, 속도는 0.62배, 한국어 정답률은 제자리. 같은 일꾼을 굴리는데 책상만 1.6배 넓게 내준 셈이고, 사람 몫으로 돌아온 이득은 없었습니다.

어떻게 쟀나 — 테스트 조건

공정하게 비교하려면 축 하나만 움직여야 합니다. 같은 일꾼에게 같은 문제지를 주고 책상 크기만 바꿔 굴리는 셈이죠. 그래서 모델 계열도 크기도 프롬프트도 전부 고정하고 양자화 태그만 갈아 끼웠습니다.

• 고정 테스트셋 3종을 각 2회씩, 총 6회 투입했습니다. TXT-01(한국어 장문 요약), TXT-02(파이썬 코드 생성), TXT-04(한국사 사실성·함정 질문)입니다. 같은 ID = 같은 입력이라 두 양자화가 정확히 같은 문제를 풀었습니다.
• 코드 채점은 눈으로 안 했습니다. 모델이 뱉은 dedup_sort 함수를 파일로 떼어내 실제로 실행하고, [3,1,2,3,1]을 넣어 [3,2,1]이 나오는지로 판정했습니다.
• VRAM은 0.5초 간격으로 샘플링해 최대값을 잡고(Q4_K_M 120회·Q8_0 97회), 측정 전 유휴 점유(1,019 MiB)를 빼서 증가분만 남겼습니다. 다만 유휴 점유 자체가 바탕화면 상태에 따라 200MiB 안팎으로 흔들리니, 증가분은 그만큼의 오차를 안고 보는 게 맞습니다. 최대값 원본은 Q4_K_M 5,690 MiB, Q8_0 8,575 MiB입니다.
• 속도는 첫 호출을 평균에서 뺐습니다. 첫 호출엔 모델을 디스크에서 올리는 시간이 섞여 있어 두 양자화를 비교하는 지표로 못 씁니다.
• 모델은 한 번에 하나만 올렸고(OLLAMA_MAX_LOADED_MODELS=1), 측정이 끝나면 바로 내려 VRAM을 반납했습니다.

VRAM — 파일 크기보다 더 먹습니다

가장 먼저 깨지는 기대가 이겁니다. "4.7GB짜리니까 VRAM도 4.7GB쯤 먹겠지"가 안 맞습니다.

Q4_K_M은 4,671 MiB, Q8_0은 7,556 MiB를 더 물었습니다. 파일보다 조금씩 더 먹는 건 가중치 말고도 컨텍스트를 담는 캐시와 런타임 몫이 같이 올라가기 때문입니다. 그래서 "카드 VRAM = 모델 파일 크기"로 계산하면 실전에서 아슬아슬하게 모자랍니다.

재미있는 건 비율입니다. 파일 크기 비율(8.10 ÷ 4.68 = 1.73)보다 실제 VRAM 비율(7,556 ÷ 4,671 = 1.62)이 조금 낮습니다. 일꾼을 어떤 크기로 굴리든 책상·의자 값은 똑같이 붙기 때문이에요. 가중치가 아닌 고정 비용이 양자화와 무관하게 얹힌다는 뜻입니다.

파라미터당 바이트를 계산해 보면 양자화가 뭘 하는 건지 선명해집니다. 7.62B 파라미터로 나누면 Q4_K_M은 약 0.61바이트, Q8_0은 약 1.06바이트, FP16은 약 2.0바이트입니다. 비트로 바꾸면 약 4.9비트 / 8.5비트 / 16비트인데, llama.cpp 공식 문서가 공개한 bits/weight 표(Q8_0 8.5008, F16 16.0005)와 소수점까지 맞아떨어집니다. Q4_K_M이 정확히 4비트가 아니라 4.9비트인 이유는 이름에 답이 있습니다. _K_M은 대부분을 4비트로 두되 민감한 일부 텐서만 더 높은 비트로 올려주는 혼합 방식이라, 순정 4비트보다 살짝 두껍습니다.

속도 — 정밀도를 올린 만큼 정확히 느려졌다

예열 후 생성 속도는 Q4_K_M 118.7 tok/s, Q8_0 74.0 tok/s였습니다. 각각 5회 측정했는데 편차가 거의 없었습니다. Q4_K_M은 118.3~119.7, Q8_0은 73.7~74.5 사이에 전부 들어왔습니다.

약 1.6배 차이입니다(반올림 전 평균으로 계산하면 1.605배). 메모리 대역폭을 두 배 가까이 더 읽어야 하니 그만큼 늦어지는 건 예상대로예요. 이 부분은 통설이 맞았습니다. 같은 시간 동안 굴리는 분량으로 환산하면, Q4_K_M 일꾼 하나가 야근 없이 Q8_0 일꾼 1.6명치를 처리하는 셈입니다.

콜드 로딩은 일부러 비교에서 뺐습니다. 첫 호출 벽시계가 Q4_K_M 39.65초, Q8_0 15.39초로 오히려 작은 모델이 더 느렸는데, 이건 성능 차이가 아니라 디스크에서 처음 읽어 올릴 때의 캐시 상태 차이입니다. 이런 걸 "Q8이 로딩이 빠르다"로 포장하면 가짜 정밀입니다. 그래서 표에 값만 적어 두고 결론에서는 안 씁니다.

한국어 사실성 — 여기서 통설이 깨졌습니다

월급을 올려준 만큼 똑똑해졌느냐. 여기가 이 테스트의 본론이고, 일꾼을 고를 때 실제로 갈리는 지점입니다.

TXT-04는 정답이 명확한 한국사 문항 3개와, 애초에 전제가 틀린 함정 문항 2개로 이뤄져 있습니다. 함정은 "임진왜란이 발발한 1682년의 국왕"(연도가 틀림)과 "세종대왕이 발명한 전기 자동차 이름"(그런 물건이 없음)입니다.

함정은 1회차에서 둘 다 잘 걸렀습니다. Q4_K_M도 Q8_0도 "1682년이 아니라 1592년"이라고 연도를 정정했고, 전기 자동차에 대해서는 "존재하지 않는 전제가 포함되어 있습니다"라고 답했습니다. Q4_K_M은 2회차에서도 둘 다 걸렀습니다.

표의 Q8_0 2회차만 0인데, 이건 함정에 걸려든 게 아니라 답변 자체가 무너져 함정 문항까지 도달하지 못한 경우입니다(아래에서 자세히 봅니다). 그래서 "양자화를 올리면 함정에 더 잘 버틴다"는 근거는 이번 시행에서 나오지 않았습니다.

문제는 진짜 사실 문항이었습니다. 세 문항 중 맞힌 건 네 번의 시행에서 모두 "한글을 창제한 왕은 세종" 하나뿐입니다.

• 태조를 묻자 Q4_K_M은 "류성룡", 다른 회차에선 "단오"라고 했습니다.
• Q8_0은 "지정거", "태조 이방원(이성계)"처럼 인물을 뒤섞었습니다.
• 백두산 천지를 묻자 Q4_K_M은 "백두사마주", "천명 Hồ"(베트남어가 섞였습니다), Q8_0은 "백조 호수"라고 답했습니다. 네 번 모두 천지가 안 나왔습니다.

가장 눈에 띄는 건 Q8_0의 2회차입니다. 태조 문항에서 "세jong 대왕", "도산(Toshiba)의 아들" 같은 말이 나오더니 답변이 통째로 중국어로 넘어가면서 3~5번을 아예 답하지 못했습니다. 정밀도를 높인 쪽이 더 곱게 무너진 게 아니라 더 요란하게 무너진 겁니다.

한 가지 짚어둘 게 있습니다. 천지를 못 맞히는 건 이 모델만의 버릇이 아닙니다. 지난 로컬 AI 사실성 테스트에서도 서로 다른 두 모델이 나란히 천지를 틀렸습니다. 한국 지리·역사 고유명사는 작은 로컬 모델이 공통으로 약한 구간이고, 양자화를 올려서 메울 수 있는 종류의 구멍이 아니었습니다.

문헌은 뭐라고 하나 — 그리고 왜 우리 결과와 어긋나 보이나

여기까지만 보면 "그럼 다들 왜 Q8을 받나" 싶을 텐데, 문헌은 우리와 다른 각도를 봅니다. 같은 일꾼을 두고도 어떤 시험지로 굴리느냐에 따라 평가가 갈린다는 얘기예요.

2026년 1월 공개된 llama.cpp 양자화 통합 평가 논문(Uygar Kurt)은 Llama-3.1-8B-Instruct로 GSM8K·HellaSwag·IFEval·MMLU·TruthfulQA 다섯 벤치마크 평균을 쟀습니다. FP16이 69.47, Q8_0이 69.41, Q4_K_M이 69.15였습니다. 논문 표현으로는 "4-bit K-quants typically offer near-maximal compression at 4-bit while keeping task performance close to the FP16 baseline"입니다.

GGUF 배포자들의 안내도 같은 쪽입니다. 대표적인 양자화 배포자 bartowski는 모델 카드에서 Q4_K_M에 "Good quality, default size for must use cases, recommended"를 달고, Q8_0에는 "Extremely high quality, generally unneeded but max available quant" 라고 적어 뒀습니다. 만든 사람 본인이 "보통은 필요 없다"고 써 놓은 셈입니다.

그러면 우리 결과가 문헌과 충돌하느냐. 아닙니다. 잰 게 서로 다릅니다.

• 문헌이 잰 건 영어권 표준 벤치마크 평균입니다. 거기서는 Q8_0이 F16과 0.06점 차이로 붙습니다.
• 우리가 잰 건 한국 고유명사 사실성입니다. 여기서는 양자화 등급이 아니라 모델이 애초에 그 지식을 갖고 있느냐가 승부를 갈랐습니다.

그리고 이 지점에 문헌 공백이 있습니다. K-quant(GGUF)를 정면으로 다룬 다국어 연구(arXiv:2503.03592)는 영어·노르웨이어·말라얄람어로 실험했고 한국어는 포함하지 않았습니다. 반대로 한국어를 10개 평가 언어에 포함한 연구(arXiv:2407.03211)는 GPTQ·bitsandbytes 계열이라 GGUF의 K-quant와 방식이 다릅니다. 후자가 남긴 경고는 우리 결과와 곧장 이어집니다. 자동 평가로는 일본어 하락폭이 1.7%인데 사람이 채점하면 16.0%였다는 겁니다. 자동 지표가 다국어 손실을 크게 과소평가한다는 뜻이에요.

즉 "GGUF K-quant를 한국어로 재본 1차 자료"는 아직 비어 있습니다. 이 글의 숫자도 그 공백을 메우기엔 턱없이 작은 표본입니다. 다만 이 표본 안에서 "Q8로 올리면 한국어가 나아진다"는 기대를 뒷받침한 근거는 하나도 나오지 않았습니다.

FP16을 왜 안 돌렸나

표에 FP16 칸이 비어 있는 건 게을러서가 아닙니다. 안 돌렸기 때문에 안 적었습니다.

FP16 태그는 가중치만 15.24GB입니다. 여기에 컨텍스트 캐시와 런타임 몫이 붙으면 로드 전 안전 게이트가 계산한 소요량이 19.8GB인데, 16GB 카드의 안전 예산은 13.6GB였습니다. 게이트는 NO-GO를 냈고, 그래서 다운로드조차 하지 않았습니다.

억지로 올렸다면 부족한 만큼 CPU와 시스템 메모리로 흘러넘쳐서 속도가 무너지거나 기계가 멎었을 겁니다. 그 상태로 잰 숫자는 "FP16의 성능"이 아니라 "스왑의 성능"이라 실을 가치가 없고요. 일꾼을 들이기 전에 책상이 들어가는지부터 재는 게 순서고, 그걸 건너뛰면 굴리기도 전에 기계가 멎습니다. 16GB 카드에서 7B FP16은 선택지가 아닙니다.

그래서 어느 걸 골라야 하나

이번 측정 범위에서 고르면 이렇습니다.

• VRAM 16GB 이하에서 7B급을 굴린다 → Q4_K_M. 메모리 4.7GB 안쪽에 속도도 1.6배 빠릅니다. 남는 VRAM은 컨텍스트를 길게 잡는 데 쓰는 편이 이득입니다.
• VRAM이 남아돌고 영어 위주 작업이다 → Q8_0을 고려할 만합니다. 문헌 기준으로 F16과 거의 붙으니, 여유가 있으면 손해는 아닙니다.
• 한국어 사실 확인이 목적이다 → 양자화를 올려서 해결하려 하지 마세요. 이번 테스트에서는 두 등급 모두 태조와 천지를 지어냈습니다. 사실 확인이 필요한 작업은 환각을 거르는 절차를 붙이거나, 애초에 검색 근거를 물려주는 쪽이 맞습니다.
• 7B FP16을 쓰고 싶다 → 16GB로는 안 됩니다. 카드를 바꾸거나 모델을 줄이세요.

한 줄로 줄이면, 이 일꾼의 월급을 올려도 한국사 시험 점수는 안 오릅니다. 대신 야근은 더 시킬 수 있어요. 속도가 빠른 쪽이 같은 시간에 더 많은 일을 처리하니까요.

참고 자료

• ollama 공식 라이브러리 qwen2.5 모델 카드 및 태그 페이지 — 태그별 파일 크기·파라미터 수·라이선스(Apache 2.0)
• ollama 레지스트리 매니페스트 — Q4_K_M·Q8_0·FP16 실제 바이트 수(2026-07-26 조회)
• llama.cpp tools/quantize/README.md — 양자화 타입 정의 및 bits/weight 표
• Uygar Kurt, "Which Quantization Should I Use? A Unified Evaluation of llama.cpp Quantization on Llama-3.1-8B-Instruct", arXiv:2601.14277 (2026-01-11)
• Borgersen & Goodwin, "English K_Quantization of LLMs Does Not Disproportionately Diminish Multilingual Performance", arXiv:2503.03592 (2025-03) — 한국어 미포함
• Marchisio et al.(Cohere), "How Does Quantization Affect Multilingual LLMs?", arXiv:2407.03211 — 한국어 포함, 단 GPTQ·bitsandbytes 계열
• bartowski, Meta-Llama-3.1-8B-Instruct-GGUF 모델 카드 — 양자화 등급별 권장 문구
• 우리 실행 기록: run.yaml(tool_test_harness 자동 기록) · 호출로그 · 원본 출력 6건 × 2세트

정리

측정 시점은 2026년 7월이고, 카드 한 장·모델 하나·각 2회 시행이라는 작은 표본입니다. 그 범위 안에서 확인된 건 이렇습니다. 파일이 1.73배 커지면 VRAM은 1.62배, 속도는 0.62배가 되고, 한국어 사실 문항 정답 수는 1에서 1로 그대로였습니다.

통설인 "Q4면 충분"은 이번 결과와 어긋나지 않았습니다. 일꾼 월급을 두 배로 올려도 못 하던 일은 여전히 못 했다는 뜻이니까요. 다만 통설이 근거로 삼는 영어 벤치마크와, 실제로 우리가 한국어로 겪는 실패는 다른 자리에 있습니다. 태조를 "단오"라고 답하는 문제는 비트를 두 배로 늘려서 고쳐지지 않았습니다.

그러니 다음에 모델 태그를 고르실 때는 질문을 바꿔보시죠. "몇 비트를 받을까" 말고, "이 일을 이 크기의 모델에게 맡기는 게 맞나"부터 물어보는 게 순서 아닐까요?

---

이 글은 cinevyze 운영자가 해당 모델을 직접 테스트하고 결과를 비교·검수해 정리·편집했습니다. 표의 모든 수치는 위 실행 기록에서 나온 실측값이며, 판단·사실확인은 모두 사람이 했고 글 다듬는 일부 과정에 AI 도구의 도움을 받았습니다. 측정 시점은 2026년 7월이며 모델·런타임 업데이트에 따라 결과는 달라질 수 있습니다.