अमेज़ॅन सेजमेकर के साथ फाल्कन मॉडल के प्रदर्शन में सुधार करें | अमेज़न वेब सेवाएँ

टेक्स्ट-जनरेटिंग जेनेरिक एआई अनुप्रयोगों के लिए बड़े भाषा मॉडल (एलएलएम) की मेजबानी के लिए इष्टतम ढांचा और कॉन्फ़िगरेशन क्या है? एलएलएम की सेवा के लिए विकल्पों की प्रचुरता के बावजूद, मॉडल के आकार, अलग-अलग मॉडल आर्किटेक्चर, अनुप्रयोगों की प्रदर्शन आवश्यकताओं और बहुत कुछ के कारण इसका उत्तर देना एक कठिन प्रश्न है। अमेज़न SageMaker बड़े मॉडल अनुमान (एलएमआई) कंटेनर एलएलएम की तैनाती को अनुकूलित करने वाले विभिन्न ढांचे और तकनीकों को एक साथ लाकर एलएलएम की सेवा करना आसान बनाता है। एलएमआई कंटेनर में एक शक्तिशाली सर्विंग स्टैक होता है जिसे कहा जाता है डीजेएल सेवारत यह अंतर्निहित एलएलएम के प्रति अज्ञेयवादी है। यह सिस्टम-स्तरीय कॉन्फ़िगरेशन पैरामीटर प्रदान करता है जिसे किसी दिए गए एलएलएम के लिए होस्टिंग इंफ्रास्ट्रक्चर के सर्वोत्तम प्रदर्शन को निकालने के लिए ट्यून किया जा सकता है। इसमें निरंतर बैचिंग जैसे हालिया अनुकूलन के लिए भी समर्थन है, जिसे पुनरावृत्त बैचिंग या रोलिंग बैचिंग भी कहा जाता है, जो थ्रूपुट में महत्वपूर्ण सुधार प्रदान करता है।

एक पहले में पद, हमने दिखाया कि आप सेजमेकर पर मॉडलों के फाल्कन परिवार को तैनात करने के लिए एलएमआई कंटेनर का उपयोग कैसे कर सकते हैं। इस पोस्ट में, हम प्रदर्शित करते हैं कि निरंतर बैचिंग जैसी तकनीकों के साथ फाल्कन-40बी की सेवा के थ्रूपुट और विलंबता को कैसे सुधारा जाए। हम सेजमेकर एलएमआई कंटेनर द्वारा प्रदान किए गए कॉन्फ़िगरेशन मापदंडों की सहज समझ भी प्रदान करते हैं जो आपके वास्तविक दुनिया के एप्लिकेशन के लिए सर्वोत्तम कॉन्फ़िगरेशन ढूंढने में आपकी सहायता कर सकता है।

एलएलएम के लिए टेक्स्ट-जनरेटिव अनुमान के बुनियादी सिद्धांत

आइए सबसे पहले टेक्स्ट जेनरेशन के लिए एलएलएम के लिए अनुमान लगाने के तरीके के बारे में कुछ बुनियादी बातों पर नजर डालें।

फॉरवर्ड पास, सक्रियण और केवी कैश

टोकन के इनपुट अनुक्रम को देखते हुए, उन्हें एक में चलाया जाता है forward pass अगला टोकन उत्पन्न करने के लिए एलएलएम (फाल्कन की तरह) की सभी परतों में। ए forward pass आउटपुट उत्पन्न करने के लिए इनपुट डेटा को तंत्रिका नेटवर्क के माध्यम से पारित करने की प्रक्रिया को संदर्भित करता है। पाठ निर्माण के मामले में, फॉरवर्ड पास में भाषा मॉडल में प्रारंभिक बीज या संदर्भ को फीड करना और अनुक्रम में अगला चरित्र या टोकन उत्पन्न करना शामिल है। पाठ का अनुक्रम उत्पन्न करने के लिए, प्रक्रिया को अक्सर पुनरावृत्त रूप से किया जाता है, जिसका अर्थ है कि इसे आउटपुट अनुक्रम में प्रत्येक चरण या स्थिति के लिए दोहराया जाता है। प्रत्येक पुनरावृत्ति पर, मॉडल अगला वर्ण या टोकन उत्पन्न करता है, जो उत्पन्न पाठ का हिस्सा बन जाता है, और यह प्रक्रिया तब तक जारी रहती है जब तक पाठ की वांछित लंबाई उत्पन्न नहीं हो जाती।

