प्रदर्शन गाइड

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

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

नोट: यदि निम्नलिखित त्वरित युक्तियाँ आपकी समस्या का समाधान नहीं करती हैं, तो कृपया TensorFlow सर्विंग के प्रदर्शन को प्रभावित करने वाली चीज़ों की गहरी समझ विकसित करने के लिए लंबी चर्चा पढ़ें।

त्वरित सुझाव

• पहले अनुरोध की विलंबता बहुत अधिक है? मॉडल वार्मअप सक्षम करें।
• क्या आप उच्च संसाधन उपयोग या थ्रूपुट में रुचि रखते हैं? बैचिंग कॉन्फ़िगर करें

प्रदर्शन ट्यूनिंग: उद्देश्य और पैरामीटर

जब TensorFlow सर्विंग के प्रदर्शन को ठीक किया जाता है, तो आमतौर पर आपके पास 2 प्रकार के उद्देश्य होते हैं और उन उद्देश्यों में सुधार करने के लिए मापदंडों के 3 समूह होते हैं।

उद्देश्य

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

पैरामीटर

हम मोटे तौर पर मापदंडों के 3 समूहों के बारे में सोच सकते हैं जिनका कॉन्फ़िगरेशन देखे गए प्रदर्शन को निर्धारित करता है: 1) टेन्सरफ्लो मॉडल 2) अनुमान अनुरोध और 3) सर्वर (हार्डवेयर और बाइनरी)।

1) टेंसरफ्लो मॉडल

मॉडल उस गणना को परिभाषित करता है जो TensorFlow सर्विंग प्रत्येक आने वाले अनुरोध को प्राप्त करने पर निष्पादित करेगी।

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

कृपया ध्यान दें, जबकि TensorFlow सर्विंग के साथ अनुमान लगाने की औसत विलंबता आमतौर पर सीधे TensorFlow का उपयोग करने से कम नहीं होती है, जहां TensorFlow सर्विंग कई अलग-अलग मॉडलों की क्वेरी करने वाले कई ग्राहकों के लिए पूंछ विलंबता को कम रखती है, जबकि थ्रूपुट को अधिकतम करने के लिए अंतर्निहित हार्डवेयर का कुशलतापूर्वक उपयोग करती है। .

2) अनुमान अनुरोध

एपीआई सतहें

TensorFlow सर्विंग में दो API सतहें (HTTP और gRPC) हैं, जो दोनों PredictionService API को लागू करती हैं (HTTP सर्वर के MultiInference एंडपॉइंट को उजागर नहीं करने के अपवाद के साथ)। दोनों एपीआई सतहें अत्यधिक ट्यून की गई हैं और न्यूनतम विलंबता जोड़ती हैं लेकिन व्यवहार में, जीआरपीसी सतह को थोड़ा अधिक प्रदर्शन करने वाला माना जाता है।

एपीआई तरीके

सामान्य तौर पर, क्लासिफाई और रिग्रेस एंडपॉइंट का उपयोग करने की सलाह दी जाती है क्योंकि वे tf.Example को स्वीकार करते हैं, जो एक उच्च-स्तरीय अमूर्तता है; हालाँकि, बड़े (O(Mb)) संरचित अनुरोधों के दुर्लभ मामलों में, समझदार उपयोगकर्ता PredictRequest का उपयोग कर सकते हैं और सीधे अपने Protobuf संदेशों को TensorProto में एन्कोड कर सकते हैं, और क्रमबद्धता को छोड़ कर tf.Example से डिसेरिएलाइज़ेशन को मामूली प्रदर्शन लाभ का स्रोत मान सकते हैं।

बैच का आकार

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

3) सर्वर (हार्डवेयर और बाइनरी)

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

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

त्वरक

यदि आपके होस्ट के पास त्वरक तक पहुंच है, तो सुनिश्चित करें कि आपने त्वरक पर सघन गणना करने के लिए अपना मॉडल लागू किया है - यदि आपने उच्च-स्तरीय टेन्सरफ्लो एपीआई का उपयोग किया है, तो यह स्वचालित रूप से किया जाना चाहिए, लेकिन यदि आपने कस्टम ग्राफ़ बनाए हैं, या पिन करना चाहते हैं विशिष्ट त्वरक पर ग्राफ़ के विशिष्ट भागों के लिए, आपको त्वरक पर कुछ सबग्राफ को मैन्युअल रूप से रखने की आवश्यकता हो सकती है (यानी with tf.device('/device:GPU:0'): ... उपयोग करके)।

