वॉइस के लिए AI रेट लिमिटिंग: कंकरेंसी, क्यूज़ और 429

अधिकतर टीमें वॉइस के लिए AI रेट लिमिटिंग वैसे ही अपनाती हैं जैसे बाकी APIs के लिए: हर मिनट रिक्वेस्ट की सीमा तय करें, सर्वर से रुकावट मिले तो फिर से कोशिश करें, और आगे बढ़ जाएं। ElevenLabs पर वर्कलोड्स के लिए यह तरीका पहले ही ट्रैफिक बर्स्ट में फेल हो जाता है, क्योंकि असली लिमिट रिक्वेस्ट काउंट नहीं, बल्कि कंकरेंसी है।

यह गाइड बताता है कि कंकरेंसी असली रुकावट क्यों है, और फिर क्लाइंट-साइड पैटर्न्स समझाता है जो आपको इसके अंदर रखते हैं। बाउंडेड कंकरेंसी पूल, ग्रेसफुल 429 हैंडलिंग, मल्टी-टेनेंट फेयरनेस, टोकन और लीकी बकेट—हम आपको ऐसे प्रैक्टिकल सिस्टम्स देते हैं जिन्हें आप लागू कर सकते हैं। हर पैटर्न के साथ एक काम करता TypeScript इम्प्लीमेंटेशन भी दिया गया है जिसे आप अपने हिसाब से बदल सकते हैं।

अगर आप वॉइस एजेंट बनाते हैं, नैरेशन पाइपलाइन या हमारे मॉडल्स पर कोई भी प्रोडक्शन सिस्टम बनाते हैं और स्केल करना चाहते हैं, तो यह प्लेबुक आपके लिए है।

संक्षिप्त में

• वॉइस के लिए AI रेट लिमिटिंग का मतलब है कंकरेंसी कंट्रोल, न कि हर मिनट रिक्वेस्ट गिनना।
• रेट लिमिटिंग की सीमा पर पहुंचने पर ट्रैफिक तुरंत रिजेक्ट नहीं होता। रिक्वेस्ट पहले प्रायोरिटी क्यू में जाती है, जिससे लगभग 50ms की देरी जुड़ती है।
• अगर क्यू में डालने के बाद भी क्षमता से ज्यादा ट्रैफिक है, तो HTTP 429 एरर मिलेगा।
• WebSockets से आपकी क्षमता काफी बढ़ जाती है, क्योंकि सिर्फ एक्टिव जेनरेशन ही आपकी लिमिट में गिनी जाती है।
• मल्टी-टेनेंट सिस्टम्स के लिए एक्स्ट्रा फेयरनेस लेयर चाहिए: हर टेनेंट के लिए बकेट, वेटेड फेयर क्यूइंग, रिजर्व्ड हेडरूम, और आइसोलेशन के लिए कीज़ पर शार्डिंग।
• दो रिस्पॉन्स हेडर—current-concurrent-requests और maximum-concurrent-requests—आपको बताते हैं कि आप AI रेट लिमिटिंग में कहां खड़े हैं।

क्यों लिमिट कंकरेंसी है, रिक्वेस्ट्स प्रति मिनट नहीं

कंकरेंसी का मतलब है एक ही समय में कितनी रिक्वेस्ट्स प्रोसेस हो रही हैं। रिक्वेस्ट्स प्रति मिनट एक विंडो में थ्रूपुट है। यह फर्क समझना जरूरी है, क्योंकि इससे तय होता है कि आपको किस चीज़ पर कंट्रोल रखना है।

जब आप ElevenLabs के किसी मॉडल का इस्तेमाल करते हैं, तो सर्वर का वर्कलोड कंकरेंट यूज़र्स की संख्या के साथ बढ़ता है। ऑडियो जेनरेशन के दौरान एक स्लॉट रिजर्व रहता है, और यह समय इनपुट की लंबाई, मॉडल और लोड पर निर्भर करता है।

रिक्वेस्ट-पर-मिनट लिमिट आपको यह नहीं बताती कि इस वक्त कितने स्लॉट्स भरे हुए हैं—जबकि सर्वर सिर्फ यही गिनता है।

