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

ज़्यादातर टीमें वॉइस के लिए AI rate limiting को दूसरे API की तरह ही संभालती हैं: प्रति मिनट अनुरोध सीमित करें, सर्वर के मना करने पर फिर से कोशिश करें, और आगे बढ़ जाएं। ElevenLabs पर वर्कलोड के लिए यह तरीका ट्रैफ़िक के पहले उछाल में ही काम करना बंद कर देता है, क्योंकि जिस सीमा तक आप वास्तव में पहुंचते हैं वह अनुरोधों की संख्या नहीं, concurrency है।

यह गाइड बताती है कि concurrency ही असली सीमा क्यों है, और फिर ऐसे client-side पैटर्न समझाती है जो आपको इसके भीतर रखते हैं। bounded concurrency pools और 429 को सहजता से संभालने से लेकर multi-tenant fairness तथा token और leaky buckets तक, हम ऐसे व्यावहारिक सिस्टम देते हैं जिन्हें आप लागू कर सकते हैं। हर पैटर्न के साथ एक काम करने वाला TypeScript implementation भी दिया गया है, जिसे आप अपनी ज़रूरत के मुताबिक ढाल सकते हैं।

अगर आप वॉइस एजेंट बनाते हैं, narration pipelines या हमारे मॉडल्स पर कोई अन्य production system चलाते हैं और उसे scale करना चाहते हैं, तो यह playbook आपके लिए है।

सारांश

• वॉइस के लिए AI rate limiting, प्रति मिनट अनुरोध गिनना नहीं बल्कि concurrency control है।
• Rate limit की ऊपरी सीमा पर पहुंचते ही ट्रैफ़िक तुरंत अस्वीकार नहीं होता। इसके बजाय, अनुरोध एक priority queue में जाते हैं, जिससे करीब 50ms जुड़ जाता है।
• Queue में जाने के बाद भी क्षमता से अधिक होने पर HTTP 429 error मिलेगा।
• WebSockets प्रभावी क्षमता को काफी बढ़ा देते हैं, क्योंकि केवल active generation ही आपकी सीमा में गिनी जाती है।
• Multi-tenant systems को fairness की एक अतिरिक्त layer चाहिए: per-tenant buckets, weighted fair queueing, reserved headroom और isolation के लिए keys के बीच sharding।
• दो response headers, current-concurrent-requests और maximum-concurrent-requests, आपको बताते हैं कि AI rate limiting के संदर्भ में आप कहां खड़े हैं।

सीमा concurrency क्यों है, प्रति मिनट अनुरोध क्यों नहीं

Concurrency एक ही समय पर in flight मौजूद अनुरोधों की संख्या है। Requests per minute किसी समयावधि में throughput है। इस अंतर को समझना ज़रूरी है, क्योंकि इससे तय होता है कि कौन-सा उपाय आपको अपनी सीमा के भीतर रखेगा।

जब आप ElevenLabs के किसी मॉडल का उपयोग करते हैं, तो सर्वर का वर्कलोड concurrent users की संख्या के साथ बढ़ता है। ऑडियो generation, generation की पूरी अवधि तक एक slot रोककर रखती है, और यह अवधि input की लंबाई, मॉडल और load के हिसाब से बदलती है।

प्रति मिनट अनुरोध की सीमा यह नहीं बताती कि इस समय कितने slots भरे हुए हैं, जबकि सर्वर केवल इसी चीज़ को मापता है।

हर plan और model family की सीमाएं

आपका concurrency budget कोई एक संख्या नहीं है। Concurrency limits हर plan और model family के अनुसार अलग होती हैं। उदाहरण के लिए, स्पीच टू टेक्स्ट की सीमा टेक्स्ट टू स्पीच की तुलना में अधिक है, क्योंकि transcription requests आमतौर पर कम समय तक चलती हैं और सिस्टम एक साथ इनकी अधिक संख्या संभाल सकता है।

सीमा हर model family के लिए अलग है। अगर आप agents के लिए Flash और narration के लिए Multilingual v2 चलाते हैं, तो आप एक साथ दो अलग budgets का उपयोग कर रहे हैं। हर plan के मौजूदा आंकड़े और concurrency section मॉडल्स पेज पर दिए गए हैं।

