Ollama eşzamanlılık ayarları: NUM_PARALLEL ve MAX_QUEUE

İlk istek oluşturulurken ikinci Ollama isteğine ne olur

Ollama eşzamanlılığı üç ortam değişkeni ile belirlenir ve varsayılan ayarlarda yüklü bir model aynı anda tek bir isteğe hizmet verir. İkinci istek reddedilmez ve kısmi bir yanıt almaz. Bir yuva boşalana kadar kuyrukta bekler ve ardından normal hızında çalışır.

Gelen bir isteğin üç olası sonucu vardır. İstek, boş bir yuvada hemen başlar. Kuyrukta bekler. Veya kuyruk zaten doludur ve sunucu HTTP 503 hatasıyla isteği reddeder. Hangisinin gerçekleşeceği OLLAMA_NUM_PARALLEL, OLLAMA_MAX_QUEUE ve OLLAMA_MAX_LOADED_MODELS değişkenleri ile belirlenir.

Varsayılan ayar güvenlidir ve ikinci bir kullanıcının hiçbir şey bozuk değilken sunucunun "donduğunu" bildirmesinin nedeni de budur. Yuva eklemek iki satırlık bir değişikliktir. Sorun yaratan kısım bellektir. Her paralel yuva, modelin halihazırda işlediği token'lar için tuttuğu bellek bloğu olan kendi anahtar/değer önbelleğine (KV cache) ihtiyaç duyar. VRAM (GPU üzerindeki video belleği) artırmadan yuva eklerseniz, yavaş bir yanıtı başarısız bir yükleme işlemine dönüştürürsünüz.

OLLAMA_NUM_PARALLEL, OLLAMA_MAX_QUEUE ve OLLAMA_MAX_LOADED_MODELS parametrelerinin işlevleri

Bunlar, Ağustos 2026 itibarıyla güncel Ollama sürümlerindeki varsayılan değerlerdir. Buradaki sayılara güvenmek yerine, aşağıda gösterilen günlük kaydını kullanarak kendi değerlerinizi kontrol edin.

• OLLAMA_NUM_PARALLEL, yüklenmiş bir modelin aynı anda kaç isteği işleyeceğini belirler. Varsayılan değer 1'dir; bu nedenle istekler sırayla karşılanır.
• OLLAMA_MAX_LOADED_MODELS, aynı anda kaç farklı modelin bellekte tutulacağını belirler. Varsayılan değer 0'dır; bu, Ollama'nın kendi seçimini yapacağı anlamına gelir: GPU başına üç model veya GPU olmayan bir makinede üç model.
• OLLAMA_MAX_QUEUE, kuyrukta kaç isteğin bekleyebileceğini belirler. Varsayılan değer 512'dir. Kuyruk doluyken gelen istek doğrudan reddedilir.

En kötü durum bellek kullanımı, ilk iki değerin çarpımıdır. Dörder yuvalı iki yüklü model, aynı anda bellekte tutulan sekiz adet KV önbelleği yuvası anlamına gelir ve Ollama bunu karşılamaya çalışacaktır. Tek GPU'lu bir sistemde genellikle tek bir modeli bellekte tutmak ve ona yuvalar atamak daha iyidir; çünkü bu durumda hesaplama, zihinden yapılabilecek kadar basit kalır.

Her bir paralel yuvanın VRAM maliyeti

Ollama bir model yüklediğinde ayrı bir çalıştırıcı (runner) süreci başlatır. Bu süreçte aktarılan iki argüman önemlidir: -c, çalıştırıcının KV önbelleği için ayırdığı toplam bağlam (context) boyutudur; -np ise paralel dizi sayısıdır. Ollama, -c değerini, istek başına bağlam uzunluğunuz ile yuva sayısının çarpımına göre ayarlar. Çalıştırıcı, bu toplam alanı yuvalar arasında eşit olarak böler; böylece her istek, talep ettiğiniz bağlam uzunluğunu kullanmaya devam eder.

