Show HN: धीमे कंप्यूटर पर GLM 5.2 चलाना

 (github.com/JustVugg)
2 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • colibrì एक pure C engine है जिसे consumer machine पर लगभग 25GB RAM में GLM-5.2 744B MoE चलाने के लिए बनाया गया है; यह routed experts को disk से stream करता है और GPU के बिना काम करता है
  • इसका मुख्य ढांचा dense हिस्से के लगभग 17B parameters को int4 में RAM में resident रखकर 9.9GB इस्तेमाल करता है, जबकि 21,504 routed experts को लगभग 370GB disk पर रखकर जरूरत पड़ने पर पढ़ता है
  • implementation में GLM-5.2 forward, MLA attention और compressed KV-cache, DeepSeek-V3 style router, MTP speculative decoding, int8/int4/int2 quantization kernels, और byte-level BPE tokenizer शामिल हैं
  • WSL2 12-core·25GB RAM·NVMe VHDX environment में load time लगभग 30 सेकंड, chat के दौरान peak RSS लगभग 20GB, और cold decode token प्रति लगभग 11GB disk read के साथ 0.05~0.1 tok/s के स्तर पर है
  • तेज NVMe और ज्यादा RAM पर cache और pinning महत्वपूर्ण हैं; वास्तविक community measurements में Apple M5 Max 128GB environment ने MTP off के आधार पर 1.06 tok/s दर्ज किया

colibrì जिस समस्या को हल करना चाहता है

  • colibrì “Tiny engine, immense model” का दावा करता है, और GLM-5.2 744B-parameter MoE model को लगभग 25GB RAM वाली consumer machine पर चलाने वाला engine है
  • runtime pure C है और इसमें Python, BLAS, GPU dependencies नहीं हैं
  • engine c/glm.c नाम की एक single C file की लगभग 1,300 lines और छोटे headers से बना है
  • example run ./coli chat है, और sample output colibrì v1.0 — GLM-5.2 · 744B MoE · int4 · streaming CPU के साथ लगभग 32 सेकंड की तैयारी time और 9.9GB resident memory दिखाता है

disk streaming आधारित MoE execution तरीका

  • GLM-5.2 का 744B Mixture-of-Experts model token प्रति केवल लगभग 40B parameters activate करता है
  • हर token पर बदलने वाले routed experts लगभग 11GB के बराबर हैं
  • dense हिस्सा RAM में resident रहता है
    • इसमें attention, shared experts, embeddings शामिल हैं
    • लगभग 17B parameters
    • int4 के आधार पर लगभग 9.9GB RAM इस्तेमाल
  • routed experts disk पर store होते हैं
    • 75 MoE layers × 256 experts और MTP head शामिल
    • कुल 21,504 routed experts
    • int4 के आधार पर expert प्रति लगभग 19MB
    • कुल disk usage लगभग 370GB
  • expert loading per-layer LRU cache, optional pinned hot-store, और OS page cache का इस्तेमाल करती है

