- Mengoptimalkan penempatan tensor antara GPU·RAM·NVMe untuk menjalankan model bahasa besar dengan scheduler inferensi sadar hierarki penyimpanan
- Di Mac Mini 32GB, mampu menjalankan model Mixtral 8x7B (31GB) pada 2.2 tok/s dan model Llama 70B (40GB) pada 0.3 tok/s
- Menganalisis pola akses dan bandwidth hardware untuk menjalankan model yang melebihi memori fisik secara stabil, termasuk model yang sebelumnya gagal di llama.cpp karena OOM
- Melalui routing pakar pada arsitektur MoE, cache neuron, dan prefetch, mengurangi I/O hingga 75% dan mencapai cache hit rate 99.5%
- Secara otomatis memilih mode Full-resident, Expert-streaming, Dense FFN-streaming sesuai ukuran model dan hardware agar performa tetap optimal
- Menyediakan HTTP API kompatibel Ollama untuk integrasi dengan OpenClaw dan lainnya, serta mendukung inferensi berbasis NVMe tanpa penurunan umur SSD karena SSD hanya dipakai baca-saja
Ikhtisar
- Hypura adalah scheduler inferensi LLM sadar hierarki penyimpanan di lingkungan Apple Silicon, alat yang melakukan optimasi penempatan tensor antara GPU·RAM·NVMe
- Dengan mendistribusikan penempatan tensor berdasarkan pola akses, biaya bandwidth, dan performa hardware, Hypura memungkinkan eksekusi stabil model besar yang melebihi memori fisik
- Di Mac Mini 32GB, mampu menjalankan model Mixtral 8x7B (31GB) pada 2.2 tok/s dan model Llama 70B (40GB) pada 0.3 tok/s
- Pada lingkungan yang sama, llama.cpp tidak dapat berjalan karena OOM (Out of Memory)
Latar belakang masalah
- Mac konsumen memiliki unified memory cepat dan penyimpanan NVMe, tetapi kapasitas memorinya terbatas
- Sebagai contoh, M1 Max 32GB tidak dapat memuat model 40GB secara langsung sehingga menyebabkan swap berlebihan dan penghentian karena OOM
- Hypura menyelesaikan masalah ini dengan menganalisis struktur model dan melakukan penempatan optimal per lapisan
Penempatan hierarkis berbasis struktur model
- Norm dan Embedding: kecil tetapi diakses pada setiap token, sehingga dipasang tetap di GPU
- Routing pakar MoE: memanfaatkan sparsity, hanya 2 dari 8 pakar yang aktif per token
- Dengan intersepsi router, pakar aktif diidentifikasi lalu hanya bagian yang diperlukan dimuat dari NVMe
- I/O berkurang 75%, dengan cache neuron mencapai hit rate 99.5%
- Melalui co-activation tracking, sistem memprediksi pakar aktif berikutnya dan melakukan prefetch terlebih dahulu
- Bobot Dense FFN: mencakup sekitar 60% ukuran model
- Dialirkan dari NVMe melalui dynamic pool buffer
- Prefetch lookahead depth disesuaikan otomatis menurut memori yang tersedia
- Hasilnya, model yang sebelumnya crash dengan pendekatan mmap kini dapat dijalankan, sementara model yang muat di memori tetap berjalan pada kecepatan Metal GPU tanpa overhead
Cara kerja
- Hypura membaca file GGUF dan memprofilkan bandwidth GPU·RAM·NVMe
- Setiap tensor ditempatkan ke salah satu dari tiga lapisan berikut
- GPU (Metal): lapisan Attention, Norm, Embedding
- RAM: lapisan overflow yang tidak bisa dimuat ke GPU
- NVMe: lapisan sisanya, dengan I/O langsung menggunakan
F_NOCACHE + pread
- Berdasarkan ukuran model dan hardware, sistem otomatis memilih mode inferensi
- Full-resident: seluruh model dimuat ke GPU+RAM, tanpa I/O NVMe
- Expert-streaming: untuk model MoE, hanya tensor non-pakar yang menetap di GPU, sedangkan tensor pakar di-stream dari NVMe
- Dense FFN-streaming: untuk model besar non-MoE, Attention+Norm berada di GPU, FFN di-stream dari NVMe
- Ukuran pool buffer, kedalaman prefetch, dan anggaran memori dihitung otomatis berdasarkan profil hardware
Performa
- Lingkungan pengujian: M1 Max, unified memory 32GB, NVMe 5.1GB/s
- Hasil benchmark utama
- Qwen 2.5 14B Q4_K_M (8.4GB): dimuat penuh di GPU, 21 tok/s
- Mixtral 8x7B Q5_K_M (30.9GB): mode Expert-streaming, 2.2 tok/s, cache hit rate 99.5%
- Llama 3.3 70B Q4_K_M (39.6GB): mode Dense FFN-streaming, 0.3 tok/s, pool 24 slot, prefetch 7 lapisan
- Model yang muat di memori memiliki overhead 0, sedangkan model yang melebihi kapasitas tetap bisa dijalankan berkat Hypura
Instalasi dan menjalankan
- Membutuhkan Rust 1.75+ dan CMake
- Prosedur instalasi
git clone --recurse-submodules https://github.com/hypura/hypura.git
cd hypura
cargo build --release
- Contoh menjalankan
hypura profile
hypura run ./model.gguf --prompt "Hello, world"
hypura run ./model.gguf --interactive
hypura bench ./model.gguf
hypura inspect ./model.gguf
- Untuk model yang belum tervalidasi, disarankan menguji dengan
--max-tokens 10
Server kompatibel Ollama
- Hypura menyediakan HTTP API kompatibel Ollama sehingga sepenuhnya kompatibel dengan alat berbasis Ollama seperti OpenClaw
hypura serve ./model.gguf
Endpoint: http://127.0.0.1:8080
API: /api/generate, /api/chat, /api/tags
- Endpoint utama
| Endpoint |
Fungsi |
GET / |
Pemeriksaan status |
GET /api/tags |
Daftar model yang dimuat |
GET /api/version |
Versi server |
POST /api/show |
Metadata model |
POST /api/generate |
Pembuatan teks |
POST /api/chat |
Pembuatan percakapan |
- Untuk integrasi OpenClaw, atur Ollama base URL ke Hypura di
~/.openclaw/openclaw.json
- Opsi server
hypura serve [OPTIONS]
--host default 127.0.0.1
--port default 8080
--context default 4096
Arsitektur
- Menggunakan struktur Cargo workspace, terdiri dari dua crate
hypura: biner dan library utamahypura-sys: binding FFI llama.cpp (build CMake)
- Modul utama
| Modul |
Peran |
scheduler/placement.rs |
Optimasi penempatan tensor antara GPU/RAM/NVMe |
compute/inference.rs |
Mesin inferensi dan fungsi load/generate untuk server |
compute/nvme_backend.rs |
NVMe streaming, cache neuron, callback evaluasi |
server/routes.rs |
Handler HTTP kompatibel Ollama |
profiler/ |
Profiling hardware |
cli/bench.rs |
Alat benchmark |
model/tensor_role.rs |
Klasifikasi peran tensor |
FAQ
-
Tidak ada masalah umur SSD
- Hypura hanya melakukan pembacaan dari SSD, tanpa penulisan
- I/O NVMe dilakukan baca-saja dengan
pread() + F_NOCACHE
- SSD hanya berperan sebagai cold storage, sedangkan komputasi dilakukan di RAM/GPU
- Penulisan yang terjadi hanya pada tingkat KB yang sangat kecil, seperti JSON hasil benchmark dan file statistik
Panduan keamanan
bench --baseline diblokir jika model melebihi batas RAM (dengan sisa margin 4GB)- Untuk model yang belum tervalidasi, uji dengan
--max-tokens 10
- Model pengujian disimpan di direktori
./test-models/
Lisensi
Pemberitahuan etis
- Kode di repositori ini tidak ditulis langsung oleh penulis
- Dibuat sebagai eksperimen pembuatan kode berbasis instruksi dengan memanfaatkan LLM
- Ini adalah proyek untuk mengeksplorasi kemungkinan pemanfaatan inferensi berbasis NVMe
1 komentar
Komentar Hacker News
Ingin mengusulkan kepada maintainer. Tabel perbandingan saat ini memuat model lama seperti Qwen 2.5 14B, Mixtral 8x7B, dan Llama 3.3 70B
Belakangan ini ada banyak laporan bahwa model Qwen 3.5 MoE menunjukkan performa luar biasa di hardware Apple
Silakan rujuk tulisan Simon Willison
Jika memungkinkan, akan bagus juga bila model Kimi K2.5 (1T parameter) ditambahkan ke tabel
Tweet terkait: seikixtc, danpacary
Muncul pesan error terkait Heroku, tetapi sekarang sudah normal lagi
Saya masuk untuk melihat artikel ini, dan ternyata Anda juga sudah menulis artikel tentang litellm. Menarik untuk dibaca
Untuk pekerjaan lokal, bahkan kecepatan di bawah 1 token per detik pun masih cukup berguna bila itu adalah pekerjaan latar belakang
Perbedaan antara “selesai segera” dan “selesai semalaman” tetap merupakan loncatan performa yang bermakna
Dalam praktiknya, yang penting adalah seberapa sekuensial (sequential) pola pembacaannya
NVMe bisa mencapai 5–7GB/s untuk pembacaan sekuensial, tetapi turun ke sekitar 500MB/s untuk pembacaan acak
Untuk model 1T, pada fp16 perlu melakukan streaming 2TB untuk satu forward pass, sehingga secara teori butuh lebih dari 300 detik per token
Ini tidak cocok untuk penggunaan interaktif, tetapi masih punya potensi untuk batch inference
Namun pada model MoE kecil, masih bisa menghasilkan beberapa token per detik sehingga tetap layak dipakai
Tidak semua 2TB dibaca; hanya sebagian layer expert yang diakses
Karena tiap layer berukuran dalam satuan MiB, efisiensi akses NVMe juga tidak terlalu buruk
Saya sempat bertanya-tanya dari mana asal istilah “model 1T parameter”. Di repo hanya terlihat model hingga 70B
Model yang realistis adalah yang lebih kecil tetapi bisa menghasilkan beberapa token per detik, yaitu keluarga MoE
Poin MoE adalah bahwa karena aktivasi jarang, ia tidak membaca seluruh 2TB
Namun pola aksesnya menjadi acak, yang merupakan kondisi terburuk bagi NVMe
Untuk pekerjaan seperti agentic inference, di mana latensi (latency) penting, bagian ini menjadi kunci
Rasanya seperti Intel Optane sedang berputar di kuburannya
Namun dalam praktiknya tidak lebih cepat daripada NVMe. Pada software yang mendukung baca/tulis paralel, perbedaannya hampir tidak ada
Meski begitu, kalau 4 buah di-RAID 0, sepertinya bisa memenuhi bandwidth PCIe 16x
Hardware Mac konsumen punya unified memory dan NVMe yang cepat, tetapi kapasitasnya terbatas
Jika memuat model 40GB pada M1 Max 32GB, swap akan melonjak liar dan akhirnya masuk kondisi panic
macOS tidak punya OOM killer seperti Linux; yang terjadi hanya kehabisan ruang swap
Mendapatkan “memori sebanyak mungkin” memang penting, tetapi bandwidth adalah variabel yang lebih besar
M4 Pro memiliki 273GB/s, M4 Max 546GB/s, dan M4 Ultra 819GB/s
Setelah model masuk ke memori, bandwidth menentukan kecepatan token
Menurut Hypura, M4 Max adalah sweet spot. Dengan 64GB, model 70B (Q4) bisa dijalankan dengan nyaman, dan generasinya bisa 2x lebih cepat daripada Pro
Proyek ini pada dasarnya bekerja seperti smart swap memory
Menarik karena ia mengatur agar NVMe tidak dipakai secara berlebihan
Namun jika NVMe benar-benar dibebani berat, ada kekhawatiran soal penurunan umur pakai
Umur sel SSD memang berkurang karena jumlah penulisan, tetapi sangat jarang controller rusak hanya karena beban baca
Kalau itu terjadi, berarti ada masalah lain pada sistem
Akan bagus jika proyek ini dibandingkan dengan eksperimen sebelumnya, upaya lain
Yang kali ini berbasis mmap, dan ada laporan bahwa overhead-nya besar