Ollama Model Performansını Artırmak için Sistem Ayarları

Yazar:komut.io ekibi
0 Yorum

Yerel bir LLM kurulumu yapıp ilk inference’ı aldığınızda heyecanlanıyorsunuz, sonra model yavaş yavaş token üretiyor ve o heyecan yerini hayal kırıklığına bırakıyor. Bunu yaşadıysanız, doğru yerdesiniz. Ollama’yı düzgün tune etmeden çalıştırmak, yüksek performanslı bir arabayı el freniyle sürmek gibi. Sistem tarafında yapılabilecek onlarca ayar var ve bunların büyük çoğunluğu dokümanlarda ya gömülü ya da hiç geçmiyor.

Bu yazıda gerçekten fark yaratan ayarları konuşacağız. Teori değil, üretim ortamında test edilmiş, “evet bu işe yarıyor” dediğim şeyler.

Önce Nerede Durduğunuzu Anlayın

Ayar yapmadan önce baseline ölçmeniz şart. Neyi optimize ettiğinizi bilmeden ilerlemeyin.

# Basit bir benchmark komutu - token/saniye çıktısını inceleyin
time ollama run llama3.2 "Türkiye'nin başkenti hakkında 500 kelimelik bir metin yaz" --verbose

# Daha sistematik ölçüm için
ollama run llama3.2 --verbose "test prompt" 2>&1 | grep -E "eval rate|prompt eval rate|load duration"

--verbose flagini her zaman kullanın. Çıktıda göreceğiniz eval rate değeri token/saniye cinsinden üretim hızınızı, load duration ise modelin RAM/VRAM’e yüklenme süresini gösteriyor. Bu iki metriği not alın, çünkü yaptığınız her değişikliğin etkisini bunlarla ölçeceksiniz.

GPU Katmanı Optimizasyonu

Ollama varsayılan olarak mümkün olduğu kadar çok katmanı GPU’ya atmaya çalışır ama bu her zaman doğru karar değil. Özellikle VRAM’in sınırda olduğu durumlarda, GPU’nun bir kısmının CPU’ya dökmesi (offloading) performansı ciddi biçimde düşürür.

# Kaç katmanın GPU'da çalıştığını görmek için
OLLAMA_DEBUG=1 ollama run llama3.2 "merhaba" 2>&1 | head -50

# GPU katman sayısını manuel olarak belirlemek
OLLAMA_NUM_GPU=999 ollama serve  # Tüm katmanları GPU'ya zorla
OLLAMA_NUM_GPU=0 ollama serve    # Tamamen CPU moduna geç

8GB VRAM’li bir sistemde 13B model çalıştırmaya çalışıyorsanız ve sürekli yavaşlık görüyorsanız, ya modeli quantize edilmiş versiyonuna düşürün (Q4_K_M genellikle iyi denge noktasıdır) ya da OLLAMA_NUM_GPU değerini düşürüp belirli katmanları CPU’da bırakın. Tam yarı yarıya GPU/CPU split, tam GPU’nun belleğe sığmadığı senaryodan genellikle daha hızlıdır.

Birden Fazla GPU Yönetimi

Sistemde birden fazla GPU varsa Ollama varsayılan davranışı her iki GPU’yu da kullanmaktır. Bazen bu istemeyebilirsiniz.

# Sadece belirli GPU'yu kullan (NVIDIA için)
CUDA_VISIBLE_DEVICES=0 ollama serve

# İki GPU'yu birlikte kullanmak için (zaten varsayılan)
CUDA_VISIBLE_DEVICES=0,1 ollama serve

# AMD GPU için
ROCR_VISIBLE_DEVICES=0 ollama serve

Bir GPU yavaş (eski ekran kartı) diğeri hızlı ise, yavaş olanı devre dışı bırakmak toplam performansı artırabilir. Senkronizasyon yükü bazen kazanımı gölgeler.

Sistem Servis Konfigürasyonu

Ollama’yı systemd servisi olarak çalıştırıyorsanız (ki üretimde böyle çalıştırmalısınız), ortam değişkenlerini servis dosyasına gömün.

# Servis override dosyası oluştur
sudo systemctl edit ollama

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

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_MAX_LOADED_MODELS=2"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_NUM_GPU=999"
Environment="OLLAMA_KEEP_ALIVE=30m"
LimitNOFILE=65535
LimitMEMLOCK=infinity

