Ollama 느릴 때 점검할 7가지: 모델·양자화·GPU 설정

Ollama가 느릴 때는 일부 환경에서는 모델 크기, 양자화 수준, GPU 인식 설정에서 원인이 갈립니다. 이 글은 로컬에서 LLM(대형 언어 모델, ChatGPT 같은 AI를 내 컴퓨터에서 돌리는 것)을 돌릴 때 답답한 응답 속도를 어디부터 손봐야 할지 순서대로 정리합니다.

Ollama(내 컴퓨터에서 오픈소스 AI 모델을 쉽게 실행해주는 프로그램)를 처음 써보면, 홈페이지에서 소개하는 모델을 그대로 받아 돌렸다가 "왜 이렇게 굼뜨지" 하는 경우가 많습니다.

원인은 하나가 아닙니다. GPU가 안 잡혀 있거나, 모델이 내 램(RAM)보다 크거나, 양자화(모델을 압축하는 기술) 옵션이 무거운 쪽으로 걸려 있을 수 있습니다. 이 글에서 하나씩 짚습니다.

먼저 병목이 어디인지 감 잡기

Ollama가 느린 원인은 크게 세 갈래입니다. 모델이 너무 크거나, GPU를 못 쓰고 있거나, 컨텍스트(한 번에 처리하는 글자량)가 과도한 경우입니다.

이 셋 중 어디에 걸렸는지 모르고 무작정 재설치부터 하면 시간만 버립니다. 아래 표부터 확인해 보세요.

증상	유력한 원인	먼저 확인할 것
첫 응답이 30초 넘게 안 나옴	모델 로딩(디스크 → 램)	모델 크기, SSD 여유 공간
답이 나오긴 하는데 글자가 뚝뚝 끊김	GPU 미사용 (CPU만 동작)	GPU 드라이버, 인식 로그
짧은 질문은 빠른데 긴 문서 넣으면 극단적으로 느림	컨텍스트 길이 과다	num_ctx 설정
처음엔 빠르다가 갈수록 느려짐	메모리 스왑(가상 메모리로 밀림)	램 사용량, 모델 사이즈

증상이 애매하면 다음 명령을 터미널(검은 화면에 명령어를 입력하는 프로그램)에 쳐서 로그를 봅니다.

ollama ps

이 명령은 현재 로딩된 모델이 GPU를 쓰는지 CPU를 쓰는지 보여줍니다. PROCESSOR 항목에 100% GPU가 아니라 100% CPU나 50%/50% 식으로 나오면 GPU 활용에 문제가 있는 겁니다.

1. 모델 크기부터 다시 고르기

로컬 LLM 속도를 결정하는 첫 번째 변수는 모델의 파라미터 수(7B, 13B, 70B 같은 숫자)입니다. B는 billion(10억)이라는 뜻으로, 숫자가 클수록 똑똑하지만 그만큼 무겁습니다.

내 컴퓨터의 램·VRAM(그래픽카드 전용 메모리)을 넘어서는 모델을 받으면, 부족한 만큼 SSD를 대신 쓰게 되어 속도가 극단적으로 떨어집니다. 이걸 "스왑"이라고 부릅니다.

대략적인 감을 잡을 수 있는 매칭표입니다. 정확한 요구 사양은 각 모델 페이지에서 확인해야 합니다.

VRAM (그래픽카드 메모리)	무리 없이 돌릴 만한 모델 급
6~8GB	7B~8B 양자화 모델
12~16GB	13B 양자화, 7B 원본
정해진 한도	30B~34B 양자화
48GB+	70B 양자화

💡 GPU가 없거나 VRAM이 정해진 한도라면, 7B보다 더 작은 3B·1B급 모델(예: Phi 계열, Gemma 2B 등)부터 시작하세요. 큰 모델을 CPU로 억지로 돌리는 것보다 훨씬 실용적입니다.

블로그 초안을 다듬거나 짧은 요약 같은 작업은 3B~7B로도 충분한 경우가 많습니다. 코드 리팩토링이나 긴 논리 추론을 시킬 때만 큰 모델을 꺼내는 식으로 나눠 쓰면 효율적입니다.

2. 양자화 옵션 이해하고 바꾸기

