Ollama'dan MLX-Server'a Geçtim: Mac Mini M4'te Yerel LLM Inference 30 Günlük Notlarım

Mac Mini M4 (24 GB unified memory) homelab'imde dört aydır yerel LLM inference için Ollama kullanıyordum. Claude Code'un MCP toolchain'i, kendi ajan servisim ve günlük "şu fonksiyonu özetle" tarzı küçük çağrılar için sorunsuz çalışıyordu. Ama nisan sonunda günlük workflow'um değişti: pipeline'lardan gelen 200-300 token'lık özetleme isteklerinin sayısı arttı, "tek dosyalık 4K context'i tara" tarzı RAG çağrıları yoğunlaştı ve ilk-token gecikmesi günde belki 40-50 kez canımı sıkmaya başladı.

30 gün önce MLX-Server'a (mlx-lm tabanlı, host üzerinde LaunchAgent ile çalışan) geçtim. Bu yazı, geçişin sebebini, gerçek tokens/sec sayılarımı, çakıldığım yerleri ve "yine de Ollama'ya geri döneceğim noktalar var mı" sorusuna verdiğim cevabı içeriyor.

Ollama Neden İlk Tercih Olur — ve Neden Sonsuza Kadar Kalmaz

Ollama'yı seçmemin sebepleri klasik: brew install ollama, ollama run llama3.1:8b, bitti. Model çekiyor, GGUF formatta saklıyor, OpenAI-uyumlu bir HTTP server açıyor, /api/chat ve /v1/chat/completions ikisi de çalışıyor. İlk gün modeli ayağa kaldırıp curl ile çağırmak 10 dakika sürdü.

Dört ayın sonunda iki şey beni rahatsız ediyordu:

Tokens/sec hissi yavaştı. Llama 3.1 8B q4_K_M ile yaklaşık 28-32 token/s alıyordum. İlk başta makul gelmişti — top ile baktığımda CPU %150 civarındaydı ve Metal kullanıldığını farz ediyordum. Ama MLX deneyimimden sonra anladım ki Apple Silicon'da bunun 1.5×-2× hızlı olabileceği gerçek.
24 GB unified RAM'i şişiriyordu. Llama 3.1 8B q4 + 8K context açıkken Activity Monitor'da Ollama process'i ~6.5 GB civarı tutuyordu. K8s pod'larım, Docker Desktop ve bir Chrome açıkken sistem swap'a giriyordu, fan duyulur hale geliyordu.

Bu iki sıkıntı ayrı ayrı dert değildi; ikisi birlikte "M4'ün Neural Engine + Metal kapasitesini tam kullanmıyorum" hissini büyüttü.

MLX-Server'ı Niye Seçtim, Niye Başka Bir Şey Değil

Apple'ın MLX framework'ü Apple Silicon için sıfırdan yazılmış bir array/tensor kütüphanesi. NumPy'a benzer API'si var, ama altında Metal ve Apple'ın matrix multiply optimizasyonlarını kullanıyor. mlx-lm paketi de bunun üstüne LLM inference katmanı koyuyor — mlx_lm.server komutuyla OpenAI-uyumlu bir HTTP server kalkıyor.

Düşündüğüm alternatifler:

llama.cpp doğrudan: Ollama zaten llama.cpp wrapper'ı. Sadece daha az şişman bir wrapper'a geçmek için uğraşmaya değmezdi.
LM Studio: GUI istemiyordum, headless homelab makinesi.
vLLM: CUDA-only, M4'te yok.
Apple'ın yeni foundation models framework'ü: macOS 15+ için, ama henüz custom model yüklemek sınırlı.

MLX-Server'ı seçmemin somut sebebi: Apple'ın kendi matrix kernel'lerini kullanan tek "OpenAI API uyumlu" sunucu çözümü ve community'sinde modeli quantize edip yayınlayan aktif insanlar var (mlx-community HuggingFace organizasyonu).

Kurulum: Beklediğimden Daha Az Sancı

Kurulum şu şekilde gitti:

# Python 3.11 (3.12'de mlx-lm bazı paketlerle çatışmıştı)
brew install python@3.11
python3.11 -m venv ~/mlx-env
source ~/mlx-env/bin/activate

pip install --upgrade pip
pip install mlx-lm

# Modeli indir (mlx-community'den 4-bit quantize)
python -m mlx_lm.convert \
  --hf-path meta-llama/Llama-3.1-8B-Instruct \
  --mlx-path ~/models/Llama-3.1-8B-Instruct-4bit \
  -q