Burada kritik parametreler şunlar:

  • OLLAMA_NUM_PARALLEL: Aynı anda kaç paralel istek işleneceği. CPU/GPU’nuz ne kadar güçlüyse o kadar artırın, ama RAM’i de göz önünde bulundurun.
  • OLLAMA_MAX_LOADED_MODELS: Kaç modeli bellekte tutacağı. Çok model geçişi yapıyorsanız artırın, VRAM kısıtlıysa 1’de bırakın.
  • OLLAMA_FLASH_ATTENTION: Flash Attention 2 desteğini açar, destekleyen GPU’larda bellek kullanımını ve hızı iyileştirir.
  • OLLAMA_KEEP_ALIVE: Model kaç dakika kullanılmadıktan sonra bellekten atılsın. -1 verirseniz hiç atılmaz.
  • LimitNOFILE: Açık dosya limiti, yüksek yük altında sorun çıkarır.
  • LimitMEMLOCK: Büyük modelleri RAM’e kilitlemeniz gerekirse bu limiti kaldırın.

Değişiklikler sonrası:

sudo systemctl daemon-reload
sudo systemctl restart ollama

CPU Optimizasyonu: NUMA ve Thread Ayarları

GPU olmayan ya da CPU inference yapılan senaryolarda, CPU konfigürasyonu belirleyici oluyor.

# NUMA topolojisini inceleyin
numactl --hardware

# Ollama'yı NUMA-aware çalıştırın (çift soketli sunucularda kritik)
numactl --cpunodebind=0 --membind=0 ollama serve

# Thread sayısını manuel ayarlayın
OLLAMA_NUM_THREAD=16 ollama serve

OLLAMA_NUM_THREAD varsayılan olarak fiziksel çekirdek sayısına eşittir. Hyperthreading açıksa, logical çekirdek sayısına çıkarmak çoğu durumda yardımcı olmaz, hatta zarar verir. LLM inference memory-bound bir işlem olduğu için daha fazla thread genellikle daha fazla bus contention demek.

Pratik bir kural: Fiziksel çekirdek sayısının %75’ini kullanın. 32 fiziksel çekirdeğiniz varsa 24 thread deneyin.

# Fiziksel çekirdek sayısını öğrenmek için
lscpu | grep "Core(s) per socket"
# Soket sayısıyla çarpın

# Daha direkt yöntem
cat /sys/devices/system/cpu/cpu*/topology/core_id | sort -u | wc -l

Bellek Optimizasyonu

Model yüklenirken ve inference sırasında bellek erişim desenleri performansı ciddi etkiler.

# Huge Pages'i etkinleştirin (büyük modeller için ciddi fark yaratır)
echo 'vm.nr_hugepages = 1024' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

# Transparent Huge Pages ayarı
echo always | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
echo defer+madvise | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

# Bu ayarın kalıcı olması için
cat << 'EOF' | sudo tee /etc/rc.local
#!/bin/bash
echo always > /sys/kernel/mm/transparent_hugepage/enabled
echo defer+madvise > /sys/kernel/mm/transparent_hugepage/defrag
EOF
sudo chmod +x /etc/rc.local

Swap konusunda dikkatli olun. Model swap’a düşerse performans yerle bir olur. Swap’ı tamamen kapatmak yerine, swappiness değerini düşürün:

# Swap kullanım eğilimini minimize et
echo 'vm.swappiness = 1' | sudo tee -a /etc/sysctl.conf

# Mevcut oturum için hemen uygula
sudo sysctl vm.swappiness=1

# Ollama process'ini yüksek öncelikli RAM kullanımı için işaretle
# PID'yi bulduktan sonra
OLLAMA_PID=$(pgrep -f "ollama serve")
echo -17 | sudo tee /proc/$OLLAMA_PID/oom_adj

Disk I/O Optimizasyonu

Model dosyaları büyük, yüklenme süreleri disk hızına doğrudan bağlı. SSD kullanıyorsanız bile scheduler ve cache ayarları önemli.

# Model dizininin hangi disk üzerinde olduğunu bulun
df -h ~/.ollama/models/

# O disk için scheduler'ı kontrol et ve değiştir
cat /sys/block/nvme0n1/queue/scheduler
echo mq-deadline | sudo tee /sys/block/nvme0n1/queue/scheduler

# Read-ahead değerini artır (büyük dosyaları okurken faydalı)
sudo blockdev --setra 4096 /dev/nvme0n1