हर प्लान, हर मॉडल फैमिली की अलग लिमिट

आपका कंकरेंसी बजट एक ही नंबर नहीं है। हर प्लान और हर मॉडल फैमिली के लिए कंकरेंसी लिमिट अलग होती है। जैसे,स्पीच टू टेक्स्ट की लिमिट टेक्स्ट टू स्पीच से ज्यादा होती है, क्योंकि ट्रांसक्रिप्शन रिक्वेस्ट्स आमतौर पर कम समय लेती हैं और सिस्टम एक साथ ज्यादा हैंडल कर सकता है।

लिमिट हर मॉडल फैमिली के लिए होती है। अगर आप एजेंट्स के लिए Flash और नैरेशन के लिए Multilingual v2 चलाते हैं, तो आप एक साथ दो अलग बजट्स पर काम कर रहे हैं। हर प्लान की मौजूदा लिमिट और कंकरेंसी सेक्शन मॉडल्स पेज पर दी गई है।

जब आप कंकरेंसी लिमिट पर पहुंचते हैं तो क्या होता है?

कंकरेंसी लिमिट पर पहुंचने से ट्रैफिक तुरंत रिजेक्ट नहीं होता। सिस्टम पहले प्रायोरिटी क्यू के जरिए ग्रेसफुली डिग्रेड करता है, और पूरी तरह रिजेक्ट तभी करता है जब आप टोटल कैपेसिटी से भी ऊपर चले जाते हैं।

जब तक आप लिमिट के अंदर हैं, रिक्वेस्ट्स तुरंत चलती हैं। लिमिट पर पहुंचने के बाद, अगली रिक्वेस्ट्स आपके प्लान की प्रायोरिटी के हिसाब से क्यू में जाती हैं। क्यू आमतौर पर लगभग 50ms की लेटेंसी जोड़ती है, तो हल्का ओवररन यूज़र्स को दिखता भी नहीं।

अगर क्यू के बाद भी सिस्टम ओवर कैपेसिटी है, तो आपको HTTP 429 मिलता है। इसका मतलब है कि आपको तुरंत फिर से ट्राई नहीं करना चाहिए, बल्कि धीमा करना चाहिए। टेबल में प्रायोरिटी लेवल तय करता है कि आपकी क्यू की रिक्वेस्ट्स बाकी ट्रैफिक के मुकाबले कब प्रोसेस होंगी; हाईयर प्लान्स की क्यू जल्दी क्लियर होती है।

HTTP बनाम WebSocket: आपकी लिमिट पर कौन कैसे गिना जाता है

आप कौन सा ट्रांसपोर्ट चुनते हैं, इससे रेट लिमिटिंग और बजट सीधे प्रभावित होते हैं। एक ही बातचीत आपकी कंकरेंसी बजट को अलग-अलग तरीके से इस्तेमाल कर सकती है, इस पर निर्भर करता है कि वह HTTP पर है या WebSocket पर।

HTTP पर, हर रिक्वेस्ट पूरी अवधि के लिए आपकी कंकरेंसी लिमिट में गिनी जाती है। WebSocket पर, सिर्फ वही समय गिना जाता है जब मॉडल एक्टिवली ऑडियो जेनरेट कर रहा है। एक ओपन लेकिन आइडल WebSocket ज्यादातर गिना नहीं जाता।

वॉइस एजेंट के लिए, बातचीत में लंबे समय तक कोई नहीं बोलता और मॉडल कुछ जेनरेट नहीं करता। HTTP में हर बार रिक्वेस्ट की अवधि के लिए स्लॉट रिजर्व रहता है। WebSocket में स्लॉट सिर्फ एक्टिव जेनरेशन के मिलीसेकंड्स में ही लगता है, तो एक कंकरेंसी स्लॉट कई बातचीतों में टाइम-शेयर हो जाता है।

प्रोटोकॉल डिटेल्स के लिए देखें रियल-टाइम TTS WebSocket गाइड। इंटरैक्टिव ट्रैफिक के लिए WebSockets सही डिफॉल्ट हैं।

