2026 Ollama 0.34.0으로 DeepSeek-R1 실행: 작업이 끝난 뒤 메모리가 해제되지 않으면 어떻게 해야 하나요?

공식 API 문서에는 keep_alive를 0으로 지정하면 모델을 즉시 내릴 수 있다고 설명되어 있습니다. Ollama API 문서의 모델 유지 시간 규칙을 기준으로 보면, Ollama 0.34.0에서 DeepSeek-R1 작업 뒤 메모리가 남을 때 먼저 메모리 상한을 키우거나 문맥을 계속 줄일 필요는 없습니다. 요청에 따라 Runner 프로세스가 계속 커지는지 확인한 뒤, 배치 경계에서 keep_alive=0 또는 모델 중지를 임시 회수책으로 사용해야 합니다. 이것은 누수 수정이 아닙니다.

마지막 업데이트: 2026년 9월 15일. API 동작은 Ollama 공식 문서, Metal 메모리 정의는 Apple 문서, 사례 상태는 공개 GitHub 이슈를 기준으로 확인했습니다.

이 글은 작업 종료 뒤 Ollama 점유율이 내려가지 않는 배치 개발자, 장시간 실행되는 AI 에이전트를 운영하는 엔지니어, 냉시작 비용과 격리 노드 도입 시점을 판단해야 하는 기술 책임자를 위한 내용입니다. 단순 설치법이 아니라 모델 회수와 Runner 교체 여부를 결정하는 글입니다.

실행 목록이 정상이어도 메모리 회수는 끝나지 않을 수 있습니다

Ollama 요청이 끝난 뒤에도 메모리가 남는 이유는 하나가 아닙니다. 모델이 공식 유지 시간 안에 남아 있는 경우, 가중치가 파일 매핑으로 유지되는 경우, 긴 요청의 KV Cache가 Runner 내부에 남는 경우, 또는 프로세스 힙이 요청량에 따라 증가하는 경우를 구분해야 합니다.

Apple Silicon은 CPU와 GPU가 같은 통합 메모리 공간을 사용합니다. Apple의 통합 메모리 설명에 따르면 Metal 장치의 통합 메모리 여부는 별도 그래픽 메모리만 보는 방식과 다르게 해석해야 합니다. 따라서 모델 실행 목록에서 DeepSeek-R1이 사라졌어도 호스트 프로세스와 운영 체제의 압력이 즉시 같은 폭으로 내려간다고 볼 수 없습니다.

반대로 실제 메모리 부족도 있습니다. 문맥이 길고 동시 요청이 늘면서 작업 집합이 커지는 경우에는 물리 자원이 부족한 것입니다. 요청이 끝날 때마다 같은 Runner의 힙이 계속 증가하는 경우에는 별도의 회수 문제일 수 있습니다. 두 현상을 섞어 sysctl 값을 임의로 바꾸면 원인 확인이 더 어려워집니다.

Apple은 Metal 작업 집합을 판단할 때 권장 최대 작업 집합 크기라는 지표를 제공합니다. Metal 작업 집합 지표 설명은 이 값을 애플리케이션 전체 메모리 상한이나 누수 판정값으로 설명하지 않습니다. 이 구분이 중요한 이유는 활동 모니터의 단일 숫자만 보고 회수 실패를 결론 내리기 쉽기 때문입니다.

문맥을 줄여도 증가한다면 다른 변수를 먼저 분리해야 합니다

문맥 길이를 줄였는데도 메모리가 계속 늘어난다면 다음 세 변수를 따로 기록해야 합니다.

• 요청 1회에 포함되는 입력과 출력의 크기
• 일정 시간 동안 처리한 전체 요청 수
• 동시에 실행된 호출 수와 서로 다른 모델 전환 횟수

문맥 길이에 따라 증가하면 KV Cache와 작업 집합을 먼저 의심할 수 있습니다. 요청 누적량에 따라 증가하면 Runner 힙이나 응답 처리 경로를 확인해야 합니다. 동시성에 따라 증가하면 각 호출의 임시 버퍼와 대기 요청이 원인일 수 있습니다.

공개된 Ollama macOS 및 Metal Runner 관련 GitHub 이슈에는 API에서 모델 점유가 안정적으로 보이는 동안 프로세스 힙이 계속 증가했다는 사례가 있습니다. 다만 해당 사례는 Ollama 0.32.15와 다른 모델을 사용했으며, Ollama 0.34.0이나 DeepSeek-R1에서 같은 문제가 공식 확인됐다는 뜻이 아닙니다. 이 사례는 원인을 좁히는 단서일 뿐입니다.

우리의 테스트 환경에서 재현되지 않은 메모리 변화와 로딩 시간은 일반 수치로 사용할 수 없습니다. 먼저 같은 DeepSeek-R1 모델, 같은 입력 순서, 같은 동시성으로 최소 재현을 만들고, 각 요청 전후에 다음 항목을 저장해야 합니다.

1. 요청 번호와 시작 및 종료 시각
2. 모델 이름과 keep_alive 값
3. Runner 프로세스 식별자
4. 시스템 메모리 압력과 스왑 활동
5. 서비스 로그의 오류 및 재시작 기록

