टेंसरफ़्लो सर्विंग कॉन्फ़िगरेशन

इस गाइड में, हम टेन्सरफ्लो सर्विंग के लिए कई कॉन्फ़िगरेशन बिंदुओं पर जाएंगे।

अवलोकन

जबकि अधिकांश कॉन्फ़िगरेशन मॉडल सर्वर से संबंधित हैं, टेन्सरफ़्लो सर्विंग के व्यवहार को निर्दिष्ट करने के कई तरीके हैं:

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

मॉडल सर्वर कॉन्फ़िगरेशन

किसी मॉडल को प्रस्तुत करने का सबसे आसान तरीका --model_name और --model_base_path फ़्लैग प्रदान करना है (या यदि डॉकर का उपयोग कर रहे हैं तो MODEL_NAME पर्यावरण चर सेट करना)। हालाँकि, यदि आप कई मॉडलों की सेवा करना चाहते हैं, या नए संस्करणों के लिए मतदान आवृत्ति जैसे विकल्पों को कॉन्फ़िगर करना चाहते हैं, तो आप मॉडल सर्वर कॉन्फ़िगरेशन फ़ाइल लिखकर ऐसा कर सकते हैं।

आप इस कॉन्फ़िगरेशन फ़ाइल को --model_config_file फ़्लैग का उपयोग करके प्रदान कर सकते हैं और Tensorflow सर्विंग को --model_config_file_poll_wait_seconds फ़्लैग सेट करके निर्दिष्ट पथ पर इस कॉन्फ़िगरेशन फ़ाइल के अद्यतन संस्करणों के लिए समय-समय पर मतदान करने का निर्देश दे सकते हैं।

डॉकर का उपयोग करने वाला उदाहरण:

docker run -t --rm -p 8501:8501 \
    -v "$(pwd)/models/:/models/" tensorflow/serving \
    --model_config_file=/models/models.config \
    --model_config_file_poll_wait_seconds=60

मॉडल सर्वर कॉन्फ़िगरेशन पुनः लोड हो रहा है

मॉडल सर्वर कॉन्फ़िगरेशन को पुनः लोड करने के दो तरीके हैं:

• --model_config_file_poll_wait_seconds फ़्लैग सेट करके सर्वर को समय-समय पर --model_config_file फ़ाइलपथ पर एक नई कॉन्फ़िग फ़ाइल की जाँच करने का निर्देश दें।

• सर्वर पर HandleReloadConfigRequest RPC कॉल जारी करके और प्रोग्रामेटिक रूप से एक नया मॉडल सर्वर कॉन्फिगरेशन प्रदान करके।

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

मॉडल सर्वर कॉन्फ़िगरेशन विवरण

प्रदान की गई मॉडल सर्वर कॉन्फ़िगरेशन फ़ाइल एक मॉडलसर्वरकॉन्फ़िग प्रोटोकॉल बफ़र होनी चाहिए।

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

model_config_list {
  config {
    name: 'my_first_model'
    base_path: '/tmp/my_first_model/'
    model_platform: 'tensorflow'
  }
  config {
    name: 'my_second_model'
    base_path: '/tmp/my_second_model/'
    model_platform: 'tensorflow'
  }
}

एक मॉडल को कॉन्फ़िगर करना

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

किसी मॉडल का विशिष्ट संस्करण प्रस्तुत करना

मॉडल के एक विशिष्ट संस्करण की सेवा के लिए, हमेशा सबसे बड़े संस्करण संख्या वाले संस्करण में परिवर्तित होने के बजाय, model_version_policy को "विशिष्ट" पर सेट करें और वह संस्करण संख्या प्रदान करें जिसे आप प्रस्तुत करना चाहते हैं। उदाहरण के लिए, संस्करण 42 को सेवा के रूप में पिन करने के लिए:

model_version_policy {
  specific {
    versions: 42
  }
}

यदि नवीनतम संस्करण में कोई समस्या पाई जाती है तो यह विकल्प किसी ज्ञात अच्छे संस्करण पर वापस जाने के लिए उपयोगी है।

एक मॉडल के एकाधिक संस्करण प्रस्तुत करना

मॉडल के कई संस्करणों को एक साथ प्रस्तुत करने के लिए, उदाहरण के लिए ट्रैफ़िक के एक टुकड़े के साथ एक अस्थायी नए संस्करण को सक्षम करने के लिए, model_version_policy को "विशिष्ट" पर सेट करें और एकाधिक संस्करण संख्याएँ प्रदान करें। उदाहरण के लिए, संस्करण 42 और 43 प्रस्तुत करने के लिए:

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}

कैनरी और रोलबैक को सरल बनाने के लिए मॉडल संस्करणों में स्ट्रिंग लेबल निर्दिष्ट करना

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

आप इन मॉडल संस्करण उपनामों या लेबलों को इस प्रकार कॉन्फ़िगर कर सकते हैं:

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 42
}
version_labels {
  key: 'canary'
  value: 43
}