फाल्कन या जीपीटी जैसे भाषा मॉडल के साथ पाठ पीढ़ी होती है autoregressive. इसका मतलब यह है कि मॉडल पहले से उत्पन्न टोकन पर कंडीशनिंग करते समय एक समय में एक टोकन उत्पन्न करता है। दूसरे शब्दों में, प्रत्येक पुनरावृत्ति पर, मॉडल पहले उत्पन्न पाठ को इनपुट के रूप में लेता है और उस संदर्भ के आधार पर अगले टोकन की भविष्यवाणी करता है। जैसा कि उल्लेख किया गया है वीएलएलएम: पेजेडअटेंशन के साथ आसान, तेज और सस्ता एलएलएम सेवा, इस ऑटोरेग्रेसिव डिकोडिंग प्रक्रिया में, एलएलएम के सभी इनपुट टोकन अपना ध्यान कुंजी और मूल्य टेंसर उत्पन्न करते हैं, और इन टेंसरों को अगले टोकन उत्पन्न करने के लिए जीपीयू मेमोरी में रखा जाता है। इन कैश्ड कुंजी और मान टेंसरों को अक्सर कहा जाता है KV cache.

चरणों को प्रीफ़िल और डीकोड करें

ऑटोरेग्रेसिव डिकोडिंग प्रक्रिया में, जैसे फाल्कन जैसे भाषा मॉडल के साथ टेक्स्ट जेनरेशन में उपयोग किया जाता है, आम तौर पर दो मुख्य चरण होते हैं: prefill चरण और decode चरण। ये चरण सुसंगत और प्रासंगिक रूप से प्रासंगिक पाठ उत्पन्न करने के लिए महत्वपूर्ण हैं।

प्रीफ़िल चरण में निम्नलिखित शामिल हैं:

• प्रारंभिक प्रसंग - प्रीफ़िल चरण उपयोगकर्ता द्वारा प्रदान किए गए प्रारंभिक संदर्भ या बीज पाठ से शुरू होता है। यह प्रारंभिक संदर्भ एक वाक्य, एक वाक्यांश या यहां तक ​​कि सिर्फ एक शब्द भी हो सकता है। यह पाठ निर्माण के लिए प्रारंभिक बिंदु निर्धारित करता है और आगे क्या आता है इसके लिए संदर्भ प्रदान करता है।
• मॉडल कंडीशनिंग - प्रदान किए गए संदर्भ का उपयोग भाषा मॉडल को अनुकूलित करने के लिए किया जाता है। मॉडल इस संदर्भ को इनपुट के रूप में लेता है और संदर्भ की अपनी समझ के आधार पर अनुक्रम में अगला टोकन (शब्द या चरित्र) उत्पन्न करता है।
• टोकन पीढ़ी - मॉडल एक समय में एक टोकन उत्पन्न करता है, जो भविष्यवाणी करता है कि पाठ में आगे क्या आना चाहिए। यह टोकन संदर्भ के साथ जोड़ा गया है, इसे प्रभावी ढंग से विस्तारित किया गया है।
• पुनरावृति कार्य - टोकन जनरेट करने की प्रक्रिया लगातार दोहराई जाती है। प्रत्येक चरण पर, मॉडल अद्यतन संदर्भ पर विचार करते हुए एक टोकन उत्पन्न करता है, जिसमें अब पिछले चरणों में उत्पन्न टोकन शामिल हैं।

प्रीफ़िल चरण तब तक जारी रहता है जब तक कि पूर्व निर्धारित रुकने की स्थिति पूरी नहीं हो जाती। यह स्थिति उत्पन्न पाठ के लिए अधिकतम लंबाई हो सकती है, एक विशिष्ट टोकन जो पाठ के अंत का संकेत देता है, या उपयोगकर्ता या एप्लिकेशन द्वारा निर्धारित कोई अन्य मानदंड हो सकता है।

डिकोड चरण में निम्नलिखित शामिल हैं:

