antirez/ds4 - Metal için DeepSeek V4 Flash yerel çıkarım motoru

• Apple Metal GPU için optimize edilmiş, yalnızca DeepSeek V4 Flash'a özel yerel çıkarım motoru; genel amaçlı bir GGUF çalıştırıcısı değil, tek bir modele odaklanan yerel bir C uygulaması
• DeepSeek V4 Flash, etkin parametre sayısı az olduğu için yüksek hız sunar ve thinking modunda diğer modellere kıyasla yaklaşık 5'te 1 uzunlukta düşünme bölümü üretir
• 1 milyon token bağlam penceresi ve aşırı sıkıştırılmış KV önbelleği sayesinde yerel ortamda da uzun bağlamlı çıkarım mümkündür; ayrıca disk KV önbelleği kalıcılığı desteklenir
• OpenAI ve Anthropic uyumlu HTTP API sunucusu dahildir; Claude Code, opencode, Pi gibi çeşitli kodlama ajanlarıyla anında entegre olabilir
• llama.cpp ve GGML ekosisteminin temeli üzerine kurulmuştur; proje, GPT 5.5'in güçlü kodlama desteğiyle geliştirilmiştir

---

Proje özeti ve tasarım felsefesi

• ds4.c, yalnızca DeepSeek V4 Flash için küçük bir yerel çıkarım motorudur; genel amaçlı bir GGUF çalıştırıcısı ya da başka bir runtime için sarmalayıcı değildir
• Çekirdek yol, DeepSeek V4 Flash'a özel Metal grafik yürütücüsüdür; buna DS4'e özel yükleme, prompt işleme, KV durumu ve sunucu API bağlayıcı kodu dahildir
• Yerel çıkarım alanında pek çok başarılı proje olsa da, yeni modeller sürekli çıktığı için ilginin dağılması gibi bir sorun vardır
  • Bu proje kasıtlı olarak aynı anda tek bir modele odaklanır ve resmi vektör doğrulaması (logits), uzun bağlam testleri ve ajan entegrasyonuna kadar gider
• Yerel çıkarım vizyonu: A) HTTP API içeren bir çıkarım motoru + B) belirli bir motor için optimize edilmiş GGUF + C) kodlama ajanı uygulamaları üzerinden test ve doğrulama; bu üç parçanın birlikte çalışması
• Yalnızca Metal desteklenir; gelecekte CUDA desteği olabilir, ancak kesin değildir
  • CPU yolu yalnızca doğruluk doğrulaması içindir; mevcut macOS sürümündeki sanal bellek uygulama hatası nedeniyle CPU kodu çalıştırıldığında kernel çökmesi oluşur
• Proje, GPT 5.5'in güçlü desteğiyle geliştirilmiş; insan tarafı ise fikir, test ve hata ayıklamayı yönlendirmiştir

DeepSeek V4 Flash neden ayrı bir motor oldu?

• Etkin parametre sayısı az olduğu için daha hızlı çıkarım sağlar
• Thinking modunda diğer modellere göre yaklaşık 5'te 1 uzunlukta düşünme bölümü üretir ve düşünme bölümünün uzunluğu problemin karmaşıklığıyla orantılıdır
  • Diğer modellerin thinking modunda pratikte kullanılamadığı durumlarda bile DeepSeek V4 Flash kullanılabilir kalır
• 1 milyon token bağlam penceresi desteği
• 284B parametre ölçeği sayesinde 27B ve 35B modellere göre bilginin sınırlarında daha fazla şey bilir
  • Bunun farkı İtalyanca TV programları veya siyasetle ilgili sorularda görülebilir
• İngilizce ve İtalyanca yazı kalitesi, sınır öncesi frontier modellere yakındır
• KV önbelleği son derece sıkıştırılmıştır; bu sayede yerel bilgisayarda uzun bağlamlı çıkarım mümkündür ve disk KV önbelleği kalıcılığı desteklenir
• Özel bir kuantizasyon yöntemiyle 2 bit kuantizasyonda bile iyi çalışır; böylece 128GB RAM'li MacBook üzerinde çalışabilir
• İleride DeepSeek tarafından V4 Flash'in güncellenmiş bir sürümünün çıkması bekleniyor

llama.cpp ve GGML'ye teşekkür

