मी केवळ plain C99 आणि NVMe drive चा वापर करून, फक्त 3.2 GB RAM असलेल्या लॅपटॉपवर 284-billion-parameter भाषा मॉडेल यशस्वीरित्या चालवले. मुख्य युक्ती म्हणजे संपूर्ण 160 GB चे checkpoint मेमरीमध्ये लोड करण्याऐवजी मॉडेलचे expert weights स्ट्रीम करणे ही होती, ज्यामुळे हे सिद्ध झाले की अगदी सर्वात मोठे mixture-of-experts (MoE) मॉडेल्स देखील ग्राहक उपकरणांवर (consumer hardware) वापरले जाऊ शकतात.

हे का महत्त्वाचे आहे

Large language models (LLMs) कोड जनरेशन, रिसर्च असिस्टन्स आणि बरेच काही सक्षम करतात, परंतु त्यांच्या आकारामुळे वापरकर्त्यांना सहसा महागड्या multi-GPU सर्व्हरवर किंवा गुणवत्तेवर परिणाम करणाऱ्या जड quantisation वर अवलंबून राहावे लागते. 284 B-parameter MoE मॉडेल काही GB RAM मध्ये चालू शकते हे दाखवणे, छंद जोपासणाऱ्यांसाठी (hobbyists), लहान स्टार्टअप्स आणि मर्यादित बजेट असलेल्या संशोधकांसाठी गुणवत्तेशी तडजोड न करता state-of-the-art मॉडेल्सवर प्रयोग करण्यासाठी नवीन मार्ग मोकळे करते.

मॉडेल आणि हार्डवेअरमधील अडथळा (bottleneck)

DeepSeek-V4-Flash प्रत्येक transformer layer मध्ये 256 experts मध्ये 284 B parameters साठवते. मूळ checkpoint डिस्कवर साधारणपणे 160 GB जागा व्यापते—हा आकार एका सामान्य लॅपटॉपमधील 3.2 GB RAM च्या तुलनेत खूप मोठा आहे. पारंपारिक inference pipelines संपूर्ण checkpoint मेमरीमध्ये मॅप करण्याचा प्रयत्न करतात, ज्यामुळे RAM लवकर संपते आणि सिस्टिम क्रॅश होते.

Streaming expert weights: मुख्य कल्पना

MoE आर्किटेक्चर प्रत्येक token साठी तज्ज्ञांचा (experts) फक्त एक छोटा गट सक्रिय करते. DeepSeek-V4-Flash मध्ये, router प्रत्येक layer मधील 256 पैकी सहा experts निवडतो. कारण गणना (computation) कधीही निष्क्रिय (dormant) experts ला स्पर्श करत नाही, त्यामुळे inference engine त्यांना लोड करणे टाळू शकते.

ही अंमलबजावणी (implementation) checkpoint ला स्ट्रीमिंग सोर्स म्हणून हाताळते. जेव्हा router ठरवतो की सध्याच्या token साठी कोणते experts आवश्यक आहेत, तेव्हा engine ते weight blocks NVMe drive मधून RAM मध्ये असलेल्या LRU (least-recently-used) cache मध्ये खेचते. जर cache पुरेसा मोठा असेल, तर सलग tokens साठी तेच experts पुन्हा वापरले जातात, ज्यामुळे cache hits मिळतात; जर cache खूप लहान असेल, तर engine वारंवार डिस्कवरून डेटा वाचते. याचा परिणाम म्हणून, पूर्ण-precision weights राखून आणि कोणत्याही GPU acceleration शिवाय, peak memory footprint 3.23 GB इतका राहतो, जो लॅपटॉपच्या मर्यादेत आहे.

अंमलबजावणीतून मिळालेले कठीण धडे

1. ओघवती उत्तरे (Fluent output) म्हणजे अचूकतेचा पुरावा नाही एक दोषपूर्ण (buggy) kernel अजूनही विश्वासार्ह वाटणारी वाक्ये तयार करू शकते, विशेषतः जेव्हा मॉडेलचे भाषिक नमुने (language patterns) संख्यात्मक त्रुटींना झाकून टाकतात. मी प्रत्येक 14 महत्त्वाच्या ऑपरेशन्सची एका नवीन PyTorch reference सोबत पडताळणी केली आणि संख्यात्मक फरक (numerical difference) अत्यंत कमी मर्यादेत आहे याची खात्री केली. हे पाऊल चुकले असते तर सूक्ष्म त्रुटी (subtle drift) लक्षात आल्या नसत्या.

