Show HN: Menjalankan GLM 5.2 di komputer lambat

 (github.com/JustVugg)
2 poin oleh GN⁺ 5 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • colibrì adalah engine murni C yang dibuat untuk menjalankan GLM-5.2 744B MoE pada mesin konsumen dengan RAM sekitar 25GB, dan bekerja tanpa GPU dengan melakukan streaming expert yang dirutekan dari disk
  • Struktur intinya menempatkan bagian dense sekitar 17B parameter tetap di RAM dalam int4 sehingga memakai 9.9GB, sementara 21.504 routed expert disimpan di disk sekitar 370GB dan dibaca saat diperlukan
  • Implementasinya mencakup forward GLM-5.2, attention MLA dan KV-cache terkompresi, router gaya DeepSeek-V3, MTP speculative decoding, kernel kuantisasi int8/int4/int2, serta tokenizer BPE level-byte
  • Di lingkungan WSL2 dengan 12 core, RAM 25GB, dan NVMe VHDX, waktu muat sekitar 30 detik, peak RSS saat chat sekitar 20GB, dan cold decode membaca disk sekitar 11GB per token dengan kecepatan 0.05~0.1 tok/s
  • Pada NVMe yang lebih cepat dan RAM yang lebih besar, cache dan pinning menjadi penting; dalam pengukuran komunitas, Apple M5 Max 128GB mencatat 1.06 tok/s dengan MTP nonaktif

Masalah yang ingin diselesaikan colibrì

  • colibrì mengusung slogan “Tiny engine, immense model” dan merupakan engine untuk menjalankan model GLM-5.2 744B-parameter MoE pada mesin konsumen dengan RAM sekitar 25GB
  • Runtime-nya ditulis dalam C murni dan tidak memiliki ketergantungan pada Python, BLAS, atau GPU
  • Engine ini terdiri dari satu file C tunggal c/glm.c sekitar 1.300 baris beserta header kecil
  • Contoh eksekusinya adalah ./coli chat, dan contoh output menampilkan colibrì v1.0 — GLM-5.2 · 744B MoE · int4 · streaming CPU dengan waktu persiapan sekitar 32 detik serta memori resident 9.9GB

Cara kerja eksekusi MoE berbasis streaming disk

  • Model 744B Mixture-of-Experts milik GLM-5.2 hanya mengaktifkan sekitar 40B parameter per token
  • Routed expert yang berubah pada setiap token setara dengan sekitar 11GB
  • Bagian dense tetap berada di RAM
    • mencakup attention, shared expert, dan embedding
    • sekitar 17B parameter
    • memakai sekitar 9.9GB RAM dalam int4
  • Routed expert disimpan di disk
    • mencakup 75 layer MoE × 256 expert dan head MTP
    • total 21.504 routed expert
    • sekitar 19MB per expert dalam int4
    • total penggunaan disk sekitar 370GB
  • Pemuatan expert memakai cache LRU per-layer, pinned hot-store opsional, dan OS page cache