• ds4.c, GGML'ye bağlanmasa da llama.cpp projesinin açtığı yolun üzerinde durur
• llama.cpp'nin kernel'leri, kuantizasyon formatları, GGUF ekosistemi ve donanım-yakın mühendislik bilgisi temel başvuru kaynaklarıdır
• Kaynak kod düzeyinde bazı parçalar MIT lisansı altında korunmuş ya da uyarlanmıştır: GGUF quant yerleşimi ve tabloları, CPU quant/dot mantığı, belirli Metal kernel'leri gibi
• LICENSE dosyasında GGML yazarlarının telif bildirimleri korunur

Model ağırlıkları

• Yalnızca bu proje için yayımlanmış DeepSeek V4 Flash GGUF dosyaları çalışır; rastgele DeepSeek/GGUF dosyaları uyumlu değildir
• 2 bit kuantizasyonda asimetrik kuantizasyon uygulanır
  • Yalnızca MoE expert'leri kuantize edilir: up/gate için IQ2_XXS, down için Q2_K
  • Paylaşılan expert'ler, projeksiyon, yönlendirme ve diğer bileşenler kuantize edilmez; böylece kalite korunur
• ./download_model.sh q2 ile 128GB RAM'li makineler için, ./download_model.sh q4 ile 256GB ve üzeri RAM'li makineler için model indirilebilir
  • İndirme Hugging Face(antirez/deepseek-v4-gguf) üzerinden yapılır ve curl -C - ile yarım kalan indirmeleri sürdürme desteği vardır
• ./download_model.sh mtp ile isteğe bağlı speculative decoding destekli GGUF da indirilebilir
  • MTP/speculative decoding yolu hâlâ deneyseldir ve şu anda yalnızca hafif bir hız artışı sağlar

Hız benchmark'ları

• --ctx 32768, --nothink, greedy decoding ve -n 256 ayarlarında tek çalıştırmalık Metal CLI sonuçları
• MacBook Pro M3 Max, 128GB (q2)
  • Kısa prompt: prefill 58.52 t/s, üretim 26.68 t/s
  • 11709 token'lık prompt: prefill 250.11 t/s, üretim 21.47 t/s
  • q4 bellek yetersizliği nedeniyle N/A
• Mac Studio M3 Ultra, 512GB (q2)
  • Kısa prompt: prefill 84.43 t/s, üretim 36.86 t/s
  • 11709 token'lık prompt: prefill 468.03 t/s, üretim 27.39 t/s
• Mac Studio M3 Ultra, 512GB (q4)
  • Kısa prompt: prefill 78.95 t/s, üretim 35.50 t/s
  • 12018 token'lık prompt: prefill 448.82 t/s, üretim 26.62 t/s

CLI kullanımı

• -p seçeneğiyle tek seferlik prompt çalıştırılır; -p olmadan çalıştırılırsa etkileşimli çok turlu sohbet moduna girer
• Etkileşimli CLI, işlenmiş sohbet dökümünü ve canlı Metal KV checkpoint'lerini korur; böylece her tur önceki konuşmayı genişletir
• Yararlı komutlar: /help, /think, /think-max, /nothink, /ctx N, /read FILE, /quit
  • Ctrl+C ile o anki üretim durdurulup prompt'a geri dönülebilir
• Varsayılan mod thinking'dir; /nothink veya --nothink ile doğrudan yanıt moduna geçilebilir
• --mtp MTP.gguf --mtp-draft 2 ile isteğe bağlı MTP speculative yolu etkinleştirilebilir
  • Yalnızca greedy decoding ile anlamlıdır; confidence gate (--mtp-margin) ile yavaş kısımların kabul edilmesi önlenebilir

Sunucu

• OpenAI/Anthropic uyumlu yerel HTTP sunucusu çalıştırabilir
• Yalnızca Metal'dir ve bellekte tek bir değiştirilebilir grafik/KV checkpoint'i tutar
  • Durumsuz istemci aynı prompt'un daha uzun bir sürümünü yeniden gönderirse ortak önek yeniden kullanılabilir
• İstek ayrıştırma ve socket işlemleri istemci thread'inde çalışsa da, çıkarımın kendisi tek bir Metal worker üzerinden sıralı biçimde yürütülür
  • Mevcut sunucu birden fazla bağımsız isteği toplu işlemez; eşzamanlı istekler sırayla bekler

• Desteklenen endpoint'ler

  • GET /v1/models, GET /v1/models/deepseek-v4-flash
  • POST /v1/chat/completions, POST /v1/completions, POST /v1/messages