• समापन - प्रीफ़िल चरण के बाद, आपके पास आंशिक रूप से उत्पन्न पाठ होगा जो किसी बिंदु पर अधूरा या कटा हुआ हो सकता है। डिकोड चरण पाठ को सुसंगत और व्याकरणिक रूप से सही बनाने के लिए उसे पूरा करने के लिए जिम्मेदार है।
• अंतिम टोकन से निरंतरता - डिकोड चरण में, मॉडल प्रीफ़िल चरण के दौरान उत्पन्न अंतिम टोकन से शुरू होता है। यह इस टोकन को प्रारंभिक संदर्भ के रूप में उपयोग करता है और पाठ को जारी रखने के लिए अगला टोकन उत्पन्न करता है।
• पुनरावर्ती पूर्णता - प्रीफ़िल चरण की तरह, टोकन उत्पन्न करने की प्रक्रिया फिर से पुनरावृत्त होती है। मॉडल एक समय में एक टोकन उत्पन्न करता है, अनुक्रम में पूर्ववर्ती टोकन पर कंडीशनिंग करता है।
• रुकने की स्थिति - डिकोड चरण में एक रुकने की स्थिति भी होती है, जो प्रीफ़िल चरण के समान हो सकती है, जैसे कि अधिकतम लंबाई तक पहुंचना या पाठ के अंत में टोकन का सामना करना। जब यह शर्त पूरी हो जाती है, तो उत्पादन प्रक्रिया रुक जाती है।

प्रीफ़िल और डिकोड चरणों का संयोजन ऑटोरेग्रेसिव मॉडल को पाठ उत्पन्न करने की अनुमति देता है जो प्रारंभिक संदर्भ पर बनाता है और पाठ के सुसंगत, प्रासंगिक और प्रासंगिक रूप से सुसंगत अनुक्रम उत्पन्न करता है।

का संदर्भ लें ट्रांसफार्मर-आधारित जनरेटिव मॉडल के लिए एक वितरित सर्विंग प्रणाली प्रक्रिया की विस्तृत व्याख्या के लिए.

गतिशील बैचिंग का उपयोग करके थ्रूपुट को अनुकूलित करना

अभी तक, हमने केवल एक इनपुट के बारे में बात की है। व्यवहार में, हम समवर्ती रूप से या क्रमबद्ध तरीके से अनुमान लगाने के लिए एप्लिकेशन क्लाइंट से बेतरतीब ढंग से आने वाले कई अनुरोधों से निपटने की उम्मीद करते हैं। पारंपरिक तरीके से, GPU के कंप्यूटिंग संसाधनों के थ्रूपुट और उपयोग को बढ़ाने के लिए बुनियादी बैचिंग का उपयोग किया जा सकता है। बैचिंग एक बैच में एक से अधिक अनुरोधों के संख्यात्मक प्रतिनिधित्व को प्रभावी ढंग से संयोजित करना और ऑटोरेग्रेसिव फॉरवर्ड पास के समानांतर रन निष्पादित करना है। यह बुद्धिमान बैचिंग सेवारत पक्ष में की जाती है। सेजमेकर एलएमआई के डीजेएलसर्विंग सर्वर को निम्नलिखित पैरामीटर सेट करके समानांतर में संसाधित करने के लिए एकाधिक अनुरोधों को एक साथ बैचने के लिए कॉन्फ़िगर किया जा सकता है सर्विंग.प्रॉपर्टीज:

• अधिकतम_बैच_विलंब = 100 - मिलीसेकंड में बैच एकत्रीकरण के लिए अधिकतम विलंब। डिफ़ॉल्ट मान 100 मिलीसेकंड है.
• बैच का आकार = 32 - गतिशील बैच आकार। डिफ़ॉल्ट 1 है.

यह मूल रूप से दर्शाता है कि DJLServing एक समय में 100 मिलीसेकंड के लिए अनुरोधों को कतारबद्ध करेगा या यदि कतारबद्ध अनुरोधों की संख्या निर्दिष्ट बैच_आकार तक है, तो बैच को अनुमान के लिए बैकएंड पर चलाने के लिए निर्धारित किया जाएगा। इसे इस नाम से जाना जाता है dynamic batching. यह गतिशील है क्योंकि उस समय अवधि में कितने अनुरोध जोड़े गए थे, इसके आधार पर बैच का आकार बैचों में बदल सकता है। हालाँकि, क्योंकि अनुरोधों की अलग-अलग विशेषताएँ हो सकती हैं, (उदाहरण के लिए, कुछ अनुरोध इनपुट के 20 टोकन और आउटपुट के 500 टोकन के आकार के हो सकते हैं, जबकि अन्य उलटे हो सकते हैं, इनपुट के 500 टोकन लेकिन आउटपुट के लिए केवल 20), कुछ अनुरोध हो सकते हैं एक ही बैच में दूसरों की तुलना में तेजी से प्रसंस्करण पूरा करें। इसके परिणामस्वरूप बैच में सभी इन-फ़्लाइट अनुरोधों के डिकोड चरण को पूरा करने की प्रतीक्षा करते समय GPU का कम उपयोग हो सकता है, भले ही कतार में अतिरिक्त अनुरोध संसाधित होने की प्रतीक्षा कर रहे हों। निम्नलिखित चित्र इस प्रक्रिया को दर्शाता है।

