가이드

작성자 Matt Connor 2026-08-09 · 업데이트됨 2026-08-13

Ollama 모델 메모리 상주 유지 및 keep_alive 설정 방법

Q: Ollama가 5분 뒤에 모델을 메모리에서 내리는 이유는 무엇입니까?

5분은 Ollama가 요청을 마친 뒤 시작하는 유휴 타이머인 keep_alive의 기본값입니다. 이 시간이 지나면 서버는 가중치를 메모리에서 해제하므로, 다음 요청 시 디스크에서 다시 불러오게 되며 이때 지연이 발생합니다. 요청별로 이 시간을 늘리려면 JSON 본문에 "keep_alive": "30m"를 포함해 보내고, 서버 전체에 적용하려면 OLLAMA_KEEP_ALIVE 환경 변수를 사용하십시오.

Q: Ollama 모델을 메모리에 계속 상주시키려면 어떻게 해야 합니까?

음수 값을 사용하십시오. 요청 시에는 "keep_alive": -1을, 서버 설정에는 OLLAMA_KEEP_ALIVE=-1를 지정합니다. 그러면 ollama ps 명령을 실행했을 때 UNTIL 열에 Forever가 표시됩니다. 이는 유휴 타이머를 제거할 뿐입니다. 만약 다른 모델이 요청되었는데 메모리가 부족하다면, 스케줄러는 공간 확보를 위해 해당 모델을 여전히 메모리에서 내릴 수 있습니다.

Q: OLLAMA_KEEP_ALIVE 설정이 무시되는 이유는 무엇입니까?

설정한 위치를 확인하십시오. systemctl show ollama --property=Environment을 실행했을 때 해당 변수가 출력되지 않는다면 서버가 이를 인식하지 못한 것입니다. 셸에서 export한 변수는 systemd 서비스에 전달되지 않기 때문입니다. sudo systemctl edit ollama.service을 사용하여 설정한 뒤, sudo systemctl daemon-reload과 sudo systemctl restart ollama를 실행하십시오. 다른 원인으로는 클라이언트가 요청 시 자체적인 keep_alive 값을 보내 서버 기본값을 덮어쓰는 경우가 있습니다.

Q: Ollama를 재시작하지 않고 메모리를 비우려면 어떻게 해야 합니까?

ollama stop qwen3:8b은 해당 모델을 즉시 메모리에서 해제하며, 서버와 다른 로드된 모델들은 계속 실행 상태로 둡니다. API를 통해서는 프롬프트 없이 "keep_alive": 0를 포함한 요청을 보내면 되며, 응답으로 "done_reason": "unload"이 돌아옵니다. ollama ps를 실행하여 모델이 더 이상 목록에 없는지 확인하십시오.

Ollama는 기본적으로 5분 뒤 모델을 메모리에서 해제합니다. 요청 시 발생하는 로딩 지연을 방지하기 위해 keep_alive 옵션을 설정하고 systemd 환경에서 모델을 영구적으로 메모리에 상주시키는 구체적인 방법을 설명합니다.

Ollama가 몇 분 뒤 모델을 메모리에서 해제하는 이유는 무엇입니까?

Ollama는 마지막 요청 이후 5분 동안 모델을 메모리에 유지하다가 해제합니다. 다음 요청이 들어오면 디스크에서 가중치를 다시 읽어 RAM이나 VRAM에 매핑해야 하므로, 첫 번째 토큰이 생성되기 전까지 지연이 발생합니다. 이것이 채팅 UI나 코딩 에이전트가 빠르게 작동하다가 잠시 조용해진 뒤, 다음 메시지에서 다시 느려지는 이유입니다. 오류가 발생한 것이 아니라 유휴 타이머가 만료된 것입니다.

이 타이머를 keep_alive이라고 합니다. 타이머는 모델별로 적용되며, 요청이 완료될 때마다 다시 시작됩니다. 현재 응답 중인 모델은 절대 해제되지 않는데, 서버는 활성 요청이 없는 모델에 대해서만 만료 처리를 수행하기 때문입니다. 2026년 8월 기준으로 기본값은 5분이며, 이 서버가 로드하는 모든 모델에 적용됩니다.