• /v1/chat/completions (OpenAI uyumlu)

  • messages, max_tokens/max_completion_tokens, temperature, top_p, top_k, min_p, seed, stream, stream_options.include_usage, tools, tool_choice desteklenir
  • Araç şeması DeepSeek'in DSML araç formatı olarak işlenir ve üretilen DSML araç çağrıları tekrar OpenAI araç çağrılarına dönüştürülür

• /v1/messages (Anthropic uyumlu)

  • Claude Code tarzı istemciler için endpoint
  • system, messages, tools, tool_choice, max_tokens, temperature, top_p, top_k, stream, stop_sequences, thinking kontrolü desteklenir
  • Araç kullanımı Anthropic tool_use blokları olarak döndürülür
• Her iki API de SSE streaming destekler; thinking modunda akıl yürütme süreci yerel API biçiminde akıtılır

Ajan istemci entegrasyonu

• ds4-server, OpenAI uyumlu chat completions kullanan yerel kodlama ajanlarıyla entegre olabilir
• 128GB RAM üzerinde 2 bit quant (81GB) çalıştırıldığında 100k~300k token bağlam penceresi uygundur
  • Tam 1M token bağlamı yaklaşık 26GB bellek kullanır (yalnızca sıkıştırılmış indeksleyici yaklaşık 22GB)
• 384000 çıktı limiti ayarıyla token sınırına takılma önlenebilir (model en fazla 384k token üretebilir)

• opencode entegrasyonu

  • ~/.config/opencode/opencode.json dosyasına provider ve agent girdileri eklenerek yapılandırılır
  • baseURL değeri http://127.0.0.1:8000/v1 olarak ayarlanır

• Pi entegrasyonu

  • ~/.pi/agent/models.json dosyasına provider ayarı eklenir
  • DeepSeek'in thinking formatı, reasoning effort desteği ve streaming usage desteği gibi uyumluluk seçenekleri bulunur
  • ~/.pi/agent/settings.json içinde varsayılan model olarak ayarlanabilir

• Claude Code entegrasyonu

  • Anthropic uyumlu endpoint kullanılır; ~/bin/claude-ds4 sarmalayıcı script'i ile ortam değişkenleri ayarlanır
  • ANTHROPIC_BASE_URL yerel sunucuya yönlendirilir ve tüm model değişkenleri deepseek-v4-flash olarak ayarlanır
  • Claude Code başlangıçta yaklaşık 25k token'lık büyük bir prompt gönderdiği için --kv-disk-dir etkinleştirilmelidir
    • İlk pahalı prefill sonrasında, disk KV önbelleği kaydedilmiş öneki yeniden kullanır; böylece sonraki oturumlarda tüm prompt'un tekrar işlenmesi gerekmez

Thinking modu

• DeepSeek V4 Flash, non-thinking, thinking ve Think Max olmak üzere üç modu destekler
• Sunucunun varsayılanı thinking modudur
• reasoning_effort=max ile Think Max istenebilir; ancak bu yalnızca bağlam boyutu model kartının önerisine göre yeterince büyükse uygulanır
  • Küçük bağlamlarda normal thinking moduna geri düşer
• OpenAI reasoning_effort=xhigh, Think Max değil, normal thinking moduna eşlenir
• Doğrudan yanıt gerekiyorsa thinking: {"type":"disabled"}, think:false veya deepseek-chat gibi non-thinking model takma adları kullanılabilir

Disk KV önbelleği

• Chat/completion API'leri durumsuzdur; bu yüzden ajan istemciler her istekte tüm konuşmayı yeniden gönderir
• ds4-server, işlenmiş token akışını önbellekteki token önekiyle karşılaştırarak çalışır
  • Canlı bellek içi checkpoint mevcut oturumu taşır
  • Disk KV önbelleği ise oturum değişimlerinde ve sunucu yeniden başlatıldıktan sonra yararlı önekleri koruyan mekanizmadır
• Şu anda bellekte yalnızca tek bir canlı KV önbelleği vardır; yeni ve alakasız bir oturum bunun yerini aldığında, eski checkpoint ancak disk KV önbelleğine yazılmışsa yeniden işleme gerekmeden sürdürülebilir
• --kv-disk-dir ve --kv-disk-space-mb ile etkinleştirilir