implement किए गए मुख्य features

  • GLM-5.2 forward को glm_moe_dsa structure के अनुसार implement किया गया है, और transformers oracle के आधार पर token-exact verify किया गया है
    • tiny-random model पर teacher-forcing 32/32
    • greedy generation 20/20
  • MLA attention में q/kv-LoRA और interleaved partial RoPE शामिल हैं
    • compressed KV-cache token प्रति 576 floats इस्तेमाल करता है
    • मौजूदा 32,768 floats/token की तुलना में 57 गुना छोटा
    • GLM-5.2 में 64 heads हैं और GQA नहीं है
  • DeepSeek-V3 style sigmoid router implement किया गया है
    • noaux_tc
    • routed_scaling_factor
    • shared expert
    • first-3-dense layers
  • Native MTP speculative decoding में GLM-5.2 का multi-token-prediction head(layer 78) draft token बनाता है और main model batched forward से verify करता है
    • MTP head int8 होना चाहिए
    • int4 में draft acceptance 0~4% तक गिर जाता है, इसलिए speculation काम नहीं करता
    • int8 में acceptance 39~59%, 2.2~2.8 tokens/forward measured है
    • rejection sampling के जरिए sampling के दौरान भी इसे lossless रखा जाता है
    • cold cache में verified draft अतिरिक्त experts को route कर सकता है, जिससे expert-loads/token लगभग 660 से लगभग 1100 तक बढ़ सकता है
    • ऐसे में cache और pin warm-up होने से पहले अधिक समय लग सकता है, इसलिए adaptive guard और DRAFT=0 option है
  • True sampling temperature और nucleus support करता है
    • default 0.7 / 0.90
    • official 1.0 / 0.95 setting के बारे में बताया गया है कि वह int4 environment में tail के quantization noise को sample करती है
  • integer-dot kernel Q8_0-style int8 activations और AVX2 maddubs का इस्तेमाल करता है
    • int8 matmul 1.4~2.5 गुना तेज है
    • measured performance 119 GFLOP/s है
    • int4 batch में 1.8 गुना तेज है
    • int4 single-row measurements में धीमा निकला, इसलिए f32 में रखा गया है
  • MLA weight absorption decode में per-token k/v reconstruction से बचाता है
    • query kv_b को absorb करती है, और context attention के बाद project होता है
    • forced absorption environment में भी TF 32/32 और generation 20/20 से verify किया गया
  • expert readahead एक expert block को multiply करते समय अगले block को WILLNEED से पढ़ता है
  • quantization kernel int8, packed int4, packed int2, per-row scales, AVX2, dequant-on-use support करता है
  • DSA sparse attention work in progress है
    • lightning-indexer weights FP8 repo से लगभग 108GB extract करने के रूप में हैं
    • indexer forward अगले stage के लिए planned है
    • तब तक attention context ≤ 2048 tokens पर dense और exact है
  • prefill और MTP verification में Batch-union MoE batch के unique experts को केवल एक बार पढ़ता है और उस expert की ओर routed सभी positions पर apply करता है
  • tokenizer C में implement किया गया byte-level BPE tokenizer है और GPT-2 style Unicode-property regex तथा 320k merges इस्तेमाल करता है
  • RAM safety device startup पर MemAvailable के आधार पर expert cache को auto size-adjust करता है
    • working set, KV, MTP row, reconstruction buffer के peak projection को reflect करता है
    • kernel OOM-killer न चले, इसे ध्यान में रखकर design किया गया है
  • offline converter c/convert_fp8_to_int4.py के रूप में दिया गया है
    • GLM-5.2 FP8 shards को एक बार में एक download करता है
    • 128×128 block scales से dequant के बाद engine container में requantize करता है
    • shard delete करते हुए आगे बढ़ता है, इसलिए पूरा 756GB FP8 checkpoint एक साथ disk पर मौजूद होना जरूरी नहीं
    • conversion resume किया जा सकता है

measured basic performance और constraints

  • development environment WSL2, 12-core, 25GB RAM, NVMe via VHDX है
  • measurements इस प्रकार हैं
    • int4 container model size: लगभग 370GB
    • resident RAM: 9.9GB
    • load time: लगभग 30 सेकंड
    • chat के दौरान peak RSS: लगभग 20GB, auto-capped
    • cold decode cost: token प्रति लगभग 11GB disk reads
    • VHDX random disk ceiling: लगभग 1GB/s
    • cold decode speed: लगभग 0.05~0.1 tok/s
    • MTP speculation: int8 head के आधार पर 2.2~2.8 tok/forward
  • यह साफ कहा गया है कि यह fast system नहीं है, और warm cache, pinned hot experts, MTP useful-response latency को घटाते हैं
  • SSD से जुड़ी cautions दो हैं
    • colibrì streaming read-only है, इसलिए read खुद SSD wear पर meaningful असर नहीं डालता
    • RAM की कमी से swap traffic पैदा हो तो writes होंगे और drive घिस सकता है
    • लंबे समय का full read duty cycle low-cost drives को heat कर सकता है, इसलिए temperature और health monitoring जरूरी है

model download और run

  • pre-converted GLM-5.2 int4 model Hugging Face पर उपलब्ध है
  • pre-converted model लेने पर FP8 → int4 conversion step skip किया जा सकता है
  • run करने के लिए COLI_MODEL को model directory पर set करें
