TurboFieldfare - Tüm M serisi Mac'lerde Gemma 4 26B'yi 2GB RAM ile çalıştıran açık kaynak motor

 (github.com/drumih)
1 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • TurboFieldfare, Gemma 4 26B-A4B'yi tüm 14.3GB modeli belleğe yüklemeden yaklaşık 2GB bellekle çalıştırarak 8GB Apple Silicon Mac'lerde yerel çıkarımı mümkün kılar
  • MoE uzman ağırlıkları, yalnızca 1.35GB paylaşılan çekirdek ve FP16 KV önbelleği bellekte tutulduktan sonra, token başına gerektiğinde SSD'den akışla getirilir; 16 yuvalı LFU önbellek ve paralel pread ile G/Ç sınırlandırılır
  • Gemma 4 26B-A4B, token başına yaklaşık 3.88B parametreyi etkinleştirir; ölçülen decoding hızı 8GB M2 MacBook Air'de 5.1~6.3 tok/s, 24GB M5 Pro'da ise 31~35 tok/s'tir
  • Swift 6.2 ve Metal 4 ile yazılmış özel bir runtime'dır; yerel Mac uygulaması, CLI, kurulum aracı ve deneysel OpenAI uyumlu sunucuyu aynı .gturbo model dizini üzerinde sunar
  • Mevcut kapsam, macOS 26 veya üstü ve en az 8GB RAM'e sahip Apple Silicon Mac'lerde yalnızca metin çıkarımı ile sınırlıdır; görüntü, ses, video ile uzak sunucu kimlik doğrulaması ve TLS desteklenmez

Belleği azaltan çalışma yapısı

  • TurboFieldfare, instruction-tuned Gemma 4 26B-A4B'yi bütünüyle belleğe yüklemez
    • 1.35GB paylaşılan çekirdek ve FP16 KV önbelleği bellekte tutulur
    • Her token için gereken routed expert'ler SSD'den Metal'in görebildiği arabellekler içine okunur
    • Kurulu yalnızca metin modeli yaklaşık 14.3GB olsa da, ağırlıklar ve 4K KV önbelleğinin kullandığı bellek yaklaşık 2GB'tır
  • Model, toplam 26B parametre içinden token başına yaklaşık 3.88B parametreyi etkinleştirir
  • Ağırlıklar group 64 tabanlı MLX affine 4-bit kullanır; router 8-bit, paylaşılan ve routed expert'ler 4-bit'tir
  • Bu, MLX veya llama.cpp'yi saran bir yapı değil, Gemma 4 26B-A4B için yapılmış Swift·Metal'e özel bir runtime'dır

Token üretim süreci

  • Her Transformer katmanında Metal, bellekte duran ağırlıklarla attention ve router hesaplamasını yapar
  • CPU, router'ın seçtiği en iyi 8 expert ID'yi katman başına 16 yuvalı LFU önbellekle karşılaştırır
    • Önbellek kaçırmaları sınırlı sayıda paralel pread çağrısıyla doldurulur
    • SSD okuması sürerken Metal, bellekte duran shared-expert dalını hesaplar
    • Okuma tamamlandığında shared output ile routed output birleştirilir
  • Prompt prefill, bir kez getirilen expert'in birden fazla satırı işleyebilmesi için en fazla 128 token'lık parçalar kullanır
  • Üretim aşamasında routed layer döngüsü token bazında tekrarlanır
  • KV önbelleği, 25 sliding-window layer için sınırlı döngüsel depolama; 5 full-attention layer için doğrusal depolama kullanır
  • Decoding attention, normalize edilmiş K ve V yollarını ayıran exact split-K/V yöntemidir

Kurulum ve model biçimi

  • İlk çalıştırmada Download seçildiğinde sabit bir Hugging Face revision'dan yaklaşık 15GB veri range request ile indirilir
  • Kurucu, özgün checkpoint'in tamamını geçici dosya ya da bellekte oluşturmaz
    • Gerekli bayt aralıklarını alıp doğrudan .gturbo düzenine yeniden paketler
    • Tam shard veya tensor'leri ayrıca hazırlamadığı için geçici bellek kullanımı sınırlı kalır
    • Tamamlanan kurulum ancak manifest ve dosya hash doğrulamasını geçerse kullanılabilir
  • Kurulum tamamlandıktan sonra model yaklaşık 14.3GB depolama alanı kaplar ve kurulum sürecinin kendisi modeli belleğe yüklemez
  • Runtime yalnızca son manifest.json dosyasını içeren tamamlanmış .gturbo dizinlerini kabul eder
  • Yarıda kalan indirmeyi sürdürme, kısmi indirme durumunu silme ve modeli yüklemeden kurulum doğrulama desteklenir