Fitur utama yang diimplementasikan

  • Forward GLM-5.2 diimplementasikan sesuai struktur glm_moe_dsa, dan divalidasi token-exact terhadap oracle transformers
    • teacher-forcing 32/32 pada model tiny-random
    • greedy generation 20/20
  • Attention MLA mencakup q/kv-LoRA dan partial RoPE yang diinterleave
    • KV-cache terkompresi memakai 576 float per token
    • 57 kali lebih kecil dibanding 32.768 float/token sebelumnya
    • GLM-5.2 memiliki 64 head tanpa GQA
  • Router sigmoid gaya DeepSeek-V3 diimplementasikan
    • noaux_tc
    • routed_scaling_factor
    • shared expert
    • first-3-dense layers
  • Native MTP speculative decoding menggunakan head multi-token-prediction GLM-5.2 (layer 78) untuk membuat draft token, lalu model utama memverifikasinya dengan batched forward
    • head MTP harus dalam int8
    • pada int4, acceptance draft turun ke 0~4% sehingga spekulasi tidak bekerja
    • pada int8, acceptance terukur 39~59%, 2.2~2.8 token/forward
    • tetap lossless saat sampling melalui rejection sampling
    • pada cold cache, verified draft dapat merutekan expert tambahan sehingga expert-loads/token bisa naik dari sekitar 660 menjadi sekitar 1100
    • dalam kasus ini, waktu bisa lebih lama sampai cache dan pin menjadi warm, sehingga ada adaptive guard dan opsi DRAFT=0
  • True sampling mendukung temperature dan nucleus
    • default 0.7 / 0.90
    • pengaturan resmi 1.0 / 0.95 dijelaskan dapat mengambil noise kuantisasi di tail pada lingkungan int4
  • Kernel integer-dot memakai aktivasi int8 gaya Q8_0 dan AVX2 maddubs
    • matmul int8 1.4~2.5 kali lebih cepat
    • performa terukur 119 GFLOP/s
    • int4 1.8 kali lebih cepat pada batch
    • int4 single-row terukur lebih lambat sehingga tetap memakai f32
  • MLA weight absorption menghindari rekonstruksi k/v per token saat decode
    • query menyerap kv_b, dan context diproyeksikan setelah attention
    • tervalidasi 32/32 pada TF dan 20/20 pada generation bahkan dalam lingkungan forced absorption
  • Expert readahead membaca block berikutnya dengan WILLNEED saat satu block expert sedang dikalikan
  • Kernel kuantisasi mendukung int8, packed int4, packed int2, scale per-row, AVX2, dan dequant-on-use
  • DSA sparse attention masih dalam pengerjaan
    • bobot lightning-indexer berbentuk ekstraksi sekitar 108GB dari repo FP8
    • forward indexer direncanakan sebagai langkah berikutnya
    • sampai saat itu, attention tetap dense dan exact untuk context ≤ 2048 token
  • Pada prefill dan verifikasi MTP, Batch-union MoE hanya membaca unique expert dalam batch satu kali, lalu menerapkannya ke semua posisi yang dirutekan ke expert tersebut
  • Tokenizer adalah tokenizer BPE level-byte yang diimplementasikan dalam C dan memakai regex properti Unicode gaya GPT-2 serta 320k merges
  • Pengaman RAM otomatis menyesuaikan ukuran cache expert saat startup berdasarkan MemAvailable
    • memperhitungkan peak projection dari working set, KV, baris MTP, dan reconstruction buffer
    • dirancang agar kernel OOM-killer tidak aktif
  • Konverter offline disediakan sebagai c/convert_fp8_to_int4.py
    • mengunduh shard FP8 GLM-5.2 satu per satu
    • melakukan dequant dengan scale block 128×128 lalu requantize ke container engine
    • berjalan sambil menghapus shard sehingga checkpoint FP8 756GB tidak perlu ada sekaligus di disk
    • konversi dapat dilanjutkan kembali

Performa dasar yang diukur dan keterbatasannya

  • Lingkungan pengembangan adalah WSL2, 12 core, RAM 25GB, NVMe via VHDX
  • Nilai yang diukur sebagai berikut
    • ukuran model container int4: sekitar 370GB
    • RAM resident: 9.9GB
    • load time: sekitar 30 detik
    • peak RSS saat chat: sekitar 20GB, auto-capped
    • biaya cold decode: sekitar 11GB disk read per token
    • batas random disk VHDX: sekitar 1GB/s
    • kecepatan cold decode: sekitar 0.05~0.1 tok/s
    • spekulasi MTP: 2.2~2.8 tok/forward dengan head int8
  • Dijelaskan bahwa ini bukan sistem yang cepat, dan warm cache, pinned hot expert, serta MTP dapat menurunkan latensi untuk mendapatkan respons yang berguna
  • Ada dua catatan terkait SSD
    • streaming colibrì bersifat read-only sehingga pembacaan itu sendiri tidak memberi dampak berarti pada keausan SSD
    • jika kekurangan RAM memicu traffic swap, akan terjadi write yang dapat mempercepat keausan drive
    • full read duty cycle dalam waktu lama dapat memanaskan drive murah, sehingga pemantauan suhu dan kesehatan diperlukan

Mengunduh model dan menjalankannya

  • Model GLM-5.2 int4 yang sudah dikonversi sebelumnya tersedia di Hugging Face
  • Jika mengambil model yang sudah dikonversi, langkah konversi FP8 → int4 bisa dilewati
  • Untuk menjalankan, tetapkan COLI_MODEL ke direktori model
