Sunucuda Birden Fazla LLM Modeli Yönetme

Birden fazla LLM modelini aynı sunucuda yönetmek, başta basit görünse de zamanla ciddi bir kaos haline gelebilir. Hangi model ne kadar RAM yiyor, hangisi aktif çalışıyor, disk doldu mu, GPU paylaşımı nasıl yapılıyor… Bu sorularla boğuşuyorsanız doğru yerdesiniz. Ollama üzerinde çok modelli bir ortamı düzgün yönetmek için gereken her şeyi bu yazıda ele alacağız.

Ollama’nın Model Yönetim Mimarisi

Ollama, modelleri /usr/share/ollama/.ollama/models/ dizininde saklar. Her model iki ana bileşenden oluşur: manifest dosyası ve blob dosyaları. Manifest, modelin hangi katmanlardan oluştuğunu tanımlar; blob’lar ise gerçek model ağırlıklarını içerir.

Bu mimariyi anlamak önemli çünkü birden fazla model çalıştırırken disk yönetimi kritik hale gelir. Örneğin llama3.2 ve llama3.1 modellerinin bazı katmanları ortak olabilir ve Ollama bu katmanları tekrar indirmez, paylaşır. Bu “content-addressable storage” yaklaşımı disk kullanımını optimize eder.

Mevcut model durumunu görmek için:

# Yüklü modelleri listele
ollama list

# Çalışan modelleri göster
ollama ps

# Model detaylarını incele
ollama show llama3.2