Çalışma ortamı ve performans

  • Gereksinimler Apple Silicon Mac, macOS 26, Metal 4, Xcode 26 ve Swift 6.2 veya üstüdür
  • Paket yalnızca arm64 içindir; daha eski macOS ve Metal sürümleri desteklenmez
  • Doğrulama hedefi 8GB M2 MacBook Air'dir; model kurulumu için boş depolama alanı ve ilk indirme için internet bağlantısı gerekir
  • Ölçülen decoding performansı şöyledir
    • 8GB M2 MacBook Air: 5.1~6.3 tok/s
    • 24GB M5 Pro: 31~35 tok/s
  • İş hacmi prompt uzunluğu, üretim uzunluğu, sayfa önbelleği durumu ve donanıma göre değiştiğinden, bu ölçümler bir performans tavanı değil referans noktasıdır
  • Modeli çalıştırmadan önce çok bellek kullanan uygulamalar kapatılmalı ve memory_pressure -Q ile boş bellek kontrol edilmelidir
  • Uygulama, decode service, CLI, sunucu, testler veya başka yerel model süreçlerinden aynı anda yalnızca biri çalıştırılmalıdır

Sunulan ürünler ve kullanım şekli

  • Swift paketi altı ürün sunar
    • TurboFieldfare: runtime ve Metal kernel'lerini içeren Swift kütüphanesi
    • TurboFieldfareMac: kurulum ve üretim için yerel Mac uygulaması
    • TurboFieldfareDecodeService: Mac uygulamasının kullandığı tek seferlik yerel model·Metal sahipliği süreci
    • TurboFieldfareCLI: komut satırı instruction chat ve raw completion
    • TurboFieldfareServer: loopback OpenAI uyumlu Chat Completions sunucusu
    • TurboFieldfareRepack: akış tabanlı kurulum ve kurulum doğrulama aracı
  • Mac uygulamasında model indirildikten sonra Load Model seçilir ve prompt girilerek üretim yapılır
    • Durum çubuğundan ilerleme, decoding hızı ve bellek kullanımı görülebilir
    • Sampling, context length, expert-cache slot ve runtime seçenekleri ayarlanabilir
  • CLI'nin instruction chat'i bir JSON mesaj dizisi alır ve bunu Mac uygulamasıyla aynı biçime dönüştürür
    • Yanıt sınırı --max-new için varsayılan değer 1,024 token'dır
    • Mac uygulaması, seçilen context window dolana kadar üretim yapabilir
  • --prompt, sohbet biçiminin uygulanmadığı raw completion ve yeniden üretilebilir karşılaştırmalar için kullanılır
  • Üretilen metin standart çıktıya, zaman istatistikleri standart hataya gönderilir; --quiet ile istatistik çıktısı kapatılabilir

Prompt ve destek kapsamı

  • Mac uygulaması girdiyi instruction olarak işler ve Gemma'nın sohbet biçimini otomatik uygular
  • Varsayılan sampling ayarları temperature 0.2, Top-K 64, Top-P 0.95'tir
    • temperature 0 yapılırsa deterministik greedy output kullanılır
    • Model tekrar edebilir veya yanlış yanıt verebilir; bu yüzden önemli sonuçlar doğrulanmalıdır
  • Uygulama ve CLI, kullanıcı·model mesajları ile isteğe bağlı system guidance destekler, ancak araçları göstermediği veya çalıştırmadığı için tool desteği sunmaz
  • Mevcut model giriş/çıkışı yalnızca metindir; görüntü, ses ve video desteklenmez
  • CLI, --max-context, --temperature, --top-k, --top-p, --repetition-penalty, --seed ve tekrar edilebilir --stop dizeleri sunar