• Önbellek anahtarı ve dosya yapısı

  • Önbellek anahtarı, ham metin değil, tam token ID'lerinin SHA1 hash'idir
  • Her token ID little-endian 32 bit tamsayı olarak hash'lenir; dosya adı biçimi <sha1>.kv olur
  • Yazma işlemi normal read/write I/O ile yapılır; mmap kullanılmaz (zaten modeli eşleyen süreçte ek VM eşlemelerini önlemek için)

• Disk önbellek dosyası düzeni

  • KVC sabit başlığı 48 bayttır: magic("KVC"), sürüm, yönlendirilmiş expert quant bitleri, kaydetme nedeni, önbelleğe alınan token sayısı, isabet sayısı, bağlam boyutu, oluşturma/son kullanım Unix zamanı, DS4 oturum payload bayt sayısı
  • İşlenmiş metin: önbelleğe alınmış token önekinin tokenizer tarafından çözümlenmiş metni (gözlem amaçlıdır, anahtar olarak kullanılmaz)
  • DS4 oturum payload'u: 13 little-endian u32 alanıyla başlar; burada magic("DSV4"), payload sürümü, bağlam boyutu, prefill chunk boyutu, KV ring kapasitesi vb. bulunur
    • Checkpoint token ID'leri, sonraki token için float32 logits, katman başına sıkıştırılmış attention satır sayıları, canlı ham sliding window KV satırları, sıkıştırılmış katmanların KV satırları ve compressor frontier tensor'leri gibi veriler kaydedilir

• Checkpoint ne zaman kaydedilir?

  • cold: uzun ilk prompt kararlı bir öneke ulaştıktan sonra, üretimden önce
  • continued: prefill veya üretim belirlenmiş aralık kadar ilerlediğinde
  • evict: alakasız bir istek canlı bellek içi oturumun yerini almadan önce
  • shutdown: sunucu düzgün şekilde kapanırken
• cold kaydetmede küçük token sonekleri kırpılır ve prefill chunk sınırına hizalanır; böylece gelecekteki isteklerde BPE sınırında yeniden tokenleştirme hataları önlenir
  • Varsayılanlar: en az 512 token önek, cold kayıtta en fazla 30000 token, sonda 32 token kırpma, 2048 token chunk hizalaması
• Varsayılan olarak 2 bit ve 4 bit yönlendirilmiş-expert varyantları arasında token önekleri eşleştiği sürece checkpoint yeniden kullanılabilir
  • --kv-cache-reject-different-quant ile yalnızca aynı kuantizasyon için yeniden kullanım ayarlanabilir

Backend

• Varsayılan backend Metal'dir (--metal)
• CPU referans/hata ayıklama yolu da vardır (--cpu), ancak üretim hedefi değildir
  • Sunucu yalnızca Metal'dir; optimize edilmiş uygulama Metal grafik yolunda bulunur

• MIT lisansı, C/Objective-C/Metal uygulaması

[GN⁺]

Hacker News yorumları

• Bunu mevcut bir kod tabanında Claude Code ile birlikte denedim; 2 bit kuantize bir model olmasına rağmen işini görüyor gibi görünüyor
  Prompt işleme birkaç dakika sürüyor ama gerçek düzenleme kısmı 20 token/sn üzerinde, yani oldukça hızlı
  Küçük görevlerde kodu gezme, değişiklik uygulama ve test yazma işlerini başardı, ancak ufak bir uyarıyı düzeltemedi
  Daha kötüsü, başka bir sorunu çözerken aynı anda yaptığımız “The Duck” ile ilgili konuşmayı halüsinasyonla buraya taşıdı. Muhtemelen Claude Code’un ilk prompt örneklerinden biri