keep_alive을 설정하는 곳은 개별 요청 시점과 서버 기본값 설정, 두 가지가 있습니다. 서버 기본값을 재부팅 후에도 유지하려면 systemd drop-in 파일을 사용해야 합니다. 이 가이드는 Ollama가 이미 서비스로 실행 중임을 전제로 합니다. 만약 그렇지 않다면 VPS에 Ollama 설치하기를 먼저 진행한 후 다시 돌아오십시오.

현재 상주 중인 모델은 무엇이며, 언제 만료됩니까?

ollama ps

NAME        ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:8b    500a1f067a9f    6.6 GB    100% GPU     4096       4 minutes from now

출력 결과가 비어 있다면 로드된 모델이 없다는 뜻이므로, 다음 요청 시 전체 로드 과정이 수행됩니다. PROCESSOR은 가중치가 저장된 위치를 알려줍니다. 100% GPU와 100% CPU은 명확한 상태를 나타냅니다. 25%/75% CPU/GPU과 같이 분할된 상태는 모델이 VRAM에 모두 들어가지 않아 일부가 프로세서에서 실행 중이며, 이로 인해 생성 속도가 느려짐을 의미합니다.

UNTIL는 카운트다운을 나타내며, 4 minutes from now과 같은 상대적인 시간을 출력합니다. 모델이 음수 값의 keep_alive와 함께 로드된 경우에는 Forever를 출력합니다. 서버가 언로딩되는 짧은 시간 동안에는 Stopping...을 출력합니다.

릴리스마다 열 구성이 변경될 수 있으므로, 스크립트에서 필드 순서를 세지 말고 헤더를 읽어야 합니다. 자동화가 필요한 경우 API를 사용하십시오.

curl -s http://localhost:11434/api/ps

각 항목에는 expires_at, 2026-08-09T14:38:31.83753Z과 같은 절대 타임스탬프, 그리고 해당 모델 중 GPU 메모리에 상주하는 비율인 size_vram가 포함됩니다. size_vram 값이 0이면 해당 모델이 CPU에서 실행 중임을 의미합니다.

리로드에 실제로 소요되는 비용

추측하지 마십시오. Ollama는 모든 응답에서 로드 시간을 load_duration이라는 항목으로 나노초 단위로 보고합니다.

sudo apt install -y jq
ollama stop qwen3:8b
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'

첫 번째 호출은 모델을 로드하므로 load_duration 값이 큽니다. 1000000000으로 나누면 초 단위로 확인할 수 있습니다. 두 번째 호출은 모델이 메모리에 상주하는 상태에서 실행되므로 훨씬 작은 숫자가 나옵니다. 이 두 수치 사이의 차이가 타이머가 만료된 후 모든 사용자가 지불하는 비용이며, 이것이 바로 keep_alive 설정을 변경해야 하는 이유입니다. 해당 일시 정지 전후의 생성 속도를 확인하려면 자신의 환경에서 초당 토큰 수를 측정하는 방법을 참조하십시오.

Ollama 모델을 요청 후에도 메모리에 유지하기

요청과 함께 keep_alive를 전송하십시오. 이 설정은 요청이 완료된 시점부터 해당 모델에 적용됩니다.

curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "hello"}],
  "keep_alive": "30m"
}'

다음 네 가지 형식의 값을 사용할 수 있습니다.

지속 시간 문자열: "30m", "24h", "90s"
단순 숫자(초 단위로 해석): 3600
음수 값(-1 또는 "-1m"): 유휴 시간 제한 없음
0: 요청 완료 즉시 언로드

요청에 포함된 값은 서버의 기본 설정을 상향 또는 하향 조정합니다. 이는 생각보다 중요합니다. 클라이언트가 자체적으로 keep_alive를 전송하면 서버에 설정된 모든 값을 덮어씁니다.