Concurrency limit पर पहुंचने पर क्या होता है?

Concurrency limit पर पहुंचने से ट्रैफ़िक तुरंत अस्वीकार नहीं होता। सिस्टम priority queue के ज़रिए सहजता से काम जारी रखता है और केवल तब पूरी तरह अस्वीकार करता है, जब आप rate limit की कुल क्षमता से अब भी अधिक हों।

जब तक आप अपनी सीमा के भीतर हैं, अनुरोध तुरंत चलते हैं। सीमा पर पहुंचने के बाद, आगे के अनुरोध आपके plan के priority level के अनुसार क्रमबद्ध queue में जाते हैं। इस queue से आमतौर पर करीब 50ms की latency जुड़ती है, इसलिए थोड़े समय का overrun यूज़र्स को अधिकतर दिखाई नहीं देता।

अगर queue में जाने के बाद भी सिस्टम क्षमता से अधिक है, तो आपको HTTP 429 मिलता है। यह तुरंत retry करने के बजाय धीमा होने का संकेत है। तालिका में priority level तय करता है कि दूसरे ट्रैफ़िक की तुलना में आपके queued requests का क्रम क्या होगा; ऊंचे plans की queue जल्दी clear होती है।

HTTP बनाम WebSocket: दोनों आपकी सीमा में कैसे गिने जाते हैं

आपका चुना हुआ transport सीधे rate limiting और budget को प्रभावित करता है। एक ही incoming conversation, HTTP या WebSocket पर चलने के आधार पर, आपके concurrency budget की काफी अलग मात्रा इस्तेमाल कर सकती है।

HTTP पर हर अनुरोध अपनी पूरी अवधि के लिए अलग से आपकी concurrency limit में गिना जाता है। WebSocket पर केवल वह समय गिना जाता है जब मॉडल सक्रिय रूप से ऑडियो बना रहा हो। खुला लेकिन idle WebSocket आमतौर पर नहीं गिना जाता।

वॉइस एजेंट में बातचीत के लंबे हिस्से ऐसे होते हैं जहां कोई बोल नहीं रहा होता और मॉडल कुछ generate नहीं कर रहा होता। HTTP के साथ आप हर turn में अनुरोध की पूरी अवधि तक एक slot रोककर रखेंगे। WebSocket के साथ slot केवल active generation के milliseconds में इस्तेमाल होता है, इसलिए एक concurrency slot कई conversations के बीच time-share हो सकता है।

Protocol की जानकारी के लिए real-time TTS WebSocket गाइड देखें। Interactive traffic के लिए WebSockets सही default हैं।

करीब 5 concurrency करीब 100 broadcasts को क्यों support कर सकती है

जब तक playback time को ध्यान में नहीं रखते, concurrency का गणित सहज नहीं लगता। Generation, playback से बहुत तेज़ है और audio generate होने पर ही slot सक्रिय रूप से भरा रहता है। यही अंतर छोटे budget को बड़े audience तक पहुंचने देता है।

सेकंड के एक हिस्से में generate होने वाला अनुरोध कई सेकंड का ऑडियो बनाता है, जिसे listener बाद में चलाता है। Playback के दौरान slot मुक्त हो जाता है और दूसरे listeners के लिए उपलब्ध रहता है।

सामान्य अनुमान के तौर पर, 5 की concurrency limit लगभग 100 simultaneous audio broadcasts support कर सकती है। सटीक संख्या वॉइस, बोलने की गति और utterances के बीच के मौन पर निर्भर करती है।

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

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

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

• वर्तमान समवर्ती अनुरोध: इस समय कितने अनुरोध in flight हैं?
• अधिकतम समवर्ती अनुरोध: उस model family के लिए आपकी सीमा।

साथ मिलकर, ये headers आपके मौजूदा उपयोग और उपलब्ध क्षमता का रियल-टाइम overview देते हैं। AI rate limits तक पहुंचने से पहले आपको अनुमान लगाने की ज़रूरत नहीं होनी चाहिए।

AI rate limiting के लिए client-side रणनीतियां

