SaaS LLM rate limits: उचित quota और concurrency नियंत्रण
प्रति-टेनेंट request व token budget, सीमित queue, concurrency सीमा, server retry संकेत और स्पष्ट उपयोगकर्ता संदेश से burst और noisy neighbor रोकें।
इस मार्गदर्शिका में
SaaS ऐप LLM अनुरोधों पर rate limit कैसे लगाए?
Provider क्षमता बचाने और हर ग्राहक को भरोसेमंद सेवा देने के लिए एप्लिकेशन स्तर पर सीमा रखें। केवल request संख्या न गिनें: provider प्रति मिनट request, token, दिन, मॉडल, image या audio सीमा लगा सकता है; आपके उत्पाद को user, tenant और organization budget भी चाहिए। Provider account quota आपके ग्राहकों के बीच उचित बाँट का विकल्प नहीं है।
Request, token और खर्च के लिए अलग नियंत्रण रखें
Request प्रति सीमा, अनुमानित input token, आरक्षित output token, दैनिक usage और महँगी सुविधा के budget चुनें। ज़रूरत के अनुसार उपयोगकर्ता, टेनेंट और संगठन स्तर पर लागू करें तथा भुगतान वाले स्तर और साझा quota की नीति लिखें। केवल महीने के अंत की चेतावनी पर निर्भर न रहें; असामान्य उपयोग के लिए कठोर सीमा या मानव समीक्षा रखें।
Provider call से पहले क्षमता आरक्षित करें
Input आकार का अनुमान लगाएँ, संभावित output budget आरक्षित करें और request भेजने से पहले concurrency slot लें। काम पूरा या विफल होने पर वास्तविक usage के साथ reservation का हिसाब मिलाएँ। कई app instance provider quota साझा करते हों तो distributed limiter या queue चाहिए; process का अपना counter पूरी सेवा की सीमा लागू नहीं कर सकता।
Fair queue और सीमित admission लागू करें
Tenant-aware queue या weighted fair scheduling से एक ग्राहक को सभी worker लेने से रोकें। Queue की अधिकतम उम्र, लंबाई, सक्रिय request और प्रति-tenant concurrency तय करें। अतिरिक्त काम provider तक पहुँचने से पहले अस्वीकार या बाद के लिए रखें और उपयोगकर्ता को बताएँ कि retry अपने आप होगा या फिर भेजना होगा।
| Tenant स्तर | RPM/TPM और दैनिक सीमा | Concurrency | Queue समय-सीमा | सीमा पार होने पर व्यवहार |
|---|---|---|---|---|
Provider 429 और retry storm कैसे सँभालें?
Retry संकेत मानें और सीमित jitter जोड़ें
Temporary rate-limit उत्तर में Retry-After मिले तो कम-से-कम उतनी प्रतीक्षा करें और अगली कोशिश से पहले random jitter जोड़ें। अधिकतम प्रयास और कुल समय सीमा रखें। असफल प्रयास भी provider सीमा में गिने जा सकते हैं, इसलिए तुरंत बार-बार request भेजना दबाव और बढ़ा सकता है।
हर failure को rate limit समझकर retry न करें
Temporary throttling को quota खत्म होने, billing रोक, गलत input, authentication error और provider outage से अलग पहचानें। Quota error में संचालन या plan बदलना होगा, retry बढ़ाना नहीं। Shared retry budget रखें ताकि SDK और application के nested retry मिलकर traffic कई गुना न कर दें।
Backpressure और सुरक्षित fallback अपनाएँ
Tenant या provider सीमा पूरी हो तो नए request रोकें, स्वीकृत गैर-AI विकल्प दें, गैर-ज़रूरी काम घटाएँ या स्पष्ट retry समय बताएँ। महत्वपूर्ण काम चुपचाप न गिराएँ और गति बढ़ाने के लिए safety check न हटाएँ। Background काम को तत्काल ग्राहक अनुरोध से अलग रखें।
टीम को क्या मापना और उपयोगकर्ता को क्या बताना चाहिए?
Provider और टेनेंट—दोनों स्तरों की सीमा मापें
Request, input/output token, 429, queue उम्र, सक्रिय concurrency, retry प्रयास, अस्वीकार अनुरोध और provider उपयोग देखें। मॉडल, सुविधा, टेनेंट स्तर और क्षेत्र के अनुसार मापें, पर raw prompt log न करें। Quota खत्म होने के बाद नहीं, पहले चेतावनी दें।
दूसरे टेनेंट का उपयोग उजागर किए बिना सीमा समझाएँ
उपयोगकर्ता को बताएँ कि उत्पाद की कौन-सी सीमा पूरी हुई, request queue में है या अस्वीकार हुई, और पता हो तो कब फिर कोशिश कर सकता है। दूसरे ग्राहक का usage या internal provider key न बताएँ। Support staff को इतना ही गोपनीयता-सीमित दृश्य दें जो उनके अपने tenant usage और provider-wide घटना में फर्क करे।
मॉडल या सुविधा बदले तो quota फिर तय करें
नया मॉडल, लंबा context, बड़ा output, image input, tool loop या retry नीति token खर्च और concurrency बदल सकती है। पूरे रास्ते का load test करें, reservation और उचित उपयोग सीमा बदलें, और विस्तार से पहले अलग-अलग tenant traffic में क्षमता तुलना करें।
SaaS LLM rate limiting: सामान्य प्रश्न
क्या provider rate limit मेरे SaaS उत्पाद को सुरक्षित करने के लिए पर्याप्त है?
नहीं। वह provider सेवा और आपके account क्षमता की रक्षा करती है। ग्राहक स्तर पर quota, concurrency, खर्च सीमा और निष्पक्ष scheduling ऐप को लागू करनी होगी।
क्या हर 429 उत्तर retry करना चाहिए?
नहीं। केवल अस्थायी throttling को सीमित budget में retry करें, Retry-After मिले तो मानें और jitter जोड़ें। Quota, billing, authentication या गलत request को अस्थायी मानकर न दोहराएँ।
Request limit लगाऊँ या token limit?
अक्सर दोनों। Request सीमा संख्या नियंत्रित करती है; token budget बदलते prompt और output आकार को पकड़ता है। खर्च के लिए दैनिक या रुपये की सीमा और चल रहे काम के लिए concurrency cap भी रखें।
एक टेनेंट को पूरी model capacity लेने से कैसे रोकें?
Shared tenant-aware admission controller, प्रति-टेनेंट concurrency व token budget, सीमित queue और weighted fair scheduling लगाएँ। असमान traffic के साथ load test करें और महत्वपूर्ण interactive काम के लिए क्षमता अलग रखें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
मसौदा 27 सितंबर 2026 को तैयार; इंजीनियरिंग, सुरक्षा और संपादकीय समीक्षा लंबित · स्रोत जाँचे गए .
- Rate limits
- Error codes
- Google SRE: Handling Overload
- Google SRE: Addressing Cascading Failures
- LLM10:2025 Unbounded Consumption
- Production best practices
- Generative AI semantic conventions
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)
- OpenAI API deprecations