생성 작업 없이 모델을 로드할 수도 있습니다. 모델 이름만 전송하십시오. 서버는 모델을 로드하고 "done": true과 함께 빈 응답을 반환합니다.

curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "keep_alive": "30m"}'

이 명령은 재부팅 후 또는 새로운 모델을 내려받은 뒤 실행하여, 첫 번째 실제 사용자 요청이 로드 시간을 기다리지 않도록 할 때 사용합니다. CLI에서도 동일한 플래그를 사용하여 같은 작업을 수행할 수 있습니다.

ollama run --keepalive 30m qwen3:8b "hello"

OLLAMA_KEEP_ALIVE를 사용하여 기본적으로 로드 상태 유지하기

서버는 시작 시 OLLAMA_KEEP_ALIVE를 읽어 들여 자체 설정값이 없는 모든 모델에 적용합니다. 이 설정은 요청 필드와 동일한 형식을 취하므로 30m, 3600, -1 모두 정상적으로 작동합니다.

문제는 이 환경 변수가 어느 환경에 적용되어야 하는가입니다. SSH 세션에서 export OLLAMA_KEEP_ALIVE=30m을 실행해도 아무런 변화가 없는데, 이는 패키지 설치 시 서버가 자체 사용자 및 자체 환경을 가진 systemd 서비스로 실행되기 때문입니다. 사용자의 로그인 셸과 해당 서비스는 서로 공유되는 환경이 없습니다. 설정이 무시되는 것처럼 보이는 가장 흔한 이유가 바로 이것입니다.

systemd drop-in을 사용하여 재부팅 후에도 설정 유지하기

sudo systemctl edit ollama.service

편집기가 열리면 두 개의 주석 표시가 나타납니다. 그 사이에 내용을 입력하십시오. 두 번째 표시 아래에 작성한 내용은 systemd가 무시합니다.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

저장하면 /etc/systemd/system/ollama.service.d/override.conf가 생성됩니다. 이는 제공된 unit 파일을 직접 수정하는 대신 drop-in을 사용하는 방식이므로, ollama.service을 교체하는 Ollama 패키지 업그레이드가 수행되어도 사용자의 설정은 유지됩니다. drop-in과 unit 파일이 생소하다면 systemd 서비스 및 타이머 가이드에서 작동 원리를 확인하십시오.

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

마지막 명령은 서비스가 실제로 실행될 환경을 출력합니다. 해당 줄에 OLLAMA_KEEP_ALIVE=30m이 없다면 drop-in이 적용되지 않은 것이며, 원인은 거의 항상 [Service] 헤더가 누락되었거나 표시 아래에 내용을 입력했기 때문입니다. 재부팅을 수행하면 로드된 모든 모델이 해제되므로, 다음 요청은 콜드 로드(cold load) 상태가 됩니다. 앞서 언급한 preload 호출을 사용하여 미리 로드하십시오.

모델을 상주시키는 비용

ollama ps의 SIZE 열은 요청 처리 중뿐만 아니라 유휴 상태인 전체 윈도우 동안 점유되는 메모리를 의미합니다. 4비트 양자화를 적용한 8B 모델은 약 5~6 GB를 차지합니다. 27B 모델은 상황이 다르며, CPU 전용 VPS에서 모델을 구동하기 위한 메모리 계산을 미리 수행한 뒤 상주 여부를 결정해야 합니다. keep_alive를 -1으로 설정하면 해당 모델이 서버 내의 다른 모든 프로세스보다 우선순위를 갖게 됩니다. 소규모 VPS에서는 데이터베이스, 웹 애플리케이션, 빌드 작업과 메모리를 직접적으로 경쟁하게 됩니다.

추정치에 의존하지 말고 실제 수치를 확인하십시오. 모델이 로드된 상태에서 아래 명령을 실행하고, ollama stop 이후에 다시 실행하십시오.

free -h