OpenAI uyumlu yerel sunucu

  • Deneysel sunucu 127.0.0.1:8080/v1 üzerinde çalışır ve Chat Completions, akış, fonksiyon araç bildirimi ve tek prefix prompt yeniden kullanımını destekler
  • Sunucu modelin ürettiği tool call'ları döndürür, ancak tüm araç çağrılarının onayı ve yürütülmesi istemcinin sorumluluğundadır
  • Uzak kimlik doğrulama ve TLS olmadığı için sunucu yalnızca loopback üzerinde tutulmalıdır
  • Mac uygulaması, CLI ve sunucu aynı .gturbo dizinini kullanır, ancak modele sahip olan ürünlerden aynı anda yalnızca biri çalıştırılmalıdır

Uygulama kapsamı ve deney kayıtları

  • Özel Metal kernel'leri quantized GEMV, attention, MoE, normalization, RoPE, sampling ve üretim düzeyi fusion işlemlerini yürütür
  • Runtime, SSD tabanlı routed-expert akışı, sınırlı expert önbelleği, parça bazlı tek prompt prefill ve token bazlı üretim uygular
  • Kernel, önbellekleme, G/Ç, prefill ve decode genelinde 103 ölçüm sonucu deney kayıtları olarak tutulur
  • Deney dokümanları, etkisi büyük optimizasyonları, başarısız fikirleri ve daha güçlü doğrulama sonrası tersine dönen ilk sonuçları içerir
  • Gelecek çalışmalar arasında iPhone·iPad uygulamaları geliştirme, mobil çıkarım hızı·bellek ölçümleri ve 16GB M4 Mac mini ile diğer 8GB Apple Silicon Mac'lerin benchmark'ları yer alır