• Daha önce Qwen3 modeli için çok benzer bir şey yapmıştım. Yalnızca Qwen3 çalıştırıyor, sadece bazı kuantizasyonları destekliyor, GGUF’tan yüklüyor ve Claude’un iteratif olarak optimize ettiği inference’ı kullanıyordu
  Tamamı birkaç dosyadan ibaretti ve anlaması kolaydı; öğrencilerin decoding stratejileri ekleyerek ya da abliteration gibi şeyleri deneyerek öğrenmesi için yapılmış bir projeydi. Ünlü framework’ler büyük ve karmaşık olduğu için kurcalaması zor, eğitim amaçlı projeler ise çoğu zaman GPT-2 gibi eski şeylerde kalıyor
  Eğitim amaçlı başlamıştı ama aklımdan çıkmayan bir fikir doğdu: belirli bir GPU+model kombinasyonu için aşırı optimize edilmiş bir inference motoru yapmak. GPU’lar pahalı ve giderek zor bulunur hale geliyor; bu yüzden soyutlamayı yeterince kaldırıp doğrudan belirli donanıma/modela uyarlarsanız epey optimizasyon yapılabilir gibi geliyor
  Tabii model eskiyince her şeyi baştan yapmak gerekmesi gibi bir sorun var

  • Hâlihazırda kullanılan inference motorları, farklı donanımlar için optimize edilmiş backend bileşenleri içeriyor
    Daha az popüler platformlarda hâlâ kolayca elde edilebilecek performans kazanımları olabilir, ancak belirli bir GPU ailesi için aşırı optimize bir model çalıştırıcı yapıp çok daha iyi performans alma alanı pek büyük değil. Ana hesaplamalar zaten her GPU’ya göre ayarlanmış, son derece optimize kernel’ler tarafından yapılıyor
    CPU mimarilerinde daha iyi çalışsın diye optimize edilmiş llama.cpp fork’ları da var, ancak bakımcılar arasında görüş ayrılığı yoksa belirli model+GPU çalıştırıcıları yapmak yerine bu tür iyileştirmeleri upstream’e birleştirmek zamanı daha iyi kullanmak olur
  • Bu bana ünlü FizzBuzz yüksek performanslı code golf yanıtını hatırlatıyor. Böyle bir optimizasyonu inference’a uygulayabilsek, belki hızı 10 katın üstüne çıkarabiliriz
    https://codegolf.stackexchange.com/questions/215216/high-thr...
  • Buna ek olarak, çipi modele göre tasarlamak nasıl olur diye düşünüyorum. Dijitalden analoğa geçip vektörleri bitlerle değil voltajla ifade etsek ne olur?
    Hesaplama yükü ağır olan matris çarpımı işlemlerini operasyonel amplifikatörlerle yapabilir miyiz? Ve bu tür analog bir yaklaşım, bit temsillerinin sınırlarından çok daha verimli olabilir mi?
  • Mojo sanki aşırı optimize donanıma özgü motorları hedefliyor gibi görünüyor ama burada ondan neredeyse hiç bahsedilmiyor
  • Benzer bir şey yapmıştım. Sorunlardan biri, LLM’lerin iyi shader yazmakta gerçekten çok kötü olması. Daha az berbat üretmeleri için çok fazla zaman harcadım

• Artık son AI modelleri kernel optimizasyonu bile yapabildiğine göre, daha fazla insan kendi donanımına uygun daha iyi inference’ı kendisi üretmeli diye düşünüyorum
  Eski bir W7900 (RDNA3) kartım var; 48GB VRAM’in yanında 123 FP16 TFLOPS/INT8 TOPS, 864GB/s bellek bant genişliği gibi değerler de gayet iyi. Ama AMD’nin ROCm desteği de, llama.cpp desteği de meşhur şekilde kötüydü
  Yakın zamanda bu kartı özel bir ajan/kodlama endpoint’i olarak kullanmak için W8A8-INT8 modeli ayarlamaya başladım. Birkaç gün boyunca yaklaşık 800 otomatik iterasyon çalıştırdım ve çeşitli frontier/SOTA modellerini denedim; Kimi K2.6 şaşırtıcı derecede iyi çıktı. Sonuçta Qwen3.6 MoE için en iyi llama.cpp değerlerine kıyasla prefill %20, decode ise %50 daha hızlı oldu
  Şu anda MTP ve DFlash optimizasyonlarına devam ediyorum ve sonuçlardan oldukça memnunum; sırada muhtemelen Gemma 4 var

  • 7900xtx ile benzer durumdayım. 24GB VRAM var ve kâğıt üstündeki performans iyi görünüyor ama pratikte çoğu şey düzgün çalışmıyor
    Yine de llama.cpp, en yüksek performansı vermese de modellerin çoğunu tutarlı şekilde çalıştırabiliyor. MTP eksik ve hibrit modellerde cache invalidation sorunu var gibi, ama en azından neyin çalıştığını biliyorum
    Python tabanlı inference araçları ise uv/venv, benim venv’im, sistem ortamı, Python ve kütüphanelerin hepsi birbirine karıştığından, gerçekte neyin çalıştığını anlamak için neredeyse bir ajana ihtiyaç duyuyor. Bunun beceri eksikliği ya da kullanıcı hatası olduğunu biliyorum ama buna ayıracak vaktim yok
    Mükemmel olmasa bile GitHub ya da Hugging Face’e koyarsanız başka ajanlar sıfırdan başlamak yerine onun üstünden ilerleyebilir. Ling-2.6-flash (107B-A7B4 MoE) için de bunu yaptım ve bu, yerel LLM için elimdeki diğer donanım olan M2 Max’te pratik şekilde çalıştırabildiğim en büyük LLM
    MTP düzgün çalışmasa bile, mevcut llama.cpp’nin Ling-2.6-flash’ı hiç çalıştıramamasına göre bu yine de bir ilerleme. İlgili tartışma https://huggingface.co/inclusionAI/Ling-2.6-flash/discussion... adresinde, 4 bit kuantizasyon https://huggingface.co/ljupco/Ling-2.6-flash-GGUF, branch ise https://github.com/ljubomirj/llama.cpp/tree/LJ-Ling-2.6-flas... adresinde
  • Bilgini ve sonuçlarını paylaşırsan harika olur
    Bence llama.cpp PC desteğini çok daha iyi verebilirdi. Bunun bir kısmı vendor desteğinin zayıf olmasından kaynaklanıyordur ama bu kadar kullanıcıya rağmen standart PC’lerde daha optimize inference örneklerini az görmek şaşırtıcı