लगभग हर AI rate limiting scenario के लिए चार मूल तरीके हैं:

• Token bucket: Tokens उपलब्ध होने पर अनुरोध आगे बढ़ने देता है। समय के साथ capacity फिर भरती है, जिससे rate limits तक पहुंचे बिना छोटे bursts संभाले जा सकते हैं।
• Leaky bucket: Incoming traffic को एक तय output rate पर smooth करने की कोशिश करता है, ताकि अचानक spikes आपके downstream systems पर बोझ न डालें।
• Bounded concurrency pool: एक साथ सक्रिय रहने वाले अनुरोधों की कुल संख्या सीमित करता है, ताकि आप concurrent request limits कभी पार न करें।
• Full jitter के साथ exponential backoff: Failed requests के बीच का समय बढ़ाता जाता है, ताकि सभी clients एक साथ retry न करें।

नीचे के sections इनमें से हर एक को क्रम से बनाना दिखाते हैं, शुरुआत उस तरीके से होती है जो concurrency limit से सबसे सीधे मेल खाता है।

नीचे दिए सभी snippets एक ही बार initialize किए गए single client को मानकर चलते हैं:

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

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

Bounded concurrency: सीमा से मेल खाने वाला तरीका

क्योंकि सर्वर concurrency को मापता है, इसलिए सबसे सीधा client control एक bounded worker pool है, जो एक समय में in flight अनुरोधों की संख्या सीमित करता है। Priority queue और jitter के लिए जगह छोड़ने को cap अपने plan की सीमा से थोड़ा नीचे रखें।

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

Token bucket: bursts की अनुमति दें, average सीमित रखें

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

काम की queue अचानक आने पर उसे smooth करने के लिए यह सही tool है, ताकि आप सब कुछ एक साथ fire न करें और concurrency spike न हो।

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

Leaky bucket: लगातार drain लागू करें

कुछ मामलों में आप bursts बिल्कुल सहन नहीं करना चाहते। Leaky bucket, input कितना भी bursty हो, काम को एक स्थिर, निश्चित rate पर स्वीकार करता है। जब downstream system को कभी-कभार spikes के बजाय smooth और predictable load चाहिए, तब यह बेहतर विकल्प है।

उदाहरण के लिए, जब आप अन्य services के साथ साझा किए गए छोटे concurrency budget के भीतर जानबूझकर काफी जगह छोड़कर चल रहे हों।

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

Full jitter के साथ exponential backoff

जब कोई अनुरोध retryable status के साथ fail हो, तो तुरंत retry करने से स्थिति और खराब होती है। Backoff retries को अलग-अलग अंतराल पर करता है और full jitter पूरे interval में हर delay को random बनाता है। इससे कई clients एक साथ retry नहीं करते और failure वाला वही spike फिर नहीं बनता।

नीचे का snippet RetryableError का उपयोग करता है, जो failed status और किसी भी Retry-After value को रखने वाली छोटी class है। इसे नीचे graceful 429 handling section में define किया गया है।

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 का मतलब है कि priority queue के बाद भी आप क्षमता से अधिक थे, इसलिए सही प्रतिक्रिया अधिक ज़ोर से retry करना नहीं, बल्कि धीमा होना है। इसे संभालने के चार तरीके हैं। इसे अच्छे से संभालने के लिए चार रणनीतियां अपनाएं:

• पहचान
• Retry-After का पालन
• Backpressure को स्पष्ट करना
• Circuit breaker से retry storms से बचना

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

पहला है पहचान। HTTP 429 (और अस्थायी 500, 502, 503 तथा 504) को retryable मानें, जबकि 400, 401, 403 और 422 को non-retryable मानें; malformed या unauthorized request को retry करना कभी सफल नहीं होता और केवल एक slot बर्बाद करता है।

दूसरा है Retry-After का पालन। Response में वह header हो तो अपना delay निकालने के बजाय उसका ठीक-ठीक पालन करें। सर्वर बता रहा है कि उसे कब capacity उपलब्ध होने की उम्मीद है, और वह आपकी exponential formula से बेहतर जानता है। Header न होने पर ही jittered backoff पर जाएं।

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

