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

मूल लेख ↗ Hacker News चर्चा ↗

प्रोजेक्ट की अवधारणा और हैकर भावना

  • यह टूल NVMe से वज़न आक्रामक रूप से स्ट्रीम करके, सब कुछ RAM में रखने के बजाय, “धीमे” / उपभोक्ता-स्तर के हार्डवेयर पर बहुत बड़े GLM 5.2 MoE मॉडल चलाता है।
  • कई टिप्पणियाँ इसके न्यूनतम, लगभग obfuscated इम्प्लीमेंटेशन और उन चीज़ों को चलाने की सामान्य “जहाँ उन्हें चलाने के लिए नहीं बनाया गया था” वाली भावना की सराहना करती हैं।
  • कई लोग ऐसे ही प्रयोगों (कस्टम स्ट्रीमिंग इंजन, mmap-आधारित रनर, Medusa/MTP, Rust पोर्ट्स) का ज़िक्र करते हैं और इसे एक व्यापक प्रवृत्ति का हिस्सा मानते हैं।

प्रदर्शन और व्यावहारिकता

  • लो-एंड हार्डवेयर पर रिपोर्ट की गई गति (≈0.05–0.1 tok/s) कुछ लोगों को इंटरैक्टिव उपयोग के लिए बहुत धीमी लगती है, हालांकि अन्य लोग 1 tok/s को भी रातभर या बैच वर्कलोड के लिए स्वीकार्य मानते हैं।
  • उच्च-स्तरीय CPU, हाई-RAM सर्वर, और GPU पर बेंचमार्क में रुचि है; कुछ लोगों को उम्मीद है कि पर्याप्त RAM होने पर एक सामान्य llama.cpp सेटअप SSD स्ट्रीमिंग से बेहतर प्रदर्शन कर सकता है।
  • अन्य प्रोजेक्ट्स (llama.cpp, flash-moe, hypura, fastllm) से तुलना सामने आती है, और एक खुला प्रश्न यह है कि क्या यह तरीका वास्तव में उन परिपक्व इंजनों से तेज़ है जो पहले से mmap और quantization का उपयोग करते हैं।

हार्डवेयर, किफ़ायतीपन, और विकल्प

  • इस पर बहस होती है कि क्या “सामान्य लोग” 24+ GB RAM और बड़े NVMe ड्राइव का खर्च उठा सकते हैं, खासकर बढ़ती मेमोरी कीमतों को देखते हुए।
  • सुझावों में 512GB–1TB RAM वाले इस्तेमाल किए गए rackmount सर्वर, Mac Studio-स्तर की मशीनें, या cloud-hosted GLM 5.2 शामिल हैं, जिन्हें अक्सर अधिक व्यावहारिक माना जाता है।
  • कई उपयोगकर्ता RAID0/parallel SSDs, hybrid CPU/GPU सेटअप, और Apple Silicon पर unified memory का लाभ उठाने जैसे विचारों को खोजते हैं।

SSD घिसावट, swapping, और सुरक्षा

  • README संभावित SSD wear के बारे में चेतावनी देता है; इससे soldered SSD वाले लैपटॉपों के लिए चिंता पैदा होती है और external “burner” drives के उपयोग के सुझाव आते हैं।
  • व्याख्याएँ अलग-अलग हैं: कुछ लोग जोखिम को swap और page cache eviction (“spilling”) से जोड़ते हैं; अन्य लोग इस बात पर ज़ोर देते हैं कि ऐप खुद केवल reads करता है और चेतावनी रूढ़िवादी है।
  • चर्चा किए गए mitigation: swap बंद करना, swappiness को ट्यून करना, read-only partitions या images। भारी reads से होने वाली wear की सटीक मात्रा अभी भी कुछ हद तक अस्पष्ट है।

धीमे मॉडलों के लिए इंटरफ़ेस और वर्कफ़्लो

  • कई टिप्पणीकार तर्क देते हैं कि chat UIs बहुत धीमे local models के लिए उपयुक्त नहीं हैं और इसके बजाय ticketing/job systems का सुझाव देते हैं।
  • विचारों में orchestrators शामिल हैं जो कार्यों को worker agents को भेजते हैं, और email तथा ticket queues के माध्यम से साधारण इंटीग्रेशन, ताकि मॉडल को एक धीमे लेकिन भरोसेमंद teammate की तरह इस्तेमाल किया जा सके।

MoE- और architecture-विशिष्ट प्रश्न

  • क्लस्टर में MPI के ज़रिए experts को वितरित करने के बारे में प्रश्न उठते हैं; उत्तर: सैद्धांतिक रूप से संभव है, लेकिन छोटे क्लस्टरों पर network latency संभवतः हावी हो जाएगी।
  • सभी experts में से केवल एक को छोड़कर बाकी को disable करना संभव माना जाता है, लेकिन इससे गुणवत्ता बहुत गिर जाएगी; इसके बजाय एक छोटे dense model का उपयोग करने की सिफारिश की जाती है.