Ollama ile yerel LLM modellerini yönetmek

· Can Acar · 4 dk okuma · Ollama , LLM , Yerel Modeller , Yapay Zeka

Selamlar, bu yazımda Ollama ile yerel modelleri yönetirken kullandığım komutları, ufak tefek alışkanlıkları ve disk şişmesin diye uyguladığım rutini toparlayacağım. Konuyu yeni keşfedenler için adım adım gideceğim ama 'sadece pull-run' yazısı değil bu, gerçekten gündelik akışta işine yarayacak şeyleri anlatmaya çalışacağım. Hadi başlayalım.

Yerel LLM çalıştırmaya başlayınca insan ilk birkaç gün heyecanla her modeli kuruyor. Ben de öyle yaptım, sonra bir gün df -h çekince 80 küsur gigabyte'ın ~/.ollama altında olduğunu gördüm. İşte bu yazı tam o noktayı önlemek üzerine.

Ollama modelleri nasıl saklıyor?

Ollama modelleri iki parçaya ayırıyor: manifest dosyaları ve blob'lar. Manifest, modelin metadata'sı (parametre sayısı, mimari, hangi blob'lara referans verdiği) gibi düşün. Blob ise asıl ağırlıkların kendisi, içerik adresli (content-addressed) saklanıyor.

Bunun hoş tarafı şu: aynı temel ağırlığı paylaşan iki model, blob'u tekrar etmiyor. Yani llama3.2'nin üzerine kendi sistem prompt'unla bir kopya oluşturduğunda disk iki katına çıkmıyor. Bu detay, ileride ollama cp kullandığımızda neden disk doldurmadığını da açıklıyor.

Model çekmek

Temel kullanım son derece sade:

ollama pull llama3.2

Komutu çalıştırınca katman katman indirme akar, sonunda success görürsün. Ama prod'a doğru bir şey yazacaksan latest kullanmaktan kaçın - benim önerim her zaman tag'i sabitlemek:

ollama pull llama3.2:3b-instruct-q4_K_M

Buradaki 3b parametre sayısı, instruct varyant, q4_K_M ise quantization seviyesi. Şahsi kanaatim, çoğu makinada q4_K_M kalite-boyut dengesinin tatlı noktası; q8_0 ya da fp16 daha kaliteli ama RAM'i hızlıca eritir. q2, q3 tarafına ise gerçekten zorda kalmadıkça inmem, kalite kaybı hissedilir oluyor.

Yüklü modelleri görmek

Hangi modeller diskte, hangileri bellekte yüklü, ikisini ayrı komutlarla görüyoruz:

ollama list
ollama ps

list diskte ne var diye söylüyor, ps ise şu an GPU/CPU'ya yüklenmiş olanı gösteriyor. ps çıktısındaki UNTIL sütunu hoş bir detay: model belirli bir süre kullanılmazsa Ollama otomatik unload ediyor. Varsayılan 5 dakika, ama API çağrısında keep_alive parametresiyle bunu değiştirebilirsin.

Bir modelin iç ayrıntısına bakmak istersen:

ollama show llama3.2 --modelfile
ollama show llama3.2 --template

Özellikle --template çıktısını ben sık kullanıyorum; çünkü bir modeli kendi sistem prompt'umla özelleştirirken doğru chat şablonunu kaybetmek istemiyorum.

Güncelleme: aslında 'update' komutu yok

Ollama'nın ayrı bir update komutu yok, pull zaten varsa atlıyor, yoksa indiriyor. Hepsini tek seferde tazelemek için ufak bir script yeter:

#!/bin/bash
# update-all.sh
ollama list | tail -n +2 | awk '{print $1}' | while read model; do
    echo "Guncelleniyor: $model"
    ollama pull "$model"
done

Bunu cron'a haftalık koyabilirsin, ama açıkçası ben elle çalıştırmayı tercih ediyorum - bazı modeller hızlı sürüm değiştiriyor, neyin değiştiğini bilmeden indirmek istemiyorum.

Modelfile ile özelleştirme

Asıl keyifli kısım burası. Modelfile, Dockerfile mantığında - bir base model alıp üzerine sistem prompt'u, parametreler ekliyorsun:

FROM llama3.2:3b

SYSTEM """
Sen kidemli bir Python gelistiricisin. Cevaplari kisa tut,
kod ornegi ver, gereksiz aciklama yapma.
"""

PARAMETER temperature 0.3
PARAMETER num_ctx 8192

Sonra ollama create py-mentor -f Modelfile ile yeni modeli oluşturuyorsun. Yeni bir blob inmiyor, sadece manifest yazılıyor. Bence bu yaklaşımın en güzel yanı: aynı base model üzerine 5-10 farklı kişilik kurabilirsin, disk neredeyse hiç şişmez.

İpucu: Modelfile'larını mutlaka projenin git repo'suna koy. Yeni bir makinaya geçtiğinde setup-models.sh ile birkaç dakikada aynı ortamı kuruyorsun.

Sık karşılaşılan tuzaklar

  • latest tag'ini prod'da kullanmak: Bir gün model yayıncısı yeni sürüm push'lar, çıktı format'ı değişir, sizin parser'ınız çatlar. Tag'i sabitle.
  • Disk dolduğunda farkına geç varmak: du -sh ~/.ollama komutunu haftada bir çalıştırma alışkanlığı edin. Özellikle 70b model denedikten sonra silmeyi unutmak çok yaygın.
  • ollama rm ile blob'lar gerçekten silinir sanmak: Manifest siliniyor; blob başka model tarafından referans alınmıyorsa garbage collect ediliyor. Yine de yer açmak için bazen ~/.ollama/models/blobs altında en büyükleri bizzat kontrol etmek gerekiyor.
  • Quantization farkını ihmal etmek: q4_K_M yerine q8_0 indirip bellek dolunca 'Ollama yavaş' demek klasik hata. Önce hardware'ine uygun quantization seç.

Doğrulama

Yeni bir model çekip çalıştığını anlamak için:

ollama run llama3.2:3b 'Selam, kisa bir test cumlesi yaz.'

Yanıt geliyorsa model sağlam. ollama ps ile bellekteki halini, ollama show <model> ile parametrelerini doğrulayabilirsin.

Kapanış

Ollama'nın model yönetimi ilk bakışta basit görünüyor ama disk, quantization ve Modelfile üçlüsünü doğru kurduğunda gerçekten rahat bir geliştirme ortamına dönüşüyor. Bana sorarsanız en değerli alışkanlık tag'leri sabitlemek ve Modelfile'ları repo'da tutmak; gerisi rutine biniyor. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.