available 열은 커널이 새로운 프로세스에 할당할 수 있는 가용 메모리입니다. NVIDIA GPU 서버에서는 nvidia-smi 명령으로 VRAM의 상태를 확인할 수 있습니다. 서버 메모리가 부족해지면 커널은 메모리를 확보하기 위해 프로세스를 강제로 종료합니다.

sudo dmesg -T | grep -i "out of memory"

ollama이 포함된 로그 라인이 나타난다면 모델 서버가 종료된 것입니다. 데이터베이스가 포함된 라인이라면 모델이 메모리를 차지하여 중요한 서비스가 종료된 상황입니다. 두 경우 모두 여유 공간이 없는 서버에서 긴 keep-alive 윈도우를 설정했기 때문에 발생합니다.

간과하기 쉬운 두 가지 비용이 있습니다. 컨텍스트 길이가 길어지면 더 큰 KV 캐시(key value cache, 모델이 생성 중에 유지하는 토큰별 어텐션 상태)를 예약하며, 이 캐시도 상주 메모리 크기에 포함됩니다. OLLAMA_NUM_PARALLEL을 1보다 크게 설정하면 병렬 슬롯마다 해당 캐시가 예약됩니다. 하나의 모델로 여러 사용자를 서비스할 계획이라면 가중치뿐만 아니라 슬롯에 필요한 메모리까지 고려하여 크기를 산정하십시오.

합리적인 기본값은 다음과 같습니다. 여유 공간이 있는 서버의 모델은 -1를 사용할 수 있습니다. 여러 서비스가 공유하는 서버라면 30m과 같이 요청 간의 공백을 메울 수 있는 윈도우를 사용하여, 작업이 중단되었을 때 메모리가 반환되도록 설정하십시오.

모델 즉시 언로드

ollama stop qwen3:8b

출력 없이 반환되며, 모델은 ollama ps에서 사라집니다. 로드되지 않은 이름을 지정하면 couldn't find model "qwen3:8b" to stop가 발생합니다. API 형식은 프롬프트가 없고 keep_alive이 0로 설정된 요청입니다.

curl -s http://localhost:11434/api/chat -d '{"model": "qwen3:8b", "messages": [], "keep_alive": 0}'

응답에는 "done_reason": "unload"이 포함됩니다. 서비스를 재시작하는 대신 이 방법을 사용하십시오. systemctl restart ollama도 메모리를 해제하지만, 로드된 다른 모든 모델을 삭제하고 실행 중인 모든 요청을 종료합니다.

한 대의 서버에서 여러 모델 실행하기

OLLAMA_MAX_LOADED_MODELS은 한 번에 로드할 수 있는 모델의 최대 개수를 제한하며, 2026년 8월 기준으로 기본값은 GPU당 3개, 또는 CPU 전용 장비의 경우 3개입니다. 이 제한은 모델 개수를 기준으로 하지만 실제 제약은 메모리 용량이므로, 3개에 도달하기 훨씬 전에 두 번째 대형 모델이 메모리 부족으로 거부될 수 있습니다.

새로운 모델이 요청되었는데 메모리가 부족하면, 스케줄러는 상주 모델 중 하나를 언로드하여 공간을 확보합니다. 이때 활성 요청이 없는 모델을 우선적으로 선택하며, 타이머가 만료되지 않은 모델이라도 퇴출합니다. 여기에는 -1로 로드된 모델도 포함됩니다. 따라서 keep_alive를 음수 값으로 설정하면 유휴 상태 타임아웃이 없음을 의미하지만, 다른 모델의 요청으로부터 가중치를 고정(pin)하여 보호하지는 않습니다.

이 결정은 디버그 수준에서 로그로 기록됩니다. 동일한 드롭인 파일에 두 번째 Environment="OLLAMA_DEBUG=1" 줄을 추가하고 재시작한 뒤 다음을 확인하십시오.

sudo journalctl -u ollama -f