# Dosya sistemi mount seçeneklerini optimize et (fstab'da)
# noatime eklemek yeterli, büyük fark yaratır
# /dev/nvme0n1p1 /home ext4 defaults,noatime 0 2

Model dosyalarını RAM’e önceden yüklemek istiyorsanız:

# Model dosyasını önbelleğe al (disk cache'e ısındır)
MODEL_PATH="$HOME/.ollama/models/blobs"
find $MODEL_PATH -name "sha256-*" -size +1G | while read f; do
    echo "Caching: $f"
    cat "$f" > /dev/null &
done
wait
echo "Model cache ısındırma tamamlandı"

Network ve API Optimizasyonu

Ollama’yı API sunucusu olarak kullanıyorsanız, özellikle çoklu istemci senaryolarında network stack ayarları devreye giriyor.

# Ollama'nın dinleyeceği adresi ve portu ayarla
# Tüm interface'lerden dinlemesi için:
OLLAMA_HOST=0.0.0.0:11434 ollama serve

# TCP optimizasyonları
cat << 'EOF' | sudo tee -a /etc/sysctl.conf
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.core.netdev_max_backlog = 65535
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_keepalive_time = 60
EOF
sudo sysctl -p

Reverse proxy kullanıyorsanız (ki yüksek yük için kullanmalısınız), Nginx konfigürasyonunda timeout değerlerini mutlaka artırın. LLM yanıtları uzun sürebilir:

# Nginx upstream konfigürasyonu
cat << 'EOF' > /etc/nginx/conf.d/ollama.conf
upstream ollama_backend {
    server 127.0.0.1:11434;
    keepalive 32;
}

server {
    listen 80;
    server_name your-server;

    location / {
        proxy_pass http://ollama_backend;
        proxy_read_timeout 600s;
        proxy_connect_timeout 10s;
        proxy_send_timeout 600s;
        proxy_buffering off;
        proxy_cache off;
    }
}
EOF

Modelfile ile Model-Level Optimizasyon

Sistem ayarlarının ötesinde, Ollama’nın Modelfile sistemi üzerinden model davranışını da kontrol edebilirsiniz.

# Özel konfigürasyonlu model oluştur
cat << 'EOF' > Modelfile
FROM llama3.2

# Context boyutunu ihtiyacınıza göre ayarlayın
# Büyük context = daha fazla VRAM kullanımı
PARAMETER num_ctx 4096

# Batch size - GPU'nuzun kapasitesine göre
PARAMETER num_batch 512

# GPU katman sayısı
PARAMETER num_gpu 35

# CPU thread sayısı (CPU offload için)
PARAMETER num_thread 8

# Yanıt kalitesi vs hız tradeoff
PARAMETER num_predict 512

SYSTEM "Sen yardımcı bir asistansın."
EOF

ollama create llama3.2-optimized -f Modelfile
ollama run llama3.2-optimized "Test"

Buradaki parametreler:

  • num_ctx: Bağlam penceresi boyutu. Gerçekten uzun belgelerle çalışmıyorsanız 2048 veya 4096 yeterli, büyütmek VRAM tüketimini ciddi artırır.
  • num_batch: Prompt işleme batch büyüklüğü. GPU belleğiniz varsa 512 veya 1024 deneyin, hızı artırır.
  • num_gpu: Model katmanlarından kaçının GPU’da çalışacağı. Modelinizin toplam katman sayısını aşmayan en büyük değeri verin.
  • num_predict: Maksimum üretilecek token sayısı. Kısa yanıtlar için düşürün, token limiti istemiyorsanız -1 yapın.

Gerçek Dünya Senaryosu: Geliştirme Ortamı vs Üretim

Tek bir laptop üzerinde geliştirme yapıyorsanız ile ekibin kullandığı bir inference sunucusu arasında yaklaşım farklılaşıyor.

Geliştirme ortamı için hızlı başlangıç scripti:

#!/bin/bash
# dev-ollama.sh - Geliştirici makinesi için optimize edilmiş başlatıcı

export OLLAMA_FLASH_ATTENTION=1
export OLLAMA_NUM_PARALLEL=1
export OLLAMA_MAX_LOADED_MODELS=1
export OLLAMA_KEEP_ALIVE=10m
export OLLAMA_NUM_GPU=999