निरंतर बैचिंग का उपयोग करके थ्रूपुट को अनुकूलित करना

- continuous batching , जिसे iterative or rolling बैचिंग में, हम प्रीफ़िल और डिकोड चरणों के बीच अंतर का लाभ उठाते हैं। निरंतर बैचिंग को सक्रिय करने के लिए, DJServing सर्विंग.गुणों के अनुसार निम्नलिखित अतिरिक्त कॉन्फ़िगरेशन प्रदान करता है:

• इंजन=एमपीआई - हम आपको निरंतर बैचिंग के लिए एमपीआई इंजन का उपयोग करने के लिए प्रोत्साहित करते हैं।
• विकल्प.रोलिंग_बैच=ऑटो या एलएमआई-डिस्ट - हम ऑटो का उपयोग करने की सलाह देते हैं क्योंकि यह भविष्य में अन्य अनुकूलन के साथ स्वचालित रूप से सबसे उपयुक्त रोलिंग बैच एल्गोरिदम चुन लेगा।
• option.max_rolling_batch_size=32 - यह समवर्ती अनुरोधों की संख्या को सीमित करता है। डिफ़ॉल्ट 32 है.

निरंतर बैचिंग के साथ, सर्विंग स्टैक (डीजेएलसर्विंग) अपने डिकोड चरण को पूरा करने के लिए बैच में सभी इन-फ़्लाइट अनुरोधों की प्रतीक्षा नहीं करता है। बल्कि, तार्किक विराम पर (डिकोड चरण में एक पुनरावृत्ति के अंत में), यह अतिरिक्त अनुरोधों को खींचता है जो कतार में प्रतीक्षा कर रहे हैं जबकि वर्तमान बैच अभी भी संसाधित हो रहा है (इसलिए नाम रोलिंग बैच). यह डिकोड चरण के प्रत्येक पुनरावृत्ति के अंत में लंबित अनुरोधों की जांच करता है। याद रखें, प्रत्येक अनुरोध के लिए, हमें प्रीफ़िल चरण और उसके बाद अनुक्रमिक डिकोड चरण चलाने की आवश्यकता है। चूँकि हम किसी अनुरोध के प्रारंभिक संकेत से सभी टोकन को उसके प्रीफ़िल चरण के समानांतर संसाधित कर सकते हैं, जब भी कोई नया अनुरोध खींचा जाता है, हम अस्थायी रूप से बैच के इन-फ़्लाइट अनुरोधों के डिकोड चरण को रोक देते हैं - हम अस्थायी रूप से इसके केवी कैश को सहेजते हैं और मेमोरी में सक्रियण और नए अनुरोधों का प्रीफ़िल चरण चलाएँ।

इस कैश का आकार निम्नलिखित विकल्प से कॉन्फ़िगर किया जा सकता है:

जब प्रीफ़िल पूरा हो जाता है, तो हम नए अनुरोधों और पुराने रुके हुए अनुरोधों को एक नए रोलिंग बैच में जोड़ते हैं, जो समानांतर में उनके डिकोड चरण के साथ आगे बढ़ सकता है। ध्यान दें कि पुराने रुके हुए अनुरोध अपने डिकोड चरण को वहीं जारी रख सकते हैं जहां उन्होंने छोड़ा था और नए अनुरोध अपने पहले नए टोकन से शुरू होंगे।

आप पहले ही महसूस कर चुके होंगे कि निरंतर बैचिंग लगभग एक समान दृष्टिकोण है जिसके साथ हम स्वाभाविक रूप से अपने दैनिक जीवन में कार्यों को समानांतर करते हैं। हमारे पास संदेश, ईमेल, फोन सूचनाएं (संभावित रूप से नए अनुरोध) यादृच्छिक समय पर आ रही हैं (जीपीयू के लिए यादृच्छिक क्रम में आने वाले कई अनुरोधों के अनुरूप)। यह सब तब हो रहा है जब हम अपने इन-फ़्लाइट कार्यों को पूरा कर रहे हैं - ईमेल लिखना, कोडिंग करना, बैठकों में भाग लेना (जीपीयू में वर्तमान में प्रसंस्करण कार्यों के अनुरूप)। तार्किक विराम पर, हम अपने इन-फ़्लाइट कार्यों को रोकते हैं और यह तय करने के लिए अपनी सूचनाओं की जाँच करते हैं कि क्या हमारी ओर से कुछ कार्रवाई आवश्यक है, और यदि वहाँ है, तो हम इसे अपने इन-फ़्लाइट कार्यों (वास्तविक जीवन रोलिंग बैच) में जोड़ते हैं, या इसे कार्य सूची (कतार) में रखें।