2. सामायिक त्रुटी (Shared failure modes) तुमच्या चाचण्यांना फसवू शकतात मेमरी-करप्शन बगमुळे routing निवडी काही मोजक्याच experts वर मर्यादित झाल्या, ज्यामुळे cache-hit rate 52% वरून 95% पर्यंत वाढला आणि प्रचंड वेग वाढल्याचा आभास निर्माण झाला. कारण test suite मध्ये एकाच दोषपूर्ण कोडच्या दोन आवृत्त्यांची तुलना केली जात होती, त्यामुळे ही समस्या लक्षात आली नाही. याचे उपाय म्हणजे एक स्वतंत्र reference path जोडणे—असा कोड ज्याचा मुख्य अंमलबजावणीशी कोणताही संबंध नसेल—जेणेकरून सामायिक दोष दुर्लक्षित राहणार नाहीत.

3. ऑप्टिमाइझ करण्यापूर्वी मोजमाप करा मी असे गृहीत धरले की मेमरी कॉपीला 1 ms लागतील आणि ते ऑप्टिमाइझ करण्यात वेळ घालवला. Profiling वरून असे दिसून आले की त्या ऑपरेशनला प्रत्यक्षात 3.6 ms लागत होते, म्हणजेच एकूण inference वेळेच्या 22%. धडा: कामगिरीसाठी महत्त्वाच्या (performance-critical) भागांसाठी कधीही अंतर्ज्ञानावर (intuition) अवलंबून राहू नका; अचूक मोजमाप हा एकमेव विश्वसनीय मार्ग आहे.

4. थर्मल स्थिती (Thermal conditions) थ्रूपुटवर मोठ्या प्रमाणात परिणाम करते "गरम झालेल्या" (heat-soaked) लॅपटॉपवर बेंचमार्क चालवल्यामुळे थंड मशीनच्या तुलनेत तीन पटीने जास्त वेळ लागला. वाढलेल्या तापमानामुळे NVMe drive चा थ्रूपुट कमी झाला आणि CPU मंदावला, ज्यामुळे निकाल बदलले. जेव्हा तुम्ही कामगिरीचे आकडे प्रकाशित करता, तेव्हा सिस्टिमची थर्मल स्थिती नोंदवा.

आकडेवारी काय दर्शवते

  • डिस्कवरील मॉडेलचा आकार: ~160 GB
  • पीक RAM वापर: 3.23 GB
  • प्रत्येक token साठी experts: 6 (256 पैकी)
  • Cache-hit rate: RAM नुसार बदलतो; 3.2 GB सह तो बदलत राहतो.
  • No quantisation: पूर्ण-precision weights स्ट्रीम केले जातात, ज्यामुळे मॉडेलची गुणवत्ता टिकून राहते.

जर RAM बजेट सुमारे 3.21 GB च्या खाली गेले, तर cache कधीही भरत नाही आणि engine प्रत्येक token साठी स्ट्रीमिंग करते, ज्यामुळे कामगिरीमध्ये मोठी घट होते.

सोर्स कोड github.com/ronak-create/deepseek-v4-in-c वर सार्वजनिकरित्या उपलब्ध आहे. प्रयोग पुन्हा करण्यासाठी किंवा विस्तार करण्यासाठी t.me/GyaanSetuAi वर एक कम्युनिटी डिस्कशन चॅनेल उपलब्ध आहे.

निष्कर्ष (Takeaway)

MoE मॉडेल प्रत्यक्षात वापरत असलेल्या तज्ज्ञांना (experts) स्ट्रीम केल्यामुळे, २८४ अब्ज (B) पॅरामीटर असलेले LLM, क्वांटायझेशन किंवा GPU एक्सीलरेशनशिवाय एका सामान्य लॅपटॉपवर चालवता येते. हा प्रयोग दर्शवतो की, चतुर डेटा मुव्हमेंट, कडक प्रमाणीकरण आणि शिस्तबद्ध मोजमाप याद्वारे अशा हार्डवेअर मर्यादांना बगल दिली जाऊ शकते, ज्या अनेकजण अपरिवर्तनीय मानतात.