कैसे ~5 कंकरेंसी ~100 ब्रॉडकास्ट्स को सपोर्ट कर सकती है

कंकरेंसी का गणित तब तक उलझा लगता है जब तक आप प्लेबैक टाइम को नहीं समझते। जेनरेशन प्लेबैक से कहीं तेज़ होती है, और स्लॉट सिर्फ तब एक्टिवली भरा होता है जब ऑडियो जेनरेट हो रहा हो। यही गैप छोटे बजट को बड़ी ऑडियंस तक पहुंचने देता है।

एक रिक्वेस्ट जो जेनरेट होने में कुछ मिलीसेकंड लेती है, कई सेकंड का ऑडियो बना देती है, जिसे लिसनर प्ले करता है—और प्लेबैक के दौरान स्लॉट खाली हो जाता है और दूसरों के लिए उपलब्ध हो जाता है।

एक मोटे अनुमान के तौर पर, 5 की कंकरेंसी लिमिट लगभग 100 एक साथ ऑडियो ब्रॉडकास्ट्स को संभाल सकती है। असली संख्या वॉइस, बोलने की गति और वाक्यों के बीच की चुप्पी पर निर्भर करती है।

वो हेडर जो बताते हैं आप कहां खड़े हैं

आपको अपनी लिमिट के मुकाबले अपनी स्थिति अंदाजा लगाने की जरूरत नहीं है। हर रिस्पॉन्स में दो नंबर होते हैं, जिनसे आप हेडरूम नाप सकते हैं।

इन दो हेडर्स पर ध्यान दें:

• मौजूदा-कनकरेंट-रिक्वेस्ट्स: अभी कितनी रिक्वेस्ट्स प्रोसेस हो रही हैं?
• अधिकतम-कनकरेंट-रिक्वेस्ट्स: उस मॉडल फैमिली के लिए आपकी लिमिट।

ये दोनों हेडर मिलकर आपको रियल-टाइम में आपकी मौजूदा यूसेज और उपलब्ध क्षमता का ओवरव्यू देते हैं। आपको अंदाजा लगाने की जरूरत नहीं पड़ेगी कि कब AI रेट लिमिटिंग आड़े आ सकती है।

AI रेट लिमिटिंग के लिए क्लाइंट-साइड स्ट्रैटेजीज़

चार बेसिक तरीके हैं जो लगभग हर AI रेट लिमिटिंग सिचुएशन को कवर करते हैं:

• टोकन बकेट: अगर टोकन उपलब्ध हैं, तो रिक्वेस्ट आगे बढ़ सकती है। कैपेसिटी समय के साथ रीफिल होती है, जिससे शॉर्ट बर्स्ट्स को हैंडल किया जा सकता है।
• लीकी बकेट: इनकमिंग ट्रैफिक को फिक्स्ड आउटपुट रेट में बदलने की कोशिश करता है, जिससे अचानक स्पाइक्स से डाउनस्ट्रीम सिस्टम्स ओवरलोड नहीं होते।
• बाउंडेड कंकरेंसी पूल: एक साथ एक्टिव रिक्वेस्ट्स की कुल संख्या सीमित करता है, जिससे आप कभी भी कंकरेंट रिक्वेस्ट लिमिट पार नहीं करते।
• फुल जिटर के साथ एक्सपोनेंशियल बैकऑफ: फेल रिक्वेस्ट्स के बीच समय को बढ़ाता है, जिससे सभी क्लाइंट्स एक साथ फिर से ट्राई नहीं करते।

नीचे दिए गए सेक्शन दिखाते हैं कि इन्हें एक-एक करके कैसे बनाएं, शुरुआत उसी से जो कंकरेंसी लिमिट से सबसे सीधे जुड़ा है।

सारे कोड स्निपेट्स एक सिंगल क्लाइंट मानकर चलते हैं, जो एक बार इनिशियलाइज़ किया गया है:

import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

const elevenlabs = new ElevenLabsClient({ apiKey: process.env.ELEVENLABS_API_KEY });

बाउंडेड कंकरेंसी: लिमिट से मेल खाने वाला बेसिक तरीका

