음성 AI 레이트 리미팅: 동시성, 대기열, 429 에러

대부분의 팀은 다른 API를 다루듯 음성용 AI 속도 제한을 적용합니다. 분당 요청 수를 제한하고, 서버가 거부하면 재시도한 뒤 넘어갑니다. 하지만 ElevenLabs 워크로드에서는 첫 트래픽 급증부터 이 방식이 무너집니다. 실제로 부딪히는 제한은 요청 수가 아니라 동시성이기 때문입니다.

이 가이드에서는 동시성이 실제 제약인 이유를 설명하고, 그 한도 내에서 운영할 수 있는 클라이언트 측 패턴을 살펴봅니다. 제한된 동시성 풀과 안정적인 429 처리부터 멀티 테넌트 공정성, 토큰 버킷과 리키 버킷까지 구현 가능한 실용적인 시스템을 제공합니다. 각 패턴에는 상황에 맞게 수정할 수 있는 TypeScript 구현 예시도 함께 제공합니다.

음성 에이전트를 구축하고 내레이션 파이프라인 또는 모델 기반의 다른 프로덕션 시스템을 확장하려는 경우, 이 가이드가 도움이 됩니다.

요약

• 음성용 AI 속도 제한은 분당 요청 수 계산이 아니라 동시성 제어입니다.
• 속도 제한 상한에 도달해도 트래픽이 즉시 거부되지는 않습니다. 대신 요청은 약 50ms의 지연을 추가하는 우선순위 큐에 들어갑니다.
• 큐잉 이후에도 용량을 초과하면 HTTP 429 오류가 발생합니다.
• WebSocket은 활성 생성 시간만 한도에 포함되므로 실질적인 용량을 크게 높입니다.
• 멀티 테넌트 시스템에는 추가 공정성 계층이 필요합니다. 테넌트별 버킷, 가중 공정 큐잉, 예약된 여유 용량, 격리를 위한 키 간 샤딩이 여기에 해당합니다. 
• current-concurrent-requests와 maximum-concurrent-requests라는 두 응답 헤더로 AI 속도 제한 현황을 파악할 수 있습니다.

제한이 분당 요청 수가 아닌 동시성인 이유

동시성은 같은 순간에 처리 중인 요청 수입니다. 분당 요청 수는 일정 시간 구간의 처리량입니다. 이 차이를 이해하는 것이 중요한 이유는 한도 내에 머물기 위해 조절해야 할 요소가 달라지기 때문입니다.

ElevenLabs 모델을 사용할 때 서버 워크로드는 동시 사용자 수에 따라 확장됩니다. 오디오 생성은 생성이 끝날 때까지 슬롯을 점유하며, 그 시간은 입력 길이, 모델, 부하에 따라 달라집니다.

분당 요청 수 제한으로는 지금 점유된 슬롯 수를 알 수 없습니다. 서버가 측정하는 것은 바로 이 값뿐입니다.

플랜 및 모델 패밀리별 제한

동시성 예산은 단일 숫자가 아닙니다. 동시성 한도는 플랜과 모델 패밀리별로 다릅니다. 예를 들어 음성 인식은 텍스트 음성 변환보다 높은 한도가 적용됩니다. 전사 요청은 일반적으로 더 짧게 지속되며, 시스템이 한 번에 더 많이 처리할 수 있기 때문입니다.

한도는 모델 패밀리별로 적용됩니다. 에이전트에 Flash를 사용하고 에이전트에 Flash를, 내레이션에 Multilingual v2를 사용한다면 두 개의 별도 예산을 동시에 사용하게 됩니다. 현재 플랜별 수치와 동시성 섹션은 모델 페이지에 문서화되어 있습니다.

동시성 한도에 도달하면 어떻게 되나요?

동시성 한도에 도달해도 트래픽이 즉시 거부되지는 않습니다. 시스템은 우선순위 큐를 통해 점진적으로 성능을 저하시키며, 속도 제한의 총용량을 계속 초과할 때만 완전 거부로 전환합니다.

