वॉइस के लिए 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 एक-साथ ऑडियो ब्रॉडकास्ट संभाल सकती है। सटीक संख्या वॉइस, बोलने की गति और वाक्यों के बीच के मौन पर निर्भर करती है।

आपकी स्थिति बताने वाले हेडर

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

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

• current-concurrent-requests: इस समय कितने अनुरोध चल रहे हैं?
• maximum-concurrent-requests: उस मॉडल फैमिली के लिए आपकी सीमा।

मिलकर, ये हेडर आपके मौजूदा उपयोग और उपलब्ध क्षमता का रियल-टाइम ओवरव्यू देते हैं। 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

टोकन बकेट: बर्स्ट की अनुमति दें, औसत सीमित रखें

टोकन बकेट में क्षमता तक टोकन रहते हैं और यह प्रति सेकंड refillRate टोकन से फिर भरता है। हर अनुरोध एक टोकन खर्च करता है, इसलिए बकेट अपने आकार तक छोटे बर्स्ट की अनुमति देता है और लंबे समय की रेट सीमित रखता है। 

जब काम की क्यू अचानक आ जाए, तो उसे सहज बनाने के लिए यह सही टूल है, ताकि आप सब कुछ एक साथ न चलाएं और कॉन्करेंसी स्पाइक न हो।

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);
  }
}

ट्रैक करने के लिए चार सिग्नल:

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

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

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

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

नीचे दिया हर कदम आपको अतिरिक्त क्षमता देगा।

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

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

फिर सही मॉडल चुनें। तेज़ जनरेशन हर स्लॉट को कम समय के लिए रखती है, जिससे एक निश्चित कॉन्करेंसी सीमा संभाल सकने वाले ब्रॉडकास्ट की संख्या बढ़ती है। Eleven Flash v2.5 रियल-टाइम काम के लिए सबसे कम लेटेंसी वाला विकल्प है; इसे Instant Voice Clone या डिफ़ॉल्ट वॉइस के साथ जोड़ने पर 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