क्योंकि सर्वर कंकरेंसी को मापता है, सबसे सीधा क्लाइंट कंट्रोल है बाउंडेड वर्कर पूल, जो एक साथ प्रोसेस हो रही रिक्वेस्ट्स की संख्या सीमित करता है। लिमिट से थोड़ा कम सेट करें, ताकि प्रायोरिटी क्यू और जिटर के लिए जगह रहे।

async function pool<T, R>(
  items: T[],
  maxInFlight: number,
  worker: (item: T) => Promise<R>,
): Promise<R[]> {
  const results: R[] = new Array(items.length);
  let next = 0;

  async function run(): Promise<void> {
    while (next < items.length) {
      const i = next++;
      results[i] = await worker(items[i]); // never more than maxInFlight of these run at once
    }
  }

  await Promise.all(
    Array.from({ length: Math.min(maxInFlight, items.length) }, run),
  );
  return results;
}

async function synthesize(text: string): Promise<Buffer> {
  const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
    text,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  const chunks: Buffer[] = [];
  for await (const chunk of stream) chunks.push(Buffer.from(chunk));
  return Buffer.concat(chunks);
}

// Plan Flash limit is, say, 10. Stay under it.
const texts = Array.from({ length: 50 }, (_, i) => `Sentence number ${i}.`);
const audio = await pool(texts, 8, synthesize); // never more than 8 in flight

टोकन बकेट: बर्स्ट्स की इजाजत, एवरेज पर कैप

टोकन बकेट में कैपेसिटी तक टोकन होते हैं और यह हर सेकंड रीफिल रेट से रीफिल होता है। हर रिक्वेस्ट एक टोकन लेती है, तो बकेट अपने साइज तक शॉर्ट बर्स्ट्स की इजाजत देता है, लेकिन लंबे समय में रेट सीमित रखता है।

जब अचानक बहुत सारा काम आ जाए, तब सबकुछ एक साथ फायर करने की बजाय इसे स्मूद करने के लिए यह सही टूल है।

class TokenBucket {
  private tokens: number;
  private updated = performance.now();

  constructor(private capacity: number, private refillPerSec: number) {
    this.tokens = capacity;
  }

  private refill(): void {
    const now = performance.now();
    const elapsed = (now - this.updated) / 1000;
    this.tokens = Math.min(this.capacity, this.tokens + elapsed * this.refillPerSec);
    this.updated = now;
  }

  tryAcquire(cost = 1): boolean {
    this.refill();
    if (this.tokens >= cost) {
      this.tokens -= cost;
      return true;
    }
    return false;
  }

  timeUntil(cost = 1): number {
    this.refill();
    return this.tokens >= cost ? 0 : ((cost - this.tokens) / this.refillPerSec) * 1000;
  }
}

लीकी बकेट: लगातार आउटपुट बनाए रखें

कुछ मामलों में आप बर्स्ट्स बिल्कुल नहीं चाहते। लीकी बकेट हर हाल में फिक्स्ड, लगातार रेट से काम स्वीकार करता है, चाहे इनपुट कितना भी बर्स्टी हो। जब डाउनस्ट्रीम सिस्टम को स्मूद, प्रेडिक्टेबल लोड चाहिए, तब यह बेहतर विकल्प है।

जैसे, जब आप जानबूझकर छोटे कंकरेंसी बजट के अंदर रहना चाहते हैं, जो और सर्विसेज के साथ शेयर हो रहा है।

class LeakyBucket {
  private next = performance.now();
  constructor(private intervalMs: number) {} // admit at most one item per intervalMs

  async acquire(): Promise<void> {
    const now = performance.now();
    const wait = Math.max(0, this.next - now);
    this.next = Math.max(now, this.next) + this.intervalMs;
    if (wait > 0) await new Promise((r) => setTimeout(r, wait));
  }
}

फुल जिटर के साथ एक्सपोनेंशियल बैकऑफ

अगर कोई रिक्वेस्ट रिट्रायबल स्टेटस के साथ फेल होती है, तो तुरंत फिर से ट्राई करना हालात और खराब कर देता है। बैकऑफ रिट्राइज के बीच गैप बढ़ाता है, और फुल जिटर हर डिले को पूरी विंडो में रैंडम करता है, जिससे कई क्लाइंट्स एक साथ ट्राई नहीं करते और वही स्पाइक दोबारा नहीं बनती।