활동 모니터의 메모리 압력은 Apple의 메모리 압력 안내처럼 시스템이 메모리를 얼마나 압박받는지 판단하는 지표로 봐야 합니다. 특정 프로세스의 점유량과 같은 의미로 취급하면 안 됩니다.

첫 번째 단계: 실행 방식부터 고정합니다

Ollama.app을 사용하는지, 터미널에서 서비스를 직접 시작했는지, 별도 API 클라이언트가 호출하는지 먼저 적습니다. 실행 방식이 섞이면 중지 명령이 다른 서비스에 적용되거나, 앱이 다시 서비스를 시작해 회수 결과를 왜곡할 수 있습니다.

수동으로 서비스를 시작한 환경이라면 현재 서비스 프로세스와 Runner 프로세스를 각각 확인합니다. API 방식이라면 요청 본문에 keep_alive가 실제로 들어갔는지 확인합니다. Ollama API 문서의 모델 언로드 예시는 요청 수준의 유지 시간 제어를 설명하지만, 이미 손상된 Metal 상태나 모든 호스트 메모리를 복구한다고 약속하지 않습니다.

다음 순서로 기록하면 됩니다.

• [ ] 같은 모델과 같은 요청 순서를 사용해 기준 실행을 남깁니다.
• [ ] 요청 전후의 Runner 식별자와 메모리 압력을 기록합니다.
• [ ] API 요청에 keep_alive: 0을 넣은 실행을 별도로 수행합니다.
• [ ] 실행 모델 목록에서 모델이 사라지는 시점을 확인합니다.
• [ ] 같은 프로세스가 남아 있는지와 스왑 활동 변화를 비교합니다.
• [ ] 다시 모델을 불러와 첫 요청의 성공 여부와 냉시작 결과를 기록합니다.
• [ ] 회수 실패가 반복될 때만 서비스 재시작을 별도 실험으로 진행합니다.

두 번째 단계: 모델 중지와 서비스 재시작을 같은 조치로 보지 않습니다

keep_alive=0은 해당 API 요청 뒤 모델을 내리도록 요청하는 방법입니다. 명령줄에서 모델을 중지하는 방법은 실행 중인 모델을 대상으로 하는 별도 제어입니다. 두 방법 모두 모델 목록을 바꿀 수 있지만, Runner 프로세스와 서비스 전체의 생명 주기를 동일하게 바꾸지는 않습니다.

모델 목록에서 사라졌는데도 Runner 식별자가 그대로 남고 메모리 압력이 유지된다면 모델 회수와 프로세스 회수를 혼동한 것입니다. 이때는 서비스 로그를 함께 보아야 합니다. Ollama의 macOS 로그 및 문제 해결 문서는 실행 환경의 로그 위치와 확인 방법을 안내합니다.

기존 Runner가 종료되지 않았거나 Metal 오류가 반복되면 완전한 서비스 재시작을 다음 단계로 올릴 수 있습니다. 다만 먼저 로그와 프로세스 정보를 보존해야 합니다. 매번 강제로 프로세스를 종료하면 재현 단서가 사라지고, 다른 요청이 중단될 수 있습니다.

세 번째 단계: 회수 경계를 요청보다 크게 잡습니다

매 요청마다 모델을 내리면 메모리 문제는 줄어들 수 있지만, 매번 모델을 다시 불러오는 냉시작 비용이 생깁니다. 이 비용은 모델 크기, 저장 장치, 동시에 사용하는 모델 수, 입력 준비 방식에 따라 달라지므로 출처 없는 일반 시간이나 메모리 수치로 판단하면 안 됩니다.

짧은 독립 배치라면 작업 묶음이 끝날 때 회수하는 방식이 적합합니다. 연속 대화나 도구 호출이 이어지는 AI 에이전트라면 요청마다 회수하지 않는 편이 안전할 수 있습니다. 다음 호출이 곧바로 이어지는데 모델을 매번 내리면 첫 응답 지연과 모델 전환 비용이 누적됩니다.

비용 관점의 판단은 다음과 같습니다.

• 단일 작업이 끝나면 다음 작업까지 오래 비는 경우: 작업 경계 회수를 우선합니다.
• 같은 모델로 연속 대화가 이어지는 경우: 세션 또는 큐 단위로 유지합니다.
• 여러 모델이 번갈아 실행되는 경우: 모델별 큐와 교체 정책을 분리합니다.
• 회수 후 작업 실패가 발생하는 경우: 빈도보다 격리와 재시도 설계를 먼저 검토합니다.

Apple Silicon 맥의 모델 실행 환경을 비교할 때 확인할 기준도 함께 보면, 단순 메모리 용량보다 저장 장치와 작업 형태를 함께 판단하는 데 도움이 됩니다.

네 번째 단계: 공유 에이전트에서는 오작동하는 언로드를 막습니다

여러 호출자가 같은 DeepSeek-R1 Runner를 공유한다면 한 작업의 keep_alive=0이 다른 작업의 진행을 방해할 수 있습니다. 특히 도구 호출 중간에 모델이 내려가면 세션 상태가 끊기거나 같은 모델이 다시 로드될 수 있습니다.

