Ollama pull ve run farkı: Model dosyaları nerede?

ollama pull ve ollama run arasındaki fark

ollama pull bir modeli indirir ve durur. ollama run modeli yalnızca eksikse indirir, ardından belleğe yükler ve etkileşimli bir sohbet başlatır. İndirme işlemi aynıdır ve dosyalar aynı konuma kaydedilir. Yalnızca run işlem sonrasında çalışmaya devam eder.

Bu tek fark, hangi komutun bir betik içerisinde, hangisinin ise klavye başında kullanılması gerektiğini belirler.

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

İlk satır modeli getirir ve çıkar; bu nedenle provizyon işlemlerinde ve bir systemd biriminde kullanımı güvenlidir. İkinci satır bir sohbet oturumu açar; oturumdan çıkmak için /bye yazın veya Ctrl+D tuşlarına basın. Üçüncü satır tek bir istem gönderir, yanıtı yazdırır ve çıkar; bu, bir betiğin oturum yerine doğrudan yanıt beklediği durumlarda ihtiyaç duyduğu biçimdir. Bu üçüncü biçim, yanıtın uzunluğunu tamamen modele bırakır; dolayısıyla tek satırlık bir soru üç paragraf olarak dönebilir. num_predict ile yanıtı sınırlandırmak, betik içindeki bir run komutunun, çağıran tarafın işleyebileceği bir boyutta kalmasını sağlar. Model isimleri hızla değiştiği için buradaki gemma4 ifadesini bir yer tutucu olarak değerlendirin: bu, Ağustos 2026 itibarıyla resmi Ollama belgelerinde kullanılan örnektir ve kütüphanedeki tüm etiketler aynı şekilde davranır. Eğer halihazırda gerçek bir sunucuda boyutlandırılmış bir modeli kullanmak isterseniz, Nemotron 3.5 Lightning modelini bir VPS üzerinde çalıştırmak başlığı, çekilecek tam etiketi ve ihtiyaç duyulan bellek miktarını belirtir.

Ollama ilk kez çalıştırıldığında neden donmuş gibi görünür

Yeni bir VPS üzerinde gerçekleştirilen ilk run, birkaç dakika boyunca hiçbir çıktı vermeden bekleyebilir. Herhangi bir hata yoktur. Model diske indirilip belleğe yüklenmeden sohbet istemi görüntülenemez; bu nedenle run, size gösterecek bir şey bulmadan önce çok gigabyte'lık bir indirme işlemi gerçekleştirmektedir.

İki durum bu süreci gizler. Ollama, ilerleme çubuğunu yalnızca terminal üzerinde çalıştırıldığında çizer; bu yüzden bir shell script, cron job, CI adımı veya düz bir ssh host ollama run ... içerisindeki run, indirme sırasında hiçbir çıktı vermez. Ayrıca baytlar diske yazıldıktan sonra, ilk token üretilmeden önce dosyanın diskten RAM'e okunması gerekir; küçük bir VPS üzerinde bu okuma işlemi yavaştır. Eğer sunucunun model için yeterli belleği yoksa, çekirdek swap yapmaya başlar ve bekleme süresi önemli ölçüde uzar.

Tahmin yürütmek yerine ikinci bir oturumdan süreci izleyin:

df -h /
watch -n5 df -h /

Boş alanın kademeli olarak azalması, indirmenin devam ettiği anlamına gelir. Komut hala meşgulken boş alanın azalması durmuşsa, indirme tamamlanmış ve belleğe yükleme süreci başlamış demektir.

Önceden indirme (pull) yapmanın temel nedeni budur. ollama run komutunu çalıştıran kişi, indirme süresini bekleyen kişi olmamalıdır.

Modeli kimse talep etmeden önce çekin

Kişi olmayan her şey için aynı durum geçerlidir: Ollama uç noktanıza yönlendirilmiş bir kodlama aracı, birkaç gigabaytlık bir indirme işleminin bitmesini beklemek yerine genellikle ilk istekte pes edecektir. Yeni bir sunucuda, sunucuyu kuran betiğin aynısı ile çekme işlemini gerçekleştirin:

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

Sunucuyu ilk kez ayağa kaldırıyorsanız, VPS üzerinde tam Ollama kurulumu rehberi, servisin kendisini ve ona kimlerin erişebileceğini kapsar. Bundan sonra yapılması gereken en önemli şey, terminal oturumunuz kapansa bile devam edecek bir çekme işlemi ayarlamaktır; çünkü yarıda kesilen bir indirme, kullanıcıların eksik verilerle dolu bir model deposuna sahip olmasına neden olur.