공간 확보를 위해 러너를 언로드한다는 메시지가 이를 유발한 요청과 함께 나타난다면, 해당 두 모델은 이 장비에서 동시에 실행될 수 없음을 의미합니다. 해결 방법은 이 장비에서 모델 개수를 줄이거나, 빠른 응답이 필요한 모델에는 긴 윈도우를 설정하고 드물게 호출하는 모델에는 0를 사용하는 것입니다.

다음 릴리스 이후에도 유효한 지침

Ollama는 자주 릴리스되며 기본 설정값도 변경되므로, 숫자를 암기하기보다는 현재 사용 중인 빌드를 직접 확인하십시오.

ollama --version
ollama serve --help

ollama serve --help는 해당 빌드가 실제로 읽어 들이는 환경 변수 목록을 제공하며, 그중에는 OLLAMA_KEEP_ALIVE도 포함되어 있습니다. 릴리스와 관계없이 항상 적용되는 두 가지 규칙은 다음과 같습니다. 요청에 포함된 값이 서버의 기본값보다 우선합니다. 그리고 ollama ps은 설정 파일의 내용과 관계없이 현재 로드된 실제 상태를 보여줍니다.

편집기나 에이전트가 서버를 구동하는 경우, 서버를 탓하기 전에 해당 클라이언트가 무엇을 전송하는지 확인하십시오. 코딩 에이전트를 자신의 Ollama 서버에 연결하기에서 해당 요청 설정이 어디에 위치하는지 다룹니다.

FAQ

Ollama가 5분 뒤에 모델을 메모리에서 내리는 이유는 무엇입니까?

5분은 Ollama가 요청을 마친 뒤 시작하는 유휴 타이머인 keep_alive의 기본값입니다. 이 시간이 지나면 서버는 가중치를 메모리에서 해제하므로, 다음 요청 시 디스크에서 다시 불러오게 되며 이때 지연이 발생합니다. 요청별로 이 시간을 늘리려면 JSON 본문에 "keep_alive": "30m"를 포함해 보내고, 서버 전체에 적용하려면 OLLAMA_KEEP_ALIVE 환경 변수를 사용하십시오.

Ollama 모델을 메모리에 계속 상주시키려면 어떻게 해야 합니까?

음수 값을 사용하십시오. 요청 시에는 "keep_alive": -1을, 서버 설정에는 OLLAMA_KEEP_ALIVE=-1를 지정합니다. 그러면 ollama ps 명령을 실행했을 때 UNTIL 열에 Forever가 표시됩니다. 이는 유휴 타이머를 제거할 뿐입니다. 만약 다른 모델이 요청되었는데 메모리가 부족하다면, 스케줄러는 공간 확보를 위해 해당 모델을 여전히 메모리에서 내릴 수 있습니다.

OLLAMA_KEEP_ALIVE 설정이 무시되는 이유는 무엇입니까?

설정한 위치를 확인하십시오. systemctl show ollama --property=Environment을 실행했을 때 해당 변수가 출력되지 않는다면 서버가 이를 인식하지 못한 것입니다. 셸에서 export한 변수는 systemd 서비스에 전달되지 않기 때문입니다. sudo systemctl edit ollama.service을 사용하여 설정한 뒤, sudo systemctl daemon-reload과 sudo systemctl restart ollama를 실행하십시오. 다른 원인으로는 클라이언트가 요청 시 자체적인 keep_alive 값을 보내 서버 기본값을 덮어쓰는 경우가 있습니다.

Ollama를 재시작하지 않고 메모리를 비우려면 어떻게 해야 합니까?

ollama stop qwen3:8b은 해당 모델을 즉시 메모리에서 해제하며, 서버와 다른 로드된 모델들은 계속 실행 상태로 둡니다. API를 통해서는 프롬프트 없이 "keep_alive": 0를 포함한 요청을 보내면 되며, 응답으로 "done_reason": "unload"이 돌아옵니다. ollama ps를 실행하여 모델이 더 이상 목록에 없는지 확인하십시오.

#ollama #llm #self-hosted-ai #systemd #performance