টেনসরফ্লো সার্ভিং কনফিগারেশন

এই নির্দেশিকায়, আমরা টেনসরফ্লো সার্ভিংয়ের জন্য অসংখ্য কনফিগারেশন পয়েন্টের উপরে যাব।

ওভারভিউ

যদিও বেশিরভাগ কনফিগারেশন মডেল সার্ভারের সাথে সম্পর্কিত, টেনসরফ্লো সার্ভিংয়ের আচরণ নির্দিষ্ট করার অনেক উপায় রয়েছে:

• মডেল সার্ভার কনফিগারেশন : মডেলের নাম, পথ, সংস্করণ নীতি এবং লেবেল, লগিং কনফিগারেশন এবং আরও অনেক কিছু নির্দিষ্ট করুন
• মনিটরিং কনফিগারেশন : প্রমিথিউস মনিটরিং সক্ষম এবং কনফিগার করুন
• ব্যাচিং কনফিগারেশন : ব্যাচিং সক্ষম করুন এবং এর পরামিতিগুলি কনফিগার করুন
• বিবিধ পতাকা : বিবিধ সংখ্যা. একটি টেনসরফ্লো সার্ভিং স্থাপনার আচরণকে সূক্ষ্ম-টিউন করতে পতাকা প্রদান করা যেতে পারে

মডেল সার্ভার কনফিগারেশন

একটি মডেল পরিবেশন করার সবচেয়ে সহজ উপায় হল --model_name এবং --model_base_path পতাকা প্রদান করা (অথবা ডকার ব্যবহার করলে MODEL_NAME এনভায়রনমেন্ট ভেরিয়েবল সেট করা)। যাইহোক, যদি আপনি একাধিক মডেল পরিবেশন করতে চান, বা নতুন সংস্করণের জন্য পোলিং ফ্রিকোয়েন্সি মত বিকল্পগুলি কনফিগার করতে চান, আপনি একটি মডেল সার্ভার কনফিগার ফাইল লিখে তা করতে পারেন।

আপনি --model_config_file ফ্ল্যাগ ব্যবহার করে এই কনফিগারেশন ফাইলটি প্রদান করতে পারেন এবং Tensorflow Serving-কে নির্দিষ্ট পাথে এই কনফিগারেশন ফাইলের আপডেট সংস্করণের জন্য পর্যায়ক্রমে পোল করার নির্দেশ দিতে পারেন --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 filepath-এ একটি নতুন কনফিগারেশন ফাইল পরীক্ষা করার নির্দেশ দেয়।

• সার্ভারে HandleReloadConfigRequest RPC কল ইস্যু করে এবং প্রোগ্রামিকভাবে একটি নতুন মডেল সার্ভার কনফিগারেশন সরবরাহ করে।

অনুগ্রহ করে মনে রাখবেন যে সার্ভার যখনই নতুন কনফিগারেশন ফাইল লোড করে, এটি নতুন নির্দিষ্ট কনফিগারেশনের বিষয়বস্তু এবং শুধুমাত্র নতুন নির্দিষ্ট কনফিগারেশনের বিষয়বস্তু উপলব্ধি করতে কাজ করবে। এর মানে হল যদি মডেল Aটি প্রথম কনফিগারেশন ফাইলে উপস্থিত থাকে, যা শুধুমাত্র মডেল B ধারণকারী ফাইল দিয়ে প্রতিস্থাপিত হয়, সার্ভারটি মডেল B লোড করবে এবং মডেল A আনলোড করবে।

মডেল সার্ভার কনফিগার বিবরণ

প্রদত্ত মডেল সার্ভার কনফিগারেশন ফাইলটি অবশ্যই একটি ModelServerConfig প্রোটোকল বাফার হতে হবে৷

সবচেয়ে উন্নত ব্যবহারের ক্ষেত্রে, আপনি ModelConfigList বিকল্পটি ব্যবহার করতে চাইবেন, যা ModelConfig প্রোটোকল বাফারগুলির একটি তালিকা। আমরা নীচের উন্নত বিকল্পগুলিতে ডুব দেওয়ার আগে এখানে একটি মৌলিক উদাহরণ।

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'
  }
}

এক মডেল কনফিগার করা হচ্ছে