इन सबको एक साथ रखना: जीपीयू के मेमोरी उपयोग के बारे में कैसे सोचें

यह देखने के लिए अपने मॉडल का लोड परीक्षण करने की अनुशंसा की जाती है कि आपके व्यावसायिक उपयोग के मामले में कौन सा कॉन्फ़िगरेशन सबसे अधिक लागत प्रभावी है। समझ विकसित करने के लिए, आइए जीपीयू के मेमोरी फ़ुटप्रिंट की कल्पना करें क्योंकि मॉडल लोड होता है और क्रमिक अनुरोधों को एक रोलिंग बैच में संसाधित किया जाता है। इस पोस्ट के लिए, मान लें कि हम फाल्कन-40बी मॉडल को जी5 इंस्टेंस प्रकार के इंस्टेंस में से एक पर लोड कर रहे हैं जो एनवीआईडीआईए ए10जी जीपीयू के साथ स्थापित हैं, प्रत्येक 24 जीबी मेमोरी के साथ। ध्यान दें कि समान समझ p3, p4 और p5 इंस्टेंस प्रकारों के लिए लागू होती है, जो V100, A100 और H100 GPU श्रृंखला के साथ आते हैं।

फाल्कन-40बी की सेवा के लिए आवश्यक कुल मेमोरी का अनुमानित मूल्य प्राप्त करने का अवलोकन निम्नलिखित है:

• मॉडल का आकार = मॉडल पैरामीटर्स की संख्या (फाल्कन-40बी के लिए 40 बिलियन) x 4 बाइट्स प्रति पैरामीटर (एफपी32 के लिए) = 160 जीबी
• अनुमान के लिए फाल्कन-40बी को लोड करने के लिए आवश्यक अनुमानित कुल मेमोरी = मॉडल आकार (=160 जीबी) + केवी कैश (ध्यान कैश) (=*20 जीबी) + एमएल फ्रेमवर्क द्वारा अतिरिक्त मेमोरी ओवरहेड (लगभग 2 जीबी)

फाल्कन-40बी के लिए, यदि हम मॉडल को bfloat16 (2 बाइट्स) डेटा प्रकार में परिमाणित करके मॉडल को संपीड़ित करते हैं, तो मॉडल का आकार लगभग 80 जीबी हो जाता है। जैसा कि आप देख सकते हैं, यह अभी भी एक त्वरक डिवाइस द्वारा समर्थित मेमोरी से बड़ा है, इसलिए हमें एक विशेष के साथ मॉडल विभाजन (शार्डिंग) तकनीक अपनाने की आवश्यकता है टेंसर समानता (टीपी) कई त्वरक उपकरणों में मॉडल तक पहुंचता है और उसे शार्प करता है। आइए मान लें कि हमने g5.24xlarge को चुना है, जिसमें 4 A10G GPU डिवाइस हैं। यदि हम निम्नलिखित के साथ DJLServing (serving.properties) को कॉन्फ़िगर करते हैं, तो हम उम्मीद कर सकते हैं कि 80 जीबी मॉडल वजन सभी 4 जीपीयू में समान रूप से विभाजित किया जाएगा:

- tensor_parallel_degree 4 पर सेट होने पर, 20 जीबी जीपीयू मेमोरी में से लगभग 24 जीबी (लगभग 84%) एक अनुरोध संसाधित होने से पहले ही उपयोग किया जा चुका है। शेष 16% GPU का उपयोग आने वाले अनुरोधों के लिए KV कैश के लिए किया जाएगा। यह संभव है कि आपके व्यावसायिक परिदृश्य और इसकी विलंबता और थ्रूपुट आवश्यकताओं के लिए, शेष मेमोरी का 2-3 जीबी पर्याप्त से अधिक हो। यदि नहीं, तो आप इंस्टेंस साइज को g5.48xlarge तक बढ़ा सकते हैं, जिसमें 8 जीपीयू हैं और 8 पर सेट टेंसर_पैरेलल_डिग्री का उपयोग करता है। ऐसे मामले में, प्रत्येक जीपीयू की उपलब्ध 10 जीबी मेमोरी में से लगभग 24 जीबी का उपयोग मॉडल वेट के लिए किया जाता है और हम सक्रियणों और KV कैश के लिए शेष GPU का लगभग 60% है। सहज रूप से, हम देख सकते हैं कि यह कॉन्फ़िगरेशन हमें उच्च थ्रूपुट प्राप्त करने की अनुमति दे सकता है। इसके अतिरिक्त, क्योंकि अब हमारे पास बड़ा बफर है, हम इसे बढ़ा सकते हैं मैक्स_रोलिंग_बैच_प्रीफिल_टोकन और अधिकतम_रोलिंग_बैच_आकार थ्रूपुट को और अधिक अनुकूलित करने के लिए पैरामीटर। साथ में, ये दो पैरामीटर मॉडल के लिए सक्रियण प्रीफ़िल और केवी कैश के पूर्व-आवंटन को नियंत्रित करेंगे। इन दो मापदंडों के लिए एक बड़ी संख्या एक बड़े थ्रूपुट से सह-संबंधित होगी, यह मानते हुए कि आपके पास GPU मेमोरी में KV कैश के लिए पर्याप्त बफर है।

