Flash-MoE - Dizüstünde 397 milyar parametreli modeli çalıştırma

 (github.com/danveloper)
5 puan yazan GN⁺ 2026-03-23 | 1 yorum | WhatsApp'ta paylaş
  • 397B parametreli Mixture-of-Experts modelini MacBook Pro (48GB RAM) üzerinde saniyede 4,4 tokenin üzerinde çalıştıran C/Metal tabanlı çıkarım motoru
  • Toplam 209GB’lık modeli SSD’den stream ederek, Python veya framework olmadan yalnızca C ve Metal shader’larıyla uygulanmış
  • SSD Expert Streaming, FMA optimize çekirdekleri, Deferred GPU Compute gibi tekniklerle GPU·SSD·CPU paralel verimliliğini en üst düzeye çıkarıyor
  • 4-bit niceleme yapılandırması, kalite ile hız arasında denge kurarken, araç çağırma özelliği de dahil üretim seviyesinde çıktı üretiyor
  • Dizüstü ortamında bile devasa MoE modelleri için gerçek zamanlı çıkarımı mümkün kılan bir hafifletme ve optimizasyon örneği

Performans sonuçları

  • 4-bit uzmanlar (FMA çekirdeği) yapılandırmasında 4.36 tok/s, yüksek kalite, toplam 209GB disk kullanımı
  • 4-bit temel yapılandırma 3.90 tok/s ile FMA optimizasyonu öncesindeki aşama
  • 2-bit uzmanlar (trust OS) yapılandırması 5.74 tok/s ile daha hızlı, ancak JSON çıktı hataları nedeniyle araç çağırma kullanılamıyor
  • 2-bit tek token tepe değeri 7.05 tok/s’ye ulaşıyor ancak gerçek kullanım için uygun değil
  • 4-bit niceleme gerçek operasyon için uygun yapılandırma

Donanım ortamı

  • MacBook Pro (Apple M3 Max), 16 çekirdekli CPU (12P+4E), 40 çekirdekli GPU, 16 çekirdekli ANE
  • 48GB birleşik bellek, yaklaşık 400GB/s bant genişliği
  • SSD 1TB Apple Fabric, 17.5GB/s sıralı okuma hızı
  • macOS 26.2 (Darwin 25.2.0) ortamı

Model mimarisi

  • Toplam 60 transformer katmanı: 45 GatedDeltaNet (doğrusal attention) + 15 full attention
  • Her katmanda 512 uzman bulunuyor ve token başına K=4 uzman etkinleşiyor (1 paylaşılan uzman dahil)
  • Hidden dimension 4096

  • Temel teknolojiler

    • SSD Expert Streaming

      • Uzman ağırlıkları (4-bit için 209GB), gerektiğinde NVMe SSD’den paralel pread() ile yükleniyor
      • Her katmanda yalnızca etkinleşen 4 uzman yükleniyor (her biri yaklaşık 6.75MB)
      • OS page cache önbellekleme yönetimini otomatik yapıyor; ayrı bir cache gerekmiyor
      • Apple’ın “LLM in a Flash” makalesinden ilham alan yapı

    • FMA optimize dequant çekirdeği

      • (nibble * scale + bias) * x işlemi fma(nibble, scale*x, bias*x) biçiminde yeniden düzenlenmiş
      • scale*x ve bias*x önceden hesaplanarak GPU FMA birimlerinin tek komutla çalışması sağlanıyor
      • Basit uygulamaya kıyasla %12 hız artışı

    • Metal Compute Shaders

      • 4-bit/2-bit dequant matris-vektör çarpımı, SwiGLU aktivasyonu, RMS normalizasyonu, GPU attention (Q@Kᵀ, softmax, scores@V), RoPE, MoE birleştirme + residual + gate gibi işlemler elle yazılmış Metal çekirdekleriyle uygulanmış

    • Deferred GPU Expert Compute

      • CMD3 (uzman ileri geçişi) komutu asenkron gönderilerek GPU çalışırken CPU’nun bir sonraki katmanı hazırlaması sağlanıyor
      • Birleştirme + normalizasyon + residual işlemleri de GPU’da yapılarak doğrudan sonraki katmana aktarılıyor

    • Accelerate BLAS kullanımı

      • GatedDeltaNet’in döngüsel hesaplamalarında cblas_sscal, cblas_sgemv, cblas_sger kullanılıyor
      • Skaler koda göre %64 daha hızlı performans

    • Trust the OS

      • Özel cache kaldırılmış, uzman verisi önbelleklemesini OS page cache’i (LRU tabanlı, yaklaşık 35GB) üstleniyor
      • Kendi Metal LRU’su, malloc cache’i ve LZ4 sıkıştırma cache’inden daha yavaş değil, hepsinden daha hızlı
      • Doğal %71 cache hit oranı elde edilmiş

  • Birleşik bellek kısıtı

    • Apple Silicon’da SSD DMA ile GPU işlemleri aynı bellek denetleyicisini paylaşıyor
    • Paralel çalışmada GPU bant genişliği doygunluğa ulaşınca gecikme keskin biçimde artıyor
    • GPU → SSD → GPU sıralı pipeline, donanım için en uygun biçim