तीसरा पहलू है backpressure को स्पष्ट करना। Retries को चुपचाप जमा न होने दें। अगर आपकी queue depth या मापा गया headroom बताता है कि आप जल्दी नया अनुरोध serve नहीं कर सकते, तो वह काम स्वीकार करने के बजाय caller को स्पष्ट संकेत के साथ edge पर ही अस्वीकार करें।

चौथा है circuit breaker से retry storms से बचना। Failures किसी threshold से ऊपर जाएं, तो उन अनुरोधों को भेजने के बजाय जिनके fail होने की उम्मीद है, circuit खोलें और cool-down window में तुरंत fail करें। Window के बाद कुछ probe requests भेजें; वे सफल हों तो circuit बंद कर दें।

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 rate limiting के लिए multi-tenant quota patterns

अब तक सब कुछ single budget के विरुद्ध एक ही application को मानकर चल रहा था। ElevenLabs पर SaaS बनाते समय समस्या बदल जाती है: आपका concurrency budget आपके सभी ग्राहकों के बीच साझा होता है और batch job चलाने वाला कोई एक tenant दूसरे सभी tenants के live traffic को रोक नहीं सकता। आपके tenants और single upstream limit के बीच fairness की एक layer चाहिए।

इसकी नींव per-tenant token buckets हैं। हर tenant को उसकी entitlement के अनुसार आकार वाला अपना bucket दें और अनुरोध तभी स्वीकार करें जब tenant bucket और global limiter, दोनों इसकी अनुमति दें।

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

Buckets किसी एक tenant को सीमा में रखते हैं, लेकिन global limiter के लिए प्रतिस्पर्धा करने पर कौन जीतेगा, यह तय नहीं करते। उसके लिए weighted fair queuing का उपयोग करें।

First-come-first-served तरीके से serve न करें, क्योंकि इससे एक tenant का burst slots पर एकाधिकार कर सकता है। Per-tenant queue रखें और हर tenant के weight के अनुपात में dispatch करें, ताकि paid tenant को free tenant की तुलना में contested capacity का बड़ा हिस्सा मिले।

Fairness के साथ headroom भी reserve करें। सामान्य traffic को concurrency limit का 100% कभी उपयोग न करने दें। Latency-sensitive interactive requests और priority queue के लिए, मान लीजिए 15-20%, एक buffer के रूप में बचाकर रखें।

जब एक budget के भीतर fairness पर्याप्त न रहे, तो workspaces या keys के बीच shard करें। आप कितनी भी निष्पक्षता से बांटें, एक single concurrency budget आखिरकार bottleneck बन जाएगा।

उस समय workloads को अपने-अपने budget वाले अलग workspaces या API keys पर बांट दें: उदाहरण के लिए, real-time agent traffic के लिए एक key और background narration के लिए दूसरी, ताकि narration backlog agent capacity को प्रभावित न कर सके।

Workspaces आपको scope restriction, credit quotas और प्रति-की नियंत्रण लागू करने देते हैं, जिनका विवरण प्रमाणीकरण दस्तावेज़ में दिया गया है।

अपने concurrency utilization की निगरानी

Measurement के बिना इनमें से कुछ भी tune नहीं किया जा सकता; जिस headroom को आप मापते नहीं, उसे manage नहीं कर सकते। हर response में current-concurrent-requests और maximum-concurrent-requests को model family के tag के साथ record करें और utilization ratio को gauge के रूप में emit करें।

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

Track करने के लिए चार signals:

• Utilization (current / maximum)।
• कुल requests के अनुपात में 429 rate।
• Retry depth, यानी हर logical request के लिए attempts की संख्या।
• Time-to-first-audio, जिसे model inference figures से नहीं, आपके application से मापा जाता है। TTFA में क्या शामिल है, इसके लिए latency को समझना देखें।

एक स्वस्थ system utilization को saturation से आराम से नीचे रखेगा और 429 केवल कभी-कभार होने वाले bursts में दिखेंगे। इन signals की निगरानी से rate-limiting pressure की जानकारी outage बनने से बहुत पहले मिल जाती है।

Client-side rate limiting से आगे कब scale करें

