Colibri: Menjalankan Model 744B di 25 GB RAM dengan C Murni

Di bulan Juli 2026, satu repositori bernama JustVugg/colibri muncul di GitHub dengan klaim yang sulit dipercaya: model 744 miliar parameter bisa dijalankan di mesin ber-RAM 25 GB, tanpa GPU, dalam bahasa C murni tanpa dependensi runtime apa pun. Enam minggu kemudian repositori itu sudah memuncaki Hacker News, dan per 6 Oktober 2026 angkanya berada di 39.801 bintang dengan 4.376 fork — salah satu pertumbuhan tercepat yang pernah dicatat repositori inference. Artikel ini membongkar apa yang sebenarnya terjadi di dalamnya: trik sparse-nya, arsitektur hierarki memorinya, angka benchmark yang dilaporkan apa adanya, dan kenapa komunitas bereaksi sekeras itu.

Apa Itu Colibri

Colibri (bahasa Italia: kolibri) adalah mesin inferensi berbinari tunggal yang ditulis dalam C murni. Tidak ada Python di runtime, tidak ada CUDA wajib, tidak ada BLAS, dan — yang penting — tidak ada konversi format. Mesin ini membaca checkpoint model secara native, jadi tidak perlu konversi ke GGUF atau format perantara lain. Satu engine yang sama menjalankan sembilan keluarga model, dari OLMoE (7B) hingga Kimi K3 (2,8 triliun parameter), di balik tiga perintah yang sama: coli chat untuk chat interaktif, coli serve untuk endpoint API kompatibel OpenAI, dan coli web untuk dashboard.

Lisensinya Apache-2.0, dan release terakhirnya (v1.12.1, 24 September 2026) menyertakan binari pra-bangun untuk Linux x86_64, macOS arm64, dan Windows x86_64. Kontribusi terverifikasi di repo didominasi satu orang — JustVugg dengan 1.418 kontribusi — dengan segelintir kontributor komunitas.

Trik Intinya: Model MoE Tidak Perlu Muat, Ia Perlu Ditempatkan

Model mixture-of-experts seperti GLM-5.2 besar di atas kertas tapi jarang aktif utuh. Dari 744 miliar parameter, hanya sekitar 40 miliar yang benar-benar dijalankan untuk setiap token — rasio sparsity sekitar 13:1. Lebih jauh, dari 40 miliar itu, hanya sekitar 11 GB yang berubah dari satu token ke token berikutnya, yaitu bobot routed experts.

Inilah titik balik berpikir yang dilakukan Colibri: alih-alih menuntut seluruh model muat di memori cepat, engine ini memisahkan model menjadi dua bagian dan menempatinya di lapisan memori yang berbeda.

• Bagian dense — attention, shared experts, embeddings (±17B parameter) — dipertahankan tetap di RAM dalam quantisasi int4, sekitar 9,9 GB.
• 19.456 routed experts (±19 MB masing-masing, total ±370 GB) tinggal di NVMe, dan di-stream ke memori hanya ketika router memintanya untuk token yang sedang diproses.

Agar aliran dari disk tidak menjadi kekacauan, Colibri membangun tiga mekanisme di atasnya: cache LRU per lapisan, learned pinned hot-store yang mempelajari expert mana yang paling sering dipakai di beban kerja Anda dan menguncinya di memori (state-nya dipersist, jadi mesin literal makin cepat seiring pemakaian), dan benang lookahead yang mem-prefetch expert selangkah lebih awal — dimungkinkan karena routing model terbukti ±71,6% bisa diprediksi satu lapisan sebelumnya.

Hasilnya: mesin butuh 25 GB RAM + 370 GB NVMe, bukan 744 GB RAM. Model yang secara teori tidak akan pernah muat, jadi muat.

Angkanya, Dilaporkan Apa Adanya

Yang membuat repositori ini dihormati bukan klaimnya, melainkan transparansi benchmark-nya — termasuk ujungnya yang memalukan. Dengan engine dan kontainer int4 yang sama, yang berubah hanyalah di mana expert-nya tinggal:

• 25 GB, NVMe konsumen, cache dingin: 0,05–0,1 token/detik. Satu balasan 100 token bisa memakan 17–33 menit. Angka ini memang proof of concept, bukan pengalaman chat.
• Desktop CPU 128 GB, cache hangat: sekitar 1,8 token/detik.
• Apple M5 Max 128 GB: sekitar 2 token/detik.
• Workstation 6× RTX 5090, seluruh expert di VRAM: 5,8–6,8 token/detik, dengan time-to-first-token sekitar 13 detik.

Botleneck-nya bukan bandwidth sekuensial melainkan random-read NVMe, dan cache hit rate menentukan lebih banyak daripada kecepatan disk mentah: menaikkan drive dari 1,5 GB/s ke 8,8 GB/s hanya memberi 2,9× kecepatan, bukan 5,8× yang teoritis. RAM lebih besar berarti lebih sedikit baca disk — itulah mengapa konfigurasi 128 GB berkali-kali lipat lebih cepat daripada konfigurasi minimum 25 GB. README proyek ini bahkan mempublikasikan hasil negatifnya: spekulasi multi-token-prediction terukur merugi 32% pada hit-rate expert 85%, dan drafter untuk DeepSeek V4 di-ship dalam keadaan nonaktif karena biaya replays-nya lebih besar dari yang dihemat.

