Hypura – Apple Silicon için depolama katmanı farkındalıklı LLM çıkarım zamanlayıcısı

(github.com/t8)

3 puan yazan GN⁺ 2026-03-25 | 1 yorum | WhatsApp'ta paylaş

GPU·RAM·NVMe arasında tensor yerleşimini optimize ederek büyük dil modellerini çalıştıran depolama katmanı farkındalıklı bir çıkarım zamanlayıcısı
32GB Mac Mini üzerinde Mixtral 8x7B(31GB) modelini 2.2 tok/s, Llama 70B(40GB) modelini 0.3 tok/s hızında çalıştırabiliyor
Erişim desenleri ile donanım bant genişliğini analiz ederek fiziksel belleği aşan modelleri de kararlı biçimde çalıştırıyor; mevcut llama.cpp'nin OOM nedeniyle başarısız olduğu modelleri bile işleyebiliyor
MoE yapısındaki uzman yönlendirmesi, nöron önbelleği, prefetch sayesinde I/O'yu %75'e kadar azaltıyor ve %99.5 önbellek isabet oranına ulaşıyor
Model boyutu ve donanıma göre Full-resident, Expert-streaming, Dense FFN-streaming modlarını otomatik seçerek en iyi performansı koruyor
Ollama uyumlu HTTP API sunuyor; OpenClaw gibi araçlarla entegre olabiliyor ve SSD'yi salt okunur kullandığı için ömür kaybı olmadan NVMe tabanlı çıkarımı destekliyor

Genel bakış

Hypura, Apple Silicon ortamında çalışan, GPU·RAM·NVMe arasında tensor yerleşimini optimize eden bir depolama katmanı farkındalıklı LLM çıkarım zamanlayıcısı
Erişim desenleri, bant genişliği maliyetleri ve donanım performansına göre tensorleri dağıtarak fiziksel belleği aşan büyük modellerin bile kararlı şekilde çalışmasını sağlıyor
32GB Mac Mini'de Mixtral 8x7B(31GB) modelini 2.2 tok/s, Llama 70B(40GB) modelini 0.3 tok/s hızında çalıştırabiliyor
Aynı ortamda llama.cpp ise OOM (Out of Memory) nedeniyle çalışmıyor

Sorunun arka planı

Tüketici sınıfı Mac'ler hızlı birleşik bellek ve NVMe depolama sunuyor, ancak bellek kapasitesi sınırlı
Örneğin 32GB M1 Max, 40GB'lık bir modeli doğrudan yükleyemediği için aşırı swap ve OOM sonlanması yaşanıyor
Hypura, model yapısını analiz edip katman bazında en uygun yerleşimi yaparak bu sorunu çözüyor

Model yapısına dayalı katman yerleşimi

Norms ve Embeddings: Küçükler ama her token'da erişildikleri için GPU'da sabit tutuluyorlar
MoE Expert Routing: Seyreklikten yararlanıyor; token başına 8 uzmandan yalnızca 2'si etkinleşiyor
- Router yakalama ile etkin uzmanlar belirleniyor, ardından yalnızca gerekli kısımlar NVMe'den yükleniyor
- I/O %75 azalıyor, nöron önbelleğinde %99.5 isabet oranı elde ediliyor
- Ortak etkinleşme takibi (co-activation tracking) ile sıradaki etkin uzmanlar tahmin edilip önceden prefetch yapılıyor
Dense FFN Weights: Model boyutunun yaklaşık %60'ını oluşturuyor
- NVMe'den dinamik havuz tamponu üzerinden stream ediliyor
- Prefetch derinliği (prefetch lookahead depth) kullanılabilir belleğe göre otomatik ayarlanıyor
Sonuç olarak, klasik mmap yaklaşımıyla çöken modeller bile çalıştırılabiliyor; belleğe sığan modeller ise Metal GPU hızında ek yük olmadan çalışıyor

Çalışma şekli

Hypura GGUF dosyalarını okuyor ve GPU·RAM·NVMe bant genişliğini profilliyor
Her tensor şu üç katmandan birine yerleştiriliyor
- GPU(Metal): Attention, Norm, Embedding katmanları
- RAM: GPU'ya yüklenemeyen taşma katmanları
- NVMe: Kalan katmanlar; F_NOCACHE + pread ile doğrudan I/O yapılıyor
Model boyutu ve donanıma göre çıkarım modu otomatik seçiliyor
- Full-resident: Tüm model GPU+RAM'e yükleniyor, NVMe I/O yok
- Expert-streaming: MoE modeller için; uzman olmayan tensorler GPU'da kalıyor, uzman tensorler NVMe'den stream ediliyor
- Dense FFN-streaming: MoE olmayan büyük modeller için; Attention+Norm GPU'da, FFN ise NVMe'den stream ediliyor
Havuz tampon boyutu, prefetch derinliği ve bellek bütçesi donanım profiline göre otomatik hesaplanıyor

Performans