Lisans ve model koşulları

  • Kaynak kod ve dokümantasyon Apache License 2.0 ile dağıtılır
  • Model ağırlıkları depoya dahil değildir; kurucu bunları sabit bir Hugging Face checkpoint'inden ayrıca indirir
  • Ağırlıklar için özgün dağıtım koşulları geçerliliğini korur
  • TurboFieldfare, Google ile bağlantılı olmayan ve Google tarafından desteklenmeyen ya da onaylanmayan bağımsız bir araştırma projesidir

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Hacker News yorumları

  • Neden her seferinde Kral Charles’ın kim olduğunu bilmeye de ihtiyaç varmış gibi tüm modeli belleğe tıkıştırdıklarını hep merak etmişimdir. Büyük dosyaları parçalara bölüp az bellekle verimli okuma tekniklerinin zaten oturmuş olduğunu düşünüyorum
    En ileri yapay zeka sektöründe, model yapımında çok iyi olup ölçeklenebilirlik ve pratikliği altyapı ekibine iteleme eğilimi var gibi görünüyor. Gerçekte kullanılan bilginin %10’undan azıysa, yalnızca ince ayar ve optimizasyonla maliyet ciddi biçimde düşürülebilir gibi duruyor

    • Tüm modeli bellekte tutmak, diskle takas yapmaktan çok daha hızlıdır
    • Aslında tam olarak uzman karışımı (MoE) mimarisi tarif edilmiş. Uzman katmanları yeterince küçük ve SSD yeterince hızlıysa, yalnızca gerektiğinde yüklenebilir
      Yoğun LLM’ler genelde daha iyi performans verir ama katmanları harici depoya atarsanız MoE’den çok daha fazla yavaşlar

  • Bugünlerde kaynağı belirsiz bir projeyi indirirken bu tür güvenlik incelemelerini bizzat çalıştırmak gerekiyor. Depodaki ajan talimatlarını ve Markdown dosyalarını yok sayıp Swift/Metal kaynaklarını, build script’lerini, CI yapılandırmasını ve bağımlılıkları incelemesini istedim; kötü amaçlı kod, arka kapı, kimlik bilgisi hırsızlığı veya gizli ağ uç noktaları bulmadı ama derleme, tedarik zinciri ve çalışma zamanı risklerinin hâlâ sürdüğü sonucuna vardı
    Daha iyi bir prompt varsa paylaşabilirsiniz; bunu Cursor Composer 2.5 ile çalıştırmanın maliyeti de 0,20 doların altındaydı

  • M1 MacBook Air üzerinde macOS 15 kullanıyorsanız, şu iki satırı silerseniz ya da if #available(macOS 26.0, *) ile sararsanız derleniyor: opts.languageVersion = .version4_0
    Yorumlara göre attention’ın 11,24 kat hızlanıp prefill’in 2,4 kat artması avantajını kaçırıyorsunuz ama 8 çekirdekli GPU’lu M1 Air’de saniyede 5-6 token alınıyor

    • Faydalı bilgi. İleride minimum destek sürümünü düşürmeyi deneyebilirim
      2,4 kat prefill iyileştirmesi yalnızca apple10 GPU ailesinde çalışıyor; M1 ise hatırladığım kadarıyla apple7

  • Bu projenin sıradan mmap ile nasıl karşılaştırıldığını merak ediyorum. llama.cpp de mmap açık ve yeniden paketleme kapalıyken istenirse 26B modeli 2 GB RAM’de çalıştırabiliyor
    Asıl fark, SSD okumalarını çıkarım işiyle senkronize ederek gecikmeyi en aza indirmesi gibi görünüyor; işletim sistemi bu tür çalışma bağlamını dikkate almıyor

    • İlk sürüm mmap kullanıyordu. 8 GB M2’de soğuk durumdaki 3,36 MB’lık uzmanı okumak mmap ile 10 ms, pread ile 2,8 ms sürüyordu; tam simülasyon ise sırasıyla saniyede 0,50 token ve 4 token veriyordu
      mmap tarafında işletim sistemi, model sayfaya dokunduğunda sonradan tepki vererek okuma yaptığı için hangi uzmanın seçildiğini ya da GPU işiyle okumayı ne zaman çakıştırabileceğini bilmiyor. Ortak ağırlıklar basitlik için hâlâ mmap kullanıyor; llama.cpp de 2 GB’ın altında çalışabilir ama muhtemelen daha yavaş olur
    • Gerçek hızı görmek için bunu llama.cpp’nin SSD offloading özelliğiyle doğrudan karşılaştırmak isterim

  • “Ölçüm sonuçları bir referans noktasıdır, performans tavanı değil” cümlesi Claude’a özgü bir ifade gibi görünüyor

    • Bu tür ifadeler o kadar yaygınlaştı ki sürekli Claude tarzı metinler okuyup ben de aynı alışkanlığı kaparım diye endişeleniyorum
    • “100’den fazla deney yaptım, çoğu başarısız oldu ama bazıları beni buraya getirdi” de aynı izin bir parçası gibi görünüyor
    • Aslında kökeni ChatGPT tarzı bir ifade olabilir ama bu yüzden Batılı şirketlerin damıtılmış çıktısı diye suçlamayacağım. 2022 sonrası yemek tarifi blogları 4.6-4.8 civarı eğitim verisine girmiş olabilir
    • Artık bu tür teşhisleri bırakma zamanı geldi diye düşünüyorum. Yeni bir tür dilbilgisi polisi olmaktan farkı yok ve pek bir değer de katmıyor
      Yazar sadece LLM ile cümleleri parlatmış ve gereksiz içerik eklememişse sorun değil. Metnin kendisi faydasız bir üretimse zaten düşük oy verilir

  • Daha hızlı SSD takılı bir M1 Max Mac Studio’da saniyede 12 token ve neredeyse anında yanıt alınması etkileyici. Büyük modelleri bellekten değil doğrudan SSD’den çalıştırmanın mümkün olabileceğini gösteriyor

    • Ne yazık ki burada en büyük darboğaz SSD okuma hızı

  • Bugünlerde çok sayıda SSD akış motoru var ama zorlu özelliklere kalkışan az. Büyük modellerde spekülatif kod çözme için MTP head bulunduğundan, bu başlık SSD’deki uzman ağırlıklarını önceden okumakta kullanılabilir
    GPU ihtiyaç duymadan önce ağırlıkları hazır etmek, VRAM önbellek kaçırma maliyetini ciddi biçimde azaltabilir; işe yaradığı kanıtlanırsa gelecekteki modeller uzmanları önceden getirmek için özel bir head’e sahip olabilir ve eğitim aşamasından itibaren buna göre tasarlanabilir

    • SSD akışında GPU doğru uzmanı getirene kadar neredeyse her zaman SSD’yi beklediği için, SSD tarafında önceden okuma için pratikte boşluk yok. Yanlış tahmin edilen uzmanı okumak daha da zararlı olur; bu yüzden tipik büyük olmayan batch ortamlarında mevcut MTP de pek işe yaramıyor
    • Gerçekte sanıldığından daha zor. Her katmanda farklı uzman kümeleri var ve küçük bir yönlendirici, alt katmandaki uzmanların çıktı durumuna bakarak hangi uzmanın kullanılacağını seçiyor
      MTP’nin ürettiği taslak tokenlarla ilk katmandaki uzmanlara kadar tahmin yapılabilir ama 10. katmanı bilmek için önce 1-9. katmanları çalıştırıp o uzmanları yüklemek gerekiyor. Bu yüzden sonraki token üreticisi yerine tüm katmanlardaki uzman etkinleşmelerini tek seferde tahmin edecek şekilde eğitilmiş bir yapıya ihtiyaç var

  • DiffusionGemma’yı çalıştıran proje de neredeyse hazır ve iki proje birleştirilirse iyi uyum sağlayabilir. 36 GB M3’te saniyede yaklaşık 20 token alınıyor ve birbirlerinin daha hızlı kernel’larını kullanma ihtimalleri de yüksek
    Kod şu anda https://github.com/mmastrac/diffgemma adresinde ama henüz dağıtıma uygun durumda değil

    • Kısa süre önce baktım ama diffusion model’leri yerelde çalıştırmanın pratik faydasının az olduğuna karar verdim: https://eamag.me/2026/why-parallel-diffusion-llms-are-slow-o...
      Bu konudaki düşünceni merak ediyorum
    • Diffusion Gemma proje sürecinin ortasında çıktı ve geçiş yapmayı ciddi biçimde düşündüm ama mevcut yönü tamamlamaya karar verdim. İki projenin çok iyi uyuşacağını düşünüyorum; ihtiyaç duyduğunuz kodu serbestçe kullanabilir ya da README’nin sonundaki LinkedIn üzerinden iletişime geçebilirsiniz

  • 8GB M2 MacBook Air'da saniyede 5~6 token ile M5 MacBook Pro'da 31~35 token arasında neden bu kadar büyük fark olduğunu merak ediyorum. SSD performans farkının o kadar büyük olacağını sanmıyorum ama bu yöntemde baskın darboğazın SSD olmasını bekliyordum

    • M5 SSD'deki performans artışı, önceki nesillerle kıyaslandığında da oldukça büyük. Blackmagic Disk Speed Test'te M5 MacBook Pro en fazla 6.323MB/s, M4 MacBook Pro ise 2.031MB/s gördü; yani 3 kattan fazla fark vardı
      https://www.tomshardware.com/laptops/macbooks/m5-macbook-pro...
    • Muhtemelen M5'te daha fazla bellek var ve işletim sistemi dosyanın büyük kısmını zaten önbelleğe almış durumda. M2'de bellek baskısı daha yüksek olduğundan SSD okuma sonuçları daha az önbelleğe alınacaktır
      İşletim sistemi önbelleği dahil toplamda yalnızca 2GB kullanılabilseydi çıkarım hızı daha da düşük olabilirdi
    • Sistem önbelleğine ve pread'e ciddi ölçüde dayanıyor. Süreç 2GB'ın altında kalsa bile M5 Mac bunun bir kısmını önbelleğe alabiliyor ve donanımın kendisi de çok daha hızlı
      Token başına okuma süresi M2'de 83ms, M5 Pro'da 12ms idi; toplam süre ise sırasıyla 163ms ve 30ms idi. Hem okuma hem de GPU işlemesi daha hızlı
    • Nesil olarak daha eski olduğundan, Pro modeller kendi aralarında karşılaştırılsa bile SSD çok daha yavaş; ayrıca aynı nesilde bile Air'in SSD'si ve bellek bant genişliği Pro'dan daha düşük olabilir
    • M5 MacBook Pro'da 24GB RAM var; bu da daha fazla bağlamı bellekte tutabilmesini sağlayabilir

  • İleride 30~60GB bellek ve çok hızlı SSD bulunan sistemlerde bu tür tekniklerle çok büyük modellerin de çalıştırılabilmesini umuyorum