양자화는 모델의 숫자를 반올림해서 파일 크기와 메모리 사용량을 줄이는 기술입니다. 사진을 JPEG로 압축하는 것과 비슷합니다 — 화질이 아주 조금 떨어지는 대신 파일이 훨씬 작아집니다.

Ollama에서 모델을 받을 때 태그 뒤에 붙는 q4_K_M, q5_K_M, q8_0 같은 게 양자화 수준입니다. 숫자가 작을수록 더 압축되어 빠르고 가볍습니다.

ollama pull llama3.1:8b-instruct-q4_K_M

이 명령은 llama3.1 8B 모델의 q4_K_M(4비트 중간 품질) 버전을 받는다는 뜻입니다.

양자화 표기	특징	언제 쓰나
q8_0	원본에 가까움, 무거움	품질 최우선, VRAM 여유 있을 때
q5_K_M	품질·속도 균형	애매하면 이걸로
q4_K_M	일부 환경에서는 기본값	속도가 급하면
q3, q2	강한 압축, 품질 저하 눈에 띔	실험용, 저사양

기본 태그(예: llama3.1:8b)는 대개 q4_K_M로 배포되지만, 모델마다 다릅니다. 공식 모델 페이지의 태그 목록을 확인해 명시적으로 선택하는 편이 안전합니다.

3. GPU를 실제로 쓰고 있는지 확인

"GPU가 있는데도 느리다"의 절반 이상은 Ollama가 GPU를 인식 못 하고 CPU로 돌리는 상황입니다.

앞서 본 ollama ps 결과에서 GPU 비율이 100%가 아니라면 아래 순서로 점검합니다.

• ☐그래픽카드 드라이버가 최신인가 (NVIDIA는 스튜디오 또는 게임 드라이버, AMD는 Adrenalin)
• ☐NVIDIA라면 CUDA 툴킷 설치 상태 확인
• ☐Windows에서 WSL(윈도우 안에서 리눅스를 쓰게 해주는 기능)로 돌린다면 WSL용 GPU 드라이버 설정 여부
• ☐Ollama 서비스를 그래픽카드 드라이버 설치 후 재시작했는지

Ollama의 서버 로그도 힌트를 줍니다. 실행 로그에 no compatible GPUs were discovered 같은 문구가 뜬다면 드라이버나 CUDA 쪽 문제입니다.

NVIDIA GPU 확인
     ↓
드라이버 최신?  → 아니오 → 업데이트
     ↓ 예
CUDA 인식?     → 아니오 → CUDA 재설치
     ↓ 예
ollama 재시작
     ↓
ollama ps 로 GPU % 확인

⚠️ 노트북 사용자는 전원 옵션도 확인하세요. 배터리 모드에서는 외장 GPU가 비활성화되거나 성능이 강제로 낮아질 수 있습니다.

4. 컨텍스트 길이(num_ctx) 손보기

컨텍스트 길이는 모델이 한 번에 기억하는 글자량입니다. 값이 클수록 긴 문서를 다룰 수 있지만, 메모리 사용량과 처리 시간이 크게 늘어납니다.

Ollama의 기본 컨텍스트는 모델에 따라 다르지만, 사용자가 늘려 놓고 잊는 경우가 많습니다. 짧은 채팅에는 오히려 손해입니다.

Modelfile(모델 설정을 담은 파일)이나 API 호출에서 num_ctx를 지정할 수 있습니다.

FROM llama3.1:8b
PARAMETER num_ctx 4096

이 설정은 컨텍스트를 4096 토큰(대략 한글 3천 자 안팎)으로 잡는다는 뜻입니다. 짧은 질문·답변 위주로 쓴다면 2048~4096으로 충분하고, 긴 문서를 통째로 넣는 경우에만 8192 이상으로 올립니다.

무작정 최대치로 두면, 짧은 대화에서도 모델이 그만큼의 메모리를 예약하기 때문에 GPU에서 밀려 CPU로 넘어가는 원인이 되기도 합니다.

5. 병렬 요청과 keep_alive 조정

여러 앱에서 동시에 Ollama를 호출하면 요청이 뒤엉켜 서로를 느리게 만듭니다. 반대로 요청 하나하나마다 모델을 새로 로딩하는 것도 낭비입니다.