API 서비스에는 다음 보호 장치를 둡니다.

• 진행 중인 요청 수를 확인한 뒤 언로드합니다.
• 새 요청을 잠시 받지 않는 배수 상태를 둡니다.
• 큐가 비었는지 확인한 뒤 회수합니다.
• 회수 뒤 간단한 건강 확인 요청을 보냅니다.
• 실패하면 같은 요청을 무한 반복하지 않고 제한된 횟수로 재시도합니다.

정기 배치에는 독점 작업 잠금을 둡니다. 잠금을 얻지 못한 작업은 모델 중지를 실행하지 않아야 합니다. 회수 작업이 끝난 뒤에는 모델 목록, Runner 식별자, 실제 테스트 응답을 확인해야 합니다. 단순한 타이머 기반 강제 종료는 모든 운영 환경의 표준 해결책이 아닙니다.

다섯 번째 단계: 실험적 커널 조정보다 교체 조건을 정합니다

다음 조건이 반복되면 문제는 단순한 조정 범위를 넘어섭니다.

• 같은 요청 묶음에서 회수 뒤에도 프로세스가 계속 누적됩니다.
• 서비스 재시작 빈도가 늘어 작업 성공률이 낮아집니다.
• 냉시작을 피하려고 모델을 유지하면 다른 작업이 메모리 압박을 받습니다.
• 한 개발자의 작업이 같은 맥의 다른 사용자나 에이전트를 중단시킵니다.
• 장애가 발생할 때마다 수동 복구가 필요합니다.

이때 단일 메모리 비율을 기준으로 결론 내리지 않습니다. 작업 성공률, 복구 빈도, 냉시작 영향, 노드 교체 가능성을 함께 봅니다. 로컬 맥을 계속 사용할지, 작업을 분리할지, 독립된 클라우드 맥으로 옮길지는 이 네 가지 비용으로 결정해야 합니다.

장시간 에이전트라면 한 프로세스에 모든 호출을 몰아넣지 말고, 작업 큐와 실행 노드를 분리하는 편이 안전합니다. 여러 팀원이 같은 환경을 공유한다면 Ollama 배치 작업과 권한 점검에 관한 JexMac 안내처럼 서비스 계정과 접근 범위도 함께 확인해야 합니다.

FAQ

모델 목록이 정상인데 호스트 메모리가 줄지 않는 이유

모델 목록은 Ollama가 관리하는 모델 실행 상태를 보여주는 값입니다. 호스트 메모리에는 Runner 힙, 파일 매핑, Metal 작업 집합, 다른 프로세스의 점유가 함께 포함될 수 있습니다. 따라서 목록의 변화와 시스템 메모리 압력의 변화가 반드시 동시에 나타나지 않습니다. 두 결과를 시간순으로 기록해야 합니다.

keep_alive 0을 적용해도 누수가 남을 수 있는 이유

이 설정은 모델 유지 시간을 즉시 끝내도록 요청하는 제어입니다. 이미 커진 프로세스 힙이나 오류 상태의 Metal 자원을 강제로 운영 체제에 반환하는 명령은 아닙니다. 모델이 내려간 뒤에도 Runner가 남아 있다면 서비스 재시작을 별도 검증하되, 먼저 로그와 프로세스 식별자를 보존해야 합니다.

모델을 내린 뒤 확인해야 할 실제 회수 증거

모델 실행 목록에서 대상이 사라지는 것은 첫 번째 증거에 불과합니다. 같은 Runner가 종료됐는지, 시스템 메모리 압력이 내려갔는지, 스왑 활동이 줄었는지, 서비스 로그에 오류가 없는지를 함께 확인해야 합니다. 이후 동일한 요청을 다시 실행해 성공 여부와 냉시작 영향을 비교해야 회수 효과를 판단할 수 있습니다.

지속형 DeepSeek-R1에서 재시작 빈도를 정하는 방법

고정된 시간 간격을 먼저 정하면 안 됩니다. 요청 수, 입력과 출력의 길이, 동시 호출 수 중 메모리 증가와 함께 움직이는 변수를 찾아야 합니다. 배치가 끝날 때 회수해도 되는지, 세션 단위 유지가 필요한지, 아니면 독립 노드로 옮겨야 하는지를 작업 성공률과 복구 비용으로 판단해야 합니다.

현재 한 대의 맥에서 배치와 지속형 에이전트를 함께 운영하면, 공유 메모리 압박과 수동 재시작, 다른 작업의 예기치 않은 중단이라는 단점이 남습니다. 클라우드 맥은 회수 정책을 잘못 설계하면 냉시작 비용이 생기지만, 작업을 독립 노드로 나누고 장애가 난 노드를 교체하기는 더 쉽습니다. 먼저 실제 요청 묶음으로 실행, 언로드, 재실행을 비교한 뒤 자주 회수해야만 안정성이 유지된다면 JexMac의 맥 렌탈 선택지를 검토하는 편이 실험적 시스템 설정을 계속 덮어쓰는 것보다 관리 가능한 비용 구조를 만들 수 있습니다.

자주 묻는 질문