Production Readiness Checklist

Roboflow deployments के लिए production readiness - HTTP error handling और retries, timeouts और cold starts, rate limits, और Dedicated Deployment replica sizing।

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

HTTP त्रुटियाँ और पुनः प्रयास

Roboflow के inference और management API मानक HTTP स्थिति कोड का उपयोग करते हैं। पूर्ण क्रॉस-टूल तालिका (REST स्थिति कोड, SDK अपवाद, और CLI निकास कोड) में उपलब्ध है त्रुटियाँ और स्थिति कोड. प्रोडक्शन के लिए मुख्य नियम यह है कि केवल वही पुनः प्रयास करें जो वास्तव में पुनः प्रयास योग्य हो:

स्थिति	पुनः प्रयास?	मार्गदर्शन
200 / 204	-	सफल।
400	नहीं	गलत स्वरूप वाला अनुरोध - payload को ठीक करें; पुनः प्रयास करने पर वही खराब अनुरोध भेजा जाएगा।
401 / 403	नहीं	प्रमाणीकरण या पहुँच विफलता। पुनः प्रयास करने पर key मान्य नहीं हो जाएगी; API key और उसके scopes की जाँच करें।
402 / 423	नहीं	प्लान की सीमा, quota पूरा हो गया है, या बिलिंग रोकी गई है। इसे बिलिंग पक्ष में हल करें; लूप में पुनः प्रयास न करें।
404	नहीं	संसाधन मौजूद नहीं है या आपकी key को दिखाई नहीं देता।
429	हाँ	दर-सीमित। बैक ऑफ करें और घातीय बैकऑफ़ के साथ पुनः प्रयास करें (देखें दर सीमाएँ).
5xx	हाँ	अस्थायी सर्वर त्रुटि। बैकऑफ़ के साथ पुनः प्रयास करना सुरक्षित है।

बैकऑफ़ पैटर्न। के लिए 429 और 5xx, घातीय बैकऑफ़ और jitter के साथ पुनः प्रयास करें (उदाहरण के लिए, 1s, 2s, 4s, 8s के साथ एक यादृच्छिक ऑफ़सेट), प्रयासों की संख्या सीमित करते हुए। कभी भी पुनः प्रयास न करें 401/403/404/400 स्वचालित रूप से - इसके बजाय उन्हें अपने ऐप्लिकेशन में प्रदर्शित करें।

