Ollama pull과 run 차이점 및 모델 저장 경로 확인

ollama pull과 ollama run의 차이

ollama pull는 모델을 다운로드한 뒤 종료합니다. ollama run는 모델이 없을 때만 다운로드한 후, 메모리에 로드하여 대화형 채팅 세션을 엽니다. 다운로드 과정은 동일하며 파일은 같은 위치에 저장됩니다. 오직 run만이 실행 후에도 계속 유지됩니다.

이러한 차이점 하나가 스크립트용 명령어와 키보드 입력용 명령어를 결정합니다.

ollama pull gemma4
ollama run gemma4
ollama run gemma4 "Reply with one word: ready"

첫 번째 줄은 모델을 가져온 뒤 종료하므로 프로비저닝이나 systemd 유닛에서 사용하기에 안전합니다. 두 번째 줄은 채팅 세션을 엽니다. 종료하려면 /bye을 입력하거나 Ctrl+D를 누르십시오. 세 번째 줄은 단일 프롬프트를 전송하고 답변을 출력한 뒤 종료합니다. 이는 세션이 아닌 답변이 필요한 스크립트에서 사용하는 방식입니다. 세 번째 방식은 답변의 길이를 전적으로 모델에 맡기므로, 한 줄짜리 질문이 세 문단으로 돌아올 수 있습니다. num_predict로 답변 제한하기를 사용하면 스크립트에서 실행한 run의 결과 크기를 호출자가 처리 가능한 수준으로 유지할 수 있습니다. 모델 이름은 빠르게 변하므로 여기서 사용한 gemma4는 예시로 간주하십시오. 이는 2026년 8월 기준 공식 Ollama 문서에서 사용하는 예시이며, 라이브러리의 모든 태그는 동일하게 동작합니다. 실제 서버 환경에서 크기가 검증된 모델을 사용하고 싶다면, VPS에서 Nemotron 3.5 Lightning 실행하기를 참조하여 정확한 태그와 필요한 메모리 사양을 확인하십시오.

첫 ollama run 실행 시 멈춘 것처럼 보이는 이유

새로 구축한 VPS에서 처음 run을 실행하면 몇 분 동안 아무런 출력도 나타나지 않을 수 있습니다. 이는 오류가 아닙니다. 모델이 디스크에 저장되고 메모리에 로드되기 전까지는 채팅 프롬프트가 표시될 수 없으므로, run은 사용자에게 보여줄 내용이 준비되기 전까지 수 기가바이트에 달하는 데이터를 다운로드하는 중입니다.

이러한 작업 과정이 보이지 않는 이유는 두 가지입니다. Ollama는 출력이 터미널일 때만 진행률 표시줄을 그리므로, 셸 스크립트, cron 작업, CI 단계 내부에서 실행하거나 단순히 ssh host ollama run ...으로 실행하는 run는 다운로드 중 아무것도 출력하지 않습니다. 데이터 다운로드가 완료된 후에도 첫 번째 토큰이 생성되려면 파일을 디스크에서 RAM으로 읽어 들여야 하는데, 사양이 낮은 VPS에서는 이 읽기 작업이 느립니다. 만약 서버의 메모리가 모델을 올리기에 부족하다면 커널이 스왑(swapping)을 시작하여 대기 시간이 훨씬 길어집니다.

추측하지 말고 다른 세션에서 상태를 확인하십시오.

df -h /
watch -n5 df -h /

여유 공간이 단계적으로 줄어든다면 다운로드가 진행 중인 것입니다. 명령은 여전히 실행 중인데 여유 공간이 더 이상 줄어들지 않는다면 다운로드가 완료되고 메모리 로드가 시작된 것입니다.

이것이 미리 모델을 받아두어야 하는 이유입니다. ollama run를 입력하는 사용자가 다운로드 시간을 기다리는 상황은 발생하지 않아야 합니다.

요청이 들어오기 전에 모델을 미리 내려받기

사람이 아닌 대상도 마찬가지입니다. Ollama 엔드포인트를 가리키는 코딩 에이전트는 수 기가바이트에 달하는 다운로드가 완료되기를 기다리기보다 첫 번째 요청에서 포기할 가능성이 큽니다. 새로운 서버를 구축할 때는 서버를 설치하는 스크립트에 모델을 내려받는 과정을 포함하십시오.