# Varsa model cache'i ısındır
if [ -d "$HOME/.ollama/models/blobs" ]; then
    echo "Model cache ısındırılıyor..."
    find "$HOME/.ollama/models/blobs" -name "sha256-*" -size +500M 
        -exec dd if={} of=/dev/null bs=1M status=none ; &
fi

ollama serve

Üretim sunucusu için systemd override:

# /etc/systemd/system/ollama.service.d/production.conf

[Service]
Environment="OLLAMA_NUM_PARALLEL=8"
Environment="OLLAMA_MAX_LOADED_MODELS=3"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KEEP_ALIVE=60m"
Environment="OLLAMA_NUM_GPU=999"
Environment="OLLAMA_HOST=127.0.0.1:11434"
CPUWeight=80
MemoryMax=90%
TasksMax=infinity
Restart=always
RestartSec=5

Performans İzleme

Yaptığınız değişikliklerin gerçekten işe yarayıp yaramadığını sürekli takip edin.

#!/bin/bash
# ollama-bench.sh - Basit performans karşılaştırma aracı

MODEL=${1:-"llama3.2"}
PROMPT="Türkiye'nin ekonomisi hakkında kısa bir paragraf yaz"
RUNS=3

echo "Model: $MODEL"
echo "Test sayısı: $RUNS"
echo "---"

total_rate=0
for i in $(seq 1 $RUNS); do
    result=$(ollama run "$MODEL" "$PROMPT" --verbose 2>&1)
    rate=$(echo "$result" | grep "eval rate" | awk '{print $3}')
    echo "Test $i: $rate token/s"
    total_rate=$(echo "$total_rate + $rate" | bc)
done

avg=$(echo "scale=2; $total_rate / $RUNS" | bc)
echo "---"
echo "Ortalama: $avg token/s"

GPU kullanımını gerçek zamanlı izlemek için:

# NVIDIA
watch -n 1 'nvidia-smi --query-gpu=utilization.gpu,utilization.memory,memory.used,memory.free --format=csv'

# AMD
watch -n 1 rocm-smi --showuse --showmemuse

# Genel sistem yükü ile beraber
htop  # ya da
glances  # daha detaylı görünüm

Yaygın Performans Tuzakları

Sahada en sık karşılaştığım sorunlar ve çözümleri:

  • Model her seferinde yeniden yükleniyor: OLLAMA_KEEP_ALIVE değeri çok düşük. Sık kullandığınız modeller için bu değeri artırın ya da -1 yapın.
  • VRAM yetmiyor ama modeli küçültemiyoruz: Önce OLLAMA_FLASH_ATTENTION=1 deneyin, birçok senaryoda %20-30 bellek tasarrufu sağlar.
  • Paralel istekler birbirini blokluyor: OLLAMA_NUM_PARALLEL değeriniz 1’de kalıyor. Artırın ama RAM’inizi de takip edin.
  • İlk istek yavaş, sonrakiler hızlı: Bu normaldir, model yükleniyor. KEEP_ALIVE artırmak bu problemi çözer.
  • CPU kullanımı %100 ama GPU boş: Flash Attention kapalı olabilir ya da model GPU’ya yüklenemiyordur. OLLAMA_DEBUG=1 ile kontrol edin.
  • Gece saatlerinde sistem yavaşlıyor: Muhtemelen başka bir servis model belleğini sıkıştırıyor. Ollama için memory cgroup limiti belirleyin.

Sonuç

Ollama performans optimizasyonu “bir kez ayarla, unut” değil, süregelen bir süreç. Donanımınız değiştikçe, yeni modeller çıktıkça, kullanım desenleriniz evriştikçe ayarlarınızı da güncelleyin.

En yüksek getiriyi sağlayan değişikler sırasıyla şunlar: Flash Attention’ı açmak, KEEP_ALIVE’ı artırmak, num_ctx’i gerçekten ihtiyaç duyduğunuz değere çekmek ve swappiness’ı düşürmek. Bunları yapıp sonra ölçtüğünüzde zaten büyük farkı göreceksiniz.

Karmaşık ayarlar yapmadan önce mutlaka baseline alın. “Sanırım daha hızlı oldu” yerine “baseline’da 12 token/s vardı, şimdi 18 token/s var” deyin. Sysadmin işi sezgiye değil, ölçüme dayanır. Özellikle bu tür ince ayar çalışmalarında veri olmadan yapılan değişiklik körü körüne bir uğraş olur. Ölçün, değiştirin, tekrar ölçün.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir