Ollama keep_alive hatası bekleyen bir model değişimini sessizce iptal edip diğer istekleri kilitleyebiliyor

Hata

dev.to'da yayımlanan bir yazı, büyük dil modellerini yerel olarak çalıştırmak için yaygın şekilde kullanılan araç Ollama'daki bir zamanlama kusurunu belgeliyor. Aynı anda yalnızca bir modelin yüklü olabildiği bir sunucuda, farklı bir modele gelen istek, Ollama'nın yerleşik modeli mevcut işini bitirir bitirmez tahliye etmesini planlamasına neden oluyor ve yeni istek bu tahliyeyi bekliyor. Kusur şu: Bu bekleme sırasında yerleşik modele gelen başka bir istek keep_alive değeri taşıyorsa, bu değer bekleyen unload işleminin yerini alıyor. Ollama modeli tahliye etmek yerine normal bir keep-alive zamanlayıcısı başlatıyor ve kuyruktaki istek, hiçbir yerde hata vermeden, tüm keep_alive süresi boyunca bekliyor.

Yazar bu durumu, tek kullanımlık bir LXC container içinde yalnızca CPU ile çalışan Ollama 0.40.8 üzerinde yeniden üretdi; sorun yukarı akışta ollama/ollama#19182 olarak izleniyor ve pull request #19190'da bir düzeltme önerildi. Yazıya göre bu düzeltme yazım anında hâlâ açıktı ve v0.40.8 ile v0.40.9-rc1 arasındaki hiçbir commit mesajında bundan bahsedilmiyor.

Yeniden üretim

Testte iki küçük model kullanıldı — qwen3:0.6b yüklü, gemma3:270m bekliyor — ve OLLAMA_MAX_LOADED_MODELS=1, OLLAMA_NUM_PARALLEL=4 ile OLLAMA_KEEP_ALIVE=30m ayarları yapıldı. Sırayla üç istek gönderildi: yüklü modelde uzun bir üretim, üç saniye sonra gemma3:270m için kısa bir istek ve iki saniye sonra da yüklü model için tek token'lık bir istek.

Dizi iki kez çalıştırıldı: birinde üçüncü istek sade, diğerinde "keep_alive": "30m" eklenmişti. Fark çarpıcıydı. keep_alive olmadan gemma3 isteği yaklaşık 9.2 saniye sonra HTTP 200 döndü ve süreç sonunda yüklü model gemma3'tü. 30 dakikalık değerle ise curl 150 saniyelik zaman aşımını tüketti ve vazgeçti; qwen3 hâlâ yüklüydü.

OLLAMA_DEBUG=1 ile etkinleştirilen debug günlüğü mekanizmayı ortaya koyuyor. Scheduler, maksimum runner sayısına ulaşıldığını ve yer açmak için birinin unload edileceğini günlüğe yazıyor, yerleşik modelin süresinin hemen dolması için sıfırlıyor ve bekleyen isteklerin bitmesini bekliyor. Ancak üçüncü istek yerleşik runner'ın yeniden değerlendirilmesine yol açıyor ve runner boşta olduğunda süresi sıfırdan farklı günlüğe kaydediliyor; böylece unload yerine bir zamanlayıcı ekleniyor. Sağlıklı çalışmada runner süresi sıfırdolan durumda bitiyor ve unload tamamlanıyor.

Neden gizli kalıyor

Yazıya göre bir operatörün normalde bakacağı her açıdan sunucu sağlıklı görünüyor. /api/ps endpoint'i yüklü modeli gösteriyor, ona giden istekler başarılı oluyor ve sorunu ortaya çıkaran scheduler mesajları yalnızca debug seviyesinde görünüyor. Hiçbir şey hata vermiyor — mağdur istek, istemcinin kendi zaman aşımına veya keep_alive süresinin dolmasına kadar askıda kalıyor.

Tetikleyici ayrıca sıradan bir istemci davranışı. Pek çok istemci ve arayüz her isteğe keep_alive ekliyor; yazıya göre bildiren kişi, "2h" gönderen bir istemciye iki saatini, bir health probe'a da on üç dakikasını kaybetmiş. Tek slotlu kurulumlar, belleği tek model alan makinelerde standart; yazar bu durumun çoğu homelab GPU'sunu tanımladığına dikkat çekiyor. Zamanlama da önemli: Hafif kullanımda çakışma hiç yaşanmayabilirken, yüklü modele kesintisiz gelen istek akışı sorunu tekrarlatıyor; böylece diğer model fiilen hiç yüklenemiyor.

Scheduler'ın içinde neler oluyor

Raporun server/sched.go okumasına göre akış şöyle: Tek slot doluyken Ollama tahliye için yerleşik runner'ı seçiyor, kalan ömrünü son isteği tamamladığında unload edilecek şekilde sıfırlıyor ve yeni isteği kuyruğa alıyor. Bu arada aynı modele gelen bir istek zaten yüklü olan runner tarafından karşılanıyor ve o isteğin keep_alive değeri runner'ın oturum süresinin üzerine yazıyor. Runner boşa geçtiğinde artık süresi dolacak şekilde işaretlenmiş olmadığından normal bir keep-alive zamanlayıcısı alıyor ve yüklü kalmaya devam ediyor; diğer istek ise arkasında kuyrukta bekliyor.

Bir düzeltme gelene kadar geçici çözümler

Yüklü model için keep_alive: 0 göndermek unload işlemini zorluyor; testte bu, bekleyen isteği 1.5 saniye içinde serbest bıraktı ve ardından gemma3 yüklendi. Diğer hafifletmeler: istemcilerin istek başına keep_alive göndermesini durdurup bunu sunucu tarafında OLLAMA_KEEP_ALIVE ile tek seferde ayarlamak ya da bellek izin veriyorsa birden fazla model slotuna izin vermek — ancak yazar, üç istekli dizinin iki slotla yeniden çalıştırılmadığını belirtiyor. Yazı ayrıca OLLAMA_MAX_LOADED_MODELS değerini okuyan ve debug günlüğü açıkken keep-alive zamanlayıcısına dönüştürülen tahliyeleri sayan bir tespit betiği de içeriyor.

Neden önemli

Bu, popüler bir yerel çıkarım sunucusundaki sessiz bir arıza modu: Bir istemcinin zararsız görünen seçeneği, sunucunun kendi zamanlama planının yerine geçiyor ve ödemesi gereken faturayı, süresiz bir askıya mahkûm edilen bambaşka bir istemci ödüyor. Konuşkan istemcilerin veya health probe'ların arkasında tek slotlu Ollama çalıştıran herkes, hiçbir hata görmeden bu duruma yakalanabilir. Daha geniş ders şöyle genellenebilir: İstek başına bir seçenek ile scheduler aynı alana yazıyorsa, hangisinin kazandığını sorun — ve bir şey hatasız askıda kaldığında senaryoyu şüpheli alanla ve şüpheli alansız olarak yeniden çalıştırın. Burada tek bir alan, dokuz saniye ile hiç arasında fark yaratmıştı.