curl -fsSL https://ollama.com/install.sh | sh
ollama pull gemma4

서버를 처음 구축하는 경우, VPS에 Ollama 전체 설치하기 문서를 참조하여 서비스 자체와 접근 권한을 설정하십시오. 그 후에는 터미널 세션이 종료되어도 유지되는 다운로드 작업을 설정하는 것이 좋습니다. 다운로드가 중간에 중단되면 모델 저장소가 불완전하게 구성될 수 있기 때문입니다.

이 작업을 tmux 내부에서 실행하거나, 부팅 시 한 번만 실행되는 systemd one-shot 유닛으로 등록하십시오. /etc/systemd/system/ollama-pull.service 파일을 작성하십시오:

[Unit]
Description=Pre-pull Ollama models
Wants=ollama.service network-online.target
After=ollama.service network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'until ollama list >/dev/null 2>&1; do sleep 2; done'
ExecStart=/bin/sh -c 'ollama pull gemma4'

[Install]
WantedBy=multi-user.target

두 명령어 모두 의도적으로 /bin/sh -c을 거쳐 실행됩니다. 단순히 ExecStart=만 사용하면 절대 경로가 필요한데, 설치 프로그램이 바이너리를 항상 같은 디렉터리에 배치하지는 않으므로 본인의 서버에서 command -v ollama를 사용하는 것이 유일한 확실한 방법입니다. 셸을 거치면 가이드에서 복사한 경로 대신 서비스의 PATH를 사용하게 됩니다. 첫 번째 ExecStart도 중요합니다. After=ollama.service은 서버 유닛이 시작되었다는 의미일 뿐 준비가 완료되었다는 뜻은 아니므로, 루프를 사용하여 ollama list가 응답할 때까지 기다린 후 다운로드를 시작해야 합니다.

sudo systemctl daemon-reload
sudo systemctl enable --now ollama-pull.service
journalctl -u ollama-pull.service

저널 로그를 확인하여 다운로드가 오류 없이 완료되었는지 확인하고, ollama list 명령어로 모델이 정상적으로 표시되는지 확인하십시오. 변경되는 태그를 최신 상태로 유지하려면 systemd 타이머나 매주 실행되는 cron 항목을 추가하여 동일한 pull 명령을 수행하십시오. 태그가 업데이트되어 다시 내려받으면 새로운 레이어가 다운로드되고 기존 레이어는 참조가 끊기게 되는데, 이는 서버가 다음번에 시작될 때 정리됩니다.

풀(pull) 작업이 중단되면 발생하는 일

모델의 각 레이어는 해당 콘텐츠의 해시값으로 저장됩니다. 따라서 풀 작업이 중단되어도 작업이 헛수고가 되지는 않습니다. 동일한 ollama pull를 다시 실행하면 이미 완료된 레이어는 인식되어 건너뛰게 되며, 다운로드가 중단되었던 레이어부터 다시 시작됩니다.

이러한 진행 상황을 무효화하는 동작이 하나 있습니다. Ollama 서버가 시작될 때, 어떤 모델 매니페스트에서도 참조하지 않는 저장된 레이어를 삭제하는데, 중단된 풀 작업으로 남은 부분 레이어가 바로 여기에 해당합니다. 따라서 서비스를 재시작하기 전에 풀을 다시 시도해야 이미 다운로드한 부분을 버리지 않게 됩니다. 풀을 먼저 재시도하고 나중에 재시작하십시오. 부분 다운로드가 재시작 후에도 반드시 유지되어야 한다면 서비스 환경 변수에 OLLAMA_NOPRUNE=1를 설정한 뒤 다시 제거하십시오. 시작 시 수행되는 정리 작업은 디스크에 고아 레이어가 쌓이는 것을 방지하는 역할을 합니다.

풀 작업이 no space left on device 오류로 중단되었다면 재시도하기 전에 여유 공간을 확보하십시오. df 명령에서 디스크가 꽉 찼다고 보고하지만 모델 디렉터리의 du 결과가 이를 설명하지 못한다면, 공간은 다른 곳에서 사용 중인 것입니다. 무언가를 삭제하기 전에 df와 du의 결과가 일치하지 않는 이유를 읽어보는 것이 좋습니다.

Ollama는 VPS의 어디에 모델을 저장합니까?