한도 미만에서는 요청이 즉시 실행됩니다. 한도에 도달하면 이후 요청은 플랜의 우선순위 수준에 따라 정렬된 큐에 들어갑니다. 큐는 일반적으로 약 50ms의 지연만 추가하므로, 짧은 초과는 사용자에게 거의 보이지 않습니다.

큐잉 후에도 시스템 용량을 초과하면 HTTP 429를 받습니다. 이는 즉시 재시도하지 말고 속도를 줄이라는 신호입니다. 표의 우선순위 수준은 대기 중인 요청이 다른 트래픽과 비교해 어떤 순서로 처리되는지 결정하며, 상위 플랜일수록 큐를 더 빨리 통과합니다.

HTTP와 WebSocket: 한도에 반영되는 방식

선택하는 전송 방식은 속도 제한과 예산에 직접 영향을 미칩니다. 동일한 대화라도 HTTP로 실행하는지 WebSocket으로 실행하는지에 따라 동시성 예산을 크게 다르게 소비할 수 있습니다.

HTTP에서는 각 요청이 전체 지속 시간 동안 동시성 한도에 개별적으로 포함됩니다. WebSocket에서는 모델이 오디오를 활발히 생성하는 시간만 포함됩니다. 연결이 열려 있어도 유휴 상태인 WebSocket은 대부분 계산되지 않습니다.

음성 에이전트의 대화에는 아무도 말하지 않고 모델도 아무것도 생성하지 않는 긴 구간이 있습니다. HTTP에서는 매 턴마다 요청 지속 시간 동안 슬롯을 점유합니다. WebSocket에서는 활성 생성 중인 밀리초 동안만 슬롯을 사용하므로, 하나의 동시성 슬롯을 여러 대화가 시간 분할해 사용할 수 있습니다. 

실시간 TTS WebSocket 가이드에서 프로토콜 세부 사항을 확인하세요. 인터랙티브 트래픽에는 WebSocket이 적합한 기본 선택입니다.

동시성 약 5개로 방송 약 100개를 지원할 수 있는 이유

재생 시간을 고려하기 전까지 동시성의 계산 방식은 직관적이지 않습니다. 생성은 재생보다 훨씬 빠르고, 슬롯은 오디오를 생성할 때만 실제로 점유됩니다. 이 차이 덕분에 작은 예산으로도 많은 청취자에게 서비스를 제공할 수 있습니다.

생성에 몇 분의 1초가 걸리는 요청도 청취자가 재생하는 데 몇 초가 걸리는 오디오를 만들 수 있습니다. 재생 중에는 슬롯이 해제되어 다른 청취자가 사용할 수 있습니다.

경험상 동시성 한도 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

토큰 버킷: 버스트는 허용하고 평균은 제한

토큰 버킷은 최대 capacity개의 토큰을 보유하고 초당 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));
  }
}

전체 지터를 적용한 지수 백오프

재시도 가능한 상태로 요청이 실패했을 때 즉시 재시도하면 상황이 더 나빠집니다. 백오프는 재시도 간격을 늘리고, 전체 지터는 각 지연을 전체 구간에 걸쳐 무작위화합니다. 따라서 많은 클라이언트가 동시에 재시도해 실패를 유발한 동일한 급증을 다시 만드는 일을 막습니다.

아래 스니펫은 실패 상태와 Retry-After 값을 보관하는 작은 클래스인 RetryableError를 참조합니다. 이 클래스는 아래의 안정적인 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에서 WebSocket으로 전환하세요. 에이전트나 실시간 사용 사례가 HTTP에서 실행 중이라면 WebSocket으로 이동해 활성 생성 시간만 계산되도록 바꿀 수 있습니다. 대화형 워크로드에서는 유휴 대화 시간이 슬롯을 소비하지 않으므로 플랜을 변경하지 않고도 실질 용량이 크게 늘어나는 경우가 많습니다.