नीचे दिया गया स्निपेट RetryableError नाम की एक छोटी क्लास का रेफरेंस लेता है, जिसमें फेल स्टेटस और कोई भी Retry-After वैल्यू होती है। यह नीचे ग्रेसफुल 429 हैंडलिंग सेक्शन में डिफाइन है।

async function withBackoff<T>(
  call: () => Promise<T>,
  opts: { maxAttempts?: number; baseMs?: number; capMs?: number } = {},
): Promise<T> {
  const { maxAttempts = 5, baseMs = 500, capMs = 20_000 } = opts;
  let attempt = 0;
  for (;;) {
    try {
      return await call();
    } catch (e) {
      if (!(e instanceof RetryableError) || ++attempt >= maxAttempts) throw e;
      // honor Retry-After if present; otherwise capped exponential growth with full jitter
      const delay =
        e.retryAfterMs ?? Math.random() * Math.min(capMs, baseMs * 2 ** attempt);
      await new Promise((r) => setTimeout(r, delay));
    }
  }
}

ग्रेसफुल 429 हैंडलिंग: जब आप लिमिट पर पहुंचें तो क्या करें

429 का मतलब है कि आप प्रायोरिटी क्यू के बाद भी ओवर कैपेसिटी थे, तो सही जवाब है धीमा करना, न कि और जोर से ट्राई करना। इसे संभालने के चार तरीके हैं:

• डिटेक्शन
• Retry-After का सम्मान करना
• बैकप्रेशर दिखाना
• सर्किट ब्रेकर से रिट्राय स्टॉर्म रोकना

आइए इन्हें थोड़ा विस्तार से समझते हैं।

पहला है डिटेक्शन। HTTP 429 (और ट्रांजिएंट 500, 502, 503, 504) को रिट्रायबल मानें, और 400, 401, 403, 422 को नॉन-रिट्रायबल; गलत या अनऑथराइज्ड रिक्वेस्ट को बार-बार ट्राई करने से कुछ नहीं होगा, बस स्लॉट बर्बाद होगा।

दूसरा है Retry-After का सम्मान करना। अगर रिस्पॉन्स में यह हेडर है, तो उसी को फॉलो करें, अपनी डिले खुद न निकालें। सर्वर आपको बता रहा है कि कब कैपेसिटी मिलेगी, और वह आपकी एक्सपोनेंशियल फॉर्मूला से बेहतर जानता है। जब हेडर न हो, तभी जिटर बैकऑफ लगाएं।

class RetryableError extends Error {
  constructor(public status: number, public retryAfterMs?: number) {
    super(`retryable ${status}`);
  }
}

function classify(resp: Response): void {
  if ([429, 500, 502, 503, 504].includes(resp.status)) {
    const ra = resp.headers.get("retry-after");
    throw new RetryableError(resp.status, ra ? Number(ra) * 1000 : undefined);
  }
  if (!resp.ok) throw new Error(`non-retryable ${resp.status}`);
}

तीसरा है बैकप्रेशर दिखाना। रिट्राइज को छुपा कर न रखें। अगर आपकी क्यू की गहराई या हेडरूम बताता है कि आप नई रिक्वेस्ट जल्दी नहीं सर्व कर सकते, तो उसे एज पर ही साफ मना कर दें, न कि ऐसा काम स्वीकारें जो आप कर नहीं सकते।

चौथा है सर्किट ब्रेकर से रिट्राय स्टॉर्म रोकना। अगर फेल्योर एक सीमा पार कर जाए, तो सर्किट खोल दें और कूल-डाउन विंडो तक फास्ट फेल करें, बजाय इसके कि आप फेल होने वाली रिक्वेस्ट्स भेजते रहें। विंडो के बाद कुछ प्रॉब रिक्वेस्ट भेजें; अगर वे सफल हों, तो सर्किट बंद कर दें।

