परिचय
नई परियोजनाओं पर AI वर्कफ़्लो टीमों द्वारा उठाए जा सकने वाले सबसे बड़े लागत-बचत कदमों में से एक है, जब उचित हो, सर्वरलेस इन्फ्रेंस का लाभ उठाना। पारंपरिक रूप से, AI मॉडलों को 24/7 चलाने के लिए एक डेडिकेटेड GPU की आवश्यकता होती है जिसका भुगतान प्रति घंटे के आधार पर किया जाता है। सर्वरलेस इन्फ्रेंस एंडपॉइंट्स के साथ, टीमों के पास कई ओपन सोर्स मॉडलों को प्रति-घंटा भुगतान करने और स्वयं सेटअप और रखरखाव प्रबंधित करने के बजाय पे-पर-टोकन आधार पर उपयोग करने का विकल्प होता है। इसने नए उत्पाद को चलाने की लागत को कम कर दिया है क्योंकि यह टीमों को केवल अपने उपयोग के लिए भुगतान करने और आवश्यकतानुसार स्केल करने की अनुमति देता है।
जबकि सर्वरलेस आर्किटेक्चर कुछ समय से अस्तित्व में है, कस्टम या फाइन-ट्यून मॉडल वाली टीमें अभी भी अक्सर GPU उपयोग के लिए प्रति घंटा दर का भुगतान करती हैं। हालांकि, फाइन-ट्यून मॉडलों को होस्ट करना और उन्हें पे-पर-टोकन बिलिंग के साथ सर्वरलेस एंडपॉइंट के माध्यम से वितरित करना संभव है। हम बताएंगे कि फाइन-ट्यून मॉडलों को सर्वरलेस तरीके से होस्ट करना कैसे संभव है और ऐसा करने के लाभ और नुकसान।
मुख्य निष्कर्ष
- LoRA जैसे पैरामीटर-कुशल फाइन-ट्यूनिंग तरीके छोटे एडाप्टर वेट्स उत्पन्न करके कस्टम मॉडलों की सर्वरलेस होस्टिंग को व्यावहारिक बनाते हैं जिन्हें एक साझा, फ्रोजन बेस मॉडल के ऊपर लेयर्ड किया जा सकता है। इसका मतलब है कि प्लेटफॉर्म एक ही GPU से सैकड़ों फाइन-ट्यून वेरिएंट की सेवा कर सकते हैं, जिससे प्रति-मॉडल डेडिकेटेड डेप्लॉयमेंट की आवश्यकता समाप्त हो जाती है।
- बर्स्टी या अप्रत्याशित ट्रैफिक वाली टीमें सर्वरलेस फाइन-ट्यून एंडपॉइंट्स पर स्विच करके इन्फ्रेंस लागत को कम कर सकती हैं, GPU को चौबीसों घंटे चलाने के बजाय केवल उनके द्वारा उपयोग किए जाने वाले टोकन के लिए भुगतान करके। डेप्लॉयमेंट भी तेज़ है, क्योंकि एक प्रशिक्षित एडाप्टर को एक प्रबंधित प्लेटफॉर्म पर अपलोड करने से मिनटों में एक लाइव API एंडपॉइंट उत्पन्न होता है बिना किसी इन्फ्रास्ट्रक्चर सेटअप के।
- फाइन-ट्यून मॉडलों के साथ सर्वरलेस इन्फ्रेंस का मुख्य ट्रेडऑफ कोल्ड स्टार्ट है, जहां एक निष्क्रिय एडाप्टर को अनुरोधों की सेवा करने से पहले स्टोरेज से पुनः लोड किया जाना चाहिए, जिससे कुछ सौ मिलीसेकंड तक की लेटेंसी जुड़ जाती है। इसे आवधिक कीप-अलाइव अनुरोधों के साथ कम किया जा सकता है, और देरी पूर्ण मॉडल कोल्ड स्टार्ट की तुलना में छोटी होती है क्योंकि केवल हल्के एडाप्टर वेट्स को लाने की आवश्यकता होती है।
समर्थित फाइन-ट्यूनिंग विधियाँ
यह स्पष्ट करना महत्वपूर्ण है कि जब हम इस संदर्भ में "फाइन-ट्यूनिंग" कहते हैं, तो हम पारंपरिक पूर्ण फाइन-ट्यूनिंग का मतलब नहीं रखते, जहां नए डेटा पर एक मॉडल के सभी वेट्स को खरोंच से पुनः प्रशिक्षित किया जाता है। पूर्ण फाइन-ट्यूनिंग महंगी, समय लेने वाली है, और एक पूरी तरह से नया मॉडल उत्पन्न करती है जो मूल जितना ही बड़ा है। उस मॉडल को सर्वरलेस तरीके से होस्ट करना अव्यावहारिक है क्योंकि इसे कई अलग-अलग उपयोगकर्ताओं के बीच साझा नहीं किया जा सकता। इसके लिए अपने स्वयं के डेडिकेटेड GPU डेप्लॉयमेंट की आवश्यकता होती है।
पैरामीटर-कुशल फाइन-ट्यूनिंग (PEFT) सभी वेट्स को पुनः प्रशिक्षित करने के बजाय केवल वेट्स के एक छोटे उपसमूह को अपडेट करता है, मूल मॉडल को फ्रोजन छोड़ देता है। यह एक बहुत छोटा अतिरिक्त वेट सेट उत्पन्न करता है जो अनुकूलन का प्रतिनिधित्व करता है, जबकि भारी बेस मॉडल अपरिवर्तित रहता है और कई अलग-अलग, असंबंधित उपयोगकर्ताओं के बीच साझा करने योग्य होता है।
सबसे व्यापक रूप से उपयोग की जाने वाली PEFT विधि लो-रैंक एडाप्टेशन (LoRA) है। मौजूदा मॉडल वेट्स को सीधे संशोधित करने के बजाय, LoRA फ्रोजन बेस मॉडल के ऊपर छोटे प्रशिक्षण योग्य एडाप्टर मैट्रिक्स जोड़ता है। ये एडाप्टर बेस मॉडल के दसियों या सैकड़ों गीगाबाइट की तुलना में केवल कुछ मेगाबाइट वेट्स में कार्य-विशिष्ट व्यवहार को कैप्चर करते हैं। LoRA कई वेरिएंट में भी आता है, जिसमें QLoRA, DoRA, और LoRA+ शामिल हैं, जो सभी सर्वरलेस इन्फ्रेंस प्लेटफॉर्म द्वारा व्यापक रूप से समर्थित हैं।
क्योंकि बेस मॉडल फ्रोजन है और सभी उपयोगकर्ताओं के लिए समान है, एक प्लेटफॉर्म इसे एक बार GPU मेमोरी में लोड कर सकता है और साझा कर सकता है। प्रत्येक उपयोगकर्ता का LoRA एडाप्टर फिर अनुरोध के समय ऊपर लोड किया जा सकता है, जिससे एक ही GPU से सैकड़ों फाइन-ट्यून वेरिएंट की सेवा करना व्यावहारिक हो जाता है। यह ध्यान रखना भी महत्वपूर्ण है कि फाइन-ट्यून मॉडलों पर सर्वरलेस इन्फ्रेंस का समर्थन करने वाले प्लेटफॉर्म आमतौर पर केवल विशिष्ट बेस मॉडल के साथ इसका समर्थन करते हैं। इसलिए आपके पास एक LoRA एडाप्टर होना चाहिए जिसे उनके समर्थित बेस मॉडल में से एक पर प्रशिक्षित किया गया हो।
एकाधिक LoRA एडाप्टर का प्रबंधन
LoRA एडाप्टर वेट्स (आमतौर पर प्रत्येक 10-100 MB के बीच) को इन्फ्रेंस सर्वर द्वारा प्रबंधित फास्ट ऑब्जेक्ट स्टोरेज या इन-मेमोरी कैश में संग्रहीत किया जाता है। जब किसी विशेष एडाप्टर के लिए अनुरोध आता है, तो सर्विंग सिस्टम उन वेट्स को लाता है और उन्हें फॉरवर्ड पास में ऑन-द-फ्लाई फ्यूज करता है।
यह फ्यूजन प्रक्रिया हल्की है। प्रत्येक ट्रांसफॉर्मर लेयर पर जहां LoRA लागू होता है, एडाप्टर दो छोटी मैट्रिक्स जोड़ता है जो लेयर के आउटपुट के लिए लो-रैंक सुधार उत्पन्न करते हैं। इन्फ्रेंस के दौरान, सर्वर बेस लेयर के आउटपुट की गणना करता है, फिर कुछ अतिरिक्त CUDA ऑपरेशन में LoRA सुधार जोड़ता है। बेस वेट्स कभी संशोधित नहीं होते, इसलिए अनुरोधों के बीच एडाप्टर स्वैप करने के लिए केवल GPU रजिस्टरों में उन छोटी मैट्रिक्स जोड़े को बदलने की आवश्यकता होती है, बजाय बेस मॉडल को पुनः लोड करने या CUDA कर्नेल को पुनः आरंभ करने के।
सबसे बड़ी चुनौतियों में से एक एक ही इंस्टेंस पर काम करने वाले सैकड़ों एडाप्टर के साथ मेमोरी प्रबंधन है। इन्फ्रेंस सर्वर को सबसे हाल ही में और सबसे अधिक उपयोग किए जाने वाले एडाप्टर वेट्स के एक छोटे रेजिडेंट कैश को सीधे VRAM में बनाए रखने की आवश्यकता होती है। अन्य एडाप्टर VRAM से हटा दिए जाते हैं और CPU RAM या ऑब्जेक्ट स्टोरेज में वापस संग्रहीत किए जाते हैं, जिससे कुछ सौ मिलीसेकंड का रीलोड समय दंड होता है।
बैचिंग प्रक्रिया उपयोग की गई LoRA विधि के आधार पर भिन्न हो सकती है। जो अनुरोध एक एडाप्टर साझा करते हैं, आमतौर पर प्रत्येक उप-समूह के लिए सुधार चलाने से पहले उप-बैच में समूहीकृत होते हैं, लेकिन S-LoRA जैसे कुछ सिस्टम, विभिन्न एडाप्टरों के अनुरोधों को एक ही फॉरवर्ड पास में पैक करते हैं और सक्रिय एडाप्टर को एक एकीकृत मेमोरी पूल में संग्रहीत करते हैं, फिर कस्टम CUDA कर्नेल के साथ उन्हें संबोधित करते हैं जो एक साथ अलग-अलग अनुक्रम स्थितियों पर अलग-अलग एडाप्टर सुधार लागू कर सकते हैं। इस दृष्टिकोण को कभी-कभी LoRA मल्टीप्लेक्सिंग कहा जाता है। यह GPU को संतृप्त रहने की अनुमति देता है तब भी जब ट्रैफिक एक साथ कई अलग-अलग फाइन-ट्यून वेरिएंट में फैला होता है। vLLM भी उन उपयोगकर्ताओं के लिए LoRA मल्टीप्लेक्सिंग का मूल रूप से समर्थन करता है जो घंटे के आधार पर GPU किराए पर ले रहे हैं।
KV-कैश एंट्री उस एडाप्टर से जुड़ी होती हैं जिसने उन्हें उत्पन्न किया। एक एडाप्टर के साथ उत्पन्न कैश एंट्री को एक अलग एडाप्टर का उपयोग करने वाले अनुरोध के लिए पुन: उपयोग नहीं किया जा सकता। इसका अंततः परिणाम एक मल्टी-एडाप्टर सेटिंग में सिंगल-मॉडल डेप्लॉयमेंट की तुलना में कम KV-कैश हिट दर में होता है, और इन्फ्रेंस सर्वरों को कैश एंट्री को अनुरोध के प्रॉम्प्ट टोकन और एडाप्टर पहचानकर्ता दोनों द्वारा कुंजी देना चाहिए।
सर्वरलेस फाइन-ट्यूनिंग का वास्तविक प्रभाव
सर्वरलेस फाइन-ट्यूनिंग की ताकत उन टीमों के लिए सबसे स्पष्ट है जो नई सेवाओं का निर्माण कर रही हैं जिनमें असंगत ट्रैफिक के विस्फोट होते हैं जैसे कि 24/7 रिज़र्व्ड GPU चलाना आवश्यक या लागत-प्रभावी नहीं है। रात भर निष्क्रिय घंटों के लिए एक निश्चित GPU-घंटे की दर का भुगतान करने के बजाय, आप केवल अपने अनुरोधों से टोकन के लिए भुगतान कर रहे हैं। सर्वरलेस आर्किटेक्चर में बदलाव करके, आप इन्फ्रेंस लागत को एक क्रम के परिमाण से कम कर सकते हैं।
डेप्लॉयमेंट गति भी बहुत तेज़ है। एक बार आपका LoRA एडाप्टर प्रशिक्षित हो जाने पर, इसे एक प्रबंधित इन्फ्रेंस प्लेटफॉर्म पर अपलोड करने से मिनटों में एक लाइव API एंडपॉइंट उत्पन्न होता है, बिना किसी क्लस्टर प्रोविजनिंग, कंटेनर ऑर्केस्ट्रेशन, या GPU ड्राइवर प्रबंधन के। यह इन्फ्रास्ट्रक्चर बोझ को सरल करता है, आपकी टीम को मॉडल और उत्पाद पर ध्यान केंद्रित करने के लिए मुक्त करता है। आप अभी भी मॉडल के व्यवहार पर नियंत्रण बनाए रखने में सक्षम हैं, और आप एडाप्टर वेट्स के मालिक हैं भले ही बेस मॉडल साझा है और कुशलतापूर्वक और किफायती रूप से चल रहा है।
फाइन-ट्यून मॉडलों को सर्वरलेस तरीके से होस्ट करने का सबसे बड़ा नुकसान कोल्ड स्टार्ट है। जब एक एडाप्टर को कुछ समय के लिए कोई ट्रैफिक नहीं मिला है, तो इन्फ्रेंस प्लेटफॉर्म आमतौर पर इसे शून्य पर स्केल करते हैं, वेट्स को GPU मेमोरी से हटा देते हैं, और अन्य उपयोगकर्ताओं के लिए VRAM को पुनः प्राप्त करते हैं। इसका मतलब है कि अगले उपयोगकर्ता को इंतजार करना होगा जबकि सिस्टम वेट्स को ऑब्जेक्ट स्टोरेज से लाता है, उन्हें लोड करता है, और फॉरवर्ड पास शुरू करता है। यह आमतौर पर कुछ सेकंड के बजाय कुछ सौ मिलीसेकंड लेता है, क्योंकि एडाप्टर छोटे हैं। एक चेतावनी के रूप में, यदि बेस मॉडल स्वयं बार-बार उपयोग नहीं किया जाता है और कुछ आर्किटेक्चर पर हटा दिया गया था, तो कोल्ड स्टार्ट अधिक समय ले सकते हैं। कोल्ड स्टार्ट विशेष रूप से टाइम-टू-फर्स्ट-टोकन (TTFT) को बढ़ाते हैं बिना टाइम-पेर-आउटपुट-टोकन को प्रभावित किए, पहली टोकन के बाद टोकन जनरेट होने की दर। TTFT वह मीट्रिक है जिसे स्ट्रीमिंग लेटेंसी को कम करने की कोशिश कर रही टीमों को देखना चाहिए।
कोल्ड स्टार्ट को कुछ तरीकों से कम किया जा सकता है। पहला, आर्किटेक्चर को कम ट्रैफिक समय के दौरान आवधिक कीप-अलाइव अनुरोध भेजने के लिए सेट किया जा सकता है। दूसरा, LoRA एडाप्टर को प्रशिक्षित करते समय इसे लोड करने के लिए अधिक कुशल बनाने के लिए कदम उठाए जा सकते हैं। प्रशिक्षण के दौरान, एक एडाप्टर का आकार और अभिव्यक्ति रैंक या 'r' नामक हाइपरपैरामीटर द्वारा नियंत्रित होती है। रैंक-8 एडाप्टर रैंक-16 एडाप्टर के प्रशिक्षण योग्य पैरामीटर्स का लगभग आधा उत्पादन करता है। यदि अन्य सभी समान हैं, तो रैंक-8 एडाप्टर का कोल्ड स्टार्ट से तेज़ TTFT होगा। साथ ही, जिन ट्रांसफॉर्मर लेयर्स पर LoRA लागू होता है, वे फाइल साइज और इन्फ्रेंस ओवरहेड को बदलते हैं। LoRA आमतौर पर प्रत्येक अटेंशन ब्लॉक में क्वेरी और वैल्यू प्रोजेक्शन मैट्रिक्स पर लागू होता है, लेकिन इसे MLP (मल्टी-लेयर पर्सेप्ट्रॉन) लेयर्स पर लागू करने से गुणवत्ता में सुधार हो सकता है जब किसी विशिष्ट डोमेन के लिए मॉडल को अनुकूलित करने का प्रयास किया जा रहा हो।
निष्कर्ष
यह संभावना है कि सर्वरलेस फाइन-ट्यून्ड इन्फ्रेंस भविष्य में एक तेजी से लोकप्रिय पेशकश होगी। वर्तमान LLM परिदृश्य बड़े, बेहतर-तर्क, मोनोलिथिक मॉडल को स्केल करने पर भारी रूप से केंद्रित है। कई विशेषज्ञ मॉडलों को एक साथ काम करने वाली आर्किटेक्चर पर कम ध्यान दिया गया है। अंततः, समुदाय कई मॉडलों को प्रबंधित करने और उन उपयोग के मामलों को खोजने के बेहतर तरीके ढूंढेगा जहां इस तरह की आर्किटेक्चर अच्छा प्रदर्शन करती है। जब ऐसा होता है, तो LoRA मल्टीप्लेक्सिंग कई कस्टम एजेंटों को उचित लागत पर प्रबंधित करने की तलाश कर रही टीमों के लिए मददगार होगा।
अभी भी उत्तर खोज रहे हैं?
यह कार्य क्रिएटिव कॉमन्स एट्रिब्यूशन-नॉनकमर्शियल- शेयरअलाइक 4.0 इंटरनेशनल लाइसेंस के तहत लाइसेंस प्राप्त है।