버스트는 크지만 평균 부하가 예산에 맞는다면, 토큰 버킷 또는 리키 버킷과 제한된 풀을 함께 사용해 피크를 평균 수준으로 평탄화할 수 있습니다.

다음으로 적합한 모델을 선택하세요. 생성 속도가 빠를수록 각 슬롯을 점유하는 시간이 짧아져 고정된 동시성 한도로 유지할 수 있는 방송 수가 늘어납니다. Eleven Flash v2.5는 실시간 작업에 가장 낮은 지연 시간 옵션이며, Instant Voice Clone 또는 기본 음성과 함께 사용하면 Professional Voice Clone의 생성당 오버헤드를 피할 수 있습니다.

그 다음에야 플랜 업그레이드를 고려해야 합니다. 클라이언트가 안정적으로 동작하는데도 정상 상태 수요가 실제로 예산을 초과한다면, 상위 플랜은 모델별 동시성 한도와 큐 우선순위를 모두 높입니다. API 가격 페이지에서 티어를 비교하세요.

공개된 한도를 초과하는 제한이 필요하다면 엔터프라이즈 플랜은 상향 및 맞춤 동시성 한도와 최고 큐 우선순위를 제공합니다. 엔터프라이즈 미리보기의 IP 허용 목록 및 무보존 모드 같은 추가 제어 기능도 적합한 사용 사례에 제공됩니다. 한도 상향은 계정 관리자에게 문의하세요.

AI 속도 제한에서 기억할 핵심 정리 

핵심적인 실수는 음성 AI 속도 제한을 요청 수 계산으로 다루는 것입니다. 여기서 다루는 모든 내용은 동시성 제어에 관한 것입니다. 성공 여부를 결정하는 수치는 같은 순간에 오디오를 생성하는 요청 수와 각 요청이 슬롯을 점유하는 시간입니다.

이 사실을 중심으로 클라이언트를 구축하세요. 

제한된 풀로 처리 중인 요청 수를 제한하고, 토큰 버킷 또는 리키 버킷으로 요청 수락을 조절하며, 상한이 있는 지수 백오프와 전체 지터로 재시도하세요. Retry-After를 준수하고 재시도 폭주가 형성되기 전에 회로를 차단하세요. 

멀티 테넌트 시스템에는 테넌트별 버킷, 가중 공정성, 예약된 여유 용량, 격리를 위한 샤딩을 추가하세요. current-concurrent-requests 및 maximum-concurrent-requests 헤더를 확인하고, 실패가 아니라 사용률 추세에 알림을 설정하세요. 

실제로 더 많은 용량이 필요하다면 순서대로 진행하세요. 먼저 WebSocket과 더 나은 클라이언트 동작을 적용하고, 그다음 적합한 모델, 플랜 업그레이드, 엔터프라이즈 한도를 고려하세요.

ElevenAPI로 음성 애플리케이션 구축

프로덕션 수준의 AI 속도 제한은 올바른 전송 방식, 올바른 모델, 그리고 현재 상태를 정확히 알려주는 헤더에서 시작됩니다.

ElevenAPI는 Eleven Flash v2.5와 같은 저지연 모델, 실시간 WebSocket 스트리밍, 음성 인식 및 텍스트 음성 변환 API, 그리고 한도 내에서 확장 가능한 음성 에이전트를 구축할 수 있게 해 주는 응답별 동시성 헤더를 제공합니다. 

이 글의 AI 속도 제한 전략과 함께 사용하면 부하 상황에서도 예측 가능한 성능을 유지하면서 반응성 높은 음성 경험을 제공할 수 있습니다. 

ElevenAPI를 살펴보고 전체 모델 라인업의 실제 동작을 확인하거나 계정을 만들어 오늘부터 ElevenLabs로 개발을 시작하세요.

AI 속도 제한 FAQ