Ollama'nın llama.cpp runner'ı yerel LLM akışında ölçülen 90 katlık görüntüleme gecikmesini ortadan kaldırıyor

Yerel LLM'li bir kodlama IDE'si geliştiren bir geliştirici sezgilere aykırı bir şey fark etti: modele her CPU çekirdeğini vermek, token'lar aynı hızda gelmeye devam etse bile uygulamayı daha yavaş hissettiriyordu. dev.to'da yazan yazar, bu farkı ölçtü ve Ollama 0.21.0'da bir Ryzen 5 4500U'nun altı mantıksal çekirdeğinin tamamını kullanan çıkarımın, dört çekirdekli çalışmayla aynı üretim hızını verdiğini ama 95. yüzdelikte kabaca 90 kat daha kötü görüntüleme gecikmesine neden olduğunu gördü — token'ın iletim hattına gelmesinden DOM'da görünmesine kadar geçen süre 181 ms'e karşılık 2 ms. Üretim sırasındaki UI tıklama yanıt süresi de 929 ms'e karşılık 158 ms ile yaklaşık altı kat yavaştı.

Gecikme nasıl ölçüldü

dev.to'da anlatılan kıyarlama, üretim hızını algılanan tepkisellikten kasıtlı olarak ayırdı. IDE ile Ollama arasındaki ince bir proxy, gelen her NDJSON parçasına zaman damgası vururken, uygulamanın içindeki bir MutationObserver akış metninin ne zaman gerçekten DOM'a ulaştığını kaydetti. Olay döngüsündeki sapma, efektif kare hızı ve üretim ortasında gerçek bir UI düğmesine tıklayan bir sonda ölçümleri tamamladı. Koşullar sabit tutuldu — temperature 0, sabit seed, 600 tahmin edilen token — ve ortancalar 60 saniyelik pencereler üzerinden alındı.

Eski motorda üretim hızı özünde aynı çıktı: saniyede 4,6'ya karşılık 4,7 karakter; çünkü decode sırasında token üretimi, mevcut işlem gücünden çok bellek bant genişliğiyle sınırlı. Görüntüleme hattı ise bambaşkaydı: tüm çekirdeklerde token'lar ekrana çizilmeden önce yarım saniyeye kadar bekledi ve süreç incelemesi runner'ın yaklaşık 5,7 çekirdeği sürekli işgal ettiğini gösterdi. Sınırlı çalışmanın daha akıcı hissettirdiği öznel izlenim, hayal ürünü değil, ölçülebilir bir render gecikmesine dayanıyordu.

Ollama 0.40.2'de ne değişti

Doğrulama sırasında yazar Ollama 0.40.2'ye yükseltti ve öncül değişti. Fark neredeyse yok oldu: altı thread ile P95 görüntüleme gecikmesi 13 ms, dört thread ile 3 ms; olay döngüsü gecikmesi etkin biçimde eşit; kare hızları 59,9'da sabitlendi; tıklama yanıtları 123 ms'e karşılık 114 ms oldu. Daha büyük bir 9,6 GB'lık model de aynı şekilde davrandı.

Runner sürecini incelemek bunun nedenini açıkladı. Sürüm 0.21.0, varsayılan olarak tüm çekirdekleri alan Ollama'nın eski motorunu kullanıyordu. Sürüm 0.40.2, llama.cpp'den llama-server'ı çalıştırıyor ve belirtilmeyen thread sayısı artık üç thread anlamına geliyor; böylece runner baştan hiçbir zaman makinenin tamamını ele geçirmiyor. Gönderiye göre, 6 gibi açık bir num_thread değeri bile yaklaşık 4,3 ila 4,6 çekirdeğin kullanılmasına neden oluyor; çünkü yeni motorun worker thread'leri meşgul dönmek yerine boşta bekliyor. Bu da her zaman yaklaşık 1,5 ila 2 yedek çekirdek bırakıyor; böylece renderer, işletim sistemi ve diğer uygulamalar öncelik alabiliyor ve UI tepkiselliğinin, prompt prefill sırasında bile bildirildiğine göre 90 ile 180 ms arasında korunduğu belirtiliyor.

Thread sınırı hâlâ neden gönderiliyor

Bu düzeltme göz önüne alındığında, bir thread sınırı ayarı gereksiz görünebilir; ancak yazar onu iki nedenden dolayı korudu. Motor iç yapıları sürümler arasında değişiyor — varsayılan tek bir sürüm içinde tüm çekirdeklerden üçe geçti — oysa açık bir num_thread, sürümden, modelden veya makinede çalışan başka her şeyden bağımsız sabit bir tavan görevi görüyor. En az bunun kadar önemlisi, bu seçeneğe yalnızca Ollama'nın yerel /api/chat uç noktası üzerinden erişilebilmesi: OpenAI uyumlu /v1 API'sinin bunun için bir kanalı yok; düşünme modellerinin (örneğin qwen3.5:4b) basit bir selamlamaya bile yanıt vermeden önce ürettiği uzun akıl yürütme izini bastıran think bayrağı için de yok.

Bu API sınırlaması bir ürün kararına dönüştü. Yazar, ücretsiz ve Electron tabanlı bir yapay zekâ kodlama IDE'si olan Teaspoon IDE v1.2.0'da CPU Threads ve Thinking ayarlarını gönderdi ve Ollama entegrasyonunu /api/chat'e taşıyarak yerel seçeneklerin gerçekten iletilebilmesini sağladı. Gönderi, OpenAI uyumlu istemciler üzerine kurulu çoğu VS Code uzantısının bu parametreleri hiçbir şekilde gönderemediğini belirtiyor.

Neden önemli

Bu hikâye, yerel model çalıştıran herkes için faydalı bir düzeltme. Saniyedeki token sayısı deneyimin yalnızca yarısını anlatıyor: renderer yetersiz beslendiğinde, özdeş üretim hızı, algılanan tepkisellikte 90 katlık bir farkla bir arada var olabilir. Ayrıca tüm çekirdekleri ayırmanın otomatik olarak optimal olmadığını ve doğru ayırmanın, sürümler arasında habersizce değişebilen motor iç yapılarına bağlı olduğunu gösteriyor. Son olarak, herhangi bir yerel LLM kıyaslamasında iletim hattına varış zamanını DOM render zamanından ayırmayı savunuyor ve yavaşluk konusundaki öznel hissi somut bir rakama dönüştürüyor. Yazar, verilerin tek bir Windows makinesinde iki ila üç çalışmayı yansıttığı uyarısında bulunuyor; dolayısıyla kesin sayılar tek makineye ait sonuçlardır — kalıcı katkı, ölçüm yaklaşımının kendisidir.