Mengapa Hype-nya Lebih dari Sekadar Kecepatan

Jika colibri hanya soal tok/s, reaksinya tidak akan sebesar ini. Ada empat hal lain yang memicu euforia komunitas:

• Kelugasan teknis. Inti engine-nya sekitar 14.700 baris C dalam satu file, tanpa dependensi. Bagi banyak pengembang, semangatnya mengingatkan pada masa awal llama.cpp — satu orang membuktikan sesuatu mungkin sebelum ekosistem menyusul.
• Koreksi yang terjamin. Output divalidasi token-per-token terhadap oracle transformers. Penempatan expert mengubah kecepatan, tidak mengubah presisi maupun semantik router. Ada garansi bahwa "menjalankan model besar di mesin kecil" bukan model yang diam-diam dipangkas.
• Dashboard expert atlas. Mode web memvisualisasikan seluruh 19.456 expert sebagai korpus hidup — menyala satu per satu saat routing berlangsung, dan sudah dikarakterisasi per kluster afinitas (Python, SQL, puisi, bahasa Mandarin). Ini cara belajar arsitektur MoE yang sulit ditemukan di tempat lain.
• README yang anti-hype. Tabel hipotesis terbuka, eksperimen yang belum punya A/B terkendali, dan kegagalan yang dicatat apa adanya — disiplin yang jarang ditemukan di repositori berusia dua bulan dengan puluhan ribu bintang.

Dalam posting Show HN-nya di Juli 2026 ("Getting GLM 5.2 running on my slow computer"), diskusi merapat ke hampir 1.000 poin dengan ratusan komentar, dan komentar teratas merangkumnya dalam satu kalimat: ini hacking jenis yang baik.

Cara Mencobanya

Persyaratan dasar: gcc/clang dengan OpenMP, CPU dengan AVX2, RAM minimal 16 GB (25 GB+ direkomendasikan), dan ruang NVMe yang cukup untuk model yang dipilih. Python hanya dibutuhkan untuk launcher dan konverter, bukan untuk runtime.

• Langkah masuk yang masuk akal: Qwen3.6 — sekitar 20 GB unduhan, jalan di 24 GB RAM, dan dengan CUDA mencapai 1,4–10 token/detik. Validasi dulu bahwa alur kerjanya cocok sebelum committing 372 GB.
• Flagship: GLM-5.2 — unduhan kontainer int4 sekitar 372 GB, minimum 25 GB RAM, kecepatan bergantung total pada tier di mana expert-nya tinggal.
• Ekstrem: Kimi K3 (2,8T) — di-stream langsung dari checkpoint MXFP4 native, kebutuhan ruang sampai ±1,6 TB.

Karena coli serve menyajikan endpoint kompatibel OpenAI, integrasi ke aplikasi yang sudah ada tinggal mengganti base URL — tanpa mengubah kode klien.

Batasan yang Perlu Dipahami

• Bukan pengganti API cloud. Di hardware realistik (bukan workstation 6-GPU), flagship-nya berjalan 1–2 token/detik dan didominasi bandwidth disk. Untuk kerja interaktif harian, ini belum kompetitif.
• Unduhan masif. 372 GB (GLM-5.2) hingga 1,6 TB (Kimi K3) sebelum satu token pun dihasilkan.
• Keausan disk. Streaming sekitar 11 GB expert per token adalah beban random-read berat untuk NVMe; proyek menyediakan pengaturan O_DIRECT dan striping dua drive, tapi durability SSD lama tetap pertanyaan yang harus dijawab pengguna.
• Kualitas int4. Ablation terdokumentasi, dan pemilihan kontainer kuantisasi memengaruhi perilaku (kontainer int4 lama pernah menyebabkan loop mode-thinking). Ini pilihan engineering yang harus dipantau, bukan detail sepele.

Kenapa Repo Ini Layak Dipantau

Colibri adalah proof of concept yang paling dibutuhkan bidang local inference: bukti bahwa pola aktivas sparse + streaming NVMe + learned cache bukan skema di kertas, melainkan kode yang berjalan hari ini. Polanya hanya akan makin cepat seiring PCIe 5.0 dan 6.0 menjadi standar — 0,1 token/detik di tahun 2026 adalah angka yang sama arsitekturnya akan jalankan di hardware dua generasi lagi, di mesin yang sudah Anda miliki. Ditambah lisensi Apache-2.0 yang bersih untuk penggunaan komersial, colibri menjadi salah satu repositori 2026 yang paling layak di-clone bukan untuk langsung dipakai, melainkan untuk dibaca.

Opini: Hype colibri sesungguhnya bukan soal menjalankan 744B di laptop — itu memang lambat dan jujur soal itu. Yang mengguncang adalah bahwa satu engineer, dalam C murni tanpa dependensi, membuktikan bahwa batas "model terlalu besar untuk hardware Anda" adalah masalah penempatan, bukan masalah arsitektur. Selama trennya demikian, setiap terobosan di NVMe dan memori adalah pendorong kecepatan untuk seluruh kelas model frontier — dan itu mengubah cara kita berpikir tentang hardware apa yang layak untuk AI lokal.

Sumber: repositori JustVugg/colibri · Situs proyek