Tüm kısıtlama bundan ibarettir ve paralelliğin ücretsiz olmamasının nedeni budur. Bir yuvadan dört yuvaya geçmek, aynı bağlam uzunluğunda dört kat daha fazla KV önbelleği gerektirir. Yuvalar arasında hiçbir veri paylaşılmaz ve boş bir yuvanın payı meşgul olana aktarılamaz; çünkü bölme işlemi çalıştırıcı başladığı anda sabitlenir.

Ayarlamayı hedeflediğiniz değerler yerine gerçek sayıları şu şekilde görebilirsiniz:

journalctl -u ollama --no-pager -n 500 | grep "starting llama-server"

Bu satır, -c ve -np dahil olmak üzere tam çalıştırıcı komut satırını içerir. Değişkeni ayarlamanıza rağmen -np değeri 1 olarak kalıyorsa, ayar sunucuya ulaşmıyor demektir; bunun nedeni bir sonraki bölümde açıklanmıştır.

Model ağırlıkları ve KV önbelleği VRAM'e sığmazsa, Ollama bazı katmanları sistem RAM'ine taşır ve bu katmanlar CPU üzerinde çalışır. CPU katmanları GPU katmanlarından çok daha yavaştır; bu durum, başlattığınız tek bir istek dahil tüm isteklerin yavaşlamasına neden olur. Dolayısıyla paralelliği artırmak, verimi artırmak yerine düşürebilir.

ollama ps

PROCESSOR sütunu, her şey sığdığında 100% GPU değerini gösterir. 35%/65% CPU/GPU gibi bir bölünme, modelin bir kısmının CPU üzerinde çalıştığı anlamına gelir. SIZE sütunu KV önbelleğini de içerir, bu nedenle yuva sayısını artırıp modeli yeniden yüklediğinizde bu değer büyür. OLLAMA_NUM_PARALLEL değerini artırın, yeniden başlatın, tek bir istek gönderin ve ollama ps komutunu tekrar çalıştırın: bu, değişikliğinizin tahmin edilen değil, ölçülen bellek maliyetidir.

Bağlam uzunluğu ve yuva sayısı birbirini çarpan olarak etkilediği için birlikte seçilmelidirler. Dört yuvalı büyük bir bağlam, dört adet büyük bağlam demektir. Eğer aynı zamanda modeliniz için num_ctx bağlam penceresini ayarlıyorsanız, bu iki değerden yalnızca birini değiştirin; aksi takdirde kartı hangisinin doldurduğunu anlayamazsınız.

Bu değişkenlerin yeniden başlatma sonrasında kalıcı olması nasıl sağlanır

Linux üzerinde Ollama bir systemd servisi olarak çalışır. Shell içerisinde export OLLAMA_NUM_PARALLEL=4 komutunu çalıştırmak hiçbir şeyi değiştirmez; çünkü systemd servisi kendi ortam değişkenleriyle başlatır ve sizin shell ortamınızı görmez. Bunun yerine bir drop-in dosyası kullanın.

sudo systemctl edit ollama.service

Açılan düzenleyicide şu satırları ekleyin:

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_MAX_QUEUE=32"

Ardından yapılandırmayı yeniden yükleyin ve servisi başlatın:

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

systemctl show komutu, systemd'nin sürece hangi değişkenleri aktaracağını listeler. Eğer değişkeniniz burada görünmüyorsa, drop-in dosyası kaydedilmemiş veya daemon-reload adımı atlanmış demektir. Durumu sunucunun kendi tarafından da doğrulayın:

journalctl -u ollama --no-pager | grep "server config" | tail -1

Ollama, başlangıçta tüm ortam değişkenlerini server config mesajını içeren bir satırda günlüğe kaydeder. Bu liste kesin bilgidir. Bir değişkenin etkili olup olmadığı konusundaki belirsizliği gidermenin en hızlı yolu budur.