# Sunucuyu başlat
python -m mlx_lm.server \
  --model ~/models/Llama-3.1-8B-Instruct-4bit \
  --port 8000 \
  --host 127.0.0.1

İlk indirme + convert ~12 dakika sürdü. Hugging Face token'ı için bir kez huggingface-cli login yaptım. mlx-community'den hazır indirip convert adımını atlayabilirsiniz; ben kendi convert'imi tutmayı tercih ettim, böylece bir Python sürümü değişikliğinde tekrar build edebiliyorum.

LaunchAgent dosyam, ~/Library/LaunchAgents/com.efa.mlx-server.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key><string>com.efa.mlx-server</string>
  <key>ProgramArguments</key>
  <array>
    <string>/Users/efa/mlx-env/bin/python</string>
    <string>-m</string><string>mlx_lm.server</string>
    <string>--model</string>
    <string>/Users/efa/models/Llama-3.1-8B-Instruct-4bit</string>
    <string>--port</string><string>8000</string>
  </array>
  <key>RunAtLoad</key><true/>
  <key>KeepAlive</key><true/>
  <key>StandardErrorPath</key>
  <string>/Users/efa/Library/Logs/mlx-server.err.log</string>
  <key>StandardOutPath</key>
  <string>/Users/efa/Library/Logs/mlx-server.out.log</string>
</dict>
</plist>

launchctl load -w ~/Library/LaunchAgents/com.efa.mlx-server.plist ile yüklüyorum. Boot sonrası ~6 saniyede 127.0.0.1:8000/v1/models cevap veriyor.

Asıl Soru: Ne Kadar Daha Hızlı?

30 günde topladığım sayıların ortalamaları — aynı promptu peş peşe 20 kez çağırıp ortancayı aldım. Test makinesi Mac Mini M4 24 GB, başka ağır yük yok, ekran kapalı değil.

Llama 3.1 8B Instruct (4-bit)

| Metrik | Ollama (q4_K_M) | MLX-Server (4-bit) | |---|---|---| | Steady-state tokens/sec | ~30 | ~52 | | İlk-token gecikmesi (cold) | ~2.1 s | ~1.3 s | | İlk-token gecikmesi (warm, 512 token prompt) | ~480 ms | ~210 ms | | RSS bellek (8K context açık) | ~6.5 GB | ~4.8 GB | | 4K context prompt eval | ~9-11 sn | ~5-6 sn |

Qwen2.5 7B Instruct (4-bit)

| Metrik | Ollama | MLX-Server | |---|---|---| | Steady-state tokens/sec | ~34 | ~58 | | RSS bellek | ~5.9 GB | ~4.2 GB |

Sayıları gözden geçirin: özellikle ilk-token gecikmesinin yarıya inmesi, günlük workflow'da en hissedilen değişiklik. Claude Code'da MCP üzerinden çağrı yaptığımda "bekledim" hissi neredeyse kayboldu. Tokens/sec farkı (~%70 hızlanma) sürekli streaming çıktılarda gözle görülür.

Bunu söylerken bir uyarı: rakamlar mlx-lm sürümüne aşırı bağımlı. Mart 2026'da mlx-lm 0.21 ile aynı testte ~46 token/s alıyordum, 0.24'te bu ~52'ye çıktı. Geriye dönük versiyon notlarını okuyun.

Vazgeçtiğim ve Geri Adım Attığım Şeyler

1. 16B-class modeli M4 24 GB'a sıkıştırma denemem

Llama 3.3 70B'yi 2-bit quantize ederek çalıştırmayı denedim. mlx-community/Llama-3.3-70B-Instruct-2bit indirdim, ~20 GB disk. Ayağa kalktı — ama steady-state ~6 token/s ve cevap kalitesi belirgin şekilde bozuktu. RAG context'i biraz uzayınca da OS swap'a girdi ve sistem fan'a gitti. Vazgeçtim: 24 GB makinede 8B-13B aralığı sweet spot, 30B üstü için ya 32 GB+ makina ya da cloud çağırmak daha mantıklı. Bu kararı vermek üç günümü aldı.

2. Konteyner içinde MLX çalıştırmak

