મેં માત્ર 3.2 GB RAM ધરાવતા લેપટોપ પર 284-બિલિયન-પેરામીટર ધરાવતું લેંગ્વેજ મોડલ ચલાવવામાં સફળતા મેળવી છે, જેમાં મેં માત્ર plain C99 અને NVMe ડ્રાઇવનો ઉપયોગ કર્યો છે. તેની યુક્તિ એ હતી કે આખા 160 GB ના ચેકપોઈન્ટને મેમરીમાં લોડ કરવાને બદલે મોડલના એક્સપર્ટ વેટ્સ (expert weights) ને સ્ટ્રીમ કરવા, જે સાબિત કરે છે કે મોટામાં મોટા mixture-of-experts (MoE) મોડલ્સને પણ કન્ઝ્યુમર હાર્ડવેર પર સમાવી શકાય છે.

તે શા માટે મહત્વનું છે

Large language models (LLMs) કોડ જનરેશન, રિસર્ચ આસિસ્ટન્સ અને ઘણું બધું સક્ષમ બનાવે છે, પરંતુ તેમનું કદ સામાન્ય રીતે વપરાશકર્તાઓને ખર્ચાળ multi-GPU સર્વર્સ અથવા ભારે quantisation તરફ ધકેલે છે જે ગુણવત્તાને નુકસાન પહોંચાડે છે. 284 B-પેરામીટર ધરાવતું MoE મોડલ થોડા ગીગાબાઇટ્સ RAM સાથે ચાલી શકે છે તે દર્શાવવાથી શોખ રાખનારાઓ (hobbyists), નાના સ્ટાર્ટઅપ્સ અને બજેટ મર્યાદા ધરાવતા સંશોધકો માટે ગુણવત્તા સાથે બાંધછોડ કર્યા વિના સ્ટેટ-ઓફ-ધ-આર્ટ મોડલ્સ સાથે પ્રયોગ કરવાની તક ખુલે છે.

મોડલ અને હાર્ડવેર બોટલનેક (bottleneck)

DeepSeek-V4-Flash દરેક transformer layer દીઠ 256 એક્સપર્ટ્સમાં 284 B પેરામીટર્સ સ્ટોર કરે છે. રો (raw) ચેકપોઈન્ટ ડિસ્કમાં અંદાજે 160 GB જગ્યા રોકે છે—જે કદ સામાન્ય લેપટોપમાં રહેલી 3.2 GB RAM કરતા ઘણું વધારે છે. પરંપરાગત inference pipelines આખા ચેકપોઈન્ટને મેમરીમાં મેપ કરવાનો પ્રયાસ કરે છે, જેનાથી RAM બજેટ ઝડપથી ખતમ થઈ જાય છે અને સિસ્ટમ ક્રેશ થઈ જાય છે.

એક્સપર્ટ વેટ્સનું સ્ટ્રીમિંગ: મુખ્ય વિચાર

MoE આર્કિટેક્ચર્સ દરેક ટોકન માટે એક્સપર્ટ્સના માત્ર એક નાના સેટને જ સક્રિય કરે છે. DeepSeek-V4-Flash માં, રૂટર (router) દરેક લેયર દીઠ 256 માંથી છ એક્સપર્ટ્સ પસંદ કરે છે. કારણ કે કમ્પ્યુટેશન ક્યારેય નિષ્ક્રિય (dormant) એક્સપર્ટ્સને સ્પર્શતું નથી, તેથી inference engine તેમને લોડ કરવાનું ટાળી શકે છે.

આ અમલીકરણ (implementation) ચેકપોઈન્ટને સ્ટ્રીમિંગ સોર્સ તરીકે ગણે છે. જ્યારે રૂટર નક્કી કરે છે કે વર્તમાન ટોકન માટે કયા એક્સપર્ટ્સની જરૂર છે, ત્યારે એન્જિન તે વેટ બ્લોક્સને NVMe ડ્રાઇવમાંથી RAM માં રહેલા LRU (least-recently-used) કેશ (cache) માં ખેંચી લે છે. જો કેશ પૂરતી મોટી હોય, તો સળંગ ટોકન્સમાં એ જ એક્સપર્ટ્સનો ફરીથી ઉપયોગ થાય છે, જેનાથી cache hits મળે છે; જો કેશ ખૂબ નાની હોય, તો એન્જિન વારંવાર ડિસ્કમાંથી વાંચન કરે છે. પરિણામ એ છે કે 3.23 GB નો પીક મેમરી ફૂટપ્રિન્ટ મળે છે, જે લેપટોપની મર્યાદામાં છે, જ્યારે ફૂલ-પ્રિસિઝન વેટ્સ જળવાઈ રહે છે અને કોઈ GPU એક્સિલરેશનની જરૂર પડતી નથી.

અમલીકરણમાંથી મેળવેલા કઠિન પાઠ

1. પ્રવાહી (Fluent) આઉટપુટ એ સાચા હોવાનો પુરાવો નથી એક બગી (buggy) કર્નલ હજુ પણ વ્યાજબી દેખાતા વાક્યો બનાવી શકે છે, ખાસ કરીને જ્યારે મોડલના લેંગ્વેજ પેટર્ન ન્યુમેરિકલ ભૂલોને છુપાવી દે છે. મેં દરેક 14 નિર્ણાયક કામગીરીને તાજા PyTorch રેફરન્સ સામે ચકાસી હતી, અને ખાતરી કરી હતી કે ન્યુમેરિકલ તફાવત ખૂબ જ નાની મર્યાદામાં રહે. આ સ્ટેપને છોડી દેવાથી સૂક્ષ્મ ભૂલો છૂટી ગઈ હોત.

