उपयोगकर्ता के निकट LLM-इन्फ़रेंस के लिए शायद ही कभी तैयार "भारी" सर्वर उपलब्ध होते हैं। आमतौर पर यह Edge-डिवाइस, गेटवे और fog-नोड्स का मिश्रण होता है, जिनमें अलग-अलग मेमोरी और कंप्यूटिंग क्षमता होती है। मॉडल को इस तरह तैनात करना जैसे कि वह हमेशा एक ही डिवाइस पर समा जाता है, वास्तविकता से आँखें मूँद लेने जैसा है: मॉडल या तो फिट नहीं होता, या अस्वीकार्य विलंब के साथ काम करता है, या महंगे संसाधन बेकार पड़े रहते हैं। E2LLM फ्रेमवर्क इसके लिए एक अधिक व्यावहारिक रास्ता सुझाता है।
क्लासिकल परिदृश्य उपयुक्त क्यों नहीं है
LLM की सर्विसिंग के पारंपरिक तरीके अक्सर यह मानकर चलते हैं कि पूरा मॉडल एक ही मशीन पर रहता है। क्लाउड में यह आमतौर पर काम करता है, लेकिन Edge/Fog-वातावरण में नोड्स कमज़ोर और अधिक विषम होते हैं। कुछ डिवाइस में वेट्स के लिए पर्याप्त मेमोरी हो सकती है, लेकिन वे कंप्यूटिंग नहीं खींच पाते; अन्य — इसके विपरीत, तेज़ होते हैं, लेकिन सीमित क्षमता के साथ। यदि मॉडल को सभी उपलब्ध डिवाइसों पर बस "बिखेरने" की कोशिश की जाए, तो समन्वय, संचार और उपयोग में समस्याएँ शुरू हो जाती हैं।
इसके अलावा, व्यवहार में एक साथ तीन चीज़ों की ज़रूरत होती है:
- पूर्वानुमानित कम विलंबता,
- संसाधनों का किफ़ायती उपयोग,
- तैनाती की उचित लागत।
ये आपस में टकराती हैं, इसलिए एकतरफा अनुकूलन नहीं, बल्कि समझौता ज़रूरी है। E2LLM इसी समझौते के इर्द-गिर्द बनाया गया है।
रिप्लिका और भूमिकाएँ: E2LLM सीमाओं से कैसे निपटता है
E2LLM का मुख्य विचार — एक मॉडल को सभी नोड्स के बीच बाँटना नहीं है, बल्कि डिवाइसों को रिप्लिका में इकट्ठा करना है। प्रत्येक रिप्लिका के अंदर मॉडल की पूरी कॉपी संग्रहीत होती है, और फिर उसे मॉडल पैरेललिज़्म की मदद से समूह के सदस्यों के बीच वितरित किया जाता है। यह मेमोरी की बर्बादी जैसा लगता है, लेकिन वास्तव में यह दोहराव फॉल्ट-टॉलरेंस बढ़ाता है और कई अनुरोधों को समानांतर में सर्विस करने की अनुमति देता है।
इसके बाद LLM-इन्फ़रेंस की संरचना का ज्ञान काम आता है। इसके दो चरण होते हैं जिनमें लोड का प्रोफ़ाइल अलग होता है: prefill, जब मॉडल सक्रिय रूप से इनपुट टोकन प्रोसेस करता है और अटेंशन कैश बनाता है, और decode, जब वह आउटपुट टोकन जनरेट करता है। इन चरणों के लिए अलग-अलग संसाधनों की आवश्यकता होती है: prefill पीक कंप्यूटिंग पावर के प्रति संवेदनशील है, decode — मेमोरी बैंडविड्थ और डेटा ट्रांसफर की लेटेंसी के प्रति।
हर समूह को दोनों काम करने के लिए मजबूर करने के बजाय, E2LLM रिप्लिका को विशेष भूमिकाएँ सौंपता है। कुछ prefill-रिप्लिका बन जाती हैं और आने वाले अनुरोधों को तेज़ी से प्रोसेस करती हैं, अन्य — decoder-रिप्लिका बन जाती हैं और सुचारू जनरेशन के लिए ज़िम्मेदार होती हैं। यह विभाजन किसी विशेष हार्डवेयर के लिए "असुविधाजनक" चरण पर संसाधन खर्च नहीं करने देता।
डिवाइसों के समूह कैसे बनते हैं
पहले मिलने वाले डिवाइसों को लेकर उन्हें रिप्लिका कह देना संभव नहीं है। E2LLM पहले यह तय करता है कि किन नोड्स को वास्तव में जोड़ा जाना चाहिए। इसके लिए जेनेटिक एल्गोरिदम का उपयोग किया जाता है: यह क्लस्टर के विकल्पों को आज़माता है और सिस्टम के अंतिम प्रदर्शन को ध्यान में रखते हुए धीरे-धीरे उन्हें बेहतर बनाता है।
जब क्लस्टर तय हो जाता है, तो उसके अंदर यह समझना होता है कि मॉडल को सदस्यों के बीच कैसे विभाजित किया जाए। यहाँ डायनामिक प्रोग्रामिंग काम करती है: यह विभाजन की ऐसी रणनीति खोजती है जिसमें डिवाइसों के बीच डेटा ट्रांसफर में "बाधाएँ" न्यूनतम हों। दूसरे शब्दों में, ऊपरी स्तर रिप्लिका की संरचना चुनने से संबंधित है, और निचला स्तर हार्डवेयर की विशिष्ट संरचना के लिए मॉडल की इष्टतम कटिंग से।
व्यवहार में इसका क्या लाभ है
लेखकों ने इस दृष्टिकोण की तुलना बेसलाइन समाधान Splitwise से की, जो prefill और decode को भी अलग करता है, लेकिन विषम वातावरण के साथ कम लचीले ढंग से काम करता है। प्रयोगों से पता चला कि E2LLM कार्यभार में बदलावों के लिए अच्छी तरह अनुकूलित होता है। यह विशेष रूप से तब ध्यान देने योग्य होता है जब इनपुट और आउटपुट टोकन की लंबाई बहुत भिन्न होती है: उदाहरण के लिए, छोटे अनुरोध आते हैं, लेकिन लंबे उत्तरों की आवश्यकता होती है, और फिर लोड अचानक बदल जाता है।
उच्च लोड पर, नया दृष्टिकोण Splitwise की तुलना में औसत प्रतीक्षा समय को 50% से अधिक कम कर देता है। इसका मतलब है कि उपयोगकर्ताओं को जनरेशन के लिए कतार में कम खड़ा होना पड़ता है, और Edge/Fog-डिवाइस स्वयं अधिक सार्थक रूप से काम करते हैं, न कि इन्फ़रेंस के दोनों चरणों को समान रूप से सर्विस करने की कोशिश करते हैं।
निष्कर्ष
E2LLM दिखाता है कि परिधि पर LLM को कुशलतापूर्वक चलाने के लिए केवल किसी एक डिवाइस की शक्ति ही महत्वपूर्ण नहीं है, बल्कि यह भी कि डिवाइस कैसे संयोजित हैं और भूमिकाओं में कैसे वितरित हैं। रिप्लिका स्तर पर पूरे मॉडल का दोहराव, prefill और decode के पृथक्करण के साथ — यह एक सचेत trade-off है: कहीं मेमोरी का त्याग करना पड़ता है, लेकिन बदले में सिस्टम को स्थिर प्रदर्शन और कम विलंबता मिलती है।
व्यावहारिक परिदृश्यों के लिए मुख्य निष्कर्ष: विषम वातावरण में पूरे मॉडल को एक नोड में ठूँसने या उसे सभी पर समान रूप से फैलाने की कोशिश नहीं करनी चाहिए। उपलब्ध हार्डवेयर से विशेष समूह बनाने चाहिए और उनके भीतर तय करना चाहिए कि कंप्यूटेशन कैसे वितरित किया जाए। ठीक इसी तरह LLM-इन्फ़रेंस बड़े क्लाउड क्लस्टर के बाहर वास्तव में व्यावहारिक बनता है।