Test ortamı: M1 Max, 32GB birleşik bellek, NVMe 5.1GB/s
Başlıca benchmark sonuçları
- Qwen 2.5 14B Q4_K_M (8.4GB): Tam GPU yüklemesi, 21 tok/s
- Mixtral 8x7B Q5_K_M (30.9GB): Expert-streaming modu, 2.2 tok/s, %99.5 önbellek isabet oranı
- Llama 3.3 70B Q4_K_M (39.6GB): Dense FFN-streaming modu, 0.3 tok/s, 24 yuvalı havuz, 7 katman prefetch
Belleğe sığan modellerde ek yük 0, sınırı aşan modellerde ise Hypura sayesinde çalıştırılabilirlik korunuyor

Kurulum ve çalıştırma

Rust 1.75+ ve CMake gerekli

Kurulum adımları

git clone --recurse-submodules https://github.com/hypura/hypura.git  
cd hypura  
cargo build --release

Çalıştırma örnekleri

hypura profile  
hypura run ./model.gguf --prompt "Hello, world"  
hypura run ./model.gguf --interactive  
hypura bench ./model.gguf  
hypura inspect ./model.gguf

Doğrulanmamış modeller için --max-tokens 10 ile test edilmesi öneriliyor

Ollama uyumlu sunucu

Hypura, Ollama uyumlu HTTP API sunuyor ve OpenClaw gibi Ollama tabanlı araçlarla tam uyumlu

hypura serve ./model.gguf  

Endpoint: http://127.0.0.1:8080  

API: /api/generate, /api/chat, /api/tags

Başlıca endpoint'ler

Endpoint	İşlev
`GET /`	Durum kontrolü
`GET /api/tags`	Yüklü model listesi
`GET /api/version`	Sunucu sürümü
`POST /api/show`	Model metadata'sı
`POST /api/generate`	Metin üretimi
`POST /api/chat`	Etkileşimli üretim

OpenClaw entegrasyonu için ~/.openclaw/openclaw.json içinde Ollama base URL'i Hypura olarak ayarlanıyor

Sunucu seçenekleri

hypura serve  [OPTIONS]  
--host    varsayılan 127.0.0.1  
--port    varsayılan 8080  
--context    varsayılan 4096

Mimari

Cargo workspace yapısında ve iki crate'ten oluşuyor
- hypura: Ana binary ve kütüphane
- hypura-sys: llama.cpp FFI binding'leri (CMake build)

Ana modüller

Modül	Rol
`scheduler/placement.rs`	GPU/RAM/NVMe arasında tensor yerleşimini optimize etme
`compute/inference.rs`	Çıkarım motoru ve sunucu için yükleme/üretim işlevleri
`compute/nvme_backend.rs`	NVMe streaming, nöron önbelleği, değerlendirme callback'leri
`server/routes.rs`	Ollama uyumlu HTTP handler'ları
`profiler/`	Donanım profilleme
`cli/bench.rs`	Benchmark aracı
`model/tensor_role.rs`	Tensor rolü sınıflandırması

SSS

SSD ömrüyle ilgili bir sorun yok
- Hypura SSD'den yalnızca okuma yapıyor, yazma yapmıyor
- NVMe I/O, pread() + F_NOCACHE ile salt okunur biçimde gerçekleştiriliyor
- SSD yalnızca soğuk depolama görevi görüyor; hesaplama RAM/GPU üzerinde yapılıyor
- Yazma işlemleri benchmark sonuç JSON'u, istatistik dosyaları vb. gibi KB düzeyinde ihmal edilebilir miktarlarda

Güvenlik yönergeleri

Model RAM sınırını (–4GB pay bırakılarak) aşıyorsa bench --baseline engelleniyor
Doğrulanmamış modeller --max-tokens 10 ile test edilmeli
Test modelleri ./test-models/ dizininde saklanıyor

Lisans

MIT License

Etik bildirim

Depodaki kodun tamamı yazar tarafından doğrudan yazılmış değil
Proje, LLM kullanılarak yapılan komut odaklı kod üretimi deneyi kapsamında oluşturuldu
NVMe tabanlı çıkarımın kullanım olanaklarını araştırmak için hazırlanmış bir proje

1 yorum

GN⁺ 2026-03-25

Hacker News görüşleri

Bakımcıya bir öneride bulunmak isterim. Mevcut karşılaştırma tablosunda Qwen 2.5 14B, Mixtral 8x7B, Llama 3.3 70B gibi eski modeller yer alıyor
Son dönemde Apple donanımında Qwen 3.5 MoE modelinin şaşırtıcı performans gösterdiğine dair çok sayıda rapor var
Simon Willison'ın yazısına bakılması faydalı olabilir
Mümkünse Kimi K2.5 (1T parametre) modeli de tabloya eklenirse iyi olur
İlgili tweet'ler: seikixtc, danpacary
- Paylaştığın için teşekkürler. İstersen Hypura ile doğrudan benchmark çalıştır; sonuçları istatistiklere ekleyebilirim. Olmazsa bunu todo listeme eklerim
- Simon, konu biraz farklı ama siten kısa süreliğine çökmüştü
  Heroku ile ilgili bir hata mesajı çıkıyordu, ama şimdi yeniden normal çalışıyor
  Şu yazıya bakmak için girmiştim, bu arada litellm ile ilgili yazını da çoktan yazmışsın. Keyifle okudum
