Ollama 모델 여러 개 관리하기 — 디스크와 VRAM을 지키는 실전 운영법

7월 22, 2026

Ollama로 로컬 LLM을 쓰기 시작하면 모델이 하나로 끝나지 않는다. 코딩 질문용으로 하나, 요약용으로 하나, RAG를 해보겠다고 임베딩 모델까지 받다 보면 어느새 대여섯 개가 쌓인다. 문제는 이때부터다. 디스크가 수십 GB씩 사라지고, 모델을 바꿔 부를 때마다 그래픽 메모리(VRAM)에서 로드와 언로드가 반복되면서 응답이 느려진다. 이 글에서는 모델을 여러 개 굴리면서 실제로 겪은 문제와, 그걸 정리하는 명령·설정을 순서대로 짚는다.

1. 모델을 여러 개 받으면 생기는 문제

먼저 무엇이 문제인지부터 분명히 해두자. 두 가지다.

디스크: 모델 파일은 한 개당 수 GB에서 수십 GB다. 4B급 양자화 모델도 3GB 안팎, 27B급이면 15GB를 훌쩍 넘는다. 서너 개만 받아도 SSD가 순식간에 줄어든다.
VRAM: 추론을 하려면 모델이 그래픽 메모리에 올라와야 한다. VRAM 8GB 환경에서 4B급 모델 하나를 올리면 여유가 많지 않다. 다른 모델을 부르면 기존 모델을 내리고 새로 올리는 스와핑이 일어나는데, 이때 수 초에서 수십 초의 로딩 지연이 생긴다.

즉 관리의 핵심은 "디스크에 뭐가 있는지"와 "메모리에 뭐가 올라와 있는지"를 구분해서 보는 것이다. Ollama는 이 둘을 각각 다른 명령으로 보여준다.

2. ollama list와 ollama ps — 뭐가 있고 뭐가 올라와 있나

디스크에 받아 둔 모델 목록은 ollama list로 본다.

ollama list
NAME                    SIZE      MODIFIED
gemma3:4b               3.3 GB    2 weeks ago
qwen2.5-coder:7b        4.7 GB    5 days ago
embeddinggemma:latest   621 MB    3 days ago

반면 지금 이 순간 메모리에 올라와 있는 모델은 ollama ps로 확인한다. 출력에는 모델이 언제까지 메모리에 유지되는지(UNTIL 열)와 CPU/GPU 어디에 올라가 있는지도 함께 나온다.

ollama ps
NAME        ID          SIZE      PROCESSOR    UNTIL
gemma3:4b   c0135ac...  4.7 GB    100% GPU     4 minutes from now

여기서 PROCESSOR 열이 중요하다. 100% GPU가 아니라 CPU 비율이 섞여 나온다면 VRAM이 부족해 일부가 시스템 메모리로 밀려났다는 뜻이고, 그 상태에서는 응답 속도가 눈에 띄게 떨어진다. 더 작은 모델이나 더 강한 양자화 버전을 쓰라는 신호다.

더 이상 쓰지 않는 모델을 메모리에서 즉시 내리려면 ollama stop 모델명을 쓴다. 이건 메모리에서만 내리는 것이고, 디스크에서 완전히 삭제하려면 ollama rm 모델명이다. 처음에는 이 둘을 헷갈리기 쉬운데, stop은 "잠깐 비켜"고 rm은 "짐 싸서 나가"라고 기억하면 된다.

3. keep_alive — 모델이 메모리에 머무는 시간 조절

Ollama는 기본적으로 마지막 요청 후 5분이 지나면 모델을 메모리에서 자동으로 내린다. 공식 문서 기준으로 이 동작은 keep_alive라는 값으로 제어한다. 조절하는 방법은 두 가지다.

API 요청마다 지정하기

/api/generate나 /api/chat 요청에 keep_alive 파라미터를 넣으면 그 모델의 유지 시간이 바뀐다.

curl http://localhost:11434/api/generate -d '{
  "model": "gemma3:4b",
  "prompt": "안녕",
  "keep_alive": "30m"
}'

값으로는 "10m", "24h" 같은 시간 문자열, 즉시 내리는 0, 계속 상주시키는 -1을 쓸 수 있다.