প্রতিটি ModelConfig একটি মডেলকে পরিবেশন করার জন্য নির্দিষ্ট করে, যার নাম এবং পথটি সহ যেখানে মডেল সার্ভার পরিবেশন করার জন্য মডেলের সংস্করণগুলি সন্ধান করবে, যেমনটি উপরের উদাহরণে দেখা গেছে। ডিফল্টরূপে সার্ভারটি সবচেয়ে বড় সংস্করণ নম্বর সহ সংস্করণটি পরিবেশন করবে। মডেল_সংস্করণ_নীতি ক্ষেত্র পরিবর্তন করে এই ডিফল্টটি ওভাররাইড করা যেতে পারে।

একটি মডেলের একটি নির্দিষ্ট সংস্করণ পরিবেশন করা

মডেলের একটি নির্দিষ্ট সংস্করণ পরিবেশন করতে, সর্বদা বৃহত্তম সংস্করণ নম্বর সহ একটিতে রূপান্তর না করে, মডেল_সংস্করণ_নীতি "নির্দিষ্ট" তে সেট করুন এবং আপনি যে সংস্করণটি পরিবেশন করতে চান তা সরবরাহ করুন৷ উদাহরণস্বরূপ, পরিবেশন করার জন্য সংস্করণ 42 পিন করতে:

model_version_policy {
  specific {
    versions: 42
  }
}

এই বিকল্পটি একটি ভাল সংস্করণে ফিরে যাওয়ার জন্য উপযোগী, যদি সাম্প্রতিক সংস্করণ(গুলি) এর সাথে একটি সমস্যা আবিষ্কৃত হয়।

একটি মডেলের একাধিক সংস্করণ পরিবেশন করা

একই সাথে মডেলের একাধিক সংস্করণ পরিবেশন করতে, যেমন ট্রাফিকের স্লাইস সহ একটি অস্থায়ী নতুন সংস্করণ ক্যানারি সক্ষম করতে, মডেল_সংস্করণ_নীতি "নির্দিষ্ট" এ সেট করুন এবং একাধিক সংস্করণ নম্বর প্রদান করুন। উদাহরণস্বরূপ, 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-এর সাথে "ক্যানারি" লেবেল সংযুক্ত করছেন। আপনি আপনার ক্লায়েন্টদের "স্থির" বা "ক্যানারি"-এর যেকোনো একটিতে সরাসরি প্রশ্ন করতে পারেন (সম্ভবত ইউজার আইডি হ্যাশ করার উপর ভিত্তি করে) ModelSpec প্রোটোকল বাফারের version_label ক্ষেত্র ব্যবহার করে এবং ক্লায়েন্টদের অবহিত না করেই সার্ভারে লেবেলটি এগিয়ে যান। একবার আপনি ক্যানারি সংস্করণ 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+1 সংস্করণ থেকে সংস্করণে নির্দেশ করতে চান, তাহলে আপনি প্রথমে সংস্করণ N এবং N+1 সমন্বিত একটি কনফিগারেশন জমা দিতে পারেন এবং তারপর একটি কনফিগারেশন জমা দিতে পারেন যাতে N+1 সংস্করণ রয়েছে, লেবেল। N+1 এবং কোন সংস্করণ N-এর দিকে নির্দেশ করছে।

REST ব্যবহার

আপনি যদি REST API সারফেস ব্যবহার করে থাকেন তাহলে ব্যবহার না করে অনুমান অনুরোধ করতে

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

আপনার অনুরোধের পথটিকে এভাবে গঠন করে একটি লেবেল ব্যবহার করে একটি সংস্করণের অনুরোধ করুন

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

মনে রাখবেন যে সংস্করণ লেবেলটি শব্দ অক্ষরগুলির একটি ক্রমানুসারে সীমাবদ্ধ, যা বর্ণসংখ্যার অক্ষর এবং আন্ডারস্কোর (যেমন [a-zA-Z0-9_]+ ) দ্বারা গঠিত।

মনিটরিং কনফিগারেশন

আপনি একটি MonitoringConfig প্রোটোকল বাফার ধারণকারী ফাইল নির্দিষ্ট করতে --monitoring_config_file পতাকা ব্যবহার করে সার্ভারে একটি পর্যবেক্ষণ কনফিগারেশন প্রদান করতে পারেন। এখানে একটি উদাহরণ:

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

উপরের পর্যবেক্ষণ URL থেকে মেট্রিক্স পড়তে, আপনাকে প্রথমে --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 : gRPC API-এর জন্য শোনার জন্য পোর্ট
• --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 স্বয়ংক্রিয় মিশ্র নির্ভুলতা সক্ষম করে