• Gerçekten harika. Tek bir açık kaynak model üzerinde aylarca yoğun optimizasyon yapılırsa ortaya ne çıkacağını merak ediyorum
  Sadece inference serving değil, harness optimizasyonu ve özel workflow’lar da dâhil olmak üzere; frontier modellerin çıkarım ve muhakeme yeteneklerine karşı, açık kaynak modellerin boyut ya da eğitim sınırlarından doğan eksiklerini ne kadar kapatabileceğini görmek isterim

  • Frontier modeller ile açık kaynak modeller arasında her zaman büyük bir fark olacak. Hele çok zengin değilsen daha da öyle; ayrıca bu sektörün tamamı birim ekonomiyi görmezden geliyor, bu da anlamsız
    Kimi 2.6’yı makul token/sn hızında çalıştırmanın aylık maliyeti 20 bin dolar; bu token’ları kâr ederek satabilmek için donanım maliyetinin ayda 1.000 doların altında olması gerekir
    Milyarderlerin token’ları maliyetinin 1/10’u ya da 1/20’sine satma cömertliğine veya yetkin açık kaynak modellerin tüketici donanımına ineceği hayaline güvenerek yetenek inşa ediyorsanız, zaten kaybetmişsiniz demektir

• Eğlenceli, ilginç ve çok şey anlatan bir veri noktası var. MacBook M3 Max cihazımda DS4, en yüksek hızda token üretirken güç tüketimi 50W’a çıkıyor

  • İnternetin, “ölçek ekonomileri sayesinde LLM veri merkezleri kullanıcı başına enerji verimliliğinde self-hosted LLM’lerden teknik olarak daha iyi” şeklindeki veri noktasını kabul etmeye henüz hazır olmadığını hissediyorum
  • Bu makinelerin “düşünmek” için ne kadar güç harcadığını düşünmek ilginç. Kabaca “çok” harcadığını varsayıyordum ama bunu sayıyla görmek iyi oldu
    DS4 Flash 50W’ta tepe yapıyor ve 280B parametreyse, 1.6T parametreli DS4 Pro kabaca 300W mı olur? En yeni GPT 5 ve Opus da benzer şekilde 500W civarında gibi hissettiriyor
    Claude Code kullanırken model kendi kendine uzun uzun dönerken, bir yerlerde veri merkezinde 500W yakıldığını varsaymak makul mü?
  • Herkes fark etmeyebilir ama bu gerçekten çok iyi ve etkileyici bir sonuç. Benim M4 Max cihazımda çoğu model 150W tüketiyor
  • Bu sayının gerçekten doğru olup olmadığını merak ediyorum. Donanıma çok hâkim olmayan biri bunu nasıl ölçer, onu da merak ediyorum
  • Yaklaşık 2-3 insan beyninin güç tüketimine eşdeğer. Müthiş bir iş

