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

ollama pull ve ollama run 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 oturumu 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 komut 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 formdur. Model isimleri hızla değiştiğinden, 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.

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 yazılıp belleğe yüklenmeden sohbet istemi görünemeyeceği için, run size gösterecek bir şey bulana kadar birkaç gigabaytlık bir indirme işlemi gerçekleştirmektedir.

Bu süreci gizleyen iki durum vardır. Ollama, ilerleme çubuğunu yalnızca çıktı bir terminale yönlendirildiğinde çizer; bu nedenle bir kabuk betiği, cron işi, CI adımı veya düz bir ssh host ollama run ... içindeki run, indirme sırasında hiçbir şey yazdırmaz. Ardından, 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 çok daha fazla 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 hala 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.

Bu durum, modelin önceden çekilmesi (pull) için geçerli bir nedendir. ollama run komutunu yazan kişi, indirme süresini bekleyen kişi olmamalıdır.

Modeli kimse talep etmeden önce çekin

Yeni bir sunucuda, sunucuyu kuran betiğin aynısını çekin:

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

Eğer 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 mantıklı işlem, terminal oturumunuz kapansa bile devam edecek bir çekme işlemi tanımlamaktır; çünkü yarıda kesilen bir indirme, model deposunun eksik dosyalarla dolmasına neden olur.

Bunu tmux içinde çalıştırın veya sistem açılışında bir kez çalışacak (one-shot) bir systemd birimi olarak tanımlayın. /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 bilinçli olarak /bin/sh -c üzerinden çalıştırılır. Doğrudan bir ExecStart= kullanımı mutlak yol gerektirir ve yükleyici ikili dosyayı her zaman aynı dizine yerleştirmez; bu nedenle kendi sunucunuzdaki command -v ollama tek güvenilir yöntemdir. Kabuk üzerinden ilerlemek, bir rehberden kopyalanan yol yerine servisin kendi PATH değerini kullanır. İlk ExecStart kullanımı da önemlidir: After=ollama.service, sunucu biriminin başlatıldığı anlamına gelir ancak bu, servisin hazır olduğu anlamına gelmez; bu yüzden döngü, ollama list yanıt verene kadar bekler ve ardından çekme işlemi başlar.

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

Günlük kayıtları (journal), çekme işleminin hatasız tamamlandığını göstermelidir ve ollama list komutu ardından modeli listelemelidir. Değişken bir etiketi (tag) güncel tutmak için, aynı çekme işlemini çalıştıran bir systemd zamanlayıcısı veya haftalık bir cron girdisi ekleyin. Değişmiş bir etiketi tekrar çekmek, yeni katmanları indirir ve eskilerini referanssız bırakır; bu eski katmanlar sunucu bir sonraki kez 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.

Bu ilerlemeyi yok eden tek bir eylem vardır. Ollama sunucusu başladığında, hiçbir model manifestosunun referans vermediği saklı katmanları siler; 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, halihazırda indirmiş olduğunuz 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ğişkenini 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 dolu bir disk 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ız faydalı olacaktır.

Ollama, modelleri bir VPS üzerinde nerede saklar?

Herhangi bir rehberdeki (bu rehber dahil) yola güvenmek yerine kendi sunucunuza sorun. Konum, paket kurulumu ile container kurulumu arasında farklılık gösterir ve eğer birisi OLLAMA_MODELS ayarını değiştirmişse tekrar değişir.

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

systemctl cat, birim dosyasını tüm eklemelerle (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. Böyle bir satır yoksa, depolama alanı servisin altında çalıştığı hesabın ev dizininde bulunur ve getent passwd, bu ev dizinini iki nokta üst üste ile ayrılmış altıncı alanda yazdırır. find, katmanların aslında yazıldığı yer olan 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ının iki parçası vardır. manifests, her model etiketi için küçük bir 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ğerine göre adlandırılır ve 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çinde kendi boyutlarını ayrı ayrı raporlasa da diskte bu alanı yalnızca bir kez kaplar. Bu nedenle, listelenen boyutların toplamı, du tarafından dizin için raporlanan değerden daha fazla olabilir.

Model dosyaları, küçük bir VPS kök dosya sistemini, yüklemeniz muhtemel 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ğlar.

Modelleri OLLAMA_MODELS ile bir veri birimine taşıma

Eğer planınızda ikinci bir disk veya daha geniş bir veri birimi varsa, root dosya sistemi dolmadan önce depolama alanını taşıyın. Henüz 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 komutu bir drop-in dosyası üzerinde düzenleyiciyi açar; böylece paketlenmiş unit dosyası bozulmaz ve paket yükseltmeleri yaptığınız değişikliğin üzerine yazmaz. Ş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 ilgili kullanıcının hedef dizine okuma ve yazma erişimi olması gerekir; bu da yukarıdaki chown satırının görevidir. Yeni yolu belirten izin hataları için journalctl -e -u ollama çıktısını kontrol edin. Eski kopyayı yalnızca liste doğru göründüğünde silin; çünkü başarısız bir taşıma işlemi ve ardından silinen kaynak, her şeyin yeniden indirilmesi 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ı, bind işleminin aktif olduğunu gösterir. Bir bind mount, sunucudaki başka bir bileşen varsayılan konumu beklediğinde işe yarar. Bunun bir dezavantajı vardır: kopyaladığınız dosyalar mount noktası altında root diskinde kalmaya devam eder ve mount tarafından gizlenir; bu nedenle mount işlemini kaldırıp dosyaları silene kadar disk alanı geri kazanılmaz. Ortam değişkeni yöntemi, sistemde daha sonra oturum açacak kişiler için açıklanması daha kolay olan yöntemdir.

Konteynerin 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) alanda saklar. Belgelenen çalıştırma komutu şöyledir:

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