# Disk kullanımını kontrol et
du -sh /usr/share/ollama/.ollama/models/
du -sh /usr/share/ollama/.ollama/models/blobs/*

Üretim ortamında bu komutları düzenli çalıştırmak yerine bir script haline getirmek çok daha mantıklı. Bunu ilerleyen bölümlerde ele alacağız.

Çoklu Model Stratejisi: Hangi Modeli Ne Zaman Kullanmalısınız

Gerçek dünya senaryosuna bakalım. Diyelim ki bir yazılım şirketinde sysadmin olarak çalışıyorsunuz ve şu ihtiyaçlar var:

• Geliştirici ekibi kod asistanı istiyor (CodeLlama veya DeepSeek Coder)
• İK departmanı Türkçe doküman özeti için model kullanmak istiyor
• DevOps ekibi log analizi için hafif bir model talep ediyor
• Yönetim ise genel amaçlı bir chat modeli istiyor

Bu senaryoda tek bir modeli herkese vermek hem performans hem kalite açısından sorun yaratır. Doğru yaklaşım, her kullanım senaryosu için uygun modeli belirleyip bunları yönetilebilir bir yapıda tutmaktır.

Model Kategorileri ve Kaynak Kullanımı

Kod modelleri: codellama:13b, deepseek-coder:6.7b, qwen2.5-coder:7b gibi modeller. GPU varsa 13b, sadece CPU ise 6.7b veya 7b tercih edilmeli.

Genel amaçlı modeller: llama3.2:3b (hızlı ve hafif), llama3.1:8b (dengeli), mistral:7b (Türkçe için makul performans).

Türkçe optimizeli modeller: Bazı topluluk modelleri Türkçe fine-tune içerir. Bunları Ollama kütüphanesinden arayabilirsiniz.

Gömülü sistemler ve edge: phi3:mini, gemma2:2b gibi düşük parametre sayılı modeller, RAM kısıtlı ortamlarda bile çalışır.

Model İndirme ve Versiyon Yönetimi

Birden fazla model indirirken dikkat edilmesi gereken nokta, indirim sırasında bant genişliği ve disk I/O yönetimidir. Modelleri sıralı indirmek genellikle daha stabildir.

#!/bin/bash
# model_setup.sh - Toplu model kurulum scripti

MODELS=(
    "llama3.2:3b"
    "llama3.1:8b"
    "codellama:13b"
    "deepseek-coder:6.7b"
    "mistral:7b"
    "phi3:mini"
)

LOG_FILE="/var/log/ollama_model_setup.log"

echo "Model kurulum başladı: $(date)" | tee -a $LOG_FILE

for model in "${MODELS[@]}"; do
    echo "İndiriliyor: $model" | tee -a $LOG_FILE
    if ollama pull "$model" >> $LOG_FILE 2>&1; then
        echo "BASARILI: $model indirildi" | tee -a $LOG_FILE
    else
        echo "HATA: $model indirilemedi" | tee -a $LOG_FILE
    fi
    # Disk durumunu kontrol et
    DISK_USAGE=$(df /usr/share/ollama -h | awk 'NR==2{print $5}' | tr -d '%')
    if [ "$DISK_USAGE" -gt 85 ]; then
        echo "UYARI: Disk dolulugu %$DISK_USAGE - Kurulum durduruluyor" | tee -a $LOG_FILE
        break
    fi
done

echo "Kurulum tamamlandı: $(date)" | tee -a $LOG_FILE
ollama list | tee -a $LOG_FILE

Modelleri güncel tutmak da önemli bir görev. Ollama’da ollama pull komutu, mevcut model varsa sadece değişen katmanları indirir.

#!/bin/bash
# model_update.sh - Tüm modelleri güncelle

echo "Yüklü modeller güncelleniyor..."
ollama list | tail -n +2 | awk '{print $1}' | while read model; do
    echo "Güncelleniyor: $model"
    ollama pull "$model"
done
echo "Güncelleme tamamlandı."

RAM ve GPU Yönetimi: Kritik Konfigürasyonlar

Birden fazla model çalışırken en büyük sorun kaynak çakışmasıdır. Ollama varsayılan olarak bir modeli belleğe yükler ve belirli bir süre (varsayılan 5 dakika) boyunca aktif tutar. Birden fazla istek geldiğinde modeller arka arkaya yüklenip boşaltılır ki bu ciddi latency sorunlarına yol açar.

Bu davranışı kontrol eden environment variable’lar:

OLLAMA_MAX_LOADED_MODELS: Aynı anda bellekte tutulacak maksimum model sayısı. Varsayılan 1 (GPU için) veya 3 (CPU için).

OLLAMA_NUM_PARALLEL: Paralel istek sayısı. Her model için ayrı context window açılır.

OLLAMA_KEEP_ALIVE: Modelin boşta ne kadar süre bellekte kalacağı. 0 anında boşalt, -1 süresiz tut, 30m 30 dakika gibi.

OLLAMA_MAX_QUEUE: İstek kuyruğu boyutu.

Systemd service dosyasını düzenleyerek bu ayarları kalıcı hale getirin:

sudo systemctl edit ollama

Açılan editörde şunları ekleyin:

[Service]
Environment="OLLAMA_MAX_LOADED_MODELS=3"
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=15m"
Environment="OLLAMA_MAX_QUEUE=100"
Environment="OLLAMA_HOST=0.0.0.0:11434"

Değişiklikleri uygulamak için:

sudo systemctl daemon-reload
sudo systemctl restart ollama

GPU olan bir sunucuda birden fazla model için VRAM yönetimi daha kritik. 24GB VRAM’li bir kart düşünün: llama3.1:8b yaklaşık 6GB, codellama:13b yaklaşık 9GB VRAM kullanır. İkisini aynı anda yükleyebilirsiniz ama üçüncü bir model yüklenince ilki diske swap edilir. Bu nedenle OLLAMA_MAX_LOADED_MODELS=2 gibi bir sınır koymak mantıklı olabilir.

Modellere Özel Konfigürasyon: Modelfile Kullanımı

Ollama’nın en güçlü özelliklerinden biri Modelfile sistemi. Her departman veya kullanım senaryosu için özelleştirilmiş model profilleri oluşturabilirsiniz.

# devops_assistant.Modelfile

FROM llama3.1:8b

PARAMETER temperature 0.1
PARAMETER top_p 0.9
PARAMETER num_ctx 4096
PARAMETER repeat_penalty 1.1

SYSTEM """
Sen bir DevOps ve sistem yönetimi uzmanısın. Log analizi, 
hata tespiti ve altyapı sorunlarını çözmede yardımcı olursun.
Yanıtlarını kısa ve eyleme geçilebilir şekilde ver.
Komut önerirken her zaman önce güvenli seçeneği sun.
"""

Bu Modelfile’dan model oluşturun:

ollama create devops-assistant -f devops_assistant.Modelfile
ollama create kod-asistani -f code_assistant.Modelfile
ollama create ik-asistani -f hr_assistant.Modelfile

# Tüm özel modelleri listele
ollama list | grep -v ":"

Modelfile parametrelerini açıklayalım:

temperature: 0’a yakın değerler deterministik ve tutarlı çıktı verir, kod için idealdir. 0.7-0.9 arası yaratıcı görevler için uygundur.

num_ctx: Context window boyutu. Büyük değerler daha fazla RAM kullanır ama uzun belgeler için gereklidir.

repeat_penalty: Tekrar eden içeriği azaltır. 1.0-1.3 arası değerler önerilir.

top_p: Nucleus sampling parametresi. Temperature ile birlikte çıktı kalitesini etkiler.

İzleme ve Loglama: Neyin Ne Yaptığını Bilmek

Birden fazla model çalıştırırken neyin ne kadar kaynak kullandığını bilmek hayat kurtarır. Basit bir izleme scripti:

#!/bin/bash
# ollama_monitor.sh - Ollama kaynak izleme

while true; do
    clear
    echo "=== OLLAMA MODEL DURUMU ==="
    echo "Tarih: $(date)"
    echo ""
    
    echo "--- Aktif Modeller ---"
    ollama ps
    echo ""
    
    echo "--- Sistem Kaynakları ---"
    echo "RAM Kullanımı:"
    free -h | grep -E "Mem:|Swap:"
    echo ""
    
    echo "CPU Kullanımı:"
    top -bn1 | grep "ollama" | awk '{print "PID:"$1, "CPU:"$9"%", "MEM:"$10"%"}'
    echo ""
    
    if command -v nvidia-smi &> /dev/null; then
        echo "GPU Durumu:"
        nvidia-smi --query-gpu=gpu_name,memory.used,memory.free,utilization.gpu 
            --format=csv,noheader,nounits
    fi
    
    echo ""
    echo "--- API İstek Logları (Son 10) ---"
    journalctl -u ollama -n 10 --no-pager | grep -E "model|request|error"
    
    sleep 10
done

Daha kapsamlı bir çözüm için Prometheus ve Grafana entegrasyonu yapmak mümkün. Ollama, /api/ps endpoint’i üzerinden model durumunu JSON olarak sunar:

# API üzerinden model durumunu sorgula
curl -s http://localhost:11434/api/ps | python3 -m json.tool

# Belirli model bilgisini çek
curl -s http://localhost:11434/api/show 
    -d '{"name": "llama3.1:8b"}' | python3 -m json.tool

# Tüm yüklü modelleri API üzerinden listele
curl -s http://localhost:11434/api/tags | 
    python3 -c "import sys,json; [print(m['name'], m['size']) 
    for m in json.load(sys.stdin)['models']]"

Nginx ile Ters Proxy ve Model Yönlendirme

Farklı departmanların farklı modellere erişmesi için Nginx ile akıllı bir yönlendirme yapısı kurabilirsiniz. Bu yaklaşım hem güvenlik hem de model yönetimi açısından avantaj sağlar.

# /etc/nginx/sites-available/ollama-proxy

upstream ollama_backend {
    server 127.0.0.1:11434;
    keepalive 32;
}

server {
    listen 443 ssl;
    server_name ai.sirket.local;
    
    ssl_certificate /etc/ssl/certs/sirket.crt;
    ssl_certificate_key /etc/ssl/private/sirket.key;
    
    # Geliştirici ekibi - kod modeline yönlendir
    location /dev/ {
        rewrite ^/dev/(.*) /$1 break;
        
        # İsteği modifiye et, her zaman kod modelini kullan
        proxy_pass http://ollama_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 300s;
        proxy_buffering off;
        
        # IP kısıtlaması
        allow 10.0.1.0/24;
        deny all;
    }
    
    # Genel kullanım
    location /api/ {
        proxy_pass http://ollama_backend/api/;
        proxy_set_header Host $host;
        proxy_read_timeout 300s;
        proxy_buffering off;
        
        allow 10.0.0.0/8;
        deny all;
    }
}

Nginx’i etkinleştirip test edin:

sudo nginx -t
sudo systemctl reload nginx

# Test isteği gönder
curl -s https://ai.sirket.local/api/generate 
    -H "Content-Type: application/json" 
    -d '{"model": "devops-assistant", "prompt": "Nginx 502 hatasının nedenleri neler?", "stream": false}' 
    | python3 -m json.tool

Disk Temizliği ve Model Arşivleme

Zamanla kullanılmayan modeller disk alanını işgal eder. Sistematik bir temizlik stratejisi şart:

#!/bin/bash
# model_cleanup.sh - Kullanılmayan modelleri tespit et ve temizle

DAYS_THRESHOLD=30
LOG_FILE="/var/log/ollama_cleanup.log"

echo "Temizlik başladı: $(date)" | tee -a $LOG_FILE

# Yüklü modelleri ve boyutlarını listele
echo "=== Mevcut Modeller ===" | tee -a $LOG_FILE
ollama list | tee -a $LOG_FILE

# Son kullanım tarihine göre analiz (Ollama log dosyasından)
echo "" | tee -a $LOG_FILE
echo "=== Son 30 Günde Kullanılan Modeller ===" | tee -a $LOG_FILE
journalctl -u ollama --since "$DAYS_THRESHOLD days ago" | 
    grep -oP '"model":"[^"]+' | 
    sort | uniq -c | sort -rn | tee -a $LOG_FILE

echo "" | tee -a $LOG_FILE
echo "Silmek istediğiniz modeli manuel olarak silin:" | tee -a $LOG_FILE
echo "ollama rm MODEL_ADI" | tee -a $LOG_FILE

# Disk kullanım raporu
echo "" | tee -a $LOG_FILE
echo "=== Disk Kullanımı ===" | tee -a $LOG_FILE
du -sh /usr/share/ollama/.ollama/models/ | tee -a $LOG_FILE
df -h /usr/share/ollama | tee -a $LOG_FILE

Model silme ve depolama yönetimi:

# Tek model sil
ollama rm codellama:7b

# Belirli tag'i sil ama ana modeli koru
ollama rm llama3.1:latest

# Tüm modelleri listele ve boyutlarını göster
ollama list | awk 'NR>1 {print $1, $3, $4}'

# Blob dosyalarını incele (büyük dosyaları bul)
find /usr/share/ollama/.ollama/models/blobs -type f -size +1G 
    -exec ls -lh {} ; | sort -k5 -rh | head -20

Yük Dengeleme ve Yüksek Erişilebilirlik

Kritik üretim ortamlarında tek Ollama instance yeterli olmayabilir. Birden fazla sunucuya yük dağıtmak için basit bir yaklaşım:

Birinci sunucu büyük modelleri (llama3.1:70b, codellama:34b) çalıştırır. İkinci sunucu orta boy modelleri (llama3.1:8b, mistral:7b) barındırır. Üçüncü sunucu ise hafif ve hızlı modelleri (phi3:mini, gemma2:2b) sunar.

Nginx bu üç backend arasında round-robin veya least_conn algoritmasıyla yük dağıtır. Ancak dikkat edilmesi gereken nokta, model tutarlılığıdır: aynı modelin tüm sunucularda mevcut olması gerekir. Model versiyon uyumsuzlukları beklenmedik sonuçlara yol açar.

Tüm sunucularda modelleri senkronize tutmak için:

#!/bin/bash
# sync_models.sh - Modelleri sunucular arası senkronize et

SERVERS=("ai-server-01:11434" "ai-server-02:11434" "ai-server-03:11434")
PRIMARY="ai-server-01:11434"

# Primary'deki model listesini al
PRIMARY_MODELS=$(curl -s "http://$PRIMARY/api/tags" | 
    python3 -c "import sys,json; [print(m['name']) for m in json.load(sys.stdin)['models']]")

for server in "${SERVERS[@]}"; do
    if [ "$server" != "$PRIMARY" ]; then
        echo "Senkronize ediliyor: $server"
        while IFS= read -r model; do
            # Modelin hedef sunucuda olup olmadığını kontrol et
            EXISTS=$(curl -s "http://$server/api/tags" | 
                python3 -c "import sys,json; models=[m['name'] for m in json.load(sys.stdin)['models']]; print('yes' if '$model' in models else 'no')")
            
            if [ "$EXISTS" = "no" ]; then
                echo "  Eksik model: $model - indiriliyor..."
                curl -s "http://$server/api/pull" 
                    -d "{"name": "$model"}" > /dev/null
            fi
        done <<< "$PRIMARY_MODELS"
    fi
done
echo "Senkronizasyon tamamlandı."

Otomatik Model Yönetim Politikaları

Tamamen otomatik bir yönetim için cron job’lar ve systemd timer’lar kullanabilirsiniz:

# /etc/systemd/system/ollama-maintenance.service
[Unit]
Description=Ollama Model Maintenance
After=ollama.service

[Service]
Type=oneshot
User=ollama
ExecStart=/usr/local/bin/ollama_maintenance.sh
StandardOutput=journal
StandardError=journal

# /etc/systemd/system/ollama-maintenance.timer
[Unit]
Description=Ollama günlük bakım

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=3600

[Install]
WantedBy=timers.target

Timer’ı etkinleştirin:

sudo systemctl enable ollama-maintenance.timer
sudo systemctl start ollama-maintenance.timer
sudo systemctl list-timers | grep ollama

Sonuç

Birden fazla LLM modelini Ollama ile yönetmek, doğru strateji olmadan gereksiz karmaşaya dönüşebilir. Bu yazıda ele aldığımız yaklaşımları özetlersek: her kullanım senaryosu için doğru model büyüklüğünü seçmek disk ve RAM kullanımını optimize eder. Modelfile’larla özelleştirilmiş profiller oluşturmak kaliteyi artırır. Environment variable’larla kaynak limitlerini belirlemek sistem stabilitesini korur. İzleme scriptleri ve log analizi sorunları erken tespit ettirir. Nginx ile ters proxy kurulumu güvenlik ve yönlendirme esnekliği sağlar.

Gerçek dünyada bu sistemleri kurarken en sık yapılan hata, önce herşeyi yükleyip sonra kaynakların tükenmesiyle karşılaşmaktır. Önce ihtiyaç analizi yapın, sonra kaynak hesaplaması yapın, en son modelleri yükleyin. Bir 8B model ortalama 5-6GB RAM, bir 13B model 8-10GB RAM ister. Bu rakamları baz alarak kaç modeli aynı anda tutabileceğinizi önceden hesaplayın.

Bu altyapıyı kurup çalıştırdıktan sonra asıl iş başlıyor: kullanıcı geri bildirimleri doğrultusunda hangi modelin hangi görevde gerçekten değer ürettiğini ölçmek. Teknik mükemmeliyetin yanında bu pratik analiz, uzun vadede hangi modellere yatırım yapacağınızı belirler.