가이드

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

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과 같은 절대 타임스탬프)과 size_vram(GPU 메모리에 상주하는 모델의 비율)가 포함됩니다. 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을(를) 변경해야 하는 이유입니다. 해당 차이의 대부분은 디스크 읽기 작업에서 발생하므로, 만약 모델 디렉터리를 다른 볼륨으로 이동했다면, 해당 볼륨의 속도가 모든 콜드 로드(cold load)의 하한선을 결정하게 됩니다. 해당 지연 시간 전후의 생성 속도를 확인하려면 자신의 장비에서 초당 토큰 수를 측정하는 방법을 참조하십시오.

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"}'

이 명령은 재부팅 후 또는 새로운 모델을 pull한 뒤에 실행하여, 첫 번째 실제 사용자 요청 시 로드 지연이 발생하지 않도록 하는 용도입니다. 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가 생성됩니다. 이는 배포된 유닛 파일을 직접 수정하는 대신 drop-in을 사용하는 방식이므로, ollama.service을 교체하는 Ollama 패키지 업그레이드가 수행되어도 사용자의 설정은 유지됩니다. drop-in과 유닛 파일이 생소하다면 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~6GB를 차지합니다. 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, 모델이 생성 과정에서 토큰별로 유지하는 어텐션 상태)를 예약하게 되며, 이 캐시 또한 상주 메모리 크기에 포함됩니다. 캐시 크기는 num_ctx에 따라 결정되므로, 컨텍스트 윈도우를 늘리는 것은 모델이 응답하는 동안뿐만 아니라 유휴 상태 전체에서 점유하는 메모리 양을 증가시킵니다. 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