Hali hazırda yüklenmiş bir model, başlatıldığı andaki yuva (slot) sayısını korur; çünkü bu değer başlatma sırasında runner sürecine sabitlenir. Yukarıdaki yeniden başlatma işlemi tüm modelleri bellekten boşaltır, böylece bir sonraki istek yeni ayarla birlikte modeli yeniden yükler ve yükleme süresi yalnızca bir kez gerçekleşir. Bir modelin bu işlemden sonra ne kadar süre bellekte kalacağı ayrı bir ayardır ve istekler arasında Ollama modelini bellekte tutma bölümünde açıklanmıştır.

İstemci açısından served, queued ve refused durumları

Aynı anda birkaç istek gönderin ve sürelerini ölçün. Aşağıdaki komut, paralel olarak sekiz adet akış isteği çalıştırır ve her biri için durumu ve süreleri yazdırır:

for i in $(seq 1 8); do
  curl -s -o /dev/null \
    -w "req$i http=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n" \
    http://127.0.0.1:11434/api/generate \
    -d '{"model":"llama3.2:3b","prompt":"Explain what a KV cache is.","stream":true}' &
done
wait

ttfb, akışın ilk baytına kadar geçen süredir; bu süre, ilk akış parçası ilk token'ı taşıdığı için ilk token'a kadar geçen süreye (TTFT) yakındır.

Paralel olarak sunulanlar (Served). Her istek benzer bir ttfb değeri bildirir ve total değeri hepsi için birlikte yükselir. GPU, çalışan yuvalar arasında paylaşıldığından, her bir yanıt tek başına çalıştırıldığından daha yavaştır ancak dakika başına tamamlanan istek sayısı artar. OLLAMA_NUM_PARALLEL değerini artırdığınızda elde ettiğiniz çalışma rejimi budur.

Kuyruğa alınanlar (Queued). İlk istekler hızlı yanıtlanır, sonrakiler ise büyük bir ttfb değerinin ardından normal bir üretim süreci gösterir. Buradaki bekleme süresi modele değil, kuyruğa aittir. Sohbet penceresini izleyen bir kullanıcı, uzun bir boşluktan sonra metnin tam hızda akmaya başladığını görür. Başlangıçta yavaş, sonrasında hızlı olan bu yapı, aşırı yüklenmiş bir GPU'dan ziyade bir kuyruğun işaretidir.

Reddedilenler (Refused). İstemci neredeyse anında http=503 hatası alır ve yanıt gövdesi şu şekildedir:

{"error":"server busy, please try again.  maximum pending requests exceeded"}

Bu mesaj, istek ulaştığı sırada kuyruğun dolu olduğu anlamına gelir. VRAM veya model hakkında herhangi bir bilgi vermez.

Dürüst bir sınırlama: Ollama, kuyruk derinliğini yayınlamaz. ollama ps ve /api/ps uç noktası, bekleyen istekleri değil, yüklenmiş olan modelleri raporlar. Bu nedenle kuyruğu, ilk bayta kadar geçen süreyi izleyerek veya ön tarafta bulunan herhangi bir katmandaki 503 yanıtlarını sayarak istemci tarafından ölçmeniz gerekir.

Neden daha küçük bir MAX_QUEUE ayarı genellikle daha iyidir

512 birimlik bir kuyruk kulağa cömert gelse de, tek bir slot üzerinde neredeyse işlevsizdir. 300 numaralı istek, tamamlanması gereken 299 işlemin arkasında bekler. Bu durum en iyi ihtimalle dakikalar sürer. Her HTTP istemcisi bu süreden çok daha önce pes eder; dolayısıyla çağrıyı yapan taraf bir istemci tarafı zaman aşımı hatası alır. Bu hata, sorunun kaynağı hakkında hiçbir bilgi vermez ve izleme sisteminizin uyarı oluşturmasını sağlayacak bir veri sunmaz.