İki nokta üst üste işaretinden önceki ollama, adlandırılmış bir Docker birimidir (volume); /root/.ollama ise sunucunun konteyner içinde yazma yaptığı yerdir. Bu nedenle, önceki bölümdeki yollar üzerinde du komutunu çalıştırmak hiçbir sonuç vermez, çünkü orada bir veri yoktur. Gerçek konumu ve boyutu yazdırmak için şunu kullanın:

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

docker volume inspect çıktısından Mountpoint alanını okuyun ve ardından bu yol üzerinde 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 konteyneri yeniden oluşturun. Konteyner root yetkisiyle yazma yaptığı için, ilgili ana makine dizininin sahipliği root üzerinde kalır. Rootless Podman altında ise kimlikler kullanıcınızın subuid aralığına eşlendiğinden, ana makine sahipliği farklı görünür: rootless Podman altında Ollama çalıştırma belgesi bu eşlemeyi açıklamaktadır.

Temizlik konusunda bir uyarı: docker volume prune komutu, hiçbir konteynerin referans vermediği tüm birimleri kaldırır. ollama konteynerini birimi olmadan kaldırır veya yeniden oluşturursanız, daha sonra yapılacak bir budama (prune) işlemi indirdiğiniz tüm modelleri siler ve bunları yeniden indirmek dışında bir geri dönüş yolu kalmaz. Bir VPS üzerinde budama işlemi yapmadan önce Docker disk kullanımı nasıl budanır başlıklı belgeyi okuyun.

Bir modeli rm ile değil, ollama rm ile silin

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm, ilgili etiket için manifest dosyasını siler ve ardından hiçbir manifest tarafından referans verilmeyen katmanları kaldırır. Bu dosyaların bağlantısı kesildiği anda disk alanı geri kazanılır, bu nedenle df hemen işlem yapar. Katmanlar paylaşımlı olduğundan, birbirine yakın iki etiketten birini silmek, ollama list yanında yazan boyuttan çok daha az yer açabilir. Bu hatalı bir silme işlemi değil, beklenen davranıştır.

Dosyaları manuel olarak silmek eşleşmeyi bozar. Bir blob dosyasını rm ile silerseniz, manifest dosyası onu listelemeye devam eder; bu durumda ollama list modeli göstermeyi sürdürür ve eksik katman okunduğunda modeli kullanma girişimi başarısız olur. Bir manifest dosyasını manuel olarak silerseniz, katmanları hiçbir şey tarafından işaret edilmeden diskte kalır ve hiçbir Ollama komutunun raporlamadığı bir alanı işgal eder. Eğer bunu zaten yaptıysanız, etiket üzerinde ollama rm çalıştırmak geride kalan girdiyi temizler; sunucuyu yeniden başlatmak ise hiçbir referansı kalmayan katmanları temizleyecektir.

Son bir ayrım, çünkü bu ikisi sürekli karıştırılmaktadır. ollama rm disk kullanımı ile ilgilidir. ollama stop gemma4 ise bir modeli bellekten kaldırır ve diskte hiçbir alan açmaz. Bir modelin indirme işlemi bittikten sonra ne kadar süre RAM'de kalacağı ayrı bir ayardır ve bir modeli her istekte yeniden yüklemek yerine bellekte tutmak konusu bunu açıklamaktadır.

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 açar. 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 istem gönderip çıkar; bu, run komutunun betiklenebilir biçimidir.

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

İndirme işlemi devam ediyordur. Sohbet istemi, model diske inip belleğe yüklenene kadar görünemez; model dosyaları birkaç gigabayt boyutundadır. Ollama ilerleme çubuğunu yalnızca çıktı bir terminale yönlendirildiğinde gösterir; bu nedenle bir betik, cron işi veya ssh host ollama run ... içindeki run komutu çalışırken 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 azaldığını görmek, indirme işleminin devam ettiğini gösterir. Modeli önceden çekerseniz bekleme süresi ortadan kalkar.

Ollama modelleri 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 mı yoksa bir drop-in dosyasında mı ayarlandığını görmek için systemctl cat ollama.service komutunu çalıştırın. Ayarlanmamışsa, depolama alanı servisi çalıştıran hesabın ev dizinindedir; bunu 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 ana makinedeki 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ının 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. Boş bir liste neredeyse her zaman ollama kullanıcısının yeni dizini okuyamadığı anlamına gelir; journalctl -e -u ollama 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ı hiçbir referans olmadan diskte kalır. Manifest dosyasını silen ve ardından başka hiçbir modelin ihtiyaç duymadığı katmanları temizleyen ollama rm <model> komutunu kullanın. Dosyalar zaten elle silindiyse, girişi temizlemek için etiket üzerinde ollama rm komutunu çalıştırın, ardından sunucuyu yeniden başlatın; bu işlem hiçbir manifestin referans vermediği katmanları kaldıracaktır.