जब आप समर्पित परिनियोजन management service (https://roboflow.cloud), तो response code को स्पष्ट रूप से जाँचें: एक 200 एक JSON body लौटाता है, और कोई भी अन्य code एक error message को string के रूप में लौटाता है।

टाइमआउट और कोल्ड स्टार्ट

यह Serverless Cloud API मॉडल्स को मांग पर लोड करती है। किसी ऐसे मॉडल पर पहला अनुरोध जो पहले से सर्वर पर मौजूद नहीं है ("warmup") में कई सेकंड लग सकते हैं, और जो मॉडल निष्क्रिय रहा है (उदाहरण के लिए, इन्फ़ेरेंस के बीच लगभग 10 मिनट) उसे अनलोड किया जा सकता है और अगले कॉल पर फिर से लोड करने की आवश्यकता हो सकती है।

• उदार client timeouts सेट करें। जो client timeout इतना कड़ा हो कि वह cold start पर ट्रिगर हो जाए, वह उन अनुरोधों को विफल कर देगा जो अन्यथा सफल हो जाते। पहले अनुरोध और निष्क्रिय अवधि के बाद warmup के लिए अतिरिक्त समय रखें।

• मॉडल को पहले से तैयार करें। यदि अनुमानित latency महत्वपूर्ण है, तो अपने latency-संवेदनशील ट्रैफ़िक से पहले एक warmup request भेजें ताकि मॉडल पहले से cached हो।

• response headers पर नज़र रखें। Serverless responses में शामिल हैं x-model-cold-start (क्या इस अनुरोध ने लोड लागत चुकाई) और x-processing-time. इनका उपयोग cold-start की आवृत्ति और processing time की निगरानी के लिए करें। देखें Serverless pricing कि ये headers बिलिंग में कैसे शामिल होते हैं।

• अपलोड को सीमा के अंदर रखें। Serverless Cloud API फ़ाइल अपलोड स्वीकार करती है, अधिकतम 20 MB; बड़ी images अस्वीकार कर दी जाती हैं। भेजने से पहले images का आकार कम करें (Python SDK यह स्वचालित रूप से करता है), जिससे आमतौर पर सटीकता पर असर नहीं पड़ता क्योंकि images वैसे भी मॉडल के input size के अनुसार resize हो जाती हैं। Batch Processing प्रति-image वही 20 MB सीमा लागू करता है।

बिना cold starts के निरंतर कम latency के लिए, उपयोग करें समर्पित परिनियोजन या Self-Hosted Inference साझा serverless endpoint के बजाय।

दर सीमाएँ

• Serverless Cloud API. एक पर 429, धीमा करें और घातीय बैकऑफ़ के साथ पुनः प्रयास करें। यदि आप लगातार सीमाओं तक पहुँच रहे हैं या अधिक throughput की आवश्यकता है, तो अपने enterprise support संपर्क या Roboflow फ़ोरम, या समर्पित परिनियोजन.

• Deployment Manager API. edge-device management endpoints स्पष्ट per-endpoint सीमाएँ लागू करते हैं और लौटाते हैं 429 जब सीमा पार हो जाती है - उदाहरण के लिए, device logs की सीमा है प्रति IP प्रति मिनट 5 अनुरोध और वैश्विक रूप से प्रति मिनट 50, और telemetry reads की सीमा है प्रति device प्रति मिनट 60 अनुरोध 10 सेकंड में 10 अनुरोधों के burst के साथ। देखें Deployment Manager API सटीक सीमाएँ और error shapes के लिए, इससे पहले कि आप किसी integration में polling जोड़ें।

जब आपके path के लिए कोई documented संख्या मौजूद न हो, तो मानें 429 कि यह बैकऑफ़ करने का संकेत है, न कि एक निश्चित budget मानने का, और सपोर्ट से संपर्क करें यदि आपको अधिक सीमा चाहिए।

समर्पित परिनियोजन replica sizing

जब आप एक समर्पित परिनियोजनबनाते हैं, आप सेट कर सकते हैं min_replicas और max_replicas (दोनों का डिफ़ॉल्ट है 1):

• min_replicas चल रही प्रतिकृतियों की संख्या है। उच्च minimum से bursty load के तहत cold-start latency कम होती है, लेकिन हमेशा चालू क्षमता की कीमत पर।

• max_replicas यह सीमित करता है कि लोड के तहत परिनियोजन कितना scale out करता है। अधिक peak throughput के लिए इसे बढ़ाएँ।

स्थिर ट्रैफ़िक के लिए, min_replicas और max_replicas का 1 सबसे सरल शुरुआती बिंदु है; बढ़ाएँ max_replicas जब एक अकेली replica peak load के साथ नहीं चल पा रही हो, और बढ़ाएँ min_replicas यदि विराम के बाद पहला अनुरोध बहुत धीमा हो।

auto-pause के साथ अंतःक्रिया

समर्पित परिनियोजन निष्क्रियता की अवधि के बाद auto-pause - के लिए 1 घंटे पर तय है dev-cpu और dev-gpu प्रकार - और जब आप अपनी API key के साथ अनुरोध भेजते हैं, तब फिर से शुरू होती है। रोका गया परिनियोजन replicas नहीं परोस रहा होता, इसलिए उसे फिर से शुरू करने वाला अनुरोध resume latency चुकाता है।

• का उपयोग करें persistent prod-cpu / prod-gpu उन प्रकारों का, जो प्रोडक्शन ट्रैफ़िक के लिए हैं और हमेशा तैयार रहने चाहिए।

• अस्थायी dev-cpu / dev-gpu प्रकारों को परीक्षण और प्रोटोटाइपिंग के लिए सुरक्षित रखें - इन्हें कुछ घंटों बाद स्वचालित रूप से भी हटा दिया जाता है।

• यदि आपको uptime के बजाय अनुरोध संख्या पर आधारित बिलिंग, या एक कस्टम pause/replica नीति चाहिए, सेल्स से संपर्क करें.

लाइव जाने से पहले

• पुनः प्रयास हर outbound call को घेरते हैं, केवल 429 और 5xx बैकऑफ़ के साथ।

• Client timeouts serverless cold starts को समाहित करने के लिए पर्याप्त उदार हैं।

• छवियों का आकार कम किया जाता है ताकि वे 20 MB अपलोड सीमा के भीतर रहें।

• API keys न्यूनतम आवश्यक scopes का उपयोग करती हैं और secrets के रूप में संग्रहीत होती हैं, hard-coded नहीं।

• समर्पित परिनियोजन के लिए, min_replicas / max_replicas आपके लोड के अनुसार आकार दिए गए हैं और आपने एक चुना है prod-* हमेशा चालू ट्रैफ़िक के लिए प्रकार।

• आप परिनियोजनों की निगरानी करते हैं - देखें Model Monitoring - और error-rate तथा latency regressions पर alert करें।