이 가이드를 포함한 어떤 문서의 경로를 맹신하기보다 직접 서버에서 확인하십시오. 저장 위치는 패키지 설치 방식과 컨테이너 방식에 따라 다르며, 누군가 OLLAMA_MODELS를 설정했다면 또다시 변경됩니다.

systemctl cat ollama.service
getent passwd ollama
sudo find / -xdev -type d -name blobs 2>/dev/null

systemctl cat은 모든 드롭인(drop-in) 설정을 포함한 유닛 파일을 출력하므로, 사용자가 설정했거나 이미지에 포함된 OLLAMA_MODELS 라인이 있다면 그곳에 나타납니다. 해당 라인이 없다면 저장소는 서비스가 실행되는 계정의 홈 디렉터리 하위에 위치하며, getent passwd는 콜론으로 구분된 여섯 번째 필드에서 해당 홈 디렉터리를 출력합니다. find은 파일 시스템에서 blobs 디렉터리를 검색하며, 이곳이 실제로 레이어가 기록되는 장소입니다. 모델이 이미 별도의 마운트 지점에 있다면 -xdev를 생략하십시오.

이제 직접 측정하고 수치를 확인하십시오:

ollama list
df -h /
sudo du -sh /the/directory/you/found
sudo du -h -d1 /the/directory/you/found

저장소는 두 부분으로 구성됩니다. manifests은 모델 태그당 작은 파일 하나를 보관하며, 이 파일은 해당 태그를 구성하는 레이어 목록을 담고 있습니다. blobs은 레이어 자체를 보관하며, 각 레이어는 내용의 해시값으로 이름이 지정됩니다. 전체 용량의 대부분은 이곳이 차지합니다. 레이어는 태그 간에 공유되므로, 동일한 가중치를 기반으로 하는 두 모델은 각각 ollama list에서 자신의 크기를 보고하지만 디스크상에서는 해당 공간을 한 번만 점유합니다. 따라서 나열된 크기의 합계가 du가 보고하는 디렉터리 크기보다 클 수 있습니다.

모델 파일은 설치할 수 있는 그 어떤 항목보다 빠르게 소형 VPS의 루트 파일 시스템을 가득 채웁니다. 모델 크기를 조절하는 가장 큰 변수는 가중치 형식입니다. q4, q8 및 fp16 선택하기를 통해 모델당 기가바이트 단위의 용량을 절약할 수 있습니다.

OLLAMA_MODELS를 사용하여 모델을 데이터 볼륨으로 이동하기

플랜에 두 번째 디스크나 더 큰 데이터 볼륨이 있다면, 루트 파일시스템이 가득 차기 전에 저장소를 이동하십시오. 서버를 먼저 중지하여 작성 중인 파일이 복사되지 않도록 하십시오.

sudo systemctl stop ollama
sudo mkdir -p /mnt/data/ollama-models
sudo rsync -a /the/directory/you/found/ /mnt/data/ollama-models/
sudo chown -R ollama:ollama /mnt/data/ollama-models
sudo systemctl edit ollama.service

systemctl edit은 드롭인 파일에서 편집기를 엽니다. 따라서 패키지된 유닛은 변경되지 않은 상태로 유지되며 패키지 업그레이드 시 변경 사항이 덮어쓰이지 않습니다. 다음 두 줄을 추가하십시오:

[Service]
Environment="OLLAMA_MODELS=/mnt/data/ollama-models"

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

systemctl show은 새로운 경로를 출력해야 하며, ollama list는 이동 전과 동일한 모델을 보여주어야 합니다. 목록이 비어 있다면 서버가 새로운 디렉터리를 읽을 수 없다는 의미입니다. 서비스는 ollama 사용자로 실행되므로, 해당 사용자는 대상 경로에 대한 읽기 및 쓰기 권한이 필요합니다. 이는 위에서 언급한 chown 줄의 역할입니다. 새로운 경로를 가리키는 권한 오류가 있는지 journalctl -e -u ollama를 확인하십시오. 목록이 올바르게 출력된 후에만 이전 복사본을 삭제하십시오. 이동에 실패했는데 원본까지 삭제하면 모든 데이터를 다시 다운로드해야 하기 때문입니다.

다른 방법은 원래 경로를 유지하고 데이터 볼륨을 해당 경로에 마운트하는 것입니다:

echo '/mnt/data/ollama-models /the/directory/you/found none bind 0 0' | sudo tee -a /etc/fstab
sudo mount -a
findmnt /the/directory/you/found
df -h /