आधुनिक सीपीयू

आधुनिक सीपीयू ने SIMD (सिंगल इंस्ट्रक्शन मल्टीपल डेटा) और सघन संगणना के लिए महत्वपूर्ण अन्य सुविधाओं (उदाहरण के लिए एक घड़ी चक्र में गुणा और जोड़) के लिए समर्थन में सुधार करने के लिए x86 इंस्ट्रक्शन सेट आर्किटेक्चर को लगातार बढ़ाया है। हालाँकि, थोड़ी पुरानी मशीनों पर चलने के लिए, TensorFlow और TensorFlow सर्विंग को इस मामूली धारणा के साथ बनाया गया है कि इनमें से नवीनतम सुविधाएँ होस्ट CPU द्वारा समर्थित नहीं हैं।

Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 FMA

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

बाइनरी कॉन्फ़िगरेशन

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

टेन्सरफ्लो सर्विंग अनुमान अनुरोध का जीवन

आइए एक सामान्य अनुरोध के माध्यम से होने वाली यात्रा को देखने के लिए टेन्सरफ्लो सर्विंग अनुमान अनुरोध के एक प्रोटोटाइप उदाहरण के जीवन के बारे में संक्षेप में जानें। हमारे उदाहरण के लिए, हम 2.0.0 टेन्सरफ्लो सर्विंग जीआरपीसी एपीआई सतह द्वारा प्राप्त किए जा रहे एक पूर्वानुमान अनुरोध पर गौर करेंगे।

आइए पहले एक घटक-स्तरीय अनुक्रम आरेख को देखें, और फिर उस कोड पर जाएं जो इंटरैक्शन की इस श्रृंखला को लागू करता है।

अनुक्रम आरेख

ध्यान दें कि क्लाइंट उपयोगकर्ता के स्वामित्व वाला एक घटक है, प्रेडिक्शन सर्विस, सर्वेबल्स और सर्वर कोर का स्वामित्व TensorFlow सर्विंग के पास है और TensorFlow रनटाइम का स्वामित्व Core TensorFlow के पास है।

अनुक्रम विवरण

1. PredictionServiceImpl::Predict PredictRequest प्राप्त करता है
2. हम TensorflowPredictor::Predict को लागू करते हैं, जो GRPC अनुरोध (यदि कोई सेट किया गया था) से अनुरोध की समय सीमा का प्रचार करता है।
3. TensorflowPredictor::Predict के अंदर, हम उस सर्व करने योग्य (मॉडल) को देखते हैं जिस पर अनुरोध अनुमान लगाना चाहता है, जिससे हम SaveModel के बारे में जानकारी प्राप्त करते हैं और इससे भी महत्वपूर्ण बात यह है कि Session ऑब्जेक्ट के लिए एक हैंडल जिसमें मॉडल ग्राफ़ है (संभवतः आंशिक रूप से) लदा हुआ। जब मॉडल को TensorFlow सर्विंग द्वारा लोड किया गया था तो यह सर्व करने योग्य ऑब्जेक्ट मेमोरी में बनाया और प्रतिबद्ध किया गया था। फिर हम भविष्यवाणी को पूरा करने के लिए इंटरनल::रनप्रेडिक्ट को लागू करते हैं।
4. internal::RunPredict में, अनुरोध को सत्यापित और प्रीप्रोसेस करने के बाद, हम Session::Run पर ब्लॉकिंग कॉल का उपयोग करके अनुमान लगाने के लिए Session ऑब्जेक्ट का उपयोग करते हैं, जिस बिंदु पर, हम कोर TensorFlow के कोडबेस में प्रवेश करते हैं। Session::Run रिटर्न और हमारे outputs टेंसर पॉप्युलेट होने के बाद, हम आउटपुट को PredictionResponse में परिवर्तित करते हैं और कॉल स्टैक पर परिणाम लौटाते हैं।