class CircuitBreaker {
  private failures = 0;
  private openedAt: number | null = null;
  constructor(private threshold = 5, private cooldownMs = 10_000) {}

  allow(): boolean {
    if (this.openedAt === null) return true;
    if (performance.now() - this.openedAt >= this.cooldownMs) {
      this.openedAt = null; // half-open: allow a probe
      this.failures = 0;
      return true;
    }
    return false;
  }

  record(ok: boolean): void {
    if (ok) {
      this.failures = 0;
      this.openedAt = null;
    } else if (++this.failures >= this.threshold) {
      this.openedAt = performance.now();
    }
  }
}

AI रेट लिमिटिंग के लिए मल्टी-टेनेंट कोटा पैटर्न्स

अब तक सब कुछ एक सिंगल एप्लिकेशन और एक बजट के लिए था। जब आप ElevenLabs पर SaaS बनाते हैं, तो समस्या बदल जाती है: आपका कंकरेंसी बजट आपके सभी कस्टमर्स में शेयर होता है, और एक टेनेंट का बैच जॉब बाकी सबके लाइव ट्रैफिक को रोक नहीं सकता। आपको अपने टेनेंट्स और अपस्ट्रीम लिमिट के बीच फेयरनेस लेयर चाहिए।

बेस है हर टेनेंट के लिए टोकन बकेट। हर टेनेंट को उसकी एंटाइटलमेंट के हिसाब से बकेट दें, और रिक्वेस्ट तभी स्वीकारें जब टेनेंट बकेट और ग्लोबल लिमिटर दोनों इजाजत दें।

class MultiTenantAdmission {
  private tenantBuckets = new Map<string, TokenBucket>();
  constructor(private globalMaxInFlight: number) {}

  private bucket(tenant: string): TokenBucket {
    let b = this.tenantBuckets.get(tenant);
    if (!b) {
      // Each tenant: burst of 5, sustained 2 starts/sec. Tune per tier.
      b = new TokenBucket(5, 2);
      this.tenantBuckets.set(tenant, b);
    }
    return b;
  }

  async run<R>(tenant: string, work: () => Promise<R>): Promise<R> {
    const b = this.bucket(tenant);
    if (!b.tryAcquire()) {
      throw new RetryableError(429, b.timeUntil());
    }
    // ... then admit through the global limiter (e.g. the bounded pool above)
    return work();
  }
}

बकेट्स किसी एक टेनेंट को ईमानदार रखते हैं, लेकिन जब टेनेंट्स ग्लोबल लिमिटर के लिए कंपटीशन करते हैं, तो कौन जीतेगा यह तय नहीं करते। इसके लिए वेटेड फेयर क्यूइंग इस्तेमाल करें।

फर्स्ट-कम-फर्स्ट-सर्व न करें, वरना एक टेनेंट का बर्स्ट सारे स्लॉट्स ले सकता है। हर टेनेंट के लिए क्यू रखें और हर टेनेंट के वेट के हिसाब से डिस्पैच करें, ताकि पेड टेनेंट को फ्री वाले से ज्यादा कैपेसिटी मिले।

फेयरनेस के ऊपर, हेडरूम रिजर्व रखें। कभी भी नॉर्मल ट्रैफिक को 100% कंकरेंसी लिमिट इस्तेमाल न करने दें। कुछ हिस्सा, जैसे 15-20%, लेटेंसी-सेंसिटिव इंटरैक्टिव रिक्वेस्ट्स और प्रायोरिटी क्यू के लिए बचाकर रखें।

जब एक ही बजट में फेयरनेस काफी न हो, तो वर्कस्पेसेज़ या कीज़ में शार्ड करें। एक ही कंकरेंसी बजट आखिरकार बॉटलनेक बन जाता है, चाहे आप उसे कितना भी फेयरली बांटें।

तब, अलग-अलग वर्कलोड्स को अलग वर्कस्पेसेज़ या API कीज़ पर रखें, जिनके अपने बजट हों: जैसे, एक की रियल-टाइम एजेंट ट्रैफिक के लिए और दूसरी बैकग्राउंड नैरेशन के लिए, ताकि नैरेशन बैकलॉग एजेंट कैपेसिटी को न छुए।

