LLM API आउटेज: रीट्राई, fallback और सीमित सेवा
त्रुटि वर्गीकरण, सीमित रीट्राई, सर्किट ब्रेकर, स्पष्ट सीमित व्यवहार और परखे प्रदाता fallback से API आउटेज के दौरान SaaS AI फीचर संभालें।
इस मार्गदर्शिका में
SaaS ऐप LLM प्रदाता आउटेज को कैसे संभाले?
अस्थायी प्रदाता समस्या को उन त्रुटियों से अलग करें जो रीट्राई से ठीक नहीं होंगी, फिर सीमित सुधार योजना अपनाएँ। प्रदाता की रीट्राई सलाह मानें, कम प्रयास वाला बजट और backoff रखें, लगातार विफलता पर circuit खोलें और AI फीचर सुरक्षित रूप से न चले तो स्पष्ट सीमित उत्तर दें। आउटेज से असीम एजेंट लूप, दोहरी ग्राहक कार्रवाई या डेटा प्रोसेसिंग और उत्तर गुणवत्ता बदलने वाला चुपचाप विकल्प शुरू न हो।
रीट्राई से पहले त्रुटि का वर्ग पहचानें
अस्थायी overload, नेटवर्क टाइमआउट और rate limit को गलत अनुरोध, गायब अनुमति, खत्म क्रेडिट और खर्च सीमा से अलग करें। अस्थायी स्थिति में सीमित इंतज़ार उपयोगी हो सकता है; प्रमाणीकरण, स्कीमा और बिलिंग त्रुटियों को दोहराने से नहीं, सुधारने से ठीक करें। अपने प्रदाता और SDK संस्करण के documented status, error code और Retry-After को देखें।
प्रयास सीमित रखें और Retry-After का पालन करें
अधिकतम प्रयास, कुल समय सीमा और प्रति टेनेंट रीट्राई बजट तय करें। प्रदाता Retry-After दे तो कम से कम उतना इंतज़ार करें; नहीं दे तो jitter सहित exponential backoff अपनाएँ और एक साथ रीट्राई से बचें। कॉल स्टैक की एक परत पर रीट्राई समन्वित करें तथा SDK के स्वचालित प्रयास भी गिनें।
अनिश्चित नतीजे से सुरक्षित तरीके से फिर शुरू करें
टाइमआउट तब भी आ सकता है जब प्रदाता या डाउनस्ट्रीम टूल काम पूरा कर चुका हो। स्थिति ट्रैक करें और साइड इफेक्ट में idempotency key रखें ताकि रीट्राई से दोहरा संदेश, खाता शुल्क या रिकॉर्ड बदलाव न हो। केवल UI में त्रुटि दिखी इसलिए गलत, अनधिकृत या स्पष्ट रूप से गैर-रीट्राई काम फिर न भेजें।
| त्रुटि वर्ग | रीट्राई और सीमा | उपयोगकर्ता को व्यवहार | fallback/रोक संकेत | मालिक और परीक्षण |
|---|---|---|---|---|
| अस्थायी overload | ||||
| Rate limit | ||||
| प्रमाणीकरण/कॉन्फ़िगरेशन त्रुटि |
सर्किट ब्रेकर और सीमित मोड ग्राहक कैसे बचाते हैं?
प्रदाता लगातार विफल हो तो सर्किट खोलें
टाइमआउट, overload उत्तर और निर्भरता स्वास्थ्य मापें। तय सीमा के बाद नई ट्रैफिक कुछ समय रोकें, फिर कम अनुरोध से वापसी जाँचें। रोक को केवल विफल प्रदाता, मॉडल मार्ग या फीचर तक सीमित रखें ताकि एक आउटेज असंबंधित SaaS सुविधाएँ बंद न करे।
उपयोगी और ईमानदार सीमित अनुभव तय करें
जहाँ सुरक्षित हो उपयोगकर्ता को मसौदा सहेजने, पहले से अधिकृत स्रोत देखने, बाद में कोशिश करने या हाथ से काम पूरा करने दें। पुराने या आंशिक नतीजे स्पष्ट बताएँ; विकल्प उत्तर को वर्तमान, सत्यापित या बराबर न दिखाएँ यदि ऐसा नहीं है। सुरक्षित आंशिक उत्तर उपलब्ध न हो तो स्पष्ट त्रुटि और अगला कदम दें, गढ़ा हुआ जवाब नहीं।
रीट्राई फैलने से पहले क्यू और भार सीमित करें
क्यू की गहराई, समवर्ती काम और प्रतीक्षा समय सीमित करें; छोड़े गए काम समाप्त करें और लिखित ग्राहक जरूरत के अनुसार प्राथमिकता दें। असफल होने वाले अनुरोध पर worker अटकाने के बजाय अतिरिक्त काम को सस्ते में अस्वीकार या आगे के लिए रोकें। बढ़ती घटना के शुरुआती संकेत में रीट्राई अनुपात और क्यू की उम्र देखें।
दूसरा AI प्रदाता कब सुरक्षित fallback है?
Failover से पहले व्यवहार और संगतता जाँचें
वैकल्पिक मॉडल पर वही गुणवत्ता, संरचित आउटपुट, सुरक्षा, विलंब और टूल उपयोग की जाँच करें जो प्राथमिक पर करते हैं। API का रूप समान हो तो भी व्यवहार समान नहीं होता। दोनों मार्गों पर एक-सा प्राधिकरण, टेनेंट फ़िल्टर, moderation और आउटपुट सत्यापन रखें।
अनुरोध भेजने से पहले डेटा शर्त और क्षेत्र की समीक्षा करें
पुष्टि करें कि वैकल्पिक प्रदाता, endpoint, region, data retention और subprocessors उस डेटा तथा ग्राहक वादे के लिए स्वीकृत हैं। आउटेज में ग्राहक प्रॉम्प्ट दूसरे सेवा को न भेजें जब तक प्रोसेसिंग और ट्रांसफ़र शर्त अनुमति न दें। मंजूरी न हो तो AI फीचर सीमित करें या रोकें।
प्रोडक्शन साइड इफेक्ट बिना failover और वापसी का अभ्यास करें
कृत्रिम या स्वीकृत ट्रैफिक पर नियमित परीक्षण करें। सर्किट खुलना, दूसरा मार्ग, बजट, सही ग्राहक स्थिति और स्थिर वापसी सत्यापित करें ताकि ट्रैफिक बार-बार दोनों तरफ न बदले। fallback बंद करने का तरीका और बदलाव के समय चल रहे काम का मिलान भी लिखें।
LLM API आउटेज के आम सवाल
क्या हर LLM API त्रुटि को रीट्राई करना चाहिए?
नहीं। केवल documented अस्थायी स्थिति को सीमित नीति के तहत दोहराएँ। प्रमाणीकरण, अनुरोध और बिलिंग त्रुटि को बार-बार भेजने के बजाय ठीक करें।
ऐप को LLM कॉल कितनी बार रीट्राई करनी चाहिए?
कोई सार्वभौमिक संख्या नहीं। प्रति अनुरोध और सेवा-स्तर बजट, कुल समय सीमा और jitter वाला backoff तय करें। SDK के प्रयास भी गिनें और प्रदाता के Retry-After का पालन करें।
क्या अपने आप दूसरे मॉडल प्रदाता पर failover करना चाहिए?
केवल तब जब विकल्प गुणवत्ता, सुरक्षा, डेटा प्रोसेसिंग, क्षेत्र और लागत समीक्षा पास कर चुका हो। अन्यथा फीचर साफ तौर पर सीमित करें या रोकें।
AI आउटेज में उपयोगकर्ता को क्या दिखाना चाहिए?
समय पर ईमानदार स्थिति और अगला उपयोगी कदम दें—जैसे काम सहेजना, बाद में कोशिश करना या स्वीकृत हाथ से किया जाने वाला रास्ता। अधूरे या बदले उत्तर को सत्यापित या बराबर न बताएँ।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
मसौदा 27 सितंबर 2026 को तैयार; इंजीनियरिंग, सुरक्षा और संपादकीय समीक्षा लंबित · स्रोत जाँचे गए .
- Error codes
- Google SRE: Handling Overload
- Google SRE: Addressing Cascading Failures
- LLM10:2025 Unbounded Consumption
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)
- Evaluation best practices
- Your data and model usage policies by endpoint
- Production best practices