Daha önceki homelab yazımda bunu kısaca anmıştım, burada netleştireyim: Docker Desktop'un macOS VM'i Metal'e tam erişemiyor. Aynı model konteyner içinde ~3× yavaş çalışıyor. K8s'ten erişmem gerektiği için ExternalName Service ile host'taki MLX-Server'ı pod'lara expose ediyorum. Konteynerize etme isteğinizi bastırın, host üzerinde tutun.

3. Ollama'nın "model yöneticisi" konforu

Ollama'nın ollama pull, ollama list, ollama rm UX'i çok temiz. MLX tarafında modeli kendin indirip kendin convert ediyorsun, ~/models altında klasör yönetimi sana ait. Bu küçük bir geri adım. Çözümüm: tek bir scripts/mlx-pull.sh yazdım, parametre olarak HF repo adı alıp convert edip ~/models/<name> altına atıyor. Yine de Ollama kadar pürüzsüz değil.

OpenAI API Uyumluluğunda Beklemediğim 2 Pürüz

MLX-Server'ın /v1/chat/completions endpoint'i çoğu istemciyle çalışıyor, ama:

tool_calls desteği gevşek. Function calling kullanan client'larım (özellikle bir Python LangGraph node'u) tool_calls field'ı dönmeyi bekliyordu. mlx-lm'in son sürümünde basit bir tool support var, ama formatı tam olarak OpenAI spec'ine uymuyor. Geçici çözüm: tool çağrılarını JSON parsing ile string output'tan çıkarıyorum.
logprobs dönmüyor. Bazı evaluation pipeline'larım token-level logprob istiyor. Şu an MLX-Server'da bunu almanın yolu yok; Ollama'da da yoktu, ama OpenAI uyumlu üst katman bir gün eklenir umuduyla bekliyorum.

Bu iki pürüz benim için bloker olmadı çünkü ağır agent workflow'larını Claude API'ye taşıdım. Yerel LLM benim için "ucuz, hızlı, offline" katman; mükemmellik beklemiyorum.

Sistem Yan Etkileri

30 günlük sonra fark ettiğim, sayısal olmayan ama önemli iki gözlem:

Fan sesi kayboldu. Ollama döneminde günde 3-5 defa Mac Mini'nin fanı duyulur hale geliyordu (ben çok hassasım, sessiz oda). MLX geçişiyle fan'ı bir hafta duymadım. Sebep muhtemelen daha az CPU/GPU saturation süresi + daha düşük bellek baskısı.
Elektrik tüketimi az da olsa düştü. Smart plug'da Ollama tipik yük altında ~38W, MLX altında benzer iş için ~32W ölçtüm. Aylık ~4 kWh fark, yani parasal olarak komik bir miktar — ama termal envelope için anlamlı.

Sonuç: 5 Madde Net Çıktı

Mac Mini M4 (24 GB) üzerinde yerel LLM inference için MLX-Server, Ollama'ya kıyasla 8B-class modellerde ~%70 daha fazla tokens/sec ve ~%55 daha düşük ilk-token gecikmesi veriyor. Apple Silicon'a yatırım yaptıysanız MLX'i denemeden Ollama'da kalmak para masaya bırakmak gibi.
24 GB unified memory, 8B-13B aralığında çok rahat; 30B üstüne çıkmaya çalışmayın. İki günümü Llama 3.3 70B 2-bit denemesine harcadım, sonuç tatmin edici değildi.
MLX'i konteyner içinde çalıştırmayın. Host üzerinde LaunchAgent + K8s'ten ExternalName Service ile expose en sağlıklı yol.
OpenAI API uyumluluğunu test edin. tool_calls ve logprobs gibi field'lar eksik veya farklı dönüyor; client'ınızın bunlara bağımlılığını önceden ölçün.
Sürüm versiyonlarını takip edin. mlx-lm 0.21 → 0.24 arasında benim use case'imde ~%13 hız artışı oldu. CHANGELOG'u haftada bir tarıyorum.

Önümüzdeki ayın planı: çekmecedeki M1 Mac Mini'yi de ağa katıp MLX'in yeni gelen multi-device inference desteğini denemek. Eğer çalışırsa 30B-class bir modeli iki cihaza dağıtarak çalıştırmak realistik hale gelebilir. Sonucu ayrı bir yazıda paylaşacağım.

Kendi yerel LLM kurulumunuzla ilgili özellikle "şunu denedim, şu yüzden vazgeçtim" tarzı deneyimlerinizi merak ederim; bu tür somut hikayeler her dökümandan değerli.