İlgili okumalar

1 yorum

 
GN⁺ 2026-03-23
Hacker News yorumları

  • Tüketici cihazlarında bile Qwen 3.5 397B çalıştırmanın başka bir yolu var
    Yaklaşık 2.5 BPW quant sürümü mevcut, bu yüzden 128GB bellekli cihazlarda da gayet mümkün
    Ben bunu M1 Ultra üzerinde yaklaşık 20 tok/s hızında, 256k context koruyarak sorunsuz çalıştırdım
    lm-evaluation-harness sonuçları yaklaşık olarak mmlu %87.86, gpqa diamond %82.32, gsm8k %86.43, ifeval %75.90 idi
    Daha ayrıntılı deneyimlerimi Hugging Face tartışma bağlantısı 1 ve bağlantı 2 içinde derledim
    Çevrimdışı inference için harika bir model

    • Bağlantıdaki yöntem de zaten 2-bit quantization kullanıyor
      Token başına uzman sayısını 10'dan 4'e düşürerek kaliteyi daha da azaltıyor
      Kısa prompt'larda idare eder ama uzun oturumlarda işe yaramaz
      JSON çıktısında "name" yerine \name\ ürettiği için tool calling de kararsız hale geliyor
    • Şu sıralar tok/s değeri ne kadar ediyor merak ediyorum
      Uzun context'lerde de iyi çalışıp çalışmadığını bilmek isterim
      Ayrıca uzun zaman sonra kullanıcı adını görmek güzel — Neovim'i yapan kişi olduğunu fark etmek gerçekten büyük başarı
      Ben de her gün kullanıyorum
    • Güç tüketimini merak ediyorum
      Belki CoconutBattery ile tahmin edilebilir
    • Bunun yalnızca tek bir M1 Ultra ile mi çalıştırıldığını merak ediyorum
    • Kişisel otomasyonda fazla kredi harcıyordum, bu bilgi çok işime yaradı

  • Ayrıntılara bakınca, 2-bit quantization ve uzman sayısını 10'dan 4'e düşürerek yaklaşık 5 tok/s elde etmiş gibi görünüyor
    İlginç bir proof of concept, ama orijinal 397B model kalitesinden oldukça uzak
    Bu tür aşırı optimizasyonlar modelin zeka kaybına yol açıyor
    JSON çıktısında "name" yerine \name\ üretme sorunu da var, bu yüzden pratik kullanım için uygun değil
    Bunun teknik olarak mümkün olduğunu gösteren bir deneme olduğunu kabul ediyorum, ama gerçekten kullanılabilir bir seviye değil
    Son zamanlarda bu tür AI tarafından yazılmış makaleler çok arttı, yorucu gelmeye başladı

    • JSON çıktı sorununu görünce, sampling'i yalnızca geçerli JSON token'larıyla sınırlamak yeterli olmaz mı diye düşündüm
      Ama gerçekte ticari LLM'lerin bile tool calling doğruluğunun düşük olduğunu duydum
      Muhtemelen uygulanması zor ya da yapısal olarak imkansız bir tarafı var

  • r/LocalLLaMA tartışmasında da bununla ilgili konuşmalar vardı

  • GitHub sayfasına göre basit mmap erişimi, sayfa düzeyindeki overhead nedeniyle darboğaza giriyor
    macOS'ta huge page ayarlamak ya da posix_fadvise ile prefetch yapmak bunu iyileştirebilir mi merak ediyorum

  • 2-bit quantization kaynaklı kalite düşüşü gerçekten ciddi bir sorun
    Gerçek işlerde, iyi ayarlanmış bir 30B 4-bit modelin 70B+ 2-bit'ten daha iyi olduğuna dair deneyimim var
    Uzman sayısını azaltınca fiilen başka bir modele dönüşüyor
    Yine de tüketici donanımının sınırlarını zorlaması açısından ilginç

  • “Laptopta çalıştırmak” başlığının her seferinde 3000 dolarlık bir MacBook anlamına gelmesi yorucu
    Sıkıştırma tekniği etkileyici, ama sıradan kullanıcı için gerçekçi bir seçenek değil

    • Ben oldukça iyi bir laptop kullanıyorum (Mac değil), o yüzden bu tür denemeler ilgimi çekiyor
      Ama başlığı görünce bunun herhangi bir laptopta çalışmasını beklemiyorum
      Aşırı alaycılık yerine bu tür deneylerden keyif alıyorum
    • İkinci el M1 Max 64GB modeller 2000 doların altında bulunabiliyor
      Video düzenleme gibi işler için zaten böyle güçlü MacBook'lara sahip olan çok kişi var
      Ayrı bir ekipman almadan mevcut laptopla deney yapabilmek asıl avantajı
    • Aslında 3000~4000 dolarlık Strix Halo laptoplarla da mümkün
    • Başlık “,on a laptop!” gibi olsaydı daha doğru olurdu
    • Ben 3000 dolarlık iki laptopluk bir cluster'la (128GB zbook) tam modeli çalıştırdım
      Yaklaşık 20 tok/s hız alıyordum ve bunun bireyler için de yeterince erişilebilir olduğunu düşünüyorum
      İş amaçlı kullanım için de yatırım yapmaya değerdi

  • “No Python. No frameworks. Just C, Objective-C, and hand-tuned Metal shaders.”
    Bu cümleyi görünce token'ın nereden geldiğini hemen anladım

  • “Hand-written Metal kernels” deniyor; acaba bunu GPT kendi mi yazdı? 😉

    • Nitekim yazar, bunun açıkça AI tarafından yazılmış kod olduğunu belirtiyor

  • Gerçekten etkileyici bir sonuç
    Linux'ta da SSD yerine sistem belleği tabanlı erişim ile benzer bir yaklaşım mümkün olur mu merak ediyorum
    Ya da ağırlıkları ROM benzeri bir biçimde saklama fikri de ilginç

    • Aynı yaklaşım Linux'ta da mümkün
      Sadece bu proje Metal kullandığı için macOS'a özel
    • Çoğu engine (ör. llama.cpp, vllm, sglang) bu özelliği destekliyor
      Ama MoE modelleri hâlâ ciddi biçimde bandwidth kısıtlı
    • Uzmanları sistem belleğine yükleme özelliği zaten çoğu yerel AI framework'ünde var
      Ancak decode aşamasında GPU yerine CPU aktarım overhead'i daha yüksek olduğu için kazanç sınırlı
      GPU'yu yalnızca paylaşılan bölümleri hızlandırmak için kullanmak daha verimli
    • GPU belleğine sığmayan bazı katmanları CPU'da çalıştırmak da mümkün
      Ama model sistem RAM'ine ya da diske taşınca performans sert biçimde düşüyor
    • Bu yaklaşım işe yararsa, iki adet 3090 ve yeterli RAM ile bile kişisel laboratuvar ölçeğinde büyük inference mümkün olabilir gibi görünüyor

  • SSD'nin darboğaz olduğuna dair bir açıklama vardı, ama yazar 15GB/s elde ettiğini söylüyor
    Oysa benim bildiğim kadarıyla azami bant genişliği 8GB/s civarındaydı. Ben neyi kaçırıyorum?

    • Bu tür yapılarda IO oldukça burst karakterli
      Router sonucu çıkınca uzmanlar SSD'den yükleniyor ve o anda SSD doyuma ulaşıyor
      Ortalama IO yaklaşık 2970MB/s, yani SSD sınırının epey altında
      Bazı tensor'ları async read ile paralelleştirmek daha iyi sonuç verebilir
      Ben Linux'ta io_uring ile denediğimde okumaların yaklaşık %20'si hesaplama sürerken paralel tamamlanıyordu
    • PCIe 5 neslinde bant genişliği iki katına çıktığı için yeni SSD'ler daha hızlı
    • MacBook Pro M5 Pro/Max modellerindeki SSD hızı o seviyede