Ollama에는 환경 변수로 조절 가능한 몇 가지 스위치가 있습니다.

환경 변수	역할
OLLAMA_NUM_PARALLEL	동시에 처리할 요청 수
OLLAMA_MAX_LOADED_MODELS	메모리에 유지할 모델 개수
OLLAMA_KEEP_ALIVE	마지막 요청 후 모델을 얼마나 메모리에 유지할지

혼자 쓰는 개발용 PC라면 병렬 수를 1~2로 낮추고, keep_alive를 넉넉히 잡아 매번 재로딩되지 않도록 합니다. 팀에서 공용 서버로 쓸 때는 반대로 병렬 수를 늘리고 로딩 모델 개수도 조정합니다.

정확한 기본값과 사용법은 Ollama 공식 문서(GitHub 저장소의 FAQ와 환경 변수 문서)에서 확인하세요. 값은 버전에 따라 바뀝니다.

6. 저장 위치와 디스크 속도

모델은 수 GB~수십 GB짜리 파일입니다. Ollama가 이 파일을 램으로 올릴 때 저장 매체 속도가 그대로 첫 응답 시간에 반영됩니다.

• HDD(회전식 하드디스크)에 모델을 두면 로딩만 환경과 절차에 따라이 걸릴 수 있습니다
• SATA SSD는 무난, NVMe SSD는 훨씬 빠릅니다
• 외장 USB 드라이브에 두는 것은 권장하지 않습니다

기본 저장 위치가 마음에 들지 않으면 OLLAMA_MODELS 환경 변수로 옮길 수 있습니다. 이때 반드시 속도가 나오는 내장 SSD 경로로 지정하세요.

또 하나, 디스크 여유 공간이 부족하면 OS가 스왑 파일을 제대로 못 만들어 전체 시스템이 느려집니다. 모델 저장 드라이브에 최소 수십 GB의 여유는 남겨 두는 게 좋습니다.

7. 그래도 느리다면 확인할 마지막 조합

여기까지 손봤는데도 답답하다면, 아래 조합을 순서대로 시도해 봅니다.

1. 지금 쓰는 모델 한 단계 아래 크기로 교체 (예: 13B → 7B)
2. 양자화를 한 단계 더 압축 (예: q5_K_M → q4_K_M)
3. num_ctx를 절반으로 축소
4. Ollama 최신 버전으로 업데이트 (성능 개선이 자주 반영됩니다)
5. 백그라운드에서 GPU·램을 잡아먹는 프로그램(게임 런처, 브라우저 탭 다수, 영상 편집기)을 종료
6. 완전 재부팅 후 Ollama만 켜서 벤치마크

그래도 안 되면 문제는 대개 하드웨어 한계입니다. VRAM 8GB에서 30B 모델을 부드럽게 돌리는 건 어렵습니다. 이때는 무리하지 말고 더 작은 모델로 내려가거나, 클라우드 GPU를 잠깐 빌리는 편이 시간을 아낍니다.

다음에 뭘 먼저 손볼지

정말 급하다면 순서는 이렇습니다. ① ollama ps로 GPU 사용률 확인 → ② 모델을 한 단계 작은 크기로 교체 → ③ num_ctx 축소. 이 세 개만 손봐도 체감 속도가 달라지는 경우가 많습니다.

로컬 LLM은 클라우드 챗봇과 달리 내 하드웨어가 상한선입니다. 그래서 "가장 좋은 모델"을 고르는 게 아니라, "내 컴퓨터에서 답답하지 않게 돌아가는 모델 중 가장 똑똑한 것"을 고르는 감각이 필요합니다.

버전에 따라 기본값과 옵션은 계속 바뀌므로, 세부 설정은 Ollama 공식 GitHub 문서에서 현재 버전 기준으로 다시 확인하는 습관을 들여 두시길 권장합니다.

함께 보면 좋은 글

• Ollama 사용법 — 로컬에서 무료로 LLM 돌리기 입문
• Docker로 AI 모델 로컬 실행하기 — Ollama 5분 가이드
• Claude Desktop 메모리 너무 먹을 때 1.8GB 줄이는 법