• Mac Studio’da 96GB RAM üstü bir seçeneği sipariş edemiyorum. M3 Ultra ya da M4 Max’te de durum aynı. Bunun Avustralya’ya özel olup olmadığını bilmiyorum
  Buna karşılık MacBook Pro’da M5 Mac ile 128GB seçilebiliyor
  https://www.apple.com/au/shop/buy-mac/mac-studio

  • Bu belleğin unobtanium’dan yapıldığına inanmak zor
    Apple, aşırı fiyat tepkisi ya da stok yokluğu tepkisi yaşamaktansa hiç fiyat koymamayı tercih etmiş olabilir
  • Sadece Avustralya’ya özel değil: https://9to5mac.com/2026/05/05/apples-most-powerful-mac-stud...
    96GB üstü tüm Mac Studio konfigürasyonlarını ve temel Mac mini’yi kaldırmışlar. Neo temel konfigürasyonunu da piyasadan çekmeyi düşündüklerine dair söylentiler var
    Görünüşe göre fab kapasitesi ve RAM tedarik kısıtlarını böyle yönetiyorlar
  • Studio artık epey eski bir ürün. Yeni model geldiğinde daha fazla bellek seçeneği sunma ihtimalleri yüksek. Yine de 128GB M5 Max MBP harika

• Basit bir motivasyon benchmark’ı ya da hedef eksik gibi geldi, ama emin değilim
  Genel araç zincirini kullanmaktan daha hızlı olduğu ya da daha büyük ve daha akıllı modeller çalıştırabildiği varsayılabilir, ancak mevcut iyileşmenin ya da beklenen iyileşmenin taban çizgiye göre ne kadar olduğu açıkça yazılmamış gibi
  Elbette ilgili karşılaştırma değerleri biliniyorsa verilen sayılardan hesap yapılabilir

• Çok etkileyici. Yalnız büyük girdilerde yanıt vermeye başlamadan önce yaklaşık 4 dakika beklemesi biraz garip görünüyor
  Mac donanımında LLM kullanmıyorum ama bu epey şaşırtıcı ve gerçek kullanımda önemli bir engel gibi duruyor
  Yine de genel kullanım açısından, cache açıklamasını görünce daha mantıklı geldi. Claude Code faydalı bir işe başlamadan önce genelde 25k token civarında büyük bir ilk prompt gönderebiliyor ve --kv-disk-dir açıkken ilk pahalı prefill’den sonra disk KV cache, kaydedilmiş prefix’i yeniden kullanarak tüm prompt’u baştan işlemeyi gereksiz kılıyor

  • Kodlama ajanları çok büyük sistem prompt’ları gönderdiğinde bu oluyor. Daha sonra araç çağrıları büyük dosyalar ya da diff’ler eklediğinde de aynı şey yaşanıyor
    Ama M3 Ultra’da prefill hızı neredeyse 500 token/sn, yani gayet kullanılabilir. M3 Max biraz daha sabır istiyor ama iyi çalışıyor; ayrıca pi agent kullanırsanız düşünme sürecini çıktıladığı için beklemek yerine sansürlenmemiş chain of thought okuyorsunuz
    Dün X’e M3 Max ile kullanım videosu koydum; oldukça iyi bir hızda token üretiyor
  • M5’te prefill daha hızlı, önceki nesiller biraz daha zayıf

• MacBook’ta büyük LLM’lerde token üretim hızı kabul edilebilir ama asıl sorun bağlamı okuma kısmı
  Bu, sohbet oturumlarında KV cache kullanılan artımlı okuma değil; büyük bir dosya yapıştırırken olduğu gibi büyük girdileri okuma durumu. Bu birkaç dakika sürebiliyor

  • DS4, prompt token’larını saniyede 460 adet işleyebiliyor. Olağanüstü değil ama o kadar da yavaş sayılmaz. M3 Max için konuşuyorum; README’deki benchmark’a bakılabilir
  • Yerel inference neden bu kadar yavaşken barındırılan modeller neden bu kadar hızlı, bunu kolay anlaşılır şekilde açıklayabilecek biri var mı?
  • Yanlış anlamadıysam bu repo 2 bit kuantizasyon ile çalıştırmayı anlatıyor
    Bu da muhtemelen bulut sağlayıcılarının sunduğu orijinal zekâ seviyesinden epey uzak demek
    Yine de ajan tabanlı workflow’larda yerel LLM’lerin potansiyelini daha iyi gösteriyor
  • Bu neden oluyor?
    Tüm sohbet geçmişini tekrar içeri vermeye dayanmayan bir mimari var mı? Örneğin döngüsel LLM’ler gibi?