2. સમાન નિષ્ફળતાના પ્રકારો (Shared failure modes) તમારા ટેસ્ટને છેતરી શકે છે મેમરી-કરપ્શન બગને રૂટિંગ પસંદગીઓને માત્ર થોડા એક્સપર્ટ્સ સુધી મર્યાદિત કરી દીધી હતી, જેનાથી કેશ-હિટ રેટ 52% થી વધીને 95% થઈ ગયો અને તે ખૂબ જ ઝડપી હોવાનો ભ્રમ પેદા કર્યો. કારણ કે ટેસ્ટ સ્યુટ એ જ બગી કોડના બે વર્ઝનની સરખામણી કરી રહ્યો હતો, તેથી તે સમસ્યાને ઓળખી શક્યો નહીં. તેનો ઉપાય એ છે કે એક સ્વતંત્ર રેફરન્સ પાથ ઉમેરવો—એવો કોડ જે પ્રાથમિક અમલીકરણ સાથે કોઈ લોજિક શેર કરતો નથી—જેથી સમાન ખામી અજાણતા પસાર ન થઈ શકે.

3. ઓપ્ટિમાઇઝ કરતા પહેલા માપો મેં ધાર્યું હતું કે મેમરી કોપીમાં 1 ms લાગશે અને તેને ઓપ્ટિમાઇઝ કરવામાં સમય વિતાવ્યો. પ્રોફાઇલિંગ દ્વારા જાણવા મળ્યું કે આ કામગીરીમાં વાસ્તવમાં 3.6 ms લાગતા હતા, અથવા કુલ ઇન્ફરન્સ સમયના 22%. પાઠ: પર્ફોર્મન્સ-ક્રિટિકલ વિભાગો માટે ક્યારેય અંતર્જ્ઞાન (intuition) પર આધાર રાખશો નહીં; ચોક્કસ માપન એ એકમાત્ર વિશ્વસનીય માર્ગદર્શક છે.

4. તાપમાનની સ્થિતિ થ્રુપુટ (throughput) ને નોંધપાત્ર રીતે અસર કરે છે "ગરમ થયેલા" (heat-soaked) લેપટોપ પર બેન્ચમાર્ક ચલાવવાથી ઠંડા મશીન કરતા ત્રણ ગણો વધુ સમય લાગ્યો. વધતા તાપમાને NVMe ડ્રાઇવના થ્રુપુટને ઘટાડ્યો અને CPU ને ધીમું પાડ્યું, જેનાથી પરિણામો ખોટા પડ્યા. જ્યારે પણ તમે પર્ફોર્મન્સના આંકડા પ્રકાશિત કરો ત્યારે સિસ્ટમની થર્મલ સ્થિતિની નોંધ લો.

આંકડાઓ કેવા દેખાય છે

  • ડિસ્ક પર મોડલનું કદ: ~160 GB
  • પીક RAM વપરાશ: 3.23 GB
  • દરેક ટોકન દીઠ એક્સપર્ટ્સ: 6 (256 માંથી)
  • કેશ-હિટ રેટ: RAM સાથે બદલાય છે; 3.2 GB સાથે તે વધઘટ થાય છે.
  • કોઈ quantisation નથી: ફૂલ-પ્રિસિઝન વેટ્સ સ્ટ્રીમ કરવામાં આવે છે, જે મોડલની ગુણવત્તા જાળવી રાખે છે.

જો RAM બજેટ અંદાજે 3.21 GB થી નીચે જાય છે, તો કેશ ક્યારેય ભરાતી નથી અને એન્જિન દરેક ટોકન પર સ્ટ્રીમ કરે છે, જેનાથી પર્ફોર્મન્સમાં મોટો ઘટાડો થાય છે.

સોર્સ કોડ github.com/ronak-create/deepseek-v4-in-c પર જાહેરમાં ઉપલબ્ધ છે. જે કોઈ આ પ્રયોગને ફરીથી કરવા અથવા વિસ્તારવા માંગતા હોય તેમના માટે t.me/GyaanSetuAi પર એક કોમ્યુનિટી ડિસ્કશન ચેનલ છે.

મુખ્ય સારાંશ (Takeaway)

MoE મોડેલ ખરેખર જે એક્સપર્ટ્સનો ઉપયોગ કરે છે તેને જ સ્ટ્રીમ કરવાથી, 284 B-પેરામીટર ધરાવતું LLM ક્વોન્ટાઇઝેશન અથવા GPU એક્સિલરેશન વગર એક સામાન્ય લેપટોપ પર ચલાવી શકાય છે. આ પ્રયોગ દર્શાવે છે કે ડેટાનું ચતુર સંચાલન, સખત વેલિડેશન અને શિસ્તબદ્ધ માપન એવા હાર્ડવેર અવરોધોને ટાળી શકે છે જેને ઘણા લોકો અપરિવર્તનીય માને છે.