PagedAttention के साथ निरंतर बैचिंग

PagedAttention यूसी बर्कले द्वारा विकसित एक नया अनुकूलन एल्गोरिदम है जो निश्चित आकार के पृष्ठों या ब्लॉकों में मेमोरी आवंटित करके ध्यान कैश (KV कैश) को गैर-सन्निहित होने की अनुमति देकर निरंतर बैचिंग प्रक्रिया में सुधार करता है। यह ऑपरेटिंग सिस्टम द्वारा उपयोग की जाने वाली वर्चुअल मेमोरी और पेजिंग अवधारणाओं से प्रेरित है।

के अनुसार वीएलएलएम कागज, टोकन के प्रत्येक अनुक्रम के ध्यान कैश को ब्लॉकों में विभाजित किया जाता है और एक ब्लॉक तालिका के माध्यम से भौतिक ब्लॉकों में मैप किया जाता है। ध्यान की गणना के दौरान, PagedAttention कर्नेल भौतिक मेमोरी से ब्लॉक को कुशलतापूर्वक लाने के लिए ब्लॉक तालिका का उपयोग कर सकता है। इसके परिणामस्वरूप मेमोरी बर्बादी में उल्लेखनीय कमी आती है और बड़े बैच आकार, बढ़े हुए GPU उपयोग और उच्च थ्रूपुट की अनुमति मिलती है।

प्रदर्शन की तुलना

आपके परिनियोजन कॉन्फ़िगरेशन का प्रभावी लोड परीक्षण सुनिश्चित करने के लिए, व्यावसायिक परिदृश्य पर विचार करके और एलएलएम-आधारित एप्लिकेशन के लिए इनपुट और आउटपुट की विशेषताओं को स्पष्ट रूप से परिभाषित करके शुरू करने की अनुशंसा की जाती है। उदाहरण के लिए, यदि आप कॉल सेंटर सारांश उपयोग के मामले पर काम कर रहे हैं, तो इनपुट में बड़ा टेक्स्ट शामिल हो सकता है, जैसे ग्राहक सेवा एजेंट और ग्राहक के बीच 500-टोकन चैट ट्रांसक्रिप्ट, लेकिन आउटपुट अपेक्षाकृत छोटा हो सकता है, लगभग 100 टोकन, प्रतिलेख के सारांश का प्रतिनिधित्व करते हैं। दूसरी ओर, यदि आप कोड जनरेशन परिदृश्य पर काम कर रहे हैं, तो इनपुट 15 टोकन जितना छोटा हो सकता है, जैसे "पेजिनेशन सहित सभी EC2 संसाधनों का वर्णन करने के लिए पायथन में एक कुशल कार्यान्वयन लिखें," लेकिन आउटपुट बहुत अधिक हो सकता है बड़ा, 500 टोकन तक पहुंच गया। यह विचार करना भी महत्वपूर्ण है कि क्या कम विलंबता प्राप्त करना या थ्रूपुट को अधिकतम करना आपके विशिष्ट परिदृश्य के लिए सर्वोच्च प्राथमिकता है।

