पेश है Amazon SageMaker Serverless Inference Benchmarking Toolkit

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

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

हालांकि, सर्वर रहित समापन बिंदु सेकंड के क्रम में ठंड शुरू होने की संभावना है, और इसलिए रुक-रुक कर या अप्रत्याशित कार्यभार के लिए अधिक उपयुक्त है।

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

इस पोस्ट में, हम टूलकिट का परिचय देते हैं और इसके कॉन्फ़िगरेशन और आउटपुट का अवलोकन प्रदान करते हैं।

समाधान अवलोकन

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

टूलकिट स्थापित करें

पहले पाइप का उपयोग करके बेंचमार्किंग लाइब्रेरी को अपने पायथन वातावरण में स्थापित करें:

pip install sm-serverless-benchmarking

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

from sm_serverless_benchmarking import benchmark
from sm_serverless_benchmarking.utils import convert_invoke_args_to_jsonl
model_name = ""
example_invoke_args = [
        {'Body': '1,2,3,4,5', "ContentType": "text/csv"},
        {'Body': '6,7,8,9,10', "ContentType": "text/csv"}
        ]
example_args_file = convert_invoke_args_to_jsonl(example_invoke_args,
output_path=".")
r = benchmark.run_serverless_benchmarks(model_name, example_args_file)

इसके अतिरिक्त, आप बेंचमार्क को सेजमेकर प्रोसेसिंग जॉब के रूप में चला सकते हैं, जो बड़ी संख्या में इनवोकेशन के साथ लंबे समय तक चलने वाले बेंचमार्क के लिए अधिक विश्वसनीय विकल्प हो सकता है। निम्नलिखित कोड देखें:

from sm_serverless_benchmarking.sagemaker_runner import run_as_sagemaker_job
run_as_sagemaker_job(
                    role="",
                    model_name="",
                    invoke_args_examples_file="",
                    )

ध्यान दें कि बेंचमार्क की अवधि के लिए एमएल.एम5.लार्ज सेजमेकर प्रोसेसिंग इंस्टेंस चलाने की अतिरिक्त लागत लगेगी।

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

बेंचमार्किंग कॉन्फ़िगरेशन

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

वहां दो प्रमुख विन्यास विकल्प: MemorySizeInMB और MaxConcurrency. MemorySizeInMB उदाहरण के लिए आवंटित स्मृति की मात्रा को कॉन्फ़िगर करता है, और 1024 एमबी, 2048 एमबी, 3072 एमबी, 4096 एमबी, 5120 एमबी, या 6144 एमबी हो सकता है। वीसीपीयू की संख्या भी आवंटित मेमोरी की मात्रा के अनुपात में मापी जाती है। MaxConcurrency पैरामीटर समायोजित करता है कि कितने समवर्ती अनुरोध एक समापन बिंदु सेवा करने में सक्षम है। के साथ MaxConcurrency 1 का, एक सर्वर रहित समापन बिंदु एक समय में केवल एक अनुरोध को संसाधित कर सकता है।

संक्षेप में, MemorySizeInMB पैरामीटर वर्टिकल स्केलेबिलिटी के लिए एक तंत्र प्रदान करता है, जिससे आप मेमोरी को समायोजित कर सकते हैं और बड़े मॉडल की सेवा के लिए संसाधनों की गणना कर सकते हैं, जबकि MaxConcurrency क्षैतिज मापनीयता के लिए एक तंत्र प्रदान करता है, जिससे आपके समापन बिंदु को अधिक समवर्ती अनुरोधों को संसाधित करने की अनुमति मिलती है।

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

बेंचमार्किंग आउटपुट

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

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

जब बेंचमार्किंग पूरी हो जाती है, तो टूल निर्दिष्ट में कई आउटपुट उत्पन्न करता है result_save_path निम्नलिखित निर्देशिका संरचना के साथ निर्देशिका:

├── benchmarking_report
├── concurrency_benchmark_raw_results
├── concurrency_benchmark_summary_results
├── cost_analysis_summary_results
├── stability_benchmark_raw_results
├── stability_benchmark_summary_results

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

आइए एक कंप्यूटर विज़न MobileNetV2 TensorFlow मॉडल की सेवा करने वाले समापन बिंदु के लिए कुछ वास्तविक बेंचमार्किंग आउटपुट की जाँच करें। यदि आप इस उदाहरण को पुन: पेश करना चाहते हैं, तो देखें उदाहरण नोटबुक गिटहब रेपो में निर्देशिका।

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

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

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