वर्कस्पेसेज़ से आप स्कोप रिस्ट्रिक्शन, क्रेडिट कोटा और प्रति-की कंट्रोल्स भी लगा सकते हैं, जैसा कि ऑथेंटिकेशन डॉक्युमेंटेशन में बताया गया है।

अपनी कंकरेंसी यूसेज की मॉनिटरिंग करें

यह सब बिना मापे ट्यून नहीं किया जा सकता; आप वह हेडरूम मैनेज नहीं कर सकते जिसे आप मापते नहीं। हर रिस्पॉन्स पर current-concurrent-requests और maximum-concurrent-requests रिकॉर्ड करें, मॉडल फैमिली के हिसाब से टैग करें, और यूसेज रेशियो को गेज के रूप में भेजें।

function recordHeadroom(resp: Response, metrics: Metrics): void {
  const cur = Number(resp.headers.get("current-concurrent-requests"));
  const max = Number(resp.headers.get("maximum-concurrent-requests"));
  if (Number.isFinite(cur) && Number.isFinite(max)) {
    metrics.gauge("el.concurrency.current", cur);
    metrics.gauge("el.concurrency.max", max);
    if (max > 0) metrics.gauge("el.concurrency.utilization", cur / max);
  }
}

चार सिग्नल्स जिन्हें ट्रैक करें:

• यूसेज (current / maximum)।
• 429 रेट, कुल रिक्वेस्ट्स के अनुपात में।
• रिट्राय डेप्थ, हर लॉजिकल रिक्वेस्ट पर कितनी बार कोशिश हुई।
• टाइम-टू-फर्स्ट-ऑडियो, आपकी एप्लिकेशन से मापा गया—not मॉडल इन्फरेंस से। TTFA में क्या-क्या शामिल है, यह लेटेंसी समझने वाले सेक्शन में देखें।

एक हेल्दी सिस्टम यूसेज को सैचुरेशन से काफी नीचे रखेगा और 429 सिर्फ कभी-कभी बर्स्ट में दिखेंगे। इन सिग्नल्स की मॉनिटरिंग से आपको रेट-लिमिटिंग प्रेशर का अंदाजा पहले ही मिल जाता है, इससे पहले कि वह आउटेज बने।

कब क्लाइंट-साइड रेट लिमिटिंग से आगे स्केल करें

क्लाइंट-साइड पैटर्न्स बहुत कुछ संभाल सकते हैं, लेकिन लगातार डिमांड आखिरकार इन्हें पार कर जाएगी। तब बदलाव करने का समय है, जिससे लागत और मेहनत दोनों में मदद मिले।

नीचे दिए गए हर स्टेप से आपको एक्स्ट्रा कैपेसिटी मिलेगी।

शुरुआत करें—इंटरैक्टिव ट्रैफिक के लिए HTTP से WebSockets पर स्विच करें। अगर आपके एजेंट्स या लाइव यूज़ केस HTTP पर चलते हैं, तो WebSocket पर जाने से सिर्फ एक्टिव जेनरेशन ही गिनी जाती है। कन्वर्सेशनल वर्कलोड्स में इससे अक्सर आपकी कैपेसिटी कई गुना बढ़ जाती है, क्योंकि आइडल टाइम स्लॉट्स नहीं खाता।

अगर आपके बर्स्ट्स बहुत तेज़ हैं लेकिन एवरेज लोड बजट में है, तो टोकन या लीकी बकेट के साथ बाउंडेड पूल पीक्स को एवरेज में बदल देता है।

फिर सही मॉडल चुनें। तेज़ जेनरेशन हर स्लॉट को कम समय के लिए रोकती है, जिससे फिक्स्ड कंकरेंसी लिमिट ज्यादा ब्रॉडकास्ट्स चला सकती है। Eleven Flash v2.5 है सबसे कम लेटेंसी वाला विकल्प रियल-टाइम काम के लिए; इसे इंस्टेंट वॉइस क्लोन या डिफॉल्ट वॉइस के साथ जोड़ें, ताकि Professional Voice Clones की हर जेनरेशन की ओवरहेड न लगे।

