Ollama v0.34.2, MLX speculative decoding kaynaklı bellek büyümesini düzeltti; v0.34.1 daha kapsamlı MLX değişiklikleri içeriyordu

İki günde iki sürüm

Ollama, v0.34.1'i 14 Eylül'de yayımladı ve ertesi gün v0.34.2 ile devam etti. Her iki sürüm notunda da MLX ve bellek geçiyor; bu durum bazı okurları ikinci sürümü ilkinin acil yaması olarak yorumlamaya itti. İki changelog'un yapılan dev.to analizine göre bu okuma resmî metinle desteklenmiyor: girdiler farklı mekanizmaları tarif ediyor ve hiçbiri ikisini tek bir regresyon olarak birbirine bağlamıyor.

v0.34.1 ne getirdi

Changelog'a göre v0.34.1 çeşitli alanları kapsıyordu:

• MLX safetensors ile ollama create artık deneysel olarak işaretlenmiyor. Aynı zamanda GGUF modelleri derlemek artık dönüştürme ve quantization için llama.cpp araçlarına dayanıyor.
• Apple silicon üzerinde MLX bellek yönetimine dair geniş ifadeli bir iyileştirme; sorunu tetikleyen koşullar veya pipeline'ın hangi bölümüne dokunduğu konusunda ayrıntı yok.
• Tekrar algılama artık tetiklenmeden önce 100 tekrarlanan token bekliyor; bu, OCR metni gibi çıktılardaki yanlış pozitifleri azaltmayı amaçlıyor.
• /api/tags endpoint'i, büyük model kütüphanelerinde hızlandı; changelog'a eklenen projenin kendi testlerine göre soğuk durumda 3,1 saniyeden 294 ms'ye düştü.
• typical_p parametresi kullanımdan kaldırıldı: yeni modellerde artık ayarlanamıyor, ancak mevcut GGUF modelleri onu koruyor.

v0.34.2 neler ekliyor

Bir gün sonraki takip sürümü şunları içeriyordu:

• Dar kapsamlı bir düzeltme, birebir alıntılanıyor: "MLX speculative decoding ile uzun üretimler sırasında yaşanan aşırı bellek büyümesi düzeltildi."
• ollama çalıştırıldığında ilk kez açılan bir kurulum akışı; oturum açma veya yalnızca yerel bir yol sunuyor ve bu durum macOS ile Windows'ta masaüstü uygulamasıyla paylaşılıyor.
• Bu iki platformda masaüstü uygulamasının Apps sayfasını doğrudan açan bir ollama://apps linki.
• Changelog'da sürüm numarası veya ayrıntı verilmeden yapılan bir llama.cpp güncellemesi.

Tek hata değil, iki bellek değinmesi

"MLX" ve "bellek" ortak sözlüğü regresyon yorumunu davet ediyor; ancak dev.to analizinin işaret ettiği gibi ifadeler ayrışıyor. v0.34.1 MLX bellek yönetiminden genel terimlerle söz ediyor. v0.34.2 ise kesin bir senaryoyu adlandırıyor: speculative decoding altındaki uzun üretimler sırasında bellek büyümesi — bu, genel bellek yönetiminden ziyade belirli bir inference tekniği.

İki changelog da v0.34.2'nin v0.34.1'in bozduğu bir şeyi onardığını belirtmiyor ve ikisinin tamamen bağımsız olduğunu da doğrulamıyor. Sürüm notları ilişkiyi basitçe açıklığa kavuşturmuyor. Bu nedenle birkaç soru açık kalıyor: bellek büyümesi v0.34.1'den önce mi vardı yoksa onunla mı geldi, speculative decoding sırasında bellek neden ilk place'te şişti, llama.cpp güncellemesi gerçekte ne içeriyor ve /api/tags zamanlamaları projenin kendi bildirdiği rakamların ötesinde nasıl ölçüldü.

Kimlerin güncellemesi gerekiyor

v0.34.2'deki bellek düzeltmesi tek bir kombinasyona uygulanır: Apple silicon üzerinde MLX modelleri, uzun üretimler ve etkin speculative decoding. GGUF modellerini llama.cpp üzerinden çalıştıran kullanıcılar, changelog'un tarifine göre düzeltmenin kapsamı dışında. Diğer herkes için v0.34.1'in değişiklikleri — stabil safetensors desteği, tekrar eşiği, typical_p'nin kullanımdan kaldırılması, /api/tags hızlanması — v0.34.2'ye yükseltildiğinde otomatik olarak geliyor; çünkü v0.34.2 onları tekrarlamıyor ya da onarmıyor, sadece bunlar zaten dahil.

Neden önemli

MLX, Apple donanımında yerel inference için önemli olan backend ve uzun üretimler sırasında sınırsız bellek büyümesi, bir sızıntı fark edilmeden uzun süren işleri — özetleme, agent'lar, toplu transkripsiyon — çökerten türden bir kusur. Bu kitle için v0.34.2, derhal kurulmaya değer somut ve belgelenmiş bir düzeltme.

Bu eşleşme aynı zamanda bir sürüm notu hijyeni sorununu da gözler önüne seriyor. Ardışık sürümler aynı alt sistemle belirsiz ve örtüşen bir dille uğraştığında, kullanıcılar tek bir hatanın iki kez yamalanmış hâline mi yoksa iki ayrı soruna mı baktıklarını ayırt edemiyor. Ollama'yı üretim bir yerel model kurulumunda çalıştıran herkes, proje aksini söyleyene kadar iki girdiyi ayrı olarak değerlendirmeli ve changelog'daki benchmark rakamlarını, bunların projenin kendisinden geldiği uyarısıyla okumalı.