Kuyruğu, sunucunuzun istemcinizin zaman aşımı süresi içinde temizleyebileceği miktara ayarlayın; böylece taşan istekler anında 503 hatasına dönüşür. 503 hatası yararlıdır: bir reverse proxy bu isteği yeniden deneyebilir, bir istemci bekleme süresini artırabilir, bir panel bu hatayı sayabilir ve bir operatör bunu okuyabilir. Bu sayıyı kendi ölçümlerinize göre belirleyin. Eğer bir işlem yaklaşık on saniye sürüyor ve istemciniz altmış saniye bekliyorsa, bu süre zarfında slot başına yaklaşık altı istek temizlenebilir. Bu değerden çok daha derin bir kuyruk, yalnızca zaman aşımı hataları üretir.

Ollama önüne ne zaman bir kuyruk koymalı

Dahili kuyruk yapısı ilk giren ilk çıkar (FIFO) mantığıyla çalışır ve çağrıyı yapanın kim olduğu hakkında hiçbir bilgisi yoktur. Tek bir sunucuyla iletişim kuran tek bir uygulama için bu yeterlidir; ek altyapı kurmak yalnızca yeni hata noktaları oluşturur. Aşağıdaki durumlardan biri geçerli olduğunda bir ara katman kullanmayı düşünün.

• Önceliklendirmeye ihtiyacınız varsa. Etkileşimli bir sohbet, toplu bir özetleme işinin arkasında beklememelidir. Ollama kuyruğunun öncelik özelliği yoktur; bu nedenle toplu işlerin dışarıda tutulması ve sisteme yavaşça beslenmesi gerekir.
• Adil dağılıma ihtiyacınız varsa. Tek bir istemci kuyruğu tamamen doldurabilir ve diğer herkes 503 hatası almaya başlar.
• İşin yeniden başlatma sonrasında da devam etmesini istiyorsanız. Kuyruk, sunucunun belleğinde tutulur. Ollama yeniden başlatıldığında bekleyen tüm istekler kaybolur.
• Geri çekilme (backoff) mekanizmasına sahip gerçek yeniden denemelere ve daha sonra inceleyebileceğiniz kayıt tutma sistemine ihtiyacınız varsa.

Hafif çözüm bir reverse proxy kullanmaktır. Nginx içerisinde limit_conn eşzamanlı bağlantıları, limit_req ise istemci başına gelen istek hızını sınırlar; böylece kapasite aşımı proxy katmanında reddedilir ve Ollama kuyruğuna asla ulaşmaz. Ağır çözüm ise, isteklerin süreç yeniden başlatmalarından bağımsız olması gerektiğinde tercih edilen, Ollama'yı çağıran bir worker'ın önünde veritabanı bulunan bir iş kuyruğudur. Gerçek trafik için bu yapıyı boyutlandırmak başlı başına bir süreçtir: eşzamanlı kullanıcılar için self-hosted LLM planlama rehberi hesaplamaları detaylandırır, VPS üzerinde Ollama çalıştırma ise bu değişkenlerin temelini oluşturan kurulumu kapsar.

Dürüst yanıtın farklı bir sunucu olduğu durumlar

Ayarlarını değiştirerek aşamayacağınız bir sınır mevcuttur. Ollama, model yüklendiğinde KV önbelleğini eşit ve sabit yuvalara böler. Boş bir yuvanın belleği meşgul bir yuva tarafından kullanılamaz ve model kaldırılmadan yuva sayısı değiştirilemez. Bu tasarım tek bir kişi, küçük bir ekip veya bir kodlama ajanı için uygundur.