इसके बाद ही प्लान अपग्रेड करें। जब आपकी लगातार डिमांड बजट से सच में ज्यादा हो जाए, और क्लाइंट सही से काम कर रहा हो, तो हाईयर प्लान से हर मॉडल की कंकरेंसी लिमिट और आपकी क्यू प्रायोरिटी दोनों बढ़ती हैं। API प्राइसिंग पेज पर टियर्स की तुलना करें।

अगर आपको पब्लिश्ड लिमिट्स से ज्यादा चाहिए, तो Enterprise प्लान्स में कस्टम और ज्यादा कंकरेंसी लिमिट्स और सबसे हाई क्यू प्रायोरिटी मिलती है। कुछ यूज़ केस के लिए एक्स्ट्रा कंट्रोल्स भी मिलते हैं, जैसे IP व्हाइटलिस्टिंग (Enterprise प्रीव्यू में) और जीरो-रिटेंशन मोड्स। लिमिट बढ़वाने के लिए अपने अकाउंट मैनेजर से संपर्क करें।

AI रेट लिमिटिंग के लिए क्या ध्यान रखें—सारांश

सबसे बड़ी गलती है वॉइस AI रेट लिमिटिंग को रिक्वेस्ट काउंटिंग समझना। यहां सब कुछ कंकरेंसी कंट्रोल के बारे में है। आपकी सफलता इस पर निर्भर है कि एक ही समय में कितनी रिक्वेस्ट्स ऑडियो जेनरेट कर रही हैं और हर एक कितनी देर स्लॉट पकड़े रहती है।

क्लाइंट को इसी आधार पर बनाएं।

इन-फ्लाइट रिक्वेस्ट्स को बाउंडेड पूल से कैप करें, टोकन या लीकी बकेट से एडमिशन को शेप करें, कैप्ड एक्सपोनेंशियल बैकऑफ और फुल जिटर के साथ रिट्राय करें, Retry-After का सम्मान करें, और रिट्राय स्टॉर्म बनने से पहले सर्किट ब्रेक करें।

मल्टी-टेनेंट सिस्टम्स के लिए, हर टेनेंट के लिए बकेट, वेटेड फेयरनेस, रिजर्व्ड हेडरूम और आइसोलेशन के लिए शार्डिंग लगाएं। current-concurrent-requests और maximum-concurrent-requests हेडर देखें और यूसेज ट्रेंड पर अलर्ट लगाएं, फेल्योर पर नहीं।

जब आपको सच में ज्यादा कैपेसिटी चाहिए, तो लिस्ट को क्रम से अपनाएं: पहले WebSockets और बेहतर क्लाइंट बिहेवियर, फिर सही मॉडल, फिर प्लान अपग्रेड, और फिर Enterprise लिमिट्स।

ElevenAPI के साथ वॉइस ऐप्लिकेशन बनाएं

प्रोडक्शन-ग्रेड AI रेट लिमिटिंग सही ट्रांसपोर्ट, सही मॉडल और ऐसे हेडर से शुरू होती है जो आपको आपकी स्थिति साफ बताते हैं।

ElevenAPI में लो-लेटेंसी मॉडल्स जैसे Eleven Flash v2.5, रियल-टाइम WebSocket स्ट्रीमिंग, स्पीच टू टेक्स्ट और टेक्स्ट टू स्पीच APIs मिलते हैं, और हर रिस्पॉन्स में कंकरेंसी हेडर मिलते हैं, जिससे आप अपनी लिमिट्स के अंदर स्केलेबल वॉइस एजेंट्स बना सकते हैं।

इस आर्टिकल में बताए गए AI रेट-लिमिटिंग स्ट्रैटेजीज़ के साथ, आप लोड के बावजूद प्रेडिक्टेबल परफॉर्मेंस के साथ रिस्पॉन्सिव वॉइस एक्सपीरियंस दे सकते हैं।

देखें ElevenAPI में सभी मॉडल्स को एक्शन में, या अकाउंट बनाएं और आज ही ElevenLabs के साथ बनाना शुरू करें।

AI रेट लिमिटिंग FAQ