Model Serving (batch vs real-time)
- ●Model serving মানে train করা model দিয়ে production-এ prediction দেওয়া — মূলত দুই ধরনের: batch ও real-time inference।
- ●Batch inference আগে থেকে বিশাল prediction তৈরি করে রাখে, real-time inference একটা request-এ মিলিসেকেন্ডে উত্তর দেয়।
- ●Latency, খরচ ও autoscaling সামলাতে caching, GPU/CPU পছন্দ ও shadow deployment গুরুত্বপূর্ণ কৌশল।
সমস্যাটা কী?
Model train হয়ে গেল, evaluation-এ ৯৫% accuracy এলো — কিন্তু একটা train করা model একটা .pkl বা .pt ফাইল মাত্র, যা পড়ে আছে। এখন আসল প্রশ্ন: এটা দিয়ে user-কে কীভাবে সেবা দেবে?
দুটো সম্পূর্ণ ভিন্ন পরিস্থিতি হতে পারে। একটা — "প্রতি রাতে সব customer-এর জন্য কোন email পাঠাব তা ঠিক করো।" আরেকটা — "এই মুহূর্তে user যে ছবি upload করল, ২০০ মিলিসেকেন্ডের মধ্যে বলো এতে বিড়াল আছে কিনা।" প্রথমটায় সময় হাতে আছে, দ্বিতীয়টায় এক চোখের পলকে উত্তর চাই। এই দুই দুনিয়ার জন্য serving-এর কৌশল সম্পূর্ণ আলাদা — এটাই model serving-এর মূল বিষয়।
মূল ধারণা
Model serving হলো একটি train করা ML model-কে production environment-এ এমনভাবে চালু রাখা, যাতে এটি নতুন input পেয়ে prediction (inference) ফেরত দিতে পারে — নির্ভরযোগ্য, দ্রুত ও খরচ-সাশ্রয়ীভাবে।
Serving-এর কেন্দ্রে থাকে একটা model server — যেমন TensorFlow Serving, TorchServe, বা NVIDIA Triton। এটা model-টা memory-তে load করে রাখে আর একটা API (REST/gRPC) দিয়ে request নেয়। তুমি input পাঠাও, সে model চালিয়ে output ফেরত দেয়। মূল চ্যালেঞ্জ তিনটি — latency (কত দ্রুত), throughput (সেকেন্ডে কতগুলো request), আর cost (কত টাকা খরচ)।
কীভাবে কাজ করে
Batch vs Real-time inference
এই দুটি serving-এর মূল ভাগ:
| বিষয় | Batch Inference | Real-time Inference |
|---|---|---|
| কখন চলে | নির্দিষ্ট সময় পরপর (রাতে) | request আসা মাত্র |
| Latency | মিনিট/ঘণ্টা চলে | মিলিসেকেন্ড |
| Input | কোটি row একসাথে | একটা request |
| খরচ | কম (একবারে চালানো) | বেশি (সবসময় চালু) |
| উদাহরণ | প্রতিদিন product recommendation pre-compute | live fraud check |
GPU vs CPU
কোন hardware-এ serve করবে সেটাও বড় সিদ্ধান্ত:
| দিক | CPU | GPU |
|---|---|---|
| ভালো যেখানে | ছোট model, কম traffic | বড় deep model, batch |
| খরচ | কম | অনেক বেশি |
| Parallelism | সীমিত | বিশাল |
ছোট একটা logistic regression-এর জন্য GPU অপচয়; কিন্তু একটা বড় transformer বা image model real-time-এ চালাতে GPU প্রায় বাধ্যতামূলক।
Latency কমানোর কৌশল
- Caching predictions: একই বা জনপ্রিয় input বারবার এলে আগের উত্তর cache থেকে দাও — model আবার চালাতে হয় না।
- Batching: real-time-এও কয়েক মিলিসেকেন্ডের কয়েকটা request একসাথে জড়ো করে একবারে চালালে GPU বেশি কার্যকর হয় (dynamic batching)।
- Model optimization: quantization বা distillation দিয়ে model ছোট ও দ্রুত করা।
Autoscaling
Traffic ওঠানামা করে — দুপুরে কম, সন্ধ্যায় বেশি। Autoscaling মানে load অনুযায়ী server-এর সংখ্যা নিজে থেকে বাড়ানো-কমানো, যাতে peak-এও latency ঠিক থাকে আবার রাতে অযথা টাকা না পোড়ে।
ভাবো একটা রেস্টুরেন্ট। Batch inference হলো বিয়ে বাড়ির রান্না — আগের রাতে ৫০০ মানুষের খাবার একবারে রেঁধে রাখা হলো, খরচ কম, কিন্তু তাজা গরম নয়। Real-time inference হলো à la carte — customer order দিলে তখনই রাঁধা হয়, গরম-তাজা, কিন্তু শেফ সবসময় প্রস্তুত থাকতে হয় বলে খরচ বেশি। সন্ধ্যায় ভিড় বাড়লে অতিরিক্ত শেফ ডাকা (autoscaling), আর বিরিয়ানির মতো জনপ্রিয় item আগে থেকে কিছু বানিয়ে রাখা (caching) — দুটোই গতি বাড়ায়।
কৌশল
Production-এ নতুন model নিরাপদে আনার কয়েকটি কৌশল:
- Shadow deployment: নতুন model real traffic পায় কিন্তু তার উত্তর user-কে দেখানো হয় না — শুধু পুরোনো model-এর সাথে তুলনা করা হয়।
- Canary release: ৫% traffic নতুন model-এ পাঠিয়ে দেখা হয় সব ঠিক আছে কিনা, তারপর ধীরে বাড়ানো হয়।
- A/B testing: দুই model সমান্তরালে চালিয়ে business metric (যেমন click rate) তুলনা করা।
কখন ব্যবহার করবে / করবে না
Batch বেছে নাও যখন: তাৎক্ষণিকতা লাগে না, prediction আগে থেকে গণনা করা যায় (যেমন নিউজলেটার, রাতের report)। Real-time বেছে নাও যখন: input আগে থেকে জানা সম্ভব না আর তাৎক্ষণিক উত্তর দরকার (search, fraud, live recommendation)।
Real-time serving-কে অতিরিক্ত-ইঞ্জিনিয়ার করা একটা সাধারণ ভুল। অনেকে batch দিয়েই চলে এমন কাজেও GPU-চালিত real-time API বানিয়ে বসে, ফলে মাসে হাজার ডলার গচ্চা যায়। আগে নিজেকে জিজ্ঞেস করো — "user কি সত্যিই এই মুহূর্তের উত্তর চায়, নাকি কাল সকালের prediction-ই যথেষ্ট?" উত্তর যদি batch হয়, batch-ই করো।
বাস্তব উদাহরণ
YouTube-এর কথা ভাবো। তোমার homepage-এর জন্য candidate video-গুলো অনেকটাই batch-এ pre-compute করা থাকে। কিন্তু তুমি একটা video play করার সাথে সাথে পাশের "up next" তালিকা real-time inference-এ ঠিক হয় — কারণ তুমি এইমাত্র কী দেখছ সেটা আগে থেকে জানা সম্ভব ছিল না।
তারা GPU server-এ বড় ranking model চালায়, dynamic batching দিয়ে throughput বাড়ায়, আর জনপ্রিয় video-র জন্য prediction cache করে। নতুন কোনো ranking model আসলে আগে shadow mode-এ চালিয়ে দেখে আসল model থেকে কতটা আলাদা, তারপর canary দিয়ে অল্প traffic-এ ছাড়ে। peak সময়ে autoscaling নিজে থেকে আরও server যোগ করে। এই পুরো ব্যবস্থাটাই পরিণত model serving।
Interview-এ "কীভাবে serve করবে" জিজ্ঞেস করলে প্রথমেই একটা প্রশ্ন ফেরত দাও — "latency requirement কী, আর prediction কি আগে থেকে compute করা যায়?" এই দুই উত্তর থেকেই batch নাকি real-time তা ঠিক হয়। তারপর latency budget (যেমন ৫০ ms), caching, autoscaling আর নিরাপদ rollout-এর জন্য shadow/canary উল্লেখ করলে তোমার উত্তর সম্পূর্ণ মনে হবে।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Batch inference কখন বেশি উপযুক্ত?
2. Real-time inference-এ caching predictions কেন কাজে লাগে?
3. Shadow deployment-এর উদ্দেশ্য কী?