COLI_MODEL=/path/to/GLM-5.2-colibri-int4 ./coli chat
  • Quick start menjalankan ./setup.sh di direktori c untuk memeriksa gcc/OpenMP, build, dan self-test
  • Untuk konversi sendiri, gunakan ./coli convert --model /nvme/glm52_i4
    • memerlukan path ext4/NVMe dengan ruang kosong sekitar 400GB
    • konversi memerlukan Python dan torch, safetensors, huggingface_hub, numpy
    • engine runtime itu sendiri tetap C murni dan Python hanya dipakai untuk converter sekali jalan
  • Opsi yang berguna adalah sebagai berikut
    • --temp T: temperature sampling, default 0.7 dan nucleus 0.90, 0 berarti greedy
    • --topp 0.7: adaptive expert top-p, mengurangi penggunaan disk 30~40%
    • --ngen N: jumlah token maksimum per jawaban
    • AUTOPIN=0: menonaktifkan auto-pin learning cache
    • THINK=1: mengaktifkan blok reasoning GLM-5.2
    • DRAFT=n: kedalaman draft MTP
    • TF=1: validasi teacher-forcing

Learning cache dan ekspektasi berdasarkan hardware

  • Learning cache mencatat expert yang benar-benar dirutekan ke .coli_usage di samping model saat dipakai
  • Saat startup, expert terpanas akan otomatis di-pin ke RAM yang tersisa
  • Deskripsi proyek menyebut colibrì akan semakin cepat seiring akumulasi pola penggunaan
  • Lingkungan yang dibutuhkan adalah Linux atau WSL2, gcc dengan dukungan OpenMP, AVX2, minimal 16GB RAM, dan NVMe lokal yang berisi model int4 sekitar 370GB
    • path ext4 direkomendasikan
    • mount network/9p disarankan untuk tidak digunakan
  • Urutan pengujian adalah build dan self-test, mengukur disk dengan iobench, memeriksa tok/s, expert hit-rate, dan RSS saat chat, merekam penggunaan expert lalu melakukan pinning, kemudian menjalankan benchmark kualitas
  • Perkiraan berdasarkan hardware bukan hasil pengukuran langsung
    • mesin pengembangan WSL2 VHDX, sekitar 1GB/s, RAM 25GB: 0.05~0.1 tok/s cold
    • Linux native, PCIe4 NVMe 3~5GB/s random, 32GB: 0.5~1 tok/s
    • PCIe5 NVMe atau 2×NVMe RAID0 8~12GB/s, 64GB, PIN sekitar 40GB: 2~4 tok/s
    • RAM 128~256GB, 12 core, hot expert tercache: 2~4 tok/s
    • RAM sama dengan 24~32 core atau kernel AVX-512/VNNI: 5~15 tok/s

Benchmark komunitas

  • Intel Core Ultra 7 270K Plus, 24 thread, WSL2, RAM 24GB, dan NVMe VHDX mencatat 0.07 tok/s dengan pengaturan default
    • disk iobench: 1.96GB/s buffered, 2.74GB/s O_DIRECT
    • expert hit: 3~4%
    • RSS: 14.1GB
  • Pada lingkungan yang sama, --topp 0.7 mencatat 0.11 tok/s
    • expert hit: 11%
    • RSS: 14.7GB
    • kecepatan end-to-end naik 1.6 kali
  • Apple M5 Max, 18 core, macOS, unified memory 128GB, dan SSD internal mencatat 1.06 tok/s
    • disk iobench: 14.2GB/s O_DIRECT
    • default, MTP nonaktif
    • expert hit: 23%
    • RSS: 21.8GB
  • Pada mesin RAM 24GB, cache expert di-auto-cap ke 2 slot per layer, sehingga meskipun disk 2~2.7 kali lebih cepat daripada mesin pengembangan, decode tetap berada dalam kondisi cold
  • Pada mesin dengan RAM kecil, batas RAM menjadi bottleneck, bukan disk
  • Nilai pada M5 Max menunjukkan model 744B bisa mencapai sekitar 1 tok/s di SSD laptop, dan disk 14GB/s memindahkan bottleneck kembali ke budget RAM dan kernel

