oMLX: Mac'te yerel modeli kodlama ajanına hızlı bağlamak, KV cache'i SSD'ye yazarak

oMLX nedir?

oMLX, Mac’te açık modelleri çalıştıran açık kaynak (Apache 2.0) bir sunucu. Şubat 2026’da Jun Kim adlı bir geliştirici yayımladı. Apple’ın kendi makine öğrenmesi kütüphanesi MLX üzerine kurulu, bu yüzden sadece Apple Silicon (M serisi) çiplerde çalışıyor. Menü çubuğundan yönetiliyor, bir de tarayıcıdan açılan bir yönetim paneli var.

Programlar ona OpenAI ya da Anthropic API’si gibi bağlanabiliyor. Yani Codex, Claude Code, OpenCode gibi kodlama ajanlarını, buluttaki model yerine kendi Mac’indeki modele yönlendirebiliyorsun. Bu fikri daha önce Ollama ile Claude Code yazısında anlatmıştık. oMLX’in farkı, ajan kullanımına göre tasarlanmış önbelleği.

Önce kavram: KV cache

Bir dil modeli metin üretirken, o ana kadarki her token için bazı ara hesaplar yapar. Bunlara key ve value deniyor; modelin hangi kelimeye ne kadar “dikkat” edeceğini bu değerler belirliyor. Her yeni kelimede hepsini baştan hesaplamamak için saklanırlar. Bu saklama alanına KV cache deniyor; modelin kısa süreli hafızası gibi düşünebilirsin.

Bir de prefill var: Modelin, cevap yazmaya başlamadan önce sana gönderilen prompt’un tamamını okuyup bu değerleri hesapladığı aşama. Mac’lerde bu aşama özellikle yavaş hissedilir.

Kodlama ajanları burada sorun çıkarır. Her adımda aynı uzun başlangıcı tekrar gönderirler: sistem talimatı, araç tanımları, okunan dosyalar. Önbellek bu başlangıcı hatırlamıyorsa, model her seferinde binlerce token’ı yeniden okur.

KV cache’i model mimarisi düzeyinde küçültmenin bir örneğini DeepSeek-V4.1-Flash yazısında anlattık.

oMLX ne yapıyor?

oMLX, KV cache’i küçük bloklara bölüp iki katmanda tutuyor:

• Sıcak katman (RAM): Sık kullanılan bloklar bellekte kalıyor.
• Soğuk katman (SSD): RAM dolunca eski bloklar diske yazılıyor.

Yeni bir istek, daha önce görülmüş bir başlangıçla (prefix) gelirse, o kısım yeniden hesaplanmıyor; diskten geri yükleniyor. Sunucuyu yeniden başlatsan bile. Fikir, büyük sunuculardaki vLLM’in blok tabanlı önbelleğinden geliyor. oMLX ayrıca birden fazla isteği aynı anda işleyebiliyor (continuous batching) ve RAM azalınca en az kullanılan modeli bellekten çıkarıyor.

Bir yanlış anlamayı düzeltelim: SSD burada modelin kendisini değil, konuşma hafızasını tutuyor. Model ağırlıkları yine RAM’e sığmalı. Ağırlıkları diskten okuyan ayrı bir yaklaşımı belleğe sığmayan modeller yazısında anlatmıştık.

Videodaki test

Better Stack, M2 işlemcili bir MacBook Pro’da Qwen 3.6’nın 35 milyar parametreli, 4 bit’e sıkıştırılmış sürümünü Codex CLI ile kullanarak basit bir film listesi uygulaması yazdırdı. Videoya göre:

• Claude Code yerine Codex seçildi, çünkü Claude Code’un kendi talimatları ve araç tanımları boş bir oturumda bile 32 bin token’lık pencerenin yarısını kaplıyordu.
• İş oMLX’te yaklaşık 20 dakika, LM Studio’da 35 dakika sürdü. Üretim hızı saniyede ortalama 47’ye karşı 16 token.
• Üretilen 1,78 milyon token’ın yaklaşık %89’u önbellekten geldi. Oturum temizlendikten sonra bile önbellek aynı başlangıcı tanıdı.
• oMLX’te bilgisayar kullanılabilir kaldı, LM Studio’da sistem ciddi şekilde yavaşladı.
• Ama oMLX birkaç kez bağlam sınırını aşıp hata verdi, LM Studio hiç vermedi.

Bu tek makinede, tek bir görevle yapılmış bir deneme. LM Studio da Mac’te MLX kullanabiliyor, yani fark büyük olasılıkla motordan çok önbellek ve ayarlardan geliyor. Hız iddialarını okurken neye bakman gerektiğini Magnitude yazısında konuşmuştuk.

Sonra ne oldu?

Proje hızla büyüdü. Ekim 2026 itibarıyla GitHub’da 22 binden fazla yıldızı var ve Eylül sonunda 0.7.0 sürümü çıktı. Bu arada görsel ve video anlayan modeller, embedding ve reranker desteği, kodlama ajanlarına tek tıkla bağlanma ve birden fazla Mac’e bir modeli bölen deneysel bir küme özelliği eklendi.

Düşün

• Kullandığın kodlama ajanı her adımda modele kaç token gönderiyor, hiç baktın mı?
• Yerel model kullanırken seni en çok yavaşlatan şey cevap üretimi mi, yoksa ilk cevabın gelmesini beklemek mi?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.