व्यावसायिक परिदृश्य की व्यापक समझ हासिल करने के बाद, आप अपने होस्टिंग वातावरण के लिए इष्टतम कॉन्फ़िगरेशन का विश्लेषण और निर्धारण कर सकते हैं। इस संदर्भ में, होस्टिंग वातावरण में विभिन्न प्रमुख तत्व शामिल हैं, जिनमें इंस्टेंस प्रकार और अन्य कॉन्फ़िगरेशन पैरामीटर शामिल हैं टेंसर_समानांतर_डिग्री, अधिकतम_रोलिंग_बैच_आकार, मैक्स_रोलिंग_बैच_प्रीफिल_टोकन, और अधिक। हमारा उद्देश्य हमारे प्रतिक्रिया समय, थ्रूपुट और मॉडल आउटपुट गुणवत्ता आवश्यकताओं का समर्थन करने के लिए सबसे प्रभावी सेटअप की पहचान करना है।

अपने विश्लेषण में, हमने पारंपरिक गतिशील बैचिंग की तुलना में निरंतर बैचिंग के लाभों को दर्शाने के लिए प्रदर्शन को बेंचमार्क किया। हमने SageMaker पर LMI कंटेनर का उपयोग करते हुए गतिशील बैचिंग और पुनरावृत्त बैचिंग के लिए सर्विंग.प्रॉपर्टीज़ में निम्नलिखित तालिका में विस्तृत कॉन्फ़िगरेशन का उपयोग किया।

गतिशील बैचिंग	सतत बैचिंग	PagedAttention के साथ निरंतर बैचिंग
इंजन=पायथन option.model_id=tiiuae/falcon-40b विकल्प.टेन्सर_पैरेलल_डिग्री=8 option.dtype=fp16 बैच_आकार=4 अधिकतम_बैच_विलंब=100 option.trust_remote_code = सत्य	इंजन = एमपीआई option.model_id = {{s3_url}} option.trust_remote_code = सत्य विकल्प.टेन्सर_पैरेलल_डिग्री = 8 option.max_rolling_batch_size = 32 विकल्प.रोलिंग_बैच = ऑटो option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = गलत	इंजन = एमपीआई option.model_id = {{s3_url}} option.trust_remote_code = सत्य विकल्प.टेन्सर_पैरेलल_डिग्री = 8 option.max_rolling_batch_size = 32 विकल्प.रोलिंग_बैच = ऑटो option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = सत्य

दो कॉन्फ़िगरेशन को फाल्कन-40बी के लिए एफपी16 डेटा प्रकार के साथ एमएल.जी5.48एक्सलार्ज पर तैनात किया गया था, जो कुछ अलग परिदृश्यों में वास्तविक दुनिया के अनुप्रयोगों का प्रतिनिधित्व करते हैं:

• बड़ी संख्या में टोकन उत्पन्न होने के साथ छोटी संख्या में इनपुट टोकन - इस परिदृश्य में, इनपुट टोकन की संख्या 32 तय की गई और 128 नए टोकन उत्पन्न हुए

बैचिंग रणनीति	थ्रूपुट (टोकन/सेकंड)	विलंबता p90 (सेकंड)
गतिशील बैचिंग	5.53	58.34
सतत बैचिंग	56.04	4.74
PagedAttention के साथ निरंतर बैचिंग	59.18	4.76

• कम संख्या में टोकन उत्पन्न होने के साथ एक बड़ा इनपुट - यहां, हम इनपुट टोकन की संख्या 256 तय करते हैं और एलएलएम को इनपुट को 32 टोकन तक सारांशित करने के लिए प्रेरित करते हैं।

बैचिंग रणनीति	थ्रूपुट (टोकन/सेकंड)	विलंबता p90 (सेकंड)
गतिशील बैचिंग	19.96	59.31
सतत बैचिंग	46.69	3.88
PagedAttention के साथ निरंतर बैचिंग	44.75	2.67

हम देख सकते हैं कि LMI कंटेनर का उपयोग करते समय SageMaker पर डायनामिक बैचिंग का उपयोग करने की तुलना में PagedAttention के साथ निरंतर बैचिंग परिदृश्य 10 में 1 गुना अधिक और परिदृश्य 2.3 में 2 गुना अधिक थ्रूपुट सुधार प्रदान करता है।

निष्कर्ष

इस पोस्ट में, हमने देखा कि एलएलएम मेमोरी का उपयोग कैसे करते हैं और बताया कि कैसे सेजमेकर पर एलएमआई कंटेनर का उपयोग करके निरंतर बैचिंग थ्रूपुट में सुधार करती है। हमने बेंचमार्क परिणाम दिखाकर सेजमेकर पर एलएमआई कंटेनर का उपयोग करके फाल्कन-40बी के लिए निरंतर बैचिंग के लाभों का प्रदर्शन किया। आप कोड यहां पा सकते हैं गीथहब रेपो.

---