findmnt이 마운트 정보를 출력한다면 바인드 마운트가 활성화된 것입니다. 바인드 마운트는 시스템의 다른 요소가 이미 기본 위치를 참조하고 있을 때 유용합니다. 여기에는 한 가지 주의점이 있습니다. 복사해 낸 파일들이 루트 디스크의 마운트 지점 아래에 그대로 남아 마운트에 의해 가려져 있다는 점입니다. 따라서 마운트를 해제하고 파일을 삭제하기 전까지는 디스크 공간이 확보되지 않습니다. 환경 변수를 사용하는 방식이 다음에 로그인할 사용자에게 설명하기 더 쉽습니다.

컨테이너가 모델을 저장하는 위치

공식 이미지는 모델을 호스트의 특정 ollama 사용자 디렉터리가 아닌, 사용자가 마운트한 위치에 저장합니다. 문서화된 실행 명령은 다음과 같습니다.

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

콜론 앞의 ollama은 명명된 Docker 볼륨이며, /root/.ollama는 컨테이너 내부에서 서버가 데이터를 기록하는 경로입니다. 따라서 이전 섹션의 경로를 대상으로 du을 실행해도 아무것도 찾을 수 없습니다. 실제 위치와 크기를 확인하려면 다음 명령을 사용하십시오.

docker volume inspect ollama
docker system df -v
docker exec -it ollama ollama list

docker volume inspect에서 Mountpoint 필드를 읽은 다음, 해당 경로를 대상으로 sudo du -sh을 실행하십시오. 모델을 데이터 볼륨에 저장하려면 명명된 볼륨을 호스트 디렉터리(-v /mnt/data/ollama:/root/.ollama)로 교체하고 컨테이너를 다시 생성하십시오. 컨테이너는 root 권한으로 기록하므로 해당 호스트 디렉터리의 소유권은 root가 됩니다. rootless Podman 환경에서는 ID가 사용자의 subuid 범위로 매핑되므로 호스트의 소유권 상태가 다르게 나타납니다. rootless Podman에서 Ollama 실행하기에서 해당 매핑을 다룹니다.

정리 작업 시 주의 사항이 있습니다. docker volume prune는 어떤 컨테이너도 참조하지 않는 모든 볼륨을 삭제합니다. 볼륨 없이 ollama 컨테이너를 제거하거나 다시 생성한 뒤 prune을 실행하면 다운로드한 모든 모델이 삭제되며, 다시 다운로드하는 방법 외에는 복구할 수 없습니다. 모델을 호스팅하는 서버에서 prune을 실행하기 전에 VPS에서 Docker 디스크 사용량 정리하는 방법을 먼저 읽어보시기 바랍니다.

rm 명령어가 아닌 ollama rm으로 모델 삭제하기

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm은 해당 태그의 매니페스트를 삭제한 뒤, 어떤 매니페스트에서도 참조하지 않는 레이어를 삭제합니다. 해당 파일들의 연결이 해제되는 즉시 디스크 공간이 확보되므로 df은 즉시 반영됩니다. 레이어는 여러 모델 간에 공유되므로, 밀접하게 연관된 두 태그 중 하나를 삭제해도 ollama list 옆에 표시된 크기보다 훨씬 적은 공간만 확보될 수 있습니다. 이는 삭제 실패가 아니라 정상적인 동작입니다.

파일을 직접 삭제하면 이 쌍이 깨집니다. rm로 블롭(blob)을 삭제해도 매니페스트에는 여전히 해당 항목이 남아 있으므로, ollama list은 계속해서 해당 모델을 표시하며 누락된 레이어를 읽으려 할 때마다 사용 시도가 실패합니다. 매니페스트를 직접 삭제하면 레이어는 디스크에 그대로 남아 아무것도 참조하지 않는 상태가 되며, Ollama 명령어로는 확인할 수 없는 공간을 차지하게 됩니다. 이미 직접 삭제를 수행했다면 해당 태그에 ollama rm을 실행하여 남은 항목을 정리하고, 서버를 재시작하여 참조되지 않는 레이어를 정리하십시오.