Benchmark kualitas dan pengukuran yang masih tersisa

  • Biaya akurasi dari kuantisasi int4 masih belum diukur
  • Harness benchmark sudah diimplementasikan, tetapi pada disk sekitar 1GB/s milik mesin pengembangan, eksekusi penuh memakan sebagian besar satu hari
  • Perintah benchmark yang disediakan menjalankan hellaswag, arc_challenge, dan mmlu
cd c
./coli bench
./coli bench hellaswag --limit 200
./coli bench mmlu arc_challenge --ram 100
  • Output berupa accuracy per task, memakai scoring log-likelihood dan gaya EleutherAI-harness
  • Skor publik GLM-5.2 full-precision disebut sekitar 85~95% pada task-task tersebut
  • Jika container int4 berada hanya beberapa poin di bawahnya, kuantisasi dianggap tervalidasi; jika tidak, itu menjadi alasan untuk berinvestasi pada kuantisasi mixed atau grouped-scale

Struktur repositori dan lisensi

  • Susunan file utamanya adalah sebagai berikut
    • c/glm.c: engine yang mencakup forward GLM-5.2, streaming MoE, MTP, dan mode serve
    • c/st.h: pembaca safetensors berbasis pread dan fadvise, tanpa mmap
    • c/tok.h: tokenizer BPE level-byte dalam C
    • c/coli: CLI untuk chat, run, bench, convert, info
    • c/iobench.c: microbenchmark disk paralel yang mencerminkan pengalaman engine
    • c/convert_fp8_to_int4.py: converter aman-disk FP8 → int4
    • c/make_glm_oracle.py: generator oracle tiny-random untuk validasi
    • c/olmoe.c: engine Stage-A dan target validasi pertama
  • Nama colibrì berasal dari burung kolibri yang dapat melayang dengan bobot kecil dan mengunjungi banyak bunga dalam sehari
  • Lisensi proyek adalah Apache 2.0, dan bobot GLM-5.2 dirilis Z.ai di bawah lisensi MIT

Bacaan terkait