लेखक के बारे में

अभि शिवादित्य AWS में एक वरिष्ठ समाधान वास्तुकार हैं, जो आर्टिफिशियल इंटेलिजेंस, वितरित कंप्यूटिंग, नेटवर्किंग और स्टोरेज जैसे क्षेत्रों में AWS सेवाओं को अपनाने की सुविधा के लिए रणनीतिक वैश्विक उद्यम संगठनों के साथ काम कर रहे हैं। उनकी विशेषज्ञता नेचुरल लैंग्वेज प्रोसेसिंग (एनएलपी) और कंप्यूटर विजन के क्षेत्र में डीप लर्निंग में निहित है। अभि ग्राहकों को AWS पारिस्थितिकी तंत्र के भीतर उच्च-प्रदर्शन मशीन लर्निंग मॉडल को कुशलतापूर्वक तैनात करने में सहायता करता है।

धवल पटेल AWS में प्रिंसिपल मशीन लर्निंग आर्किटेक्ट हैं। उन्होंने वितरित कंप्यूटिंग और आर्टिफिशियल इंटेलिजेंस से संबंधित समस्याओं पर बड़े उद्यमों से लेकर मध्यम आकार के स्टार्टअप तक के संगठनों के साथ काम किया है। वह एनएलपी और कंप्यूटर विज़न डोमेन सहित डीप लर्निंग पर ध्यान केंद्रित करता है। वह ग्राहकों को सेजमेकर पर उच्च प्रदर्शन मॉडल अनुमान प्राप्त करने में मदद करता है।

पिनाक पाणिग्रही AWS पर रणनीतिक व्यावसायिक समस्याओं को हल करने के लिए मशीन लर्निंग संचालित समाधान बनाने के लिए ग्राहकों के साथ काम करता है। जब वह मशीन लर्निंग में व्यस्त नहीं होता, तो उसे सैर करते, किताब पढ़ते या खेल देखते हुए पाया जा सकता है।

अभि सोधानी AWS में वरिष्ठ AI/ML सॉल्यूशंस आर्किटेक्ट के पद पर हैं, जहां वे ग्राहकों को जेनरेटिव AI और ML समाधानों पर तकनीकी विशेषज्ञता और मार्गदर्शन प्रदान करने में माहिर हैं। उनका प्राथमिक ध्यान डिजिटल नेटिव व्यवसायों को जेनरेटिव एआई और एमएल प्रौद्योगिकियों की पूरी क्षमता का एहसास करने में सहायता करना है, जिससे वे अपने व्यावसायिक उद्देश्यों को प्रभावी ढंग से प्राप्त करने में सक्षम हो सकें। अपने पेशेवर प्रयासों से परे, अभि पढ़ने जैसी बौद्धिक गतिविधियों के साथ-साथ योग, ध्यान जैसी शारीरिक और मानसिक भलाई को बढ़ावा देने वाली गतिविधियों में संलग्न होने के लिए एक मजबूत जुनून प्रदर्शित करता है।

किंग लैन एडब्ल्यूएस में सॉफ्टवेयर डेवलपमेंट इंजीनियर हैं। वह अमेज़ॅन में कई चुनौतीपूर्ण उत्पादों पर काम कर रहा है, जिसमें उच्च प्रदर्शन एमएल अनुमान समाधान और उच्च प्रदर्शन लॉगिंग सिस्टम शामिल हैं। किंग की टीम ने बहुत कम विलंबता के साथ अमेज़ॅन विज्ञापन में पहला बिलियन-पैरामीटर मॉडल सफलतापूर्वक लॉन्च किया। किंग को इंफ्रास्ट्रक्चर ऑप्टिमाइजेशन और डीप लर्निंग एक्सेलेरेशन का गहन ज्ञान है।

• एसईओ संचालित सामग्री और पीआर वितरण। आज ही प्रवर्धित हो जाओ।
• प्लेटोडेटा.नेटवर्क वर्टिकल जेनरेटिव एआई। स्वयं को शक्तिवान बनाएं। यहां पहुंचें।
• प्लेटोआईस्ट्रीम। Web3 इंटेलिजेंस। ज्ञान प्रवर्धित। यहां पहुंचें।
• प्लेटोईएसजी. कार्बन, क्लीनटेक, ऊर्जा, पर्यावरण, सौर, कचरा प्रबंधन। यहां पहुंचें।
• प्लेटोहेल्थ। बायोटेक और क्लिनिकल परीक्षण इंटेलिजेंस। यहां पहुंचें।
• स्रोत: https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/