- Kimi örneğinde token hızı (metric) bilgisinin eksik olması üzücü
Yerel işlerde saniyede 1 token'dan düşük hız bile arka plan işi ise gayet kullanılabilir
“Hemen bitiyor” ile “bir gecede tamamlanıyor” arasındaki fark hâlâ anlamlı bir performans sıçraması
Pratikte önemli olan, okuma deseninin ne kadar sıralı (sequential) olduğudur
NVMe sıralı okumada 5–7GB/s verirken, rastgele okumada 500MB/s seviyesine düşüyor
1T model için fp16 temelinde tek bir forward pass'te 2TB veri stream edilmesi gerektiğinden, teorik olarak token başına 300 saniyeden fazla sürer
Etkileşimli kullanım için uygun değil ama batch inference için potansiyeli var
- M1 Max'te 4K rastgele okuma (QD=1) yaklaşık 65MB/s seviyesinde
- Katılıyorum. Bu, pratik kullanımdan çok POC (Proof of Concept) gibi
  Ama küçük MoE modellerinde saniyede birkaç token üretilebildiği için gerçekten kullanılabilir olabilir
- MoE modellerinin özü seyrek aktivasyon (sparse activation)
  Tüm 2TB okunmuyor, yalnızca uzman katmanlarının bir kısmına erişiliyor
  Her katman birkaç MiB ölçeğinde olduğu için NVMe erişim verimliliği de o kadar kötü değil
“1T parametreli model” ifadesinin nereden geldiğini merak ettim. Repoda yalnızca 70B ve altı modeller görünüyor
- Bu, olasılık düzeyinde söylenmişti. Ama performans çok yavaş olduğu için özel uzun süreli işler dışında pratik değil
  Gerçekçi modeller, daha küçük ama saniyede birkaç token üretebilen MoE ailesi
- Başlık biraz abartılı duruyor. Sonuçta önemli olan hız, ama buna dair bilgi yok
MoE'nin olayı, seyrek aktivasyon sayesinde tüm 2TB'nin okunmaması
Ama erişim deseni rastgeleleştiği için NVMe açısından en kötü koşul ortaya çıkıyor
Ajan çıkarımı gibi gecikme (latency) kritik işlerde kilit nokta bu
Intel Optane mezarında ters dönüyor olmalı
- Memristor da 10 yıl önce yakında ticarileşecek gibi görünüyordu, şimdi ise tamamen ortadan kayboldu
- Hâlâ sakladığım 4 yeni Optane var. Şaka gibi ama gerçekten var
  Ama pratikte NVMe'den daha hızlı değiller. Paralel okuma/yazma destekleyen yazılımlarda fark neredeyse yok
- Intel'in iyi bir şey yapıp sonra yarı yolda bırakmasına artık alıştık
  Yine de 4 tanesini RAID 0 ile birleştirirsen PCIe 16x bant genişliğini doldurabilir gibi
- pmem'den bahsedilmiş
Tüketici sınıfı Mac donanımı hızlı birleşik bellek ve NVMe sunuyor ama kapasite sınırlı
32GB M1 Max'e 40GB'lık bir model yüklersen swap kontrolden çıkıyor ve sonunda panic durumuna düşüyor
macOS'ta Linux tarzı bir OOM killer yok; sadece swap alanı tükeniyor
“Mümkün olduğunca çok bellek” bulundurmak önemli, ama daha büyük değişken bant genişliği (bandwidth)
M4 Pro 273GB/s, M4 Max 546GB/s, M4 Ultra 819GB/s
Model belleğe sığdıktan sonra token hızını belirleyen şey bant genişliği oluyor
Hypura açısından M4 Max sweet spot gibi görünüyor. 64GB ile 70B modeli (Q4) rahatça çalıştırabiliyor ve Pro'ya kıyasla 2 kat hızda üretim yapabiliyor
Bu proje aslında akıllı swap belleği gibi çalışıyor
NVMe'yi aşırı kullanmamayı hedeflemesi ilginç
Ama NVMe gerçekten yoğun kullanılırsa ömür kısalması endişesi doğabilir
- “NVMe'yi yormak” ifadesi bana yabancı geliyor
  SSD'lerde yazma sayısı arttıkça hücre ömrü azalır ama okuma yüküyle denetleyicinin zarar görmesi neredeyse hiç görülmez
  Eğer oluyorsa sistemde başka bir sorun vardır
Bu projeyi önceki deneylerle, bir başka denemeyle karşılaştırmak iyi olurdu
Bunun mmap tabanlı olduğu ve bu yüzden overhead'in büyük olduğuna dair raporlar vardı
- İlgili kod LLM tarafından yazılmış, bu yüzden güvenilirliği düşük
- Ayrıca bu uygulama agresif quantization kullanmadığı için kalite kaybı daha az