API त्रुटि 429 Too Many Requests: सीमाएं, Retry-After और सुरक्षित बैकऑफ
LLM API में HTTP 429 त्रुटियों को हल करने के लिए डेवलपर गाइड: RPM/TPM सीमा विश्लेषण, Retry-After पढ़ना और एक्सपोनेंशियल बैकऑफ कोड लागू करना।
HTTP 429 Too Many Requests त्रुटि तब उत्पन्न होती है जब कोई क्लाइंट API प्रदाता द्वारा निर्धारित अनुरोध आवृत्ति या टोकन सीमा को पार कर जाता है। बिना सोचे-समझे तुरंत पुनः प्रयास (retry) करने से समस्या हल नहीं होती, बल्कि यह 'रिट्राई स्टॉर्म' (retry storm) उत्पन्न करके खाते को लंबे समय तक अवरुद्ध कर देती है।
अपने एप्लिकेशन की स्थिरता बहाल करने के लिए, डेवलपर्स को सीमा के प्रकार (RPM, TPM या बैलेंस समाप्ति) की पहचान करनी चाहिए, Retry-After हेडर को सही ढंग से पार्स करना चाहिए और रैंडम जिटर के साथ एक्सपोनेंशियल बैकऑफ (Full Jitter Exponential Backoff) लागू करना चाहिए।
LLM API में HTTP 429 त्रुटि के कारण
आधुनिक भाषा मॉडल API (जैसे OpenAI, Anthropic और संगत गेटवे) में 429 स्थिति कोड मुख्य रूप से तीन कारणों से आता है:
- RPM (Requests Per Minute): प्रति मिनट अनुरोधों की संख्या की सीमा। यह तब होता है जब बिना कतार नियंत्रण के समानांतर कई अनुरोध भेजे जाते हैं।
- TPM (Tokens Per Minute): एक मिनट की अवधि में कुल इनपुट और आउटपुट टोकन की सीमा। लंबे संदर्भ या बड़े प्रॉम्प्ट भेजने पर यह सीमा जल्दी समाप्त हो जाती है।
- कोटा या बैलेंस की समाप्ति: प्रीपेड बैलेंस शून्य होने या निर्धारित खर्च सीमा तक पहुंचने के कारण रुकावट।
जब त्रुटि बैलेंस समाप्ति या 5-घंटे की सदस्यता सीमा के कारण होती है, तो स्वचालित पुनः प्रयास केवल नेटवर्क बैंडविड्थ बर्बाद करते हैं। जटिल लॉग का विश्लेषण किए बिना मूल कारण को तुरंत समझने के लिए, BetterToken एक पारदर्शी डैशबोर्ड प्रदान करता है: यह वास्तविक समय में HTTP स्थिति कोड, इनपुट/आउटपुट/कैश टोकन का सटीक विवरण और पे-ऐज़-यू-गो बैलेंस दिखाता है बिना किसी 5-घंटे के लॉकआउट के।
429 त्रुटि निदान तालिका
Retry-After हेडर को सही ढंग से पार्स करना
RFC 6585 विनिर्देश के अनुसार, Retry-After हेडर दो मानक प्रारूपों में प्रतीक्षा समय प्रदान करता है:
- सापेक्ष सेकंड (पूर्णांक या दशमलव, उदा.
Retry-After: 12) - HTTP-Date टाइमस्टैम्प (उदा.
Retry-After: Sun, 23 Aug 2026 03:05:00 GMT)
Full Jitter एक्सपोनेंशियल बैकऑफ लागू करना
यदि Retry-After हेडर अनुपस्थित है, तो जिटर के साथ एक्सपोनेंशियल बैकऑफ का उपयोग करें। प्रयास के लिए प्रतीक्षा समय की गणना:
सुरक्षा और पुनः प्रयास में सावधानी
रीड-ओनली (GET) अनुरोधों को दोहराना सुरक्षित है। लेकिन LLM अनुमान वाले POST अनुरोधों के लिए:
- डुप्लिकेट निष्पादन रोकें: यदि नेटवर्क टाइमआउट होता है, तो दोबारा भेजने से पहले जांचें कि टोकन खर्च हुए या कार्य पूरा हुआ या नहीं।
- क्लाइंट रिक्वेस्ट आईडी का उपयोग करें: लॉग में ट्रैक करने के लिए
X-Request-IDहेडर शामिल करें। - 401/403 को 429 न समझें: प्रमाणीकरण त्रुटियों को ठीक करने के लिए API कुंजी बदलनी होगी, इंतजार नहीं करना होगा।
रिकवरी सत्यापन
पूरा ट्रैफ़िक फिर से शुरू करने से पहले:
- न्यूनतम टोकन (
max_tokens: 5) के साथ एक परीक्षण अनुरोध भेजें। - HTTP 200 प्राप्त होने और
x-ratelimit-remaining-requestsहेडर की पुष्टि करें। - त्रुटि दर की निगरानी करते हुए धीरे-धीरे समानांतर अनुरोध बढ़ाएं।
कठोर मिनट सीमाओं के कारण अचानक होने वाली 429 रुकावटों से बचने और अनुरोधों पर पूर्ण नियंत्रण रखने के लिए, BetterToken API पर स्विच करें, समर्पित API कुंजियां बनाएं और डैशबोर्ड में रीयल-टाइम टोकन उपयोग की निगरानी करें।