निम्न तालिका प्रत्येक मेमोरी कॉन्फ़िगरेशन के लिए CloudWatch द्वारा कैप्चर किए गए मीट्रिक दिखाती है।

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

लागत और स्थिरता बेंचमार्क का अंतिम आउटपुट एक अनुशंसित मेमोरी कॉन्फ़िगरेशन है, साथ ही एक तुलनीय सेजमेकर होस्टिंग इंस्टेंस के खिलाफ सर्वर रहित एंडपॉइंट के संचालन की लागत की तुलना करने वाली तालिका के साथ। एकत्र किए गए डेटा के आधार पर, टूल ने निर्धारित किया कि इस मॉडल के लिए 2048 एमबी कॉन्फ़िगरेशन सबसे इष्टतम है। हालांकि 3072 कॉन्फ़िगरेशन लगभग 10 मिलीसेकंड बेहतर विलंबता प्रदान करता है, जो लागत में 30% की वृद्धि के साथ आता है, $4.55 से $5.95 प्रति 1 मिलियन अनुरोध। इसके अतिरिक्त, आउटपुट से पता चलता है कि एक सर्वर रहित एंडपॉइंट एक तुलनीय रीयल-टाइम होस्टिंग इंस्टेंस के मुकाबले 88.72% तक की बचत प्रदान करेगा, जब 1 मिलियन से कम मासिक आमंत्रण अनुरोध होते हैं, और 8.5 मिलियन अनुरोधों के बाद रीयल-टाइम एंडपॉइंट के साथ भी टूट जाता है।

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

उदाहरण के लिए, सेटिंग करके concurrency_benchmark_max_conc parameter से [4, 8] और concurrency_num_clients_multiplier से [1, 1.5, 2], दो समापन बिंदु लॉन्च किए गए हैं: एक के साथ MaxConcurency 4 का और अन्य 8. प्रत्येक समापन बिंदु को एक के साथ बेंचमार्क किया जाता है (MaxConcurency x गुणक) सिम्युलेटेड समवर्ती ग्राहकों की संख्या, जो 4 की संगामिति वाले समापन बिंदु के लिए 4, 6 और 8 समवर्ती क्लाइंट के साथ परीक्षण बेंचमार्क लोड करने के लिए अनुवाद करता है।

इस बेंचमार्क का पहला आउटपुट एक टेबल है जो लेटेंसी मेट्रिक्स, थ्रॉटलिंग अपवाद और प्रत्येक से जुड़े प्रति सेकंड मेट्रिक्स (टीपीएस) के लेनदेन को दर्शाता है। MaxConcurrency समवर्ती ग्राहकों की विभिन्न संख्याओं के साथ विन्यास। ये मेट्रिक्स उपयुक्त निर्धारित करने में मदद करते हैं MaxConcurrency अपेक्षित यातायात भार को संभालने के लिए सेटिंग। निम्न तालिका में, हम देख सकते हैं कि 8 की अधिकतम संगामिति के साथ कॉन्फ़िगर किया गया एक समापन बिंदु 16 समवर्ती ग्राहकों को संभालने में सक्षम था, जिसमें प्रति सेकंड औसतन 2,500 लेनदेन किए गए 24 आह्वानों में से केवल दो थ्रॉटलिंग अपवाद थे।

आउटपुट का अगला सेट प्रत्येक के लिए एक चार्ट प्रदान करता है MaxConcurrency विभिन्न भारों के तहत विलंबता के वितरण को दर्शाने वाली सेटिंग। इस उदाहरण में, हम देख सकते हैं कि एक समापन बिंदु a MaxConcurrency 4 की सेटिंग मंगलाचरण विलंबता में न्यूनतम वृद्धि के साथ अधिकतम 8 समवर्ती ग्राहकों के साथ सभी अनुरोधों को सफलतापूर्वक संसाधित करने में सक्षम थी।

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

निष्कर्ष

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

अतिरिक्त संसाधन

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

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

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

ऋषभ राय चौधरी अमेज़ॅन सेजमेकर के साथ एक वरिष्ठ उत्पाद प्रबंधक हैं, जो मशीन सीखने के अनुमान पर ध्यान केंद्रित कर रहे हैं। उन्हें AWS पर मशीन लर्निंग ग्राहकों के लिए नए अनुभव और नए अनुभव बनाने का शौक है, ताकि उनके कार्यभार को बढ़ाने में मदद मिल सके। अपने खाली समय में, उन्हें यात्रा करना और खाना बनाना पसंद है। आप उसे ढूंढ सकते हैं लिंक्डइन.