Client-side patterns काफी काम संभाल सकते हैं, लेकिन steady-state demand आखिरकार इनसे बढ़ जाएगी। ऐसा होने पर cost और effort, दोनों में मदद करने वाले बदलाव करने का समय है।

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

Interactive traffic के लिए पहले HTTP से WebSockets पर जाएं। अगर आपके agents या live use cases HTTP पर चलते हैं, तो WebSocket पर जाने से accounting बदल जाती है और केवल active generation गिनी जाती है। Conversational workloads में plan बदले बिना भी इससे अक्सर effective capacity कई गुना हो जाती है, क्योंकि idle conversation time slots का उपयोग करना बंद कर देता है।

अगर आपके bursts spiky हैं लेकिन average load budget में है, तो token या leaky bucket के साथ bounded pool peaks को average में बदल देता है।

फिर सही मॉडल चुनें। तेज़ generation हर slot को कम समय तक रखती है, जिससे fixed concurrency limit अधिक broadcasts संभाल सकती है। Real-time काम के लिए Eleven Flash v2.5 सबसे कम latency वाला विकल्प है; इसे इंस्टेंट वॉइस क्लोन या default voice के साथ उपयोग करने से Professional Voice Clones का per-generation overhead बचता है।

इसके बाद ही plan upgrade करें। Client के सही तरीके से काम करने के बाद भी जब आपकी steady-state demand वास्तव में budget से अधिक हो, तो ऊंचा plan per-model concurrency limit और आपकी queue priority, दोनों बढ़ाता है। API pricing page पर tiers की तुलना करें।

अगर आपको प्रकाशित सीमाओं से अधिक चाहिए, तो Enterprise plans बढ़ी हुई और custom concurrency limits के साथ सबसे ऊंची queue priority देते हैं। योग्य use cases के लिए IP whitelisting (Enterprise preview में) और zero-retention modes जैसे अतिरिक्त controls भी उपलब्ध हैं। Limits बढ़ाने के लिए अपने account manager से संपर्क करें।

AI rate limiting के लिए याद रखने योग्य बातें

मुख्य गलती यह है कि वॉइस AI rate limiting को requests गिनने जैसा समझा जाए। यहां सब कुछ concurrency control के बारे में है। आपकी सफलता तय करने वाली संख्या यह है कि एक ही पल में कितने requests ऑडियो generate कर रहे हैं और हर एक कितनी देर तक slot रखता है।

इसी तथ्य के आधार पर अपना client बनाएं।

Bounded pool से in-flight requests सीमित करें, token या leaky bucket से admission shape करें, capped exponential backoff और full jitter के साथ retry करें, Retry-After का पालन करें और retry storm बनने से पहले circuit break करें।

Multi-tenant systems के लिए per-tenant buckets, weighted fairness, reserved headroom और isolation के लिए sharding जोड़ें। current-concurrent-requests और maximum-concurrent-requests headers पर नज़र रखें और failures पर नहीं, utilization trend पर alert करें।

जब आपको सच में अधिक capacity चाहिए, तो इस क्रम में आगे बढ़ें: पहले WebSockets और बेहतर client behavior, फिर सही मॉडल, फिर plan upgrade और फिर Enterprise limits।

ElevenAPI के साथ वॉइस applications बनाएं

Production-grade AI rate limiting की शुरुआत सही transport, सही मॉडल और ऐसे headers से होती है जो ठीक-ठीक बताते हैं कि आप कहां खड़े हैं।

ElevenAPI, Eleven Flash v2.5 जैसे low-latency models, real-time WebSocket streaming, स्पीच टू टेक्स्ट और टेक्स्ट टू स्पीच APIs, साथ ही per-response concurrency headers देता है, जिनसे आप वॉइस एजेंट बना सकते हैं, जो आपकी सीमाओं के भीतर scale करें।

इस लेख की AI rate-limiting strategies के साथ, आप responsive voice experiences दे सकेंगे और predictable performance बनाए रखेंगे, load के दौरान भी।

पूरा model lineup काम करते हुए देखने के लिए ElevenAPI देखें, या आज ही ElevenLabs के साथ बनाना शुरू करने के लिए अकाउंट बनाएं।

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