Aynı anda birçok kullanıcıya hizmet vermek üzere tasarlanan sunucular farklı çalışır. Bu sunucular, KV önbelleğini talep üzerine küçük sayfalar halinde ayırır ve gelen istekleri halihazırda çalışmakta olan bir gruba ekler; böylece bellek, sabit bir bölümlendirme yerine gerçek talebe göre şekillenir. Hedefiniz tek bir GPU üzerinde çok sayıda eşzamanlı kullanıcı ise, bu mimari fark OLLAMA_NUM_PARALLEL değerinin herhangi birinden daha önemlidir. Ollama ve vLLM arasındaki karşılaştırma bu kararı vermek için doğru yerdir. Ancak sırf prensip gereği geçiş yapmayın: farklı bir sunucuyu yönetmek daha fazla iş yükü getirir ve eğer trafiğiniz birkaç kişiden ibaretse, yerleşik davranış en doğru çözümdür.

Kendi verimliliğinizi ve ilk token sürenizi ölçün

Yayınlanan saniye başına token (tokens per second) değerleri; başkasına ait GPU, model, kuantizasyon, bağlam uzunluğu ve istem (prompt) verilerine dayanır. Bunların hiçbiri sizin sisteminizle eşleşmez; bu nedenle okuduğunuz her rakamı kaba bir ipucu olarak değerlendirin ve önünüzdeki makineyi kendiniz ölçün.

Ollama, her yanıtın sonundaki JSON nesnesinde zamanlama verilerini döndürür. eval_count üretilen token sayısıdır, eval_duration ise bunların üretilmesi için harcanan süredir (nanosaniye cinsinden).

sudo apt install -y jq
curl -s http://127.0.0.1:11434/api/generate \
  -d '{"model":"llama3.2:3b","prompt":"Explain what a KV cache is.","stream":false}' \
  | jq '{prompt_eval_count, eval_count, eval_duration, tokens_per_second: (.eval_count / (.eval_duration / 1000000000))}'

Bunu tek bir yuva (slot) ile çalıştırın, ardından gerçekte beklediğiniz eşzamanlılık değerinde tekrar çalıştırın ve kullanıcı memnuniyetini belirleyen iki sayıyı karşılaştırın: ilk token süresi ve istek başına saniye başına token değeri. İstek başına verimlilik, yuvalar eklendikçe her zaman düşer. Asıl soru, bu düşüşün kullanıcılarınızın kabul edeceği sınırların ötesine geçip geçmediğidir. Yerel bir LLM üzerinde saniye başına token ölçümü konusu, çalıştırmalar arasında istemi nasıl sabit tutacağınız da dahil olmak üzere yöntemi daha ayrıntılı olarak ele almaktadır.

Açık bir uç nokta ve geniş bir kuyruk, hizmet reddi saldırıları için bir hedeftir

OLLAMA_HOST=0.0.0.0:11434 ayarının yapılması, API'yi tüm ağ arayüzlerine açar ve Ollama'nın yerleşik bir kimlik doğrulama mekanizması yoktur. Varsayılan kuyruk boyutuna sahip açık bir uç nokta, onu bulan herkesin 512 adet bekleyen isteğini kabul eder. Bir saldırganın bu kuyruğu doldurması neredeyse hiçbir maliyet gerektirmez: uzun istemler, giriş zorunluluğu yok, hız sınırlaması yok, fatura yok. Bu durumda kendi kullanıcılarınız 503 yanıtları alır veya uzun süre beklemek zorunda kalır; makine ise sürekli meşgul olur.

Dinleyiciyi loopback üzerinde tutun ve ona bir SSH tüneli veya özel bir ağ üzerinden erişin ya da önüne kimlik doğrulama ve hız sınırlama katmanı ekleyin. Ollama API uç noktasını güvenli hale getirme bölümü her iki yöntemi de kapsar. Kuyruk ayarını bu işlemlerden sonra yapın; çünkü kuyruk uzunluğu bir kapasite ayarıdır ve herhangi bir koruma sağlamaz.

FAQ

İkinci Ollama isteğim neden birincinin bitmesini bekliyor?