1 komentar

 
GN⁺ 5 jam lalu
Komentar Hacker News

  • Yang paling membuat penasaran adalah apakah saat benar-benar dipakai ini masih berada di level yang bisa diukur dalam token/detik, atau justru mendekati 1 token per menit
    LLM lokal tetap cukup berguna meski lambat seperti 1 token/detik, jika bisa dibiarkan mengerjakan proyek semalaman lalu hasilnya dicek 6~8 jam kemudian
    Sebaliknya, 0,05~0,1 token/detik pada perangkat keras spesifikasi minimum yang disebut di tautan itu tampaknya hampir tidak punya kegunaan praktis
    Meski begitu, konsep keseluruhannya sangat bagus, dan saya berharap akan ada lebih banyak upaya untuk menjalankan model kelas 350B~900B secara lokal di perangkat keras yang masih terjangkau bagi orang biasa, meskipun hanya 1 token/detik
    Saya suka arah pemikiran seperti, “Ada NVMe SSD dengan performa baca cepat, dan ada model raksasa di disk lokal, jadi jangan muat semuanya sekaligus, baca saja 11GB/token saat dibutuhkan”

    • Lucu juga bahwa berkat Claude Cowork, saya jadi terbiasa menunggu waktu respons
      Sekarang saya merasa paling lambat sekitar 2028 nanti saya akan menjalankannya secara lokal
      Saya ingin anggarannya di bawah 10 ribu dolar, dan bisa menjalankan model yang sebanding dengan model terbaik saat ini
    • Untuk model lokal yang lambat atau beberapa proyek tertentu, antarmuka chat mungkin pendekatan yang keliru, dan bentuk seperti sistem tiket bisa jadi lebih cocok
      Sebelum menghabiskan uang untuk Mac Studio atau GPU, saya sudah memutuskan cara memvalidasi ide ini dengan perangkat keras yang saya miliki sekarang, dan sepertinya minggu ini saya bisa membuat semacam proof of concept
      Ini bukan ide baru, saya hanya perlu waktu untuk membuatnya berjalan sesuai cara kerja saya
    • Di README ada benchmark menjalankan Colibrì pada berbagai perangkat keras, dan saya pernah melihat waktu yang cukup bagus
      Saya terus mencoba meningkatkannya lebih lanjut
    • Untuk kebanyakan proyek, lebih praktis memakai cloud yang menyediakan GLM 5.2 gratis
      1 token per menit terlalu kecil bahkan jika dibandingkan dengan batas penggunaan gratis
    • Akhir-akhir ini saya jadi berpikir apakah “orang biasa” sekarang benar-benar mampu menyediakan RAM 24GB dan NVMe SSD 0,5TB

  • Saya sedang membuat sesuatu yang mirip untuk macOS di Apple Silicon
    Arah yang saya ambil adalah Unsloth split GGUF, compressed partial residency di unified memory, kernel Metal native, dan compressed KV native khusus RAM
    Ini tampaknya lebih masuk akal di 128GB daripada di 64GB saya, dan kalau sudah siap saya berencana mengunggahnya ke GitHub

    • Saya punya MacBook Pro M4 128GB yang sedang menunggu, jadi saya sangat ingin mencobanya

  • Di sisi pembuatan gambar/video, saya juga pernah mencoba strategi serupa lewat https://github.com/cretz/thinfer
    Ada banyak pekerjaan yang masuk ke branch video
    Saya terus membutuhkan engine inferensi yang bisa memuat dan mengeluarkan bobot dengan metode LRU saat dibutuhkan, jadi akhirnya saya membuat dengan vibe coding sebuah alat yang menerima --vram-budget dan tetap berada dalam batas itu
    Terlihat bahwa biaya memindahkan byte yang di-mmap masuk dan keluar dari VRAM cukup murah dibandingkan komputasinya, dan bila digabungkan dengan pipelining serta double buffering, hampir selalu bottleneck-nya bukan memori melainkan komputasi
    Tentu saja saya memakai model yang jauh lebih kecil

    • Sepertinya Anda sudah memasukkan sangat banyak model seperti krea, wan, hunyan, dan lain-lain
      Saya penasaran apakah Anda membuat harness umum yang bisa menjalankan semuanya
      Saya juga penasaran model mana yang lebih konsisten tetap berada dalam anggaran VRAM

  • llama.cpp mendukung berbagai kuantisasi 4-bit ke bawah dan secara default mem-mmap model, jadi tidak perlu menaruh seluruh bobot di memori
    Sistem operasi akan mengambilnya dari penyimpanan saat diperlukan
    Keren bahwa ini diimplementasikan dengan sangat sedikit kode tanpa dependensi, tetapi saya penasaran apakah ada keuntungan performa nyata

  • Cukup keren
    Minggu ini saya sempat mencoba GLM 5.2 dan sama-sama terkesan
    Di perusahaan, kami sedang menguji eksekusi lokal pada perangkat keras yang sangat mahal sebelum memulai proyek berikutnya, dan senang melihat ada orang-orang yang menjalankan rilis model open source raksasa ini di mesin yang lebih rata-rata
    Meski belum terlalu praktis, ini tetap pekerjaan yang bagus

    • Saya penasaran perangkat keras apa yang dipakai

  • Saya tidak terlalu paham struktur internal LLM, tetapi saya penasaran apakah struktur serupa bisa dipakai pada model lain yang punya “lapisan”
    Saya ingin tahu apakah bisa begitu satu lapisan selesai bekerja, lapisan itu dibuang dari RAM, lalu lapisan berikutnya dimuat dari disk dan diaktifkan terhadap hasil dari lapisan pertama

  • Mesin saya punya RAM 64GB dan VRAM 24GB, jadi saya penasaran apakah ini bisa disetel agar memakai RAM lebih banyak
    Atau mungkin Gemma/Qwen bisa dijalankan di GPU lalu GLM-5.2 mendelegasikan tugas-tugas yang lebih kecil ke sana
    Mungkin GLM-5.2 juga perlu dilatih ulang sampai tingkat tertentu
    Saya juga penasaran apakah memakai beberapa disk secara paralel untuk menambah bandwidth bisa mempercepatnya
    Peringatan keausan SSD menyebut bahwa cold start berat karena sekitar 11GB/token pembacaan acak, dan walaupun pembacaan itu sendiri aman, page cache sistem operasi bisa menimbulkan penulisan, serta penggunaan berlebihan bisa mempercepat keausan SSD murah
    Salah satu cara aman mungkin membuat partisi terpisah untuk bobot model dan mengaturnya sebagai read-only
    Saya tidak tahu apakah page cache itu berlaku per partisi atau per disk, tetapi jika per disk, mungkin ada cara memformat data.iso read-only seperti partisi lalu me-mount-nya sebagai disk

    • Saya memakai laptop kecil
      Kalau saya punya lebih banyak disk, saya benar-benar bisa mengujinya
      Kalau ada benchmark, silakan unggah sebagai pull request atau issue dan kita bisa mengerjakannya bersama
    • Saya penasaran apakah pernyataan “page cache sistem operasi bisa menimbulkan penulisan” itu halusinasi
      Apa yang saya lewatkan? Kenapa pembacaan dalam jumlah besar bisa menimbulkan penulisan?
    • Itu bisa jadi ide yang bagus, dan kita bisa mengerjakannya bersama

  • Ada peringatan keausan SSD di halaman ini https://github.com/JustVugg/colibri#ssd-wear-warning
    Kalau memakai PC desktop rakitan sendiri, SSD bisa diganti, tetapi bagaimana dengan pengguna yang memakai SSD solder?
    Apakah sebaiknya menghindari aplikasi seperti ini, atau tetap memakainya sambil menerima kemungkinan perangkat penyimpanan rusak lebih cepat?
    Sepertinya penyimpanan eksternal perlu dipakai sebagai SSD habis pakai

    • Sebaiknya dihindari
      Laptop dengan SSD solder perlu benar-benar memantau pemakaian dan berhati-hati
      Proyek ini tampak lebih seperti eksperimen daripada sesuatu yang akan dijalankan semua orang, tapi tetap cukup keren
    • Setahu saya, peringatannya berkaitan dengan swap out saat penggunaan memori berlebihan
      Tidak perlu berpikir mistis soal ini
      Aktivitas disk, terutama penulisan, bisa diukur
      Misalnya di Linux bisa memakai iostat atau vmstat
    • Itu peringatan yang cukup konservatif
      Aplikasi ini tidak melakukan penulisan, jadi secara nyata aplikasinya sendiri tidak akan mengauskan SSD
      Selebihnya lebih mirip praktik pengelolaan umum yang tidak terlalu terkait dengan aplikasinya
    • Untuk penggunaan seperti itu, sepertinya memang lebih tepat memakai drive eksternal

  • Secara teknis ini mengesankan, tetapi saya penasaran apakah benar-benar bisa dipakai secara praktis

  • Sebenarnya saya juga sedang membuat hal yang sama, tetapi saya memilih mem-mmap seluruh model ke memori agar tidak menambah penggunaan RAM
    Saya juga meminta Claude mengimplementasikan Medusahttps://arxiv.org/abs/2401.10774 pada model itu, agar bisa mendapat manfaat prediksi multi-token tanpa harus memuat model tambahan ke memori
    Baru saja saya sampai di rumah dan ingin menambahkan, semua modifikasi saya lakukan di llama.cpp, dan tujuan akhirnya adalah menjalankannya di sesuatu seperti komputer papan tunggal yang menangani file mmap lewat NVMe
    Berdasarkan pengujian sebelumnya, batas teoritis konfigurasi saya saat ini tampaknya sekitar 1,8 token/detik, tetapi head Medusa tambahan itu belum sepenuhnya terlatih, dan saya juga jujur tidak yakin apakah itu dihitung berdasarkan token yang dihasilkan
    Pada akhirnya idenya terlihat serupa, tetapi saya belum tahu cara menulis parser/runner LLM dari nol, jadi alih-alih menentukan apa yang harus tetap di memori, saya menyerahkannya ke kernel Linux
    Terakhir, saya sudah membatasi penggunaan llama.cpp menjadi 16GB dari total 32GB saya, jadi mungkin masih bisa diturunkan lagi

    • Colibrì masih perlu banyak perbaikan, jadi kalau ada ide atau hal lain, pull request, issue, maupun benchmark semuanya sangat diterima
    • Ini memang pendekatan yang selama ini saya penasarkan