Bunu tmux içinde çalıştırın veya önyükleme sırasında çalışan bir "one-shot" birimi olarak systemd'ye verin. /etc/systemd/system/ollama-pull.service dosyasını oluşturun:

[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

Her iki komut da kasıtlı olarak /bin/sh -c üzerinden çalıştırılır. Yalın bir ExecStart= mutlak yol gerektirir ve yükleyici ikili dosyayı her zaman aynı dizine yerleştirmez; bu nedenle kendi sunucunuzdaki command -v ollama tek güvenilir yanıttır. Shell üzerinden ilerlemek, bir rehberden kopyalanan yol yerine servisin kendi PATH değerini kullanır. İlk ExecStart ifadesi de önemlidir: After=ollama.service, sunucu biriminin başlatıldığı anlamına gelir ancak bu, servisin hazır olduğu anlamına gelmez; bu nedenle döngü, çekme işlemi başlamadan önce ollama list yanıt verene kadar bekler.

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

Günlük kayıtları, çekme işleminin hatasız tamamlandığını göstermeli ve ollama list komutu ardından modeli listelemelidir. Hareketli bir etiketi güncel tutmak için bir systemd zamanlayıcısı veya aynı çekme işlemini çalıştıran haftalık bir cron girdisi ekleyin. Değişmiş bir etiketi yeniden çekmek, yeni katmanları indirir ve eskilerini referanssız bırakır; bu artıklar sunucu bir sonraki başlatıldığında temizlenir.

Bir çekme işlemi kesintiye uğradığında ne olur

Bir modelin her katmanı, kendi içeriğinin hash değeri altında saklanır. Bu nedenle kesintiye uğrayan bir çekme işlemi boşa giden bir çalışma değildir: aynı ollama pull komutunu tekrar çalıştırdığınızda, zaten tamamlanmış olan katmanlar tanınır ve atlanır; böylece indirme işlemi kesilen katmandan devam eder.

Bir eylem bu ilerlemeyi yok eder. Ollama sunucusu başladığında, hiçbir model manifestosunun referans vermediği saklı katmanları kaldırır; yarım kalan bir çekme işleminden geriye kalan kısmi katman da tam olarak budur. Bu yüzden servisi yeniden denemeden önce yeniden başlatmak, zaten indirdiğiniz parçayı çöpe atar. Önce çekme işlemini tekrar deneyin, servisi daha sonra yeniden başlatın. Eğer kısmi bir indirmenin yeniden başlatma sonrasında mutlaka korunması gerekiyorsa, servis ortamında OLLAMA_NOPRUNE=1 değerini ayarlayın ve ardından bu ayarı geri alın; çünkü bu başlangıç temizliği, yetim katmanların diskte birikmesini önleyen mekanizmadır.

Eğer çekme işlemi no space left on device hatasıyla sonlandıysa, tekrar denemeden önce diskte yer açın. Eğer df komutu diskin dolu olduğunu bildiriyor ve model dizini üzerindeki du komutu bu durumu açıklamıyorsa, alan başka bir yere gitmiştir; herhangi bir şeyi silmeden önce df ve du komutlarının neden farklı sonuçlar verdiği konusunu okumanızda fayda vardır.

Ollama, bir VPS üzerinde modelleri nerede saklar?

Herhangi bir rehberdeki veya bu belgedeki yola güvenmek yerine kendi sunucunuza danışın. Konum, paket kurulumu ile container kurulumu arasında farklılık gösterir ve eğer birisi OLLAMA_MODELS değişkenini ayarladıysa tekrar değişir.

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

systemctl cat komutu, birim dosyasını tüm ek yapılandırmalarla (drop-in) birlikte yazdırır; böylece sizin tarafınızdan ayarlanan veya imajınıza gömülü olan bir OLLAMA_MODELS satırı burada görünür hale gelir. Böyle bir satır yoksa, depolama alanı servisin çalıştırıldığı hesabın ev dizini altındadır ve getent passwd komutu, iki nokta üst üste ile ayrılmış altıncı alanda bu ev dizinini yazdırır. find komutu, katmanların fiilen yazıldığı blobs dizinini bulmak için dosya sistemini tarar. Modeller halihazırda ayrı bir bağlama noktasında (mount) olabilir, bu durumda -xdev komutunu kullanın.

Şimdi ölçüm yapın ve kendi değerlerinizi okuyun:

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

Depolama alanı iki bölümden oluşur. manifests, her model etiketi için bir küçük dosya tutar ve bu dosya, etiketin hangi katmanlardan oluşturulduğunu listeler. blobs ise katmanların kendisini tutar; her biri içeriğinin hash değeri ile adlandırılır ve toplam boyutun neredeyse tamamı buradadır. Katmanlar etiketler arasında paylaşıldığı için, aynı ağırlıklar üzerine inşa edilmiş iki model, ollama list içerisinde kendi boyutlarını rapor etseler de diskte bu alanı yalnızca bir kez kaplarlar. Bu nedenle, listelenen boyutların toplamı du tarafından rapor edilen dizin boyutundan daha fazla görünebilir.

Model dosyaları, küçük bir VPS kök dosya sistemini kurabileceğiniz diğer her şeyden daha hızlı doldurur ve boyutları üzerindeki en büyük etken ağırlık formatıdır. q4, q8 ve fp16 arasında seçim yapmak, model başına gigabaytlarca tasarruf sağlayabilir.

Modelleri OLLAMA_MODELS ile bir veri birimine taşıma

Eğer planınızda ikinci bir disk veya daha geniş bir veri birimi varsa, kök dosya sistemi dolmadan önce depolama alanını taşıyın. Hala yazılmakta olan bir dosyayı kopyalamamak için önce sunucuyu durdurun.

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 bir drop-in dosyası üzerinde düzenleyiciyi açar; böylece paketlenmiş unit dosyası değişmeden kalır ve bir paket yükseltmesi yaptığınız değişikliğin üzerine yazamaz. Şu iki satırı ekleyin:

[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 yeni yolunuzu yazdırmalı ve ollama list taşınmadan önce gösterdiği modellerin aynısını göstermelidir. Boş bir liste, sunucunun yeni dizini okuyamadığı anlamına gelir. Servis ollama kullanıcısı olarak çalışır, bu nedenle bu kullanıcının hedef dizine okuma ve yazma erişimine sahip olması gerekir; bu da yukarıdaki chown satırının görevidir. Yeni yolu belirten izin hataları için journalctl -e -u ollama dosyasını kontrol edin. Eski kopyayı yalnızca liste doğru göründükten sonra silin; çünkü başarısız bir taşıma işlemi ve ardından silinen kaynak, her şeyi yeniden indirmeniz gerektiği anlamına gelir.

Diğer seçenek, orijinal yolu koruyup veri birimini bu yol üzerine bağlamaktır (mount):

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 komutunun mount noktasını yazdırması, bağlama işleminin aktif olduğu anlamına gelir. Bir bind mount, sunucudaki başka bir öğe varsayılan konumu beklediğinde yardımcı olur. Bunun bir dezavantajı vardır: kopyaladığınız dosyalar kök disk üzerinde mount noktasının altında kalır ve mount tarafından gizlenir; bu nedenle siz unmount edip onları silene kadar disk alanı geri kazanılmaz. Ortam değişkeni yöntemi, daha sonra sisteme giriş yapacak kişilere açıklanması açısından iki yöntemden daha kolay olanıdır.

Kapsayıcının bunları nerede tuttuğu

Resmi imaj, modelleri herhangi bir ollama kullanıcısına ait ana makine dizininde değil, bağladığınız (mount) herhangi bir yerde saklar. Belgelenmiş çalıştırma komutu şöyledir:

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

İki noktadan önceki ollama adlandırılmış bir Docker birimidir (volume) ve /root/.ollama, sunucunun kapsayıcı içinde yazma yaptığı yerdir. Bu nedenle, önceki bölümdeki yollara karşı du komutunu çalıştırmak hiçbir şey bulamaz, çünkü orada hiçbir şey yoktur. Gerçek konumu ve boyutu yazdırın:

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

docker volume inspect içindeki Mountpoint alanını okuyun, ardından ona karşı sudo du -sh komutunu çalıştırın. Modelleri bir veri birimine koymak için, adlandırılmış birimi bir ana makine dizini (-v /mnt/data/ollama:/root/.ollama) ile değiştirin ve kapsayıcıyı yeniden oluşturun. Kapsayıcı root olarak yazma yapar, bu nedenle söz konusu ana makine dizininin sahibi root olur. Rootless Podman altında kimlikler bunun yerine kullanıcınızın subuid aralığına eşlenir, bu yüzden ana makine sahipliği tekrar farklı görünür: rootless Podman altında Ollama çalıştırma bu eşlemeyi kapsar.

Temizlik hakkında bir uyarı. docker volume prune, hiçbir kapsayıcının referans vermediği her birimi kaldırır. ollama kapsayıcısını birimi olmadan kaldırır veya yeniden oluşturursanız, daha sonra yapılacak bir budama (prune) işlemi, indirdiğiniz her modeli geri dönüşü olmayacak şekilde siler; tek çözüm onları tekrar indirmektir. Modelleri barındıran bir sunucuda budama işlemi yapmadan önce VPS üzerinde Docker disk kullanımı nasıl budanır konusunu okuyun.

Remove a model with ollama rm, not with rm

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm deletes the manifest for that tag, then deletes the layers no remaining manifest refers to. The space comes back as soon as those files are unlinked, so df moves straight away. Because layers are shared, removing one of two closely related tags can free far less than the size ollama list printed next to it. That is correct behaviour, not a failed delete.

Deleting files by hand breaks the pair. Remove a blob with rm and the manifest still lists it, so ollama list keeps showing the model and any attempt to use it fails when the missing layer is read. Remove a manifest by hand and its layers stay on disk with nothing pointing at them, holding space that no Ollama command will report to you. If you have already done it, ollama rm on the tag clears the leftover entry, and restarting the server clears layers that nothing refers to.

One last distinction, because the two get mixed up constantly. ollama rm is about disk. ollama stop gemma4 unloads a model from memory and frees no disk at all. How long a model stays resident in RAM once the download is finished is a separate setting, and keeping a model loaded instead of reloading it on every request covers it.

FAQ

ollama pull ve ollama run arasındaki fark nedir?

ollama pull bir modeli diske indirir ve çıkar. ollama run modelin diskte olup olmadığını kontrol eder, yoksa indirir, belleğe yükler ve ardından etkileşimli bir sohbet oturumu başlatır. Her ikisi de aynı dosyaları aynı dizine yazar. Hazırlık aşamalarında ve betiklerde pull komutunu, klavye başında bir kullanıcı varken ise run komutunu kullanın. ollama run <model> "your prompt" tek bir komut gönderip çıkar; bu, run komutunun betiklenebilir biçimidir.

İlk ollama run komutum neden donmuş gibi görünüyor?

Model indirilmektedir. Sohbet istemi, model diskte hazır olana ve belleğe yüklenene kadar görünemez; modeller birkaç gigabayt boyutundadır. Ollama ilerleme çubuğunu yalnızca çıktı bir terminale yönlendirildiğinde çizer; bu nedenle bir betik, cron işi veya ssh host ollama run ... içindeki bir run komutu, işlem sürerken hiçbir şey göstermez. İkinci bir oturum açın ve watch -n5 df -h / komutunu çalıştırın: boş alanın kademeli olarak azalması, indirmenin devam ettiğini gösterir. Modeli önceden çekerseniz bekleme süresi ortadan kalkar.

Ollama modellerini nerede saklar?

Konum kuruluma göre değişir, bu yüzden varsayımda bulunmak yerine yazdırın. OLLAMA_MODELS değişkeninin unit dosyasında veya bir drop-in dosyasında tanımlı olup olmadığını görmek için systemctl cat ollama.service komutunu çalıştırın. Tanımlı değilse, depolama alanı servisi çalıştıran hesabın ev dizini altındadır; bunu da getent passwd ollama komutu yazdırır. sudo find / -xdev -type d -name blobs 2>/dev/null katman dizinini doğrudan bulur. Container imajı için depolama alanı mount edilen volume içindedir ve docker volume inspect ollama komutu bunun host üzerindeki Mountpoint yolunu yazdırır.

Ollama modellerini başka bir diske nasıl taşırım?

Servisi durdurun, depolama alanını rsync -a ile yeni konuma kopyalayın, dizinin sahipliğini sudo chown -R ollama:ollama <directory> ile servis hesabına verin, ardından sudo systemctl edit ollama.service komutunu çalıştırın ve [Service] satırı altına Environment="OLLAMA_MODELS=<directory>" ekleyin. sudo systemctl daemon-reload ile yeniden yükleyin ve servisi başlatın. systemctl show ollama --property=Environment ve ollama list ile doğrulayın. Listenin boş görünmesi neredeyse her zaman ollama kullanıcısının yeni dizini okuyamadığı anlamına gelir; journalctl -e -u ollama komutu yolu gösterecektir.

Model dosyalarını silmek alanı boşaltır mı?

Dosyaları elle silmek baytları boşaltır ancak depolama alanını tutarsız bırakır. Bir blob dosyasını silerseniz manifest dosyası o modeli listelemeye devam eder, bu yüzden model ollama list içinde görünmeye devam eder ve kullanıldığında hata verir. Bir manifest dosyasını silerseniz, katmanları diskte kalır ve hiçbir şey onlara referans vermez. Manifest dosyasını ve başka hiçbir modelin ihtiyaç duymadığı katmanları silen ollama rm <model> komutunu kullanın. Dosyalar zaten elle silindiyse, girişi temizlemek için etiket üzerinde ollama rm komutunu çalıştırın ve ardından hiçbir manifestin referans vermediği katmanları temizlemek için sunucuyu yeniden başlatın.