Çünkü OLLAMA_NUM_PARALLEL varsayılan olarak 1 değerindedir; bu nedenle yüklenen bir model aynı anda tek bir isteği işler ve diğerleri sıraya girer. Bekleyen istek, HTTP bağlantısını açık tutar ve bir yuva (slot) boşalana kadar hiçbir veri göndermez; bu durum istemci tarafında yavaş bir model gibi görünür. Zamanlama yapısı durumu ele verir: uzun bir duraksamadan sonra metnin tam hızda gelmesi bir kuyruk olduğunu, ilk token'dan itibaren yavaş bir akış olması ise modelin yavaş çalıştığını gösterir. Bir systemd drop-in dosyası ile yuva sayısını artırın ve servisi yeniden başlatın.

"server busy, please try again. maximum pending requests exceeded" hatası ne anlama gelir?

Bu, Ollama'nın HTTP 503 durumu ile döndürdüğü kuyruk taşma hatasıdır. Halihazırda bekleyen istek sayısı, varsayılan değeri 512 olan OLLAMA_MAX_QUEUE sınırına ulaşmıştır; bu nedenle yeni gelen istek kuyruğa eklenmek yerine reddedilmiştir. Bu bir bellek veya model hatası değildir. Kuyruk sınırını artırmak, istemcilerin reddedilmeden önce sadece daha uzun süre beklemesine neden olur; bu yüzden gerçek çözümler, VRAM kapasiteniz yeterliyse yuva sayısını artırmak, gelen yükü azaltmak veya istekleri yeniden deneyip önceliklendirebilecek bir kuyruk mekanizmasını ön tarafa yerleştirmektir.

OLLAMA_NUM_PARALLEL değerini artırmak Ollama'yı hızlandırır mı?

Hayır. Bu ayar, aynı anda daha fazla isteğin çalışmasına izin verir; ancak her bir istek tek başına çalıştığı duruma göre daha yavaş olur çünkü GPU kaynaklarını paylaşırlar. Ayrıca KV önbelleğini (cache) çoğaltır; çünkü Ollama, çalıştırıcıyı (runner) bağlam uzunluğunuzun yuva sayısıyla çarpımı kadar toplam bağlam boyutuyla başlatır. Eğer sonuç artık VRAM'e sığmıyorsa, Ollama katmanları CPU'ya aktarır ve rekabet olmasa bile tek bir istek dahil her şey yavaşlar. Değişiklikten sonra ollama ps komutunu kontrol edin ve PROCESSOR sütununun hala 100% GPU değerini gösterdiğini doğrulayın.

Bu değişkenleri değiştirdikten sonra Ollama'yı yeniden başlatmam gerekiyor mu?

Evet. Sunucu bu değişkenleri başlangıçta okur ve çalışan bir model, başlatıldığı sırada sabitlenen yuva sayısını korur. Drop-in dosyasını sudo systemctl edit ollama.service ile düzenleyin, ardından sudo systemctl daemon-reload ve sudo systemctl restart ollama komutlarını çalıştırın. systemctl show ollama --property=Environment ile durumu doğrulayın ve ardından sunucunun gerçekten yüklediği ortam değişkenlerini listeleyen journalctl -u ollama dosyasındaki server config satırını kontrol edin.

Kaç adet paralel yuva ayarlamalıyım?

1 ile başlayın ve her seferinde bir adım artırın. Her adımdan sonra Ollama'yı yeniden başlatın, modeli yüklemek için bir istek gönderin ve ollama ps komutunu çalıştırın. PROCESSOR değerinin hala 100% GPU olduğu ve SIZE sütununun sunduğunuz en uzun bağlam için yeterli boş alan bıraktığı son değerde durun. Ardından, gerçek eşzamanlılık yükünüz altında ilk token'a kadar geçen süreyi ve saniyedeki token sayısını ölçün; eğer istek başına hız kullanıcılarınızın toleransının altına düşerse bir adım geri gidin.