Ollama KV 캐시 q8_0, 6GB에서 켜 봤더니: 8B는 40% 느려지고 4B는 메모리만 아꼈다
긴 문서를 넣을 때 그래픽 메모리를 아끼는 방법으로 Ollama의 OLLAMA_KV_CACHE_TYPE=q8_0이 자주 추천됩니다. 문맥을 기억하는 공간(KV 캐시)을 8비트로 압축해서 크기를 약 절반으로 줄이는 설정입니다. GTX 1660 SUPER 6GB에서 실제로 켜 봤습니다.
결론부터 정리하면 이렇습니다.
- Qwen3 8B는 오히려 느려졌습니다. 약 3,500토큰 문서 뒤의 답 속도가 19.6~20.2 → 11.8~11.9 tok/s(약 40% 감소), 약 8,600토큰 문서에서는 10.5~10.6 → 5.6 tok/s(약 47% 감소)였습니다.
- Qwen3 4B-instruct는 속도는 거의 그대로, 그래픽 메모리만 약 980MB 줄었습니다. 약 8,600토큰 문서 뒤에도 초당 약 50토큰으로 답했습니다.
- 측정하다 함정도 하나 찾았습니다. Ollama를 스크립트로 강제 종료하고 다시 켜면, 모델을 돌리던 작업 프로세스(
llama-server.exe)가 남아서 그래픽 메모리를 계속 붙잡을 수 있습니다. 설정을 바꾸려고 재시작했다면 꼭 확인하세요.
한눈에 보는 결과
Ollama 0.34.4, num_ctx 16384, 모든 층을 그래픽카드에 올린 상태(num_gpu 99)입니다. 각 조건을 2번씩 쟀습니다.
| 모델 · KV 캐시 | 문서 | 읽는 시간 | 답 쓰는 속도 | 그래픽 메모리 | 공유 GPU 메모리 |
|---|---|---|---|---|---|
| 8B · 기본(f16) | 약 3,500토큰 | 41.2~42.7초 | 19.6~20.2 tok/s | 5,771~5,832MB | 약 2,440~2,520MB |
| 8B · q8_0 | 약 3,500토큰 | 44.4~45.5초 | 11.8~11.9 tok/s | 5,771~5,775MB | 약 1,350~1,360MB |
| 8B · 기본(f16) | 약 8,600토큰 | 125.1~128.6초 | 10.5~10.6 tok/s | 5,769~5,771MB | 약 2,510MB |
| 8B · q8_0 | 약 8,600토큰 | 133.9~137.0초 | 5.6 tok/s | 5,777MB | 약 1,350~1,360MB |
| 4B-instruct · 기본(f16) | 약 8,600토큰 | 53.6~55.4초 | 50.9~51.0 tok/s | 5,352MB | 436MB |
| 4B-instruct · q8_0 | 약 8,600토큰 | 57.5~58.9초 | 49.9~50.4 tok/s | 4,369MB | 436MB |
- 8B의 기본(f16) 3,500토큰 값은 q8_0 측정 앞과 뒤에 한 번씩 재서(19.6~19.7, 20.1~20.2 tok/s) 그사이 측정 환경이 흔들리지 않았는지 확인했습니다.
- 4B-instruct 기본(f16) 값은 같은 날 오전에 긴 문서 글에서 잰 값이라, 측정 시각이 다릅니다. 그래서 4B의 속도 비교는 참고용입니다.
- 문서 한가운데 숨긴 네 자리 숫자는 모든 조건에서 2번 다 찾았습니다. 압축해도 이 정도 찾기에는 문제가 없었습니다.
- "답 쓰는 속도"는 숨긴 숫자를 숫자만으로 답할 때의 속도라, 몇 토큰짜리 아주 짧은 답에서 잰 값입니다.
테스트 환경과 방법
- CPU: Intel Core i9-10900K, RAM: 32GB (3200MHz)
- 그래픽카드: NVIDIA GeForce GTX 1660 SUPER 6GB (6,144MB), 드라이버 591.86, Windows 11 Home
- Ollama 0.34.4, 모델은
qwen3:8b(Q4_K_M)에num_gpu 99를 넣은 모델과qwen3:4b-instruct(Q4_K_M) - 문서는 긴 문서 글과 같은 방식으로 만든 한국어 글(약 4,800자, 약 12,000자)입니다.
KV 캐시 설정은 Ollama를 끈 뒤, 서버를 띄우는 PowerShell 프로세스에만 환경 변수 OLLAMA_KV_CACHE_TYPE=q8_0을 주고 ollama serve로 다시 켜서 바꿨습니다(사용자·시스템 환경 변수는 건드리지 않음). 측정이 끝나면 환경 변수 없이 원래 Ollama 앱을 다시 켰습니다. Ollama FAQ에 따르면 KV 캐시 압축은 플래시 어텐션이 켜져 있을 때 적용되고, 플래시 어텐션은 지원되는 백엔드·장치에서 자동으로 켜집니다. 실제로 적용됐는지는 ollama ps의 모델 크기로 확인했습니다. 8B는 7.4GB에서 6.3GB로, 4B-instruct는 5.0GB에서 3.9GB로 줄어 표시됐습니다.
8B는 왜 느려졌을까
압축으로 문맥 공간이 줄어든 건 분명합니다. ollama ps 크기가 1.1GB 줄었고, 윈도우의 "공유 GPU 메모리" 사용량도 약 2,500MB에서 약 1,360MB로 줄었습니다. 그런데도 답 쓰는 속도는 40~47% 떨어졌습니다.
8B는 모델 파일만으로 6GB 카드가 거의 꽉 차서, 문맥 공간 상당 부분이 그래픽 메모리 밖(시스템 메모리)에 있는 것으로 보입니다(긴 문서 글 참고). 압축으로 그 양은 줄었지만 여전히 다 들어가지는 않았고, 압축된 값을 풀어 계산하는 비용이 더해져 더 느려졌을 가능성이 있습니다. 원인을 직접 확인한 것은 아닙니다.
참고로 같은 모델을 llama.cpp로 직접 돌렸을 때는 결과가 달랐습니다. 긴 문서 글에서 KV 캐시를 q8_0으로 압축하니 8,192토큰을 채운 상태의 생성 속도가 13.2에서 18.0 tok/s로 빨라졌습니다(다만 12,288토큰에서는 5.7 tok/s로 떨어졌습니다). llama-bench는 채울 토큰만큼만 문맥 공간을 잡고, Ollama는 num_ctx(16,384)만큼 미리 잡는다는 차이도 있습니다. 실행 도구와 메모리 배치 방식이 다르면 같은 압축도 결과가 달라질 수 있다는 뜻입니다. 효과가 있을지는 직접 재 보고 켜세요.
4B-instruct는 메모리만 아꼈다
4B-instruct는 모델 파일이 작아서 기본 설정에서도 문맥 공간이 대부분 그래픽 메모리 안에 들어갑니다. q8_0으로 압축하니 그래픽 메모리 사용량이 5,352MB에서 4,369MB로 약 980MB 줄었고, 답 속도는 약 50 tok/s로 거의 그대로였습니다. 문서 읽는 시간은 53.6~55.4초에서 57.5~58.9초로 조금 늘었습니다(측정 시각이 달라 참고용).
그래픽 메모리가 1GB 가까이 남으니, 4B로 긴 문서를 다루면서 브라우저나 다른 프로그램을 같이 띄워야 할 때는 켜 볼 만합니다. num_ctx를 더 키우는 데 쓸 수도 있지만, 이번에는 16,384까지만 재 봤습니다.
측정 중 찾은 함정: 남아 있는 llama-server.exe
처음 측정할 때는 q8_0이 약 2.3~2.8배나 느리게 나왔습니다. 확인해 보니 측정 직전 그래픽 메모리 사용량이 5,700MB를 넘은 경우가 있었고, nvidia-smi로 그래픽카드를 쓰는 프로세스를 보니 C:\Users\(사용자)\AppData\Local\Programs\Ollama\lib\ollama\llama-server.exe가 많을 때는 4개까지 떠 있었습니다.
이번에 쓴 Ollama는 모델을 llama-server.exe라는 별도 프로세스로 돌립니다. 측정 스크립트가 설정을 바꾸려고 ollama app과 ollama 프로세스를 PowerShell의 Stop-Process -Force로 강제 종료했는데, 그 아래에서 돌던 llama-server.exe는 함께 꺼지지 않고 남았습니다. 재시작할 때마다 하나씩 늘어서 4개가 됐고, 스크립트를 고친 뒤 다시 잴 때도 재시작 두 번 모두 하나씩 남아 있었습니다. 남은 프로세스는 불러온 모델을 그래픽 메모리에 들고 있던 것으로 보입니다. 이 프로세스들을 끄자 그래픽 메모리 사용량은 약 620MB로 돌아왔습니다. 위 표는 4B-instruct 기본값 한 줄을 빼면 모두 그 뒤에 다시 잰 값입니다.
- Ollama 설정을 바꾸려고
Stop-Process -Force같은 방법으로 강제 종료했다면, 다시 켜기 전에llama-server.exe가 남아 있는지 확인하세요. 작업 관리자에서 끝낸 경우는 시험하지 않았습니다. - 남아 있다면 끝내고 나서 Ollama를 켜야 합니다. PowerShell이라면
Get-Process llama-server | Where-Object Path -like '*\Ollama\*'로 Ollama 쪽 프로세스만 골라 볼 수 있습니다(직접 설치한 llama.cpp의 llama-server와 구분하기 위해서). - 트레이 아이콘의 "Quit Ollama"로 정상 종료했을 때도 남는지는 시험하지 않았습니다.
- 갑자기 모델이 느려졌다면
nvidia-smi로 그래픽 메모리를 누가 쓰고 있는지 먼저 보세요.
6GB 그래픽카드라면
- 8B에는 KV 캐시 q8_0을 켜지 마세요. 이 환경에서는 긴 문서 답이 40~47% 느려졌습니다.
- 4B-instruct에는 메모리가 모자랄 때만 켜세요. 속도는 거의 같고 그래픽 메모리가 약 1GB 남습니다.
- 긴 문서가 목적이라면 설정보다 모델 선택이 효과가 큽니다. 같은 약 8,600토큰 문서에서 8B는 초당 약 10.5토큰(오전 측정에서는 약 12토큰), 4B-instruct는 초당 약 50토큰으로 답했습니다.
한계
- 그래픽카드 한 종류(GTX 1660 SUPER 6GB), Ollama 한 버전(0.34.4)에서만 쟀습니다. 그래픽 메모리가 넉넉한 카드에서는 결과가 다를 수 있습니다.
- 8B 기본값과 q8_0은 같은 시간대에 이어서 쟀지만, 4B-instruct 기본값은 오전 측정값입니다.
- 이 PC에서 같은 8B 설정의 3,500토큰 답 속도는 오전에 21.9~22.2 tok/s, 오후에 19.6~20.2 tok/s로 약 10% 차이가 났고, 8,600토큰에서는 약 13% 차이였습니다. 오후에는 측정 직전 그래픽 메모리 사용량이 약 180MB 더 많았습니다. 그래서 비교는 같은 시간대의 값끼리만 했습니다.
- 기본값은 Ollama 앱이 띄운 서버에서, q8_0은 직접 띄운
ollama serve에서 쟀습니다.num_ctx·num_gpu는 요청마다 직접 지정해서 영향은 작다고 봤습니다. - 압축이 긴 요약·추론 품질에 주는 영향은 보지 않았습니다. 숨긴 숫자 하나 찾기만 확인했습니다.