एआय उत्पादन तयार करणे हे केवळ मॉडेलला प्रशिक्षण देणे नाही. मॉडेल थेट झाल्यानंतर, वापरकर्ते अनुमान प्रणालीला विनंत्या पाठवतात. त्या प्रणालीला मॉडेल मेमरीमध्ये आणावे लागेल, वापरकर्त्याचे इनपुट घ्यावे लागतील, आवश्यक गणना चालवावी लागेल आणि उत्तर परत पाठवावे लागेल.
जेव्हा लोड कमी असतो, तेव्हा धीमे अनुमान अनेकदा ॲपमध्ये अतिरिक्त प्रतीक्षा वेळ म्हणून दाखवले जाते. जेव्हा भार जास्त असतो तेव्हा चित्र बदलते. अधिक विलंबामुळे लोकांना उत्पादनाबद्दल कसे वाटते हे दुखावू शकते. संगणकाच्या चुकीच्या वापरामुळे प्रति मिनिट किती कार्ये पूर्ण होतात हे कमी होऊ शकते. आवश्यक नसलेले अतिरिक्त काम देखील क्लाउड बिले वाढवू शकते.
तर, अनुमानाचे काम वास्तविक वापरात चांगले चालण्यासाठी तैनात मॉडेल मिळवण्याबद्दल आहे. Google क्लाउड हे उत्पादनात गती आणि कार्यक्षमता दोन्ही सुधारते म्हणून फ्रेम करते. ते वेगवान रनटाइम्स, मेमरीची उत्तम हाताळणी, बॅचिंग आणि मॉडेल स्तरावर ट्यूनिंग यांसारख्या निराकरणांकडे निर्देश करते.
तुम्ही एक सेटिंग निवडू शकत नाही आणि ती प्रत्येक मॉडेलला मदत करेल अशी अपेक्षा करू शकत नाही. चॅटबॉट, इमेज क्लासिफायर, शिफारस सेवा आणि ऑफलाइन दस्तऐवज वर्कफ्लो त्याच प्रकारे कार्य करत नाहीत. वर्कलोड जवळून पाहण्यापासून चांगल्या सुधारणा सुरू होतात. मग तुम्ही सिस्टीमची चाचणी करा आणि त्यातून तुम्हाला आवश्यक असलेल्या परिणामांची तुलना करा.
प्रशिक्षण आणि अनुमान एकाच ध्येयासाठी तयार केलेले नाहीत
प्रशिक्षणामध्ये, सिस्टम मोठ्या डेटासेटचे अनेक वेळा वाचन करते. मॉडेलचे वजन बदलण्यासाठी ते डेटा वापरते. अनुमानानुसार, मॉडेल आधीच सेट केले आहे. ते नंतर नवीन इनपुट घेते आणि अंदाज किंवा मजकूर परत करते.
वास्तविक जगात गतीबद्दल अनुमान अनेकदा कठोर असते. ग्राहक ॲपला सहसा स्थिर, जलद उत्तरे हवी असतात. पार्श्वभूमीत चालवलेले काम ते किती पूर्ण करू शकते आणि प्रत्येक आयटमची किंमत यावर अधिक लक्ष केंद्रित करू शकते.
मोठ्या भाषेच्या मॉडेलसह, गोष्टी अधिक तपशीलवार होतात. Google क्लाउड LLM निष्कर्षामधील दोन चरणांबद्दल बोलतो. जेव्हा प्रॉम्प्ट हाताळले जाते तेव्हा प्रीफिल होते. जेव्हा प्रत्येक आउटपुट टोकन एकामागून एक तयार केले जाते तेव्हा डीकोड होते. त्या पायऱ्या हार्डवेअरमध्ये वेगवेगळ्या मर्यादा गाठू शकतात.
तर, केवळ मॉडेल रन टाइमला गती देणे नेहमीच पुरेसे नसते. एंड-टू-एंड विलंब इतर ठिकाणांहूनही येऊ शकतो. यामध्ये नेटवर्क ट्रान्सफर, डेटा तयार करणे, रांगेत थांबणे, मॉडेल लोड करणे, मजकूर टोकन करणे आणि अंतिम पोस्ट-प्रोसेसिंग समाविष्ट आहे.
विलंब आणि संपूर्णपणे पाहून सुरुवात करा
लेटन्सी म्हणजे विनंतीपासून उत्तर येईपर्यंतची वेळ. दिलेल्या कालावधीत सिस्टम किती हाताळू शकते हे थ्रूपुट आहे. ही दोन उद्दिष्टे एकमेकांच्या विरोधात खेचू शकतात. चॅट-शैलीच्या साधनांसाठी जलद प्रत्युत्तरे बहुधा महत्त्वाची असतात. मोठ्या फाइल्स वाचणाऱ्या आणि रूपांतरित करणाऱ्या पाइपलाइनमध्ये, एकच फाइल किती लवकर पूर्ण होते यापेक्षा स्थिर व्हॉल्यूम महत्त्वाचा असू शकतो.
NVIDIA TensorRT मार्गदर्शन म्हणते की तुम्ही वास्तविक ध्येयावर आधारित बेंचमार्क केले पाहिजे. हे असेही सूचित करते की वास्तविक उपयोजनांना बऱ्याचदा चांगल्या थ्रूपुटची आवश्यकता असते, तरीही लोक स्वीकारू शकतील अशा पातळीखाली विलंब ठेवत असतात.
जनरेटिव्ह AI सह, गट सामान्यतः एकापेक्षा जास्त संख्या मोजतात. ते पहिल्या टोकनसाठी वेळ पाहू शकतात. ते प्रत्येक व्युत्पन्न टोकन वेळेचा मागोवा घेऊ शकतात. इतर चेकमध्ये एंड-टू-एंड विनंती लेटन्सी, प्रत्येक सेकंदाची विनंती आणि प्रत्येक सेकंदाला किती टोकन हाताळले जातात याचा समावेश असू शकतो. आणखी एक गोष्ट: प्रथम बेसलाइन सेट करा. तुम्ही तसे न केल्यास, तुम्ही एक भाग ट्यून करू शकता आणि तरीही संपूर्ण ॲप चांगले झाले की नाही हे चुकवू शकता.
बॅचिंग हार्डवेअरला अधिक पूर्णपणे चालवण्यास मदत करते
अनुमान जलद करण्यासाठी बॅचिंग ही एक प्रयत्न केलेली आणि चाचणी केलेली पद्धत आहे. एका वेळी एक विनंती हाताळण्याऐवजी, सिस्टम अनेक इनपुट गोळा करते. मग ते त्यांना एका एकत्रित पासमध्ये चालवते.
एकाच वेळी अनेक काम करण्यासाठी अनेक प्रवेगक तयार केले जातात. त्यामुळे जेव्हा एकाधिक विनंत्या समान रन सामायिक करतात, तेव्हा मशीन अधिक उपयुक्त गणना करू शकते आणि कमी वेळ वाया घालवू शकते. NVIDIA म्हणते की बॅचिंग थ्रूपुट वाढवू शकते. कल्पना सोपी आहे: नियंत्रण कार्य आणि सेटअपची किंमत इनपुटमध्ये सामायिक केली जाते.
तरीही, मोठ्या बॅच नेहमी जिंकत नाहीत. सर्व्हरने पुरेशा विनंत्या गोळा करण्याची वाट पाहिल्यास, वापरकर्ते जास्त वेळ रांगेत बसू शकतात. लहान बॅचेस लवकर प्रतिसाद देऊ शकतात, परंतु ते डिव्हाइस व्यस्त ठेवू शकत नाहीत. त्यामुळे तुम्ही कमी विलंब आणि उच्च थ्रुपुट यापैकी एक निवडणे आवश्यक आहे.
डायनॅमिक आणि सतत बॅचिंग
वास्तविक वापरकर्ता रहदारी जवळजवळ कधीही व्यवस्थित, वेळेच्या लहरींमध्ये येत नाही. कॉल वेगवेगळ्या क्षणी दिसतात आणि ते भिन्न इनपुट आकार आणि भिन्न आउटपुट लांबी विचारू शकतात. डायनॅमिक किंवा सतत बॅचिंगसह, अनुमान सर्व्हर गट फ्लायवर कार्य करतात. नवीन विनंत्या आल्यावर ते जुळवून घेते.
LLM कार्यांसाठी, इन-फ्लाइट बॅचिंग अधिक थेट मार्गाने मदत करू शकते. इतर विनंत्या अजूनही टोकन तयार करत असताना नवीन विनंत्या सुरू होऊ शकतात. Google क्लाउड याला इन-फ्लाइट बॅचिंग म्हणतो आणि ते पायाभूत सुविधा-स्तरीय ऑप्टिमायझेशन म्हणून हाताळते. NVIDIA चे TensorRT-LLM देखील इन-फ्लाइट बॅचिंगची सूची देते आणि तुम्हाला शेड्युलिंग पर्याय सेट करू देते. परिणामी, तुम्ही प्रवेगक वापर वाढवू शकता. कोणतेही काम करण्यापूर्वी तुम्हाला बॅच पूर्ण आकारात येण्याची वाट पाहण्याची गरज नाही.
तरीही, सर्वोत्तम सेटअप वर्कलोडवर अवलंबून आहे. परस्परसंवादी ॲप्सना सहसा कठोर विलंब लक्ष्यांची आवश्यकता असते. ऑफलाइन नोकऱ्या अधिक काळ प्रतीक्षा करू शकतात जर ते अधिक चांगले थ्रूपुटकडे नेईल.
कॅशिंग इन्फरन्स दरम्यान वारंवार काम कापून काढण्यास मदत करते
अनेक AI टास्कमध्ये, तोच डेटा पुन्हा पुन्हा दिसतो. प्रणालीने प्रत्येक कॉलसाठी त्याची पुनर्गणना केल्यास, ते गोष्टी कमी करते. हे अतिरिक्त गणना देखील बर्न करते. मोठ्या भाषा मॉडेलसाठी, KV-कॅशे आणि उपसर्ग कॅशिंग सारख्या पद्धती आहेत. जेव्हा एकाधिक विनंत्या प्रॉम्प्टच्या समान प्रारंभाचा वापर करतात तेव्हा हे पुनरावृत्ती केलेल्या चरणांवर कमी करू शकतात. जेव्हा प्रॉम्प्ट उपसर्ग पुन्हा वापरला जातो तेव्हा रिडंडंट प्रीफिल कार्य वगळण्याचा एक मार्ग म्हणून AWS उपसर्ग कॅशिंगचे वर्णन करते.
कॅशिंग केवळ मॉडेलच्या आत नाही. सेवा सामान्य परिणाम, एम्बेडिंग व्हेक्टर, पुनर्प्राप्त केलेले दस्तऐवज किंवा इतर इंटरमीडिएट आउटपुट यासारख्या वस्तू संचयित करू शकते जेव्हा ते वापर केसमध्ये बसते.
अवघड भाग म्हणजे काय ठेवायचे ते निवडणे. आपण संग्रहित आयटमसाठी एक वेळ मर्यादा देखील सेट करणे आवश्यक आहे. कॅशे खूप मोठी झाल्यास, ते थेट कार्यापासून GPU मेमरी काढून घेऊ शकते. AWS हे देखील सूचित करते की GPU जागा कमी झाल्यावर कॅश्ड केव्ही ब्लॉक्स काढावे लागतील. त्यामुळे सेव्ह केलेल्या गणनेच्या विरूद्ध मेमरी वापर संतुलित करणे हे ध्येय आहे.
हार्डवेअर प्रवेग अनुमानाला गती देऊ शकते
अनुमान काढण्यासाठी बऱ्याचदा जड गणना आवश्यक असते, विशेषत: मोठ्या न्यूरल नेट आणि जनरेटिव्ह सिस्टमसह.
त्या मॉडेल्सनी अनेक मॅट्रिक्स ऑपरेशन्स पुन्हा पुन्हा चालवल्या पाहिजेत. GPUs आणि इतर AI चिप्स या प्रकारच्या गणितासाठी तयार केल्या आहेत. सामान्य प्रशिक्षण आणि अनुमानाच्या कामावर सामान्य CPU पेक्षा जलद प्रक्रिया करण्याचे त्यांचे लक्ष्य आहे. उदाहरणार्थ, NVIDIA TensorRT NVIDIA GPU वर डीप-लर्निंग इन्फरन्स ट्यून करते. हे लेयर फ्यूजन, CUDA आलेख, मल्टी-स्ट्रीम एक्झिक्युशन आणि टेन्सर कोअर स्पीडअप यासारख्या गोष्टींना समर्थन देते.
TensorRT-LLM मोठ्या भाषेच्या मॉडेलमध्ये समान कल्पना आणते. हे जलद रनटाइम वर्तन जोडते जसे की इन-फ्लाइट बॅचिंग, पेज्ड केव्ही कॅशिंग आणि क्वांटायझेशन पर्याय. तरीही, हार्डवेअरची निवड वर्कलोडशी जुळली पाहिजे. एक मोठा प्रवेगक अधिक हेडरूम देऊ शकतो, परंतु जर नोकरीने त्याचा चांगला वापर केला तरच. नसल्यास, जोडलेल्या पायाभूत सुविधांसाठी अतिरिक्त खर्च कदाचित उपयुक्त ठरणार नाही.
परिमाणीकरण मॉडेल खर्च कमी करू शकते
तुम्हाला नेहमी मॉडेल हलके करण्यासाठी पुन्हा डिझाइन करण्याची गरज नाही. आणखी एक मार्ग म्हणजे लहान संख्यात्मक मूल्ये वापरणे. हे मेमरी वापर आणि अनुमान दरम्यान केलेले कार्य दोन्ही कमी करू शकते.
परिमाणीकरणासह, मॉडेल वजन आणि सक्रियता कमी-परिशुद्धता स्वरूपात संग्रहित करते. बऱ्याच प्रणाल्यांसाठी, उच्च सुस्पष्टतेवरून INT8, INT4 किंवा FP8 वर स्विच केल्याने मेमरीच्या गरजा कमी होऊ शकतात. तुम्ही काय चालवत आहात त्यानुसार ते अनुमान अधिक सहजतेने चालवू शकते.
Google क्लाउड मॉडेल स्तरावर अनुमान काढण्याचा मुख्य मार्ग म्हणून परिमाणीकरण सूचीबद्ध करते. NVIDIA चे TensorRT-LLM मार्गदर्शक FP8, INT8 आणि INT4 परिमाणीकरण देखील नमूद करतात.
तरीही, एक नकारात्मक बाजू आहे. जेव्हा तुम्ही कमी अचूकता वापरता, तेव्हा काही कार्यांमध्ये आउटपुट गुणवत्तेमध्ये घट दिसू शकते. संघांनी विलंबता, मेमरी गरजा आणि एकूण खर्चासह अचूकता तपासली पाहिजे. मॉडेलचा वेग वाढवणारा परंतु वास्तविक वापरासाठी परिणाम खूपच खराब करणारा बदल उत्पादनासाठी विजय नाही.
मेमरी मर्यादा मोठ्या मॉडेल्सला मारतात
जरी हार्डवेअरमध्ये मजबूत गणना असली तरीही, मेमरी अद्याप कार्यप्रदर्शन कॅप करू शकते. हे LLM अनुमानात जलद दिसून येते. मॉडेल वजन जागा घेतात, परंतु KV कॅशे देखील एक प्रमुख चालक आहे. जेव्हा चॅट्स लांब होतात, किंवा जेव्हा अनेक वापरकर्ते एकाच वेळी विनंत्या पाठवतात, तेव्हा KV कॅशे वाढते. ही वाढ मेमरी वापरास डिव्हाइसच्या धारण करण्यापेक्षा जास्त वाढवू शकते.
काही पद्धतींचा उद्देश मेमरी अधिक काळजीपूर्वक वापरणे आहे. PagedAttention हे एक उदाहरण आहे, आणि हे KV कॅशे आयटम एकाच सतत क्षेत्राऐवजी ब्लॉकमध्ये ठेवणे आहे. गुगल क्लाउडने नोंदवले आहे की हा दृष्टीकोन नॉन-लग्न ब्लॉक्स वापरून विखंडन कमी करण्यात मदत करतो.
जेव्हा मेमरी चांगल्या प्रकारे हाताळली जाते, त्याच प्रवेगकावर अधिक विनंत्या चालू शकतात. ते तुम्हाला प्रत्यक्षात किती हार्डवेअर वापरायचे ते वाढवू शकते.
कोणत्याही ऑप्टिमायझेशन प्रयत्नांमध्ये विश्वसनीयता समाविष्ट करणे आवश्यक आहे
विश्वासार्हतेचे काय होते हे देखील तपासल्याशिवाय तुम्ही गती वाढीचा न्याय करू नये. वेगवान धावांसाठी ट्यूनिंग, जसे की मोठ्या बॅच, कमी अचूकता किंवा जास्त कॅशिंग, अयशस्वी होण्याचे नवीन मार्ग आणू शकतात.
त्यामुळे एका प्रवेगक वर अधिक काम ढकलणे आणि सर्व काही एकाच वेळी हाताळण्यासाठी त्यावर अवलंबून राहणे.
वास्तविक अनुमान सेवेमध्ये, स्पष्ट संरक्षण सेट करा.
कालबाह्य वर्तन, रांगांवर मर्यादा, स्मरणशक्तीचा ताण, एका प्रसंगावर बरीच कामे, तुटलेले किंवा रखडलेले मॉडेल कामगार आणि अचानक वाहतूक वाढीसाठी योजना करा.
हे कमी क्षमतेचे नियोजन करण्यास देखील मदत करते.
जर एखादे शीर्ष मॉडेल थोड्या काळासाठी डाउन असेल, तर सिस्टीम लहान मॉडेलवर स्विच करू शकते किंवा उत्पादनाची उद्दिष्टे अद्याप फिट असताना भिन्न सर्व्हिंग मार्ग वापरू शकते.
केवळ सर्वोच्च वापर पिळून काढणे हे ध्येय नाही. जेव्हा सिस्टम सामान्य लोड अंतर्गत असते तेव्हा ध्येय स्थिर आणि अपेक्षित कामगिरी असते.
कृतीत प्रणाली पाहणे वास्तविक स्लो पॉइंट्स दर्शविते
लॅबमध्ये बेंचमार्क रन करण्याने तुम्ही लॉन्च केल्यानंतर जे पाहता ते नेहमी जुळत नाही. वास्तविक वापरामध्ये, प्रॉम्प्टची लांबी खूप बदलू शकते. आउटपुट देखील बदलू शकतात आणि विनंत्या व्यवस्थित नमुन्यांमध्ये येत नाहीत.
विविध समवर्ती स्तर देखील आहेत. नेटवर्क विलंब क्षणाक्षणाला बदलतो.
ट्रॅफिक स्पाइक सिस्टमला देखील आघात करू शकतात.
NVIDIA स्पष्ट बेसलाइनसह प्रारंभ करण्याचे सुचवते.
संपूर्ण ॲप चाचण्यांमधून केवळ अनुमान-चाचण्या विभक्त करा असेही ते म्हणतात. पूर्ण ॲप चाचण्यांमध्ये अनुमानापूर्वीच्या पायऱ्या आणि त्यानंतरच्या पायऱ्यांचा समावेश होतो. त्यामुळे उत्पादनातील निरीक्षण सरासरी विलंबाप्रमाणे एका क्रमांकावर थांबू नये. p95 आणि p99 सारखे टक्केवारी सरासरी लपवू शकतील असे स्लो कॉल दाखवण्यास मदत करतात. ते शेपटीच्या वर्तनाकडे निर्देश करतात जे वापरकर्त्यांना लक्षात येईल.
एक्सीलरेटर किती मेहनत घेत आहे हेही बघायला हवे. मेमरी वापराचा मागोवा घ्या आणि रांगेच्या खोलीवर लक्ष ठेवा. विनंती दर, त्रुटी दर आणि टोकन थ्रूपुटचे निरीक्षण करा. तसेच प्रति विनंती खर्च किंवा कामाच्या प्रति युनिट खर्चाचा मागोवा घ्या. या संकेतांसह, बदल खरोखर मदत करतो की नाही हे तुम्ही सांगू शकता. ऑप्टिमायझेशन केवळ एक भाग नव्हे तर संपूर्ण सेवा सुधारते याची पुष्टी करणे सोपे होते.
निष्कर्ष
अनुमान ट्यूनिंग एक व्यापार बंद आहे. तुम्हाला कमी विलंब, प्रति युनिट वेळेत अधिक काम, सर्व्हरचा चांगला वापर, मजबूत अपटाइम आणि कमी खर्च हवा आहे. तरीही एक ध्येय खूप दूर ढकलल्याने दुसऱ्याला दुखापत होऊ शकते. तुम्ही बॅचेसमध्ये विनंत्या गट केल्यास, तुम्ही थ्रुपुट वाढवू शकता. परंतु बॅचेस खूप वेळ थांबल्यास, वापरकर्त्यांना लांब रांगा दिसतात. आपण कॅशिंग वापरत असल्यास, आपण काही पुनरावृत्ती काम टाळता. तरीही, मोठे कॅशे मेमरी खातात आणि इतर भाग कमी करू शकतात. तुम्ही परिमाण काढल्यास, तुम्ही गणना आणि मेमरी वापर कमी कराल. परंतु अचूकता खूप कमी केल्याने आउटपुट गुणवत्तेला हानी पोहोचू शकते. वेगवान मशीन्स मदत करतात, परंतु जर ते निष्क्रिय बसले तर खर्चाचा फायदा कमी होऊ शकतो.
संघांनी ते जे मोजतात त्यावरून ऑप्टिमाइझ केले पाहिजे, अंदाजावरून नाही. स्पष्ट कार्यप्रदर्शन बेसलाइन सेट करून प्रारंभ करा. वापर केसमध्ये बसणारा सर्व्हिंग सेटअप निवडा. बॅचिंग आणि कॅशिंग काळजीपूर्वक वापरा. हार्डवेअर प्रवेग वापरा जेथे ते मदत करते. मॉडेल आकार आणि मेमरीच्या गरजांवर लक्ष ठेवा. नंतर उत्पादनात काय होते ते पहा आणि वर्कलोड बदलत असताना समायोजित करा. उद्देश फक्त गती नाही. उद्दिष्ट अशी प्रणाली आहे जी आवश्यक गुणवत्ता आणि प्रतिसादाची पूर्तता करते आणि मागणी वाढत असताना समंजसपणे गणना खर्च करते.
Comments are closed.