उपरोक्त उदाहरण में, आप संस्करण 42 और 43 पेश कर रहे हैं, और लेबल "स्थिर" को संस्करण 42 के साथ और लेबल "कैनरी" को संस्करण 43 के साथ जोड़ रहे हैं। आप अपने ग्राहकों से "स्थिर" या "कैनरी" में से किसी एक पर सीधे प्रश्न पूछ सकते हैं। (शायद उपयोगकर्ता आईडी को हैश करने पर आधारित) मॉडलस्पेक प्रोटोकॉल बफर के संस्करण_लेबल फ़ील्ड का उपयोग करके, और क्लाइंट को सूचित किए बिना सर्वर पर लेबल को आगे बढ़ाएं। एक बार जब आप कैनरी संस्करण 43 पूरा कर लें और इसे स्थिर में बढ़ावा देने के लिए तैयार हों, तो आप कॉन्फ़िगरेशन को इसमें अपडेट कर सकते हैं:

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 43
}
version_labels {
  key: 'canary'
  value: 43
}

यदि आपको बाद में रोलबैक करने की आवश्यकता है, तो आप पुराने कॉन्फ़िगरेशन पर वापस लौट सकते हैं जिसका संस्करण 42 "स्थिर" है। अन्यथा, आप संस्करण 42 को उतारकर और तैयार होने पर नया संस्करण 44 लोड करके आगे बढ़ सकते हैं, और फिर कैनरी लेबल को 44 तक आगे बढ़ा सकते हैं, इत्यादि।

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

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

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

इस सुरक्षा जांच का अनुपालन करने के लिए, यदि पहले से उपयोग में आने वाले संस्करण लेबल को दोबारा असाइन किया जा रहा है, तो आपको इसे केवल पहले से लोड किए गए संस्करणों को ही असाइन करना होगा। उदाहरण के लिए, यदि आप किसी लेबल को संस्करण N से संस्करण N+1 की ओर ले जाना चाहते हैं, तो आप पहले संस्करण N और N+1 युक्त एक कॉन्फ़िगरेशन सबमिट कर सकते हैं, और फिर एक कॉन्फ़िगरेशन सबमिट कर सकते हैं जिसमें संस्करण N+1, लेबल शामिल है एन+1 की ओर इशारा करते हुए और कोई संस्करण एन नहीं।

बाकी उपयोग

यदि आप अनुमान अनुरोध करने के लिए उपयोग करने के बजाय REST API सतह का उपयोग कर रहे हैं

/v1/models/<model name>/versions/<version number>

बस अपने अनुरोध पथ को इस प्रकार संरचित करके एक लेबल का उपयोग करके एक संस्करण का अनुरोध करें

/v1/models/<model name>/labels/<version label> ।

ध्यान दें कि संस्करण लेबल वर्ड वर्णों के अनुक्रम तक ही सीमित है, जो अल्फ़ान्यूमेरल वर्णों और अंडरस्कोर (यानी [a-zA-Z0-9_]+ ) से बना है।

मॉनिटरिंग कॉन्फ़िगरेशन

आप मॉनिटरिंग कॉन्फिग प्रोटोकॉल बफर वाली फ़ाइल को निर्दिष्ट करने के लिए --monitoring_config_file ध्वज का उपयोग करके सर्वर को एक मॉनिटरिंग कॉन्फ़िगरेशन प्रदान कर सकते हैं। यहाँ एक उदाहरण है:

prometheus_config {
  enable: true,
  path: "/monitoring/prometheus/metrics"
}

उपरोक्त मॉनिटरिंग यूआरएल से मेट्रिक्स पढ़ने के लिए, आपको सबसे पहले --rest_api_port फ़्लैग सेट करके HTTP सर्वर को सक्षम करना होगा। फिर आप अपने प्रोमेथियस सर्वर को --rest_api_port और path के मानों को पास करके मॉडल सर्वर से मेट्रिक्स खींचने के लिए कॉन्फ़िगर कर सकते हैं।

टेन्सरफ़्लो सर्विंग उन सभी मेट्रिक्स को एकत्रित करती है जो सर्विंग के साथ-साथ कोर टेन्सरफ़्लो द्वारा कैप्चर किए गए हैं।

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

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

उदाहरण बैचिंग पैरामीटर फ़ाइल:

max_batch_size { value: 128 }
batch_timeout_micros { value: 0 }
max_enqueued_batches { value: 1000000 }
num_batch_threads { value: 8 }

कृपया गहन चर्चा के लिए बैचिंग गाइड देखें और पैरामीटर्स कैसे सेट करें यह समझने के लिए पैरामीटर्स पर अनुभाग देखें।

विविध झंडे

गाइड में अब तक शामिल किए गए झंडों के अलावा, यहां हम कुछ अन्य उल्लेखनीय झंडों की सूची बना रहे हैं। पूरी सूची के लिए, कृपया स्रोत कोड देखें।

• --port : जीआरपीसी एपीआई सुनने के लिए पोर्ट
• --rest_api_port : HTTP/REST API को सुनने के लिए पोर्ट
• --rest_api_timeout_in_ms : HTTP/REST API कॉल के लिए टाइमआउट
• --file_system_poll_wait_seconds : वह अवधि जिसके दौरान सर्वर प्रत्येक मॉडल के संबंधित मॉडल_बेस_पथ पर नए मॉडल संस्करणों के लिए फ़ाइल सिस्टम का चुनाव करता है
• --enable_model_warmup :assets.extra/ निर्देशिका में उपयोगकर्ता द्वारा प्रदत्त PredictionLogs का उपयोग करके मॉडल वार्मअप को सक्षम करता है
• --mixed_precision=bfloat16 : BF16 स्वचालित मिश्रित परिशुद्धता को सक्षम करता है