환경변수로 전역 기본값 바꾸기

매 요청마다 넣기 번거로우면 OLLAMA_KEEP_ALIVE 환경변수로 기본값 자체를 바꾼다. Windows에서는 PowerShell로 사용자 환경변수를 등록한 뒤 트레이의 Ollama를 완전히 종료하고 다시 실행해야 적용된다.

# 전역 기본 유지 시간을 30분으로
setx OLLAMA_KEEP_ALIVE "30m"

공식 문서 기준으로, 요청에 직접 넣은 keep_alive 값이 환경변수보다 우선한다. 그래서 평소에는 전역값을 넉넉히 두고, 임베딩처럼 한 번 쓰고 마는 작업만 요청에서 "keep_alive": 0을 주는 식으로 조합하면 편하다.

4. 용도별 모델 매핑 — 하나로 다 하려 하지 않기

모델을 여러 개 두는 이유는 결국 용도별로 최적 크기가 다르기 때문이다. 큰 모델 하나로 전부 처리하면 VRAM도 부족하고 간단한 작업에 낭비가 크다. 실제 운영에서 쓰는 매핑 예시는 다음과 같다.

용도	모델 예시	이유
일반 대화·요약·글쓰기	gemma3:4b	속도와 품질 균형, 한국어 무난
코딩 질문·코드 리뷰	qwen2.5-coder:7b	코드 특화 학습 모델
문서 임베딩(RAG용)	embeddinggemma	1GB 미만으로 가볍고 다국어 지원
품질 우선 장문 작업	12B급 이상 (VRAM 여유 시)	느리지만 결과물이 낫다

글을 쓰는 시점에는 Gemma 4 계열까지 공개되어 있는데, 표의 모델명을 최신 세대로 바꿔도 관리 방법 자체는 동일하다. 포인트는 "자주 쓰는 주력 모델 1개는 keep_alive를 길게, 가끔 쓰는 보조 모델은 기본값대로 자동 언로드"라는 원칙이다. 임베딩 모델은 파일도 작고 로딩도 빨라서 그때그때 올렸다 내려도 부담이 없다.

5. 모델 저장 경로 관리 — C드라이브 말고 D드라이브로

Windows에서 Ollama는 기본적으로 %USERPROFILE%\.ollama\models 아래에 모델을 저장한다. 시스템 드라이브(C:)가 작다면 모델 몇 개 만에 경고가 뜬다. 저장 위치는 OLLAMA_MODELS 환경변수로 바꾼다.

트레이 아이콘에서 Ollama를 완전히 종료한다.
PowerShell에서 setx OLLAMA_MODELS "D:\OllamaModels"를 실행하거나, 시스템 속성의 환경 변수 편집 창에서 직접 추가한다.
Ollama를 다시 실행하고 새 모델을 하나 받아 D:\OllamaModels 아래에 blobs 폴더가 생기는지 확인한다.

이미 받아 둔 모델을 다시 내려받고 싶지 않다면, Ollama를 끈 상태에서 기존 .ollama\models 폴더의 내용물을 새 경로로 옮긴 뒤 재시작하면 된다. 환경변수를 바꿨는데도 새 모델이 계속 C드라이브로 가면 재부팅이 가장 확실하다. 새 터미널과 서비스가 변수를 다시 읽게 되기 때문이다.

6. 마무리 — 관리 루틴 요약

정리하면 운영 루틴은 단순하다. 주기적으로 ollama list로 디스크를 훑어 안 쓰는 모델을 ollama rm으로 지우고, 작업 중에는 ollama ps로 VRAM 상태를 확인하며, 주력 모델은 keep_alive로 상주시키고, 저장 경로는 처음부터 넉넉한 드라이브로 잡아 둔다. 이 네 가지만 습관이 되면 모델이 열 개가 되어도 무섭지 않다.

※ 이 글의 명령어와 환경변수 동작은 2026년 기준이며 변경될 수 있습니다.

함께 보면 좋은 글: 개인 컴퓨터에 무료 LLM 구축하기 — Ollama로 Gemma 4 설치부터 저장 위치 변경까지

이 블로그 검색

에이븐스튜디오