Ollama Eşzamanlılık Ayarları: NUM_PARALLEL ve MAX_QUEUE

İlk Ollama isteği üretim yaparken ikinci isteğe 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 (slot) 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, aslında hiçbir şey bozulmamışken sunucunun "donduğunu" bildirmesinin nedeni de budur. Yuva eklemek iki satırlık bir değişikliktir. Sorun yaratan kısım ise 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 log satırını kullanarak kendi değerlerinizi kontrol edin.

• OLLAMA_NUM_PARALLEL, yüklü 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 seçimi otomatik yapacağı anlamına gelir: GPU başına üç model veya GPU olmayan bir makinede toplam üç model.
• OLLAMA_MAX_QUEUE, kuyrukta kaç isteğin bekleyebileceğini belirler. Varsayılan değer 512'dir. Kuyruk doluyken gelen istekler doğrudan reddedilir.

En kötü durum bellek kullanımı, ilk iki değerin çarpımıdır. Dörder yuvaya sahip iki yüklü model, aynı anda bellekte tutulan sekiz 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 tutup ona yuva 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 argümanlardan ikisi kritik öneme sahiptir: -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ı olarak belirler. Ç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ğuna sahip olur.

Tüm kısıtlama bundan ibarettir ve paralelliğin ücretsiz olmamasının nedeni de budur. Yuva sayısını birden dörde çıkarmak, istek başına 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ılmaz; çünkü bölme işlemi çalıştırıcı başladığı anda sabitlenir.

Ayarlamayı hedeflediğiniz değerler yerine gerçek değerleri ş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; sonraki bölüm bunun nedenini açıklar.

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. Yeterince büyük bir modelde, ağırlıklar daha herhangi bir yuva hesabı yapılmadan durumu belirler; bu yüzden Kimi K3 boyutunda bir modeli kendi sunucunuzda barındırmak, kaç yuva ayarladığınızdan ziyade kaç ekran kartına sahip olduğunuzla ilgili bir konudur.

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. Eğer bu ölçüm modelin artık sığmadığını gösteriyorsa, ağırlıkların aynı bütçenin diğer yarısı olduğunu unutmayın; fp16'dan q8 veya q4 yapısına geçmek, eklemeye çalıştığınız yuvanın maliyetinden daha fazla VRAM tasarrufu sağlayabilir.

Bağlam uzunluğu ve yuva sayısı birbiriyle çarpıldığından, birlikte seçilmeleri gerekir. Dört yuvalı büyük bir bağlam, dört adet büyük bağlam demektir. Eğer modeliniz için num_ctx bağlam penceresini de ayarlıyorsanız, bu iki değerden yalnızca birini değiştirin; aksi takdirde kartı hangisinin doldurduğunu tespit edemezsiniz.

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 shell ortamınızı görmez. Bunun yerine bir drop-in dosyası kullanın.

sudo systemctl edit ollama.service

Açılan düzenleyicide şunu ekleyin:

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

Ardından yeniden yükleyin ve başlatın:

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

systemctl show komutu, systemd'nin sürece ileteceği değerleri yazdırır. Eğer değişkeniniz burada görünmüyorsa, drop-in dosyası kaydedilmemiş veya daemon-reload adımı atlanmış olabilir. 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 harita kesin bilgidir. Bir değişkenin etkili olup olmadığı konusundaki tartışmaları sonlandırmanın en hızlı yolu budur.

Hali hazırda yüklenmiş bir model, başlatıldığı slot sayısını korur; çünkü bu değer, başlatma anında runner sürecine sabitlenir. Yukarıdaki yeniden başlatma işlemi her şeyi bellekten boşaltır, böylece bir sonraki istek modeli yeni ayarla yükler ve yükleme süresi bir kez ödenir. Bir modelin bundan sonra ne kadar süre bellekte kalacağı ayrı bir kontrol konusudur ve istekler arasında bir Ollama modelini bellekte tutma bölümünde ele alınmış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, sekiz akış isteğini paralel olarak ç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; ilk akış parçası ilk token'ı taşıdığı için bu süre, 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 eş zamanlı olarak yükselir. GPU, çalışan yuvalar arasında paylaşıldığı için her bir yanıt tek başına olduğundan daha yavaştır, ancak dakika başına tamamlanan istek sayısı artar. OLLAMA_NUM_PARALLEL değerini yükselttiğinizde satın aldığınız çalışma rejimi budur.

Kuyruğa alınanlar (Queued). İlk istekler hızlı yanıt verir, sonrakiler ise büyük bir ttfb değerinin ardından normal bir üretim süreci sergiler. Bekleme süresi modele değil, kuyruğa aittir. Sohbet penceresini izleyen bir kullanıcı, uzun bir boşluktan sonra metnin tam hızda aktığı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ını alır ve gövde içeriği şöyledir:

{"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 bildirir. Bu nedenle kuyruğu, ilk bayta kadar geçen süreyi izleyerek istemci tarafından ölçmeli veya ön tarafta bulunan herhangi bir katmanda 503 yanıtlarını saymalısınız.

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

512'lik bir kuyruk kulağa cömert gelse de, tek bir slot üzerinde neredeyse işlevsizdir. 300. istek, tamamlanması gereken 299 neslin arkasında bekler. Bu, 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, neden hakkında hiçbir bilgi vermez ve izleme sisteminize uyarı oluşturacak bir veri sağlamaz.

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

Ollama önüne ne zaman kuyruk sistemi konulmalı

Ollama içindeki yerleşik kuyruk yapısı ilk giren ilk çıkar (FIFO) mantığıyla çalışır ve çağrıyı yapanın kim olduğu hakkında bir bilgiye sahip değildir. 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 kuyruk sistemi kullanmayı değerlendirin:

• Önceliklendirme yapmanız gerekiyorsa. Etkileşimli bir sohbet, toplu özetleme işleminin 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 kullanım sağlamanız gerekiyorsa. Tek bir istemci kuyruğu tamamen doldurabilir ve diğer tüm kullanıcılar 503 hatası alır.
• İşlemlerin 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) stratejisiyle çalışan ve daha sonra inceleyebileceğiniz kayıtlar tutan gerçek bir yeniden deneme mekanizmasına ihtiyacınız varsa.

Hafif çözüm bir reverse proxy kullanmaktır. Nginx üzerinde 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, Ollama'yı çağıran bir worker'ın önünde veritabanı destekli bir iş kuyruğu kullanmaktır; isteklerin bir süreç yeniden başlatmasından sağ çıkması gerekiyorsa bu yöntem tercih edilmelidir. 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 temel aldığı kurulumu açıklar.

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

Ayarlarını değiştirerek aşamayacağınız bir sınır vardır. Ollama, model yüklendiğinde KV önbelleğini eşit ve sabit yuvalara böler. Boş bir yuvanın belleği meşgul olan 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. KV önbelleğini talep üzerine küçük sayfalar halinde tahsis ederler ve gelen istekleri halihazırda çalışmakta olan bir gruba eklerler; böylece bellek, sabit bir bölümlenme yerine gerçek talebi takip eder. 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 karşılaştırması bu kararı vermek için doğru yerdir. Ancak sadece 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 cevaptır.

Kendi verimliliğinizi ve ilk belirtece ulaşma sürenizi ölçün

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

Ollama, her yanıtın sonundaki JSON nesnesi içerisinde zamanlama verilerini döndürür. eval_count üretilen belirteç sayısını, eval_duration ise bunların üretilmesi için harcanan süreyi nanosaniye cinsinden gösterir.

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))}'

Bu işlemi önce tek bir yuva (slot) ile, ardından gerçekte beklediğiniz eşzamanlılık değerinde çalıştırın. Kullanıcı memnuniyetini belirleyen iki temel değeri karşılaştırın: ilk belirtece ulaşma süresi ve istek başına saniye başına belirteç sayısı. Yuva sayısı arttıkça istek başına verimlilik her zaman düşer. Önemli olan, bu düşüşün kullanıcılarınızın kabul edilebilir bulduğu sınırın altına inip inmediğidir. Yerel bir LLM üzerinde saniye başına belirteç ölçümü başlıklı içerik, istemin çalıştırılmalar arasında nasıl sabit tutulacağı da dahil olmak üzere yöntemi daha ayrıntılı olarak ele almaktadır.

Geniş bir kuyruğa sahip herkese açık bir uç nokta, 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 arayüzlerde erişilebilir kılar ve Ollama'nın yerleşik bir kimlik doğrulama mekanizması yoktur. Varsayılan kuyruğa sahip açık bir uç nokta, onu bulan herhangi birinden 512 adet bekleyen isteği kabul edecektir. Bir saldırganın bu kuyruğu doldurmasının maliyeti neredeyse sıfırdır: uzun istemler, giriş gereksinimi 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 tüm süre boyunca meşgul edilir.

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 konusu her iki yöntemi de kapsar. Kuyruğu ancak bu işlemler tamamlandıktan sonra yapılandırı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ırayla bekler. 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. Sorunun kaynağını anlamak için zamanlama şekline bakılmalıdır: uzun bir duraksamanın ardından 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. Yuva sayısını bir systemd drop-in dosyası ile artırın ve servisi yeniden başlatın.

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

Bu, Ollama'nın 503 HTTP 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 en yeni istek kuyruğa eklenmek yerine reddedilmiştir. Bu bir bellek veya model hatası değildir. Kuyruk sınırını artırmak, çağrı yapanların aynı reddedilme mesajını almadan önce sadece daha uzun süre beklemesine neden olur. Gerçek çözümler; VRAM kapasiteniz yeterliyse yuva sayısını artırmak, gelen yükü azaltmak veya istekleri yeniden deneyebilen ve önceliklendirebilen 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, Ollama çalıştırıcıyı (runner) toplam bağlam uzunluğunuzun yuva sayısıyla çarpımı kadar bir bağlam boyutuyla başlattığı için KV önbelleğini de katlar. 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ğinden emin olun.

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 doğrulama yapı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ç paralel yuva (slot) ayarlamalıyım?

1 değerinden 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şluk bıraktığı son değerde durun. Ardından, gerçek eşzamanlılık yükünüz altında ilk token'a ulaşma süresini ve saniyedeki token sayısını ölçün; eğer istek başına hız kullanıcılarınızın tolerans seviyesinin altına düşerse bir adım geri gidin.