COLI_MODEL=/path/to/GLM-5.2-colibri-int4 ./coli chat
  • quick start में c directory में ./setup.sh से gcc/OpenMP check, build, self-test किया जाता है
  • direct conversion करना हो तो ./coli convert --model /nvme/glm52_i4 इस्तेमाल करें
    • लगभग 400GB free space वाला ext4/NVMe path चाहिए
    • conversion के लिए Python और torch, safetensors, huggingface_hub, numpy चाहिए
    • runtime engine खुद pure C है और Python केवल one-time converter के लिए इस्तेमाल होता है
  • useful options ये हैं
    • --temp T: sampling temperature, default 0.7 और nucleus 0.90, 0 का मतलब greedy
    • --topp 0.7: adaptive expert top-p, disk usage 30~40% घटाता है
    • --ngen N: response प्रति maximum tokens
    • AUTOPIN=0: learning cache auto-pin disable
    • THINK=1: GLM-5.2 reasoning block enable
    • DRAFT=n: MTP draft depth
    • TF=1: teacher-forcing validation

Learning cache और hardware के हिसाब से expectations

  • Learning cache actual use में routed experts को model के पास .coli_usage में record करता है
  • startup पर spare RAM में सबसे hot experts को automatically pin करता है
  • project description बताता है कि usage जमा होने के साथ colibrì और fast होता जाता है
  • required environment Linux या WSL2, OpenMP-supporting gcc, AVX2, minimum 16GB RAM, और लगभग 370GB int4 model वाला local NVMe है
    • ext4 path recommended है
    • network/9p mount का इस्तेमाल न करने की सलाह है
  • test sequence है: build और self-test, iobench से disk measurement, chat में tok/s·expert hit-rate·RSS check, expert usage record के बाद pinning, quality benchmark run
  • hardware-wise estimates measurements नहीं, बल्कि अनुमान हैं
    • development machine WSL2 VHDX, लगभग 1GB/s, 25GB RAM: 0.05~0.1 tok/s cold
    • native Linux, PCIe4 NVMe 3~5GB/s random, 32GB: 0.5~1 tok/s
    • PCIe5 NVMe या 2×NVMe RAID0 8~12GB/s, 64GB, PIN लगभग 40GB: 2~4 tok/s
    • 128~256GB RAM, 12-core, hot experts cached: 2~4 tok/s
    • उसी RAM के साथ 24~32-core या AVX-512/VNNI kernels: 5~15 tok/s

community benchmarks

  • Intel Core Ultra 7 270K Plus, 24 threads, WSL2, 24GB RAM, NVMe VHDX environment पर default settings ने 0.07 tok/s दर्ज किया
    • disk iobench: 1.96GB/s buffered, 2.74GB/s O_DIRECT
    • expert hit: 3~4%
    • RSS: 14.1GB
  • उसी environment में --topp 0.7 ने 0.11 tok/s दर्ज किया
    • expert hit: 11%
    • RSS: 14.7GB
    • end-to-end speed 1.6 गुना बढ़ी
  • Apple M5 Max, 18 cores, macOS, 128GB unified memory, internal SSD environment ने 1.06 tok/s दर्ज किया
    • disk iobench: 14.2GB/s O_DIRECT
    • default, MTP off
    • expert hit: 23%
    • RSS: 21.8GB
  • 24GB RAM machine में expert cache layer प्रति 2 slots पर auto-cap हो जाता है, इसलिए development machine से disk 2~2.7 गुना तेज होने पर भी decode cold state में रहता है
  • छोटी RAM machine में disk से ज्यादा RAM cap bottleneck बनता है
  • M5 Max measurement ऐसा case है जिसमें 744B model laptop SSD पर लगभग 1 tok/s देता है, और 14GB/s disk bottleneck को फिर RAM budget और kernel की ओर shift कर देता है

quality benchmarks और बाकी measurements

  • int4 quantization का accuracy पर cost अभी measured नहीं है
  • benchmark harness implement हो चुका है, लेकिन development machine की लगभग 1GB/s disk पर full run में दिन का काफी हिस्सा लग जाता है
  • दिए गए benchmark commands hellaswag, arc_challenge, mmlu run करते हैं