마지막으로, 두 개념이 자주 혼동되므로 명확히 구분해야 합니다. ollama rm는 디스크와 관련이 있습니다. ollama stop gemma4은 메모리에서 모델을 내릴 뿐 디스크 공간을 전혀 확보하지 않습니다. 모델 다운로드가 완료된 후 RAM에 얼마나 오래 상주할지는 별도의 설정이며, 요청마다 다시 로드하지 않고 모델을 메모리에 유지하기에서 다룹니다.

FAQ

ollama pull과 ollama run의 차이점은 무엇입니까?

ollama pull는 모델을 디스크에 다운로드한 뒤 종료합니다. ollama run는 모델이 이미 디스크에 있는지 확인하고, 없다면 다운로드한 뒤 메모리에 로드하여 대화형 세션을 시작합니다. 두 명령어 모두 동일한 디렉터리에 동일한 파일을 기록합니다. 프로비저닝이나 스크립트에는 pull을 사용하고, 사용자가 직접 조작할 때는 run을 사용하십시오. ollama run <model> "your prompt"은 프롬프트 하나를 전송하고 종료하며, 이는 run를 스크립트에서 사용하기 적합하게 만든 형태입니다.

첫 ollama run 실행 시 멈춘 것처럼 보이는 이유는 무엇입니까?

다운로드 중이기 때문입니다. 모델이 디스크에 저장되고 메모리에 로드되기 전까지는 대화 프롬프트가 나타나지 않으며, 모델 파일은 수 기가바이트에 달합니다. Ollama는 출력이 터미널일 때만 진행률 표시줄을 출력하므로, 스크립트나 cron 작업, ssh host ollama run ... 내부의 run은 작업 중 아무런 표시를 하지 않습니다. 두 번째 세션을 열고 watch -n5 df -h /를 실행하십시오. 여유 공간이 단계적으로 줄어든다면 다운로드가 진행 중인 것입니다. 모델을 미리 pull 해두면 대기 시간이 사라집니다.

Ollama는 모델을 어디에 저장합니까?

저장 위치는 설치 방식에 따라 다르므로 추측하지 말고 직접 확인해야 합니다. systemctl cat ollama.service을 실행하여 unit 파일이나 drop-in 설정에 OLLAMA_MODELS가 지정되어 있는지 확인하십시오. 지정되지 않았다면 서비스가 실행되는 계정의 홈 디렉터리 아래에 저장되며, getent passwd ollama로 확인할 수 있습니다. sudo find / -xdev -type d -name blobs 2>/dev/null은 레이어 디렉터리 위치를 직접 알려줍니다. 컨테이너 이미지의 경우 저장소는 마운트된 볼륨 내부에 있으며, docker volume inspect ollama이 호스트의 Mountpoint을 출력합니다.

Ollama 모델을 다른 디스크로 옮기려면 어떻게 합니까?

서비스를 중지하고 rsync -a를 사용하여 저장소를 새 위치로 복사한 뒤, sudo chown -R ollama:ollama <directory>으로 서비스 계정에 디렉터리 소유권을 부여하십시오. 그 후 sudo systemctl edit ollama.service을 실행하여 [Service] 라인 아래에 Environment="OLLAMA_MODELS=<directory>"를 추가합니다. sudo systemctl daemon-reload로 설정을 다시 불러온 뒤 서비스를 재시작하십시오. systemctl show ollama --property=Environment와 ollama list으로 확인합니다. 목록이 비어 있다면 거의 항상 ollama 사용자가 새 디렉터리를 읽을 권한이 없기 때문입니다. journalctl -e -u ollama을 실행하면 경로를 확인할 수 있습니다.

모델 파일을 삭제하면 공간이 확보됩니까?

파일을 수동으로 삭제하면 용량은 확보되지만 저장소 상태가 일관되지 않게 됩니다. 블롭(blob)을 삭제해도 매니페스트에는 해당 모델이 남아 있어 ollama list 목록에 계속 표시되며, 사용 시 오류가 발생합니다. 매니페스트를 삭제해도 참조되지 않는 레이어 파일이 디스크에 남습니다. 매니페스트를 삭제하고 다른 모델이 사용하지 않는 레이어까지 정리해 주는 ollama rm <model>을 사용하십시오. 파일을 이미 수동으로 삭제했다면 해당 태그에 대해 ollama rm을 실행하여 항목을 지운 뒤 서버를 재시작하십시오. 그러면 어떤 매니페스트도 참조하지 않는 레이어가 제거됩니다.