cd c
./coli bench
./coli bench hellaswag --limit 200
./coli bench mmlu arc_challenge --ram 100
  • output task-wise accuracy है, और log-likelihood scoring तथा EleutherAI-harness style इस्तेमाल करता है
  • full-precision GLM-5.2 के public scores इन tasks पर लगभग 85~95% बताए गए हैं
  • अगर int4 container कुछ points के अंतर में आ जाए, तो quantization validate हो जाएगा; नहीं तो mixed या grouped-scale quantization में invest करने का आधार बनेगा

repository structure और license

  • मुख्य files का structure इस प्रकार है
    • c/glm.c: GLM-5.2 forward, streaming MoE, MTP, serve mode वाला engine
    • c/st.h: pread और fadvise आधारित safetensors reader, mmap इस्तेमाल नहीं
    • c/tok.h: C byte-level BPE tokenizer
    • c/coli: chat, run, bench, convert, info CLI
    • c/iobench.c: engine जैसा अनुभव करता है वैसा parallel disk microbenchmark
    • c/convert_fp8_to_int4.py: disk-safe FP8 → int4 converter
    • c/make_glm_oracle.py: validation के लिए tiny-random oracle generator
    • c/olmoe.c: Stage-A engine और पहला validation target
  • colibrì नाम hummingbird से आया है, क्योंकि वह कम weight के साथ hover करता है और एक दिन में कई फूलों तक जाता है
  • project license Apache 2.0 है, और GLM-5.2 weights Z.ai ने MIT के तहत release किए हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News टिप्पणियाँ

  • सबसे ज़्यादा जिज्ञासा यही है कि असल इस्तेमाल में यह टोकन/सेकंड में मापने लायक है या 1 मिनट में 1 टोकन के करीब है।
    लोकल LLM अगर 1 टोकन/सेकंड जितना धीमा भी हो, तो रात भर किसी प्रोजेक्ट पर छोड़कर 6–8 घंटे बाद नतीजा देखने के तरीके में यह काफ़ी उपयोगी रहा।
    इसके उलट, लिंक में दिए सबसे कम स्पेसिफिकेशन वाले हार्डवेयर पर 0.05–0.1 टोकन/सेकंड के लिए उपयोगी काम लगभग नहीं दिखता।
    फिर भी पूरा कॉन्सेप्ट शानदार है, और उम्मीद है कि आम लोगों की पहुँच वाले हार्डवेयर पर 350B–900B स्तर के मॉडल लोकल चलाने—भले ही 1 टोकन/सेकंड पर—की और कोशिशें होंगी।
    “तेज़ read performance वाला NVMe SSD है, लोकल डिस्क पर एक विशाल मॉडल है, तो पूरा लोड करने के बजाय ज़रूरत पड़ने पर 11GB/टोकन पढ़ें” वाली दिशा पसंद आई।

    • Claude Cowork की वजह से response time का इंतज़ार करने की आदत पड़ गई है, यह मज़ेदार है।
      अब लगता है कि बहुत देर से भी 2028 तक इसे लोकल चला रहे होंगे।
      बजट 10,000 डॉलर से कम रखना है, और आज के टॉप-लेवल मॉडल से टक्कर लेने वाला मॉडल चलाना चाहता हूँ।
    • धीमे लोकल मॉडल या कुछ प्रोजेक्ट्स के लिए chat interface गलत तरीका हो सकता है, और ticket system जैसा रूप ज़्यादा सही हो सकता है।
      Mac Studio या GPU पर पैसा खर्च करने से पहले मौजूदा हार्डवेयर पर इस आइडिया को validate करने का तरीका तय कर लिया है, और लगता है इस हफ्ते proof of concept बना सकता हूँ।
      यह नया आइडिया नहीं है, बस इसे मेरे workflow के हिसाब से चलाने लायक बनाने में समय चाहिए।
    • README में कई तरह के हार्डवेयर पर Colibrì चलाने के benchmarks हैं, और मैंने काफ़ी अच्छे समय देखे हैं।
      इसे लगातार और बेहतर करने की कोशिश कर रहा हूँ।
    • ज़्यादातर प्रोजेक्ट्स के लिए GLM 5.2 मुफ्त में देने वाला cloud इस्तेमाल करना ज़्यादा व्यावहारिक है।
      1 मिनट में 1 टोकन तो free usage limit की तुलना में भी बहुत कम है।
    • सोचता हूँ कि आजकल “आम आदमी” 24GB RAM और 0.5TB NVMe SSD afford कर सकता है या नहीं।

  • Apple Silicon वाले macOS के लिए कुछ ऐसा ही बना रहा हूँ।
    दिशा है Unsloth split GGUF, unified memory में compressed हिस्सों को resident रखना, native Metal kernels, और RAM-only native compressed KV इस्तेमाल करना।
    मेरे 64GB से ज़्यादा 128GB पर यह समझ में आएगा, और तैयार होने पर GitHub पर डालने का इरादा है।

    • 128GB MacBook Pro M4 इंतज़ार में है, इसलिए खुशी से test करना चाहूँगा।

  • image/video generation में भी https://github.com/cretz/thinfer के साथ ऐसी ही strategy आज़माई थी।
    video branch में काफ़ी काम हुआ है।
    ज़रूरत के समय weights को LRU तरीके से अंदर-बाहर लाने वाला inference engine लगातार चाहिए था, इसलिए आखिर में vibe coding से एक ऐसा tool बनाया जो --vram-budget लेता है और उसी के भीतर रहता है।
    mmap किए गए bytes को VRAM के अंदर-बाहर ले जाने की लागत compute के मुकाबले काफ़ी सस्ती निकली, और pipelining व double buffering मिलाने पर लगभग हमेशा bottleneck memory नहीं, compute बन जाता है।
    बेशक, हम कहीं छोटे models इस्तेमाल कर रहे हैं।

    • लगता है krea, wan, hunyan आदि सच में बहुत सारे models डाले हैं।
      जिज्ञासा है कि क्या सभी चलाने के लिए कोई common harness बनाया है।
      यह भी जानना चाहता हूँ कि कौन-से models VRAM budget के भीतर ज़्यादा consistent रहते हैं।

  • llama.cpp 4-bit और उससे कम की कई तरह की quantization सपोर्ट करता है और default रूप से model को mmap करता है, इसलिए पूरे weights को memory में रखने की ज़रूरत नहीं होती।
    operating system ज़रूरत पड़ने पर storage से ले आता है।
    dependencies के बिना बहुत कम code में implement करना बढ़िया है, लेकिन क्या वाकई performance benefit है, यह जानने की इच्छा है।

  • काफ़ी शानदार।
    इस हफ्ते GLM 5.2 के साथ काम किया और यह भी उतना ही impressive लगा।
    कंपनी में हम अगला प्रोजेक्ट शुरू करने से पहले बेहद महंगे hardware पर local execution test कर रहे हैं, और यह अच्छा लगता है कि लोग इस विशाल open source model release को average मशीनों पर चला रहे हैं।
    भले ही अभी practical value बहुत ज़्यादा न हो, काम अच्छा है।

    • कौन-सा hardware है, यह जानना चाहूँगा।

  • LLM की internal structure के बारे में बहुत नहीं जानता, लेकिन सोचता हूँ कि “layers” वाले दूसरे models में भी ऐसी ही structure इस्तेमाल की जा सकती है या नहीं।
    क्या ऐसा संभव है कि एक layer अपना काम खत्म करे तो उसे RAM से हटा दें, फिर अगली layer disk से load करें और पहली layer के result पर activate करें?

  • मेरी मशीन में RAM 64GB और VRAM 24GB है, इसलिए जिज्ञासा है कि क्या इसे ज़्यादा RAM इस्तेमाल करने के लिए tune किया जा सकता है।
    या GPU पर Gemma/Qwen चलाकर GLM-5.2 उससे छोटे tasks delegate करवा सकता है।
    शायद GLM-5.2 को कुछ हद तक retrain भी करना पड़े।
    कई disks parallel में इस्तेमाल करके bandwidth बढ़ाने से speed बढ़ सकती है या नहीं, यह भी जानना चाहता हूँ।
    SSD wear warning में लिखा है कि cold start random reads में लगभग 11GB/टोकन जितना heavy है, read खुद सुरक्षित है लेकिन operating system page cache writes बना सकता है, और बहुत ज़्यादा इस्तेमाल सस्ते SSDs की wear तेज़ कर सकता है।
    सुरक्षित तरीका यह हो सकता है कि model weights के लिए अलग partition बनाया जाए और उसे read-only set किया जाए।
    नहीं पता page cache partition-level होता है या disk-level, लेकिन अगर disk-level है तो read-only data.iso को partition की तरह format करके disk के रूप में mount करने का तरीका भी हो सकता है।

    • मैं एक छोटा laptop इस्तेमाल कर रहा हूँ।
      अगर और disks होते तो वाकई test कर सकता था।
      benchmark आए तो pull request या issue के रूप में डाल दें, हम साथ काम कर सकते हैं।
    • “operating system page cache writes बना सकता है” क्या hallucination है?
      मैं क्या miss कर रहा हूँ? bulk reads writes क्यों बनाएँगे?
    • यह अच्छा idea हो सकता है, और हम साथ काम कर सकते हैं।

  • पेज पर SSD wear warning है https://github.com/JustVugg/colibri#ssd-wear-warning।
    खुद parts assemble करके बनाए desktop PC में SSD बदला जा सकता है, लेकिन soldered SSD इस्तेमाल करने वाले users क्या करें?
    ऐसी applications से बचें, या storage के जल्दी खराब होने की संभावना स्वीकार करके आगे बढ़ें?
    लगता है external storage को expendable SSD की तरह इस्तेमाल करना पड़ेगा।

    • बचना ही सही है।
      soldered SSD वाले laptops में usage को पक्का monitor करना और सावधानी रखनी चाहिए।
      यह project सभी के चलाने की चीज़ से ज़्यादा एक experiment जैसा लगता है, फिर भी काफ़ी शानदार है।
    • मेरी समझ के मुताबिक warning बहुत ज़्यादा memory usage के दौरान swap out के बारे में है।
      यहाँ अंधविश्वास की तरह सोचने की ज़रूरत नहीं है।
      disk activity, खासकर writes, मापे जा सकते हैं।
      उदाहरण के लिए Linux में iostat या vmstat इस्तेमाल कर सकते हैं।
    • यह काफ़ी conservative warning है।
      application writes नहीं करती, इसलिए असल में application खुद SSD को wear नहीं करती।
      बाकी बातें application से अलग सामान्य management practices जैसी हैं।
    • ऐसे use case के लिए external drive इस्तेमाल करना सही लगता है।

  • तकनीकी तौर पर impressive है, लेकिन जिज्ञासा है कि क्या यह सच में practically usable है।

  • मैं भी असल में यही चीज़ बना रहा था, लेकिन extra RAM usage से बचने के लिए पूरे model को memory में mmap करने की दिशा में गया।
    साथ ही Claude से model में Medusahttps://arxiv.org/abs/2401.10774 implement करवाया, ताकि extra model को memory में लाए बिना multi-token prediction का फायदा मिल सके।
    अभी घर पहुँचा हूँ, तो जोड़ दूँ कि सारी modifications llama.cpp में कर रहा हूँ, और अंतिम लक्ष्य इसे ऐसी जगह चलाना है जैसे कोई single-board computer जो NVMe से mmap file handle करता हो।
    पुराने tests के आधार पर मौजूदा configuration की theoretical limit लगभग 1.8 टोकन/सेकंड लगती है, लेकिन extra Medusa head पूरी तरह trained नहीं है और सच कहूँ तो generated tokens में count होता है या नहीं, यह भी ठीक से नहीं जानता।
    आखिरकार idea मिलता-जुलता लगता है, लेकिन मैं अभी LLM parser/runner scratch से लिखना नहीं जानता, इसलिए memory में क्या रखना है यह specify करने के बजाय Linux kernel पर छोड़ दिया।
    अंत में, llama.cpp usage को अपने 32GB में से 16GB तक limit किया है, इसलिए शायद इसे और कम करना भी संभव हो।

    • Colibrì को अभी लगातार सुधार की ज़रूरत है, इसलिए ideas या कुछ और हो तो pull requests, issues, benchmarks—सबका स्वागत है।
    • जिस approach को लेकर मैं जिज्ञासु था, वह ठीक यही थी।