Meta Model API에 대한 Muse Wonder의 속도 제한은 분당 요청 3,000개와 분당 토큰 4,000,000개입니다. 둘 다 API 키가 아닌 모델별 및 팀별로 적용됩니다. 조직에서 생성하는 모든 키는 동일한 풀에서 가져옵니다. 백그라운드 응답에는 분당 600개의 새로운 제출이 별도로 허용됩니다. 게시된 사용 계층이 없으며 더 많은 것을 요청할 수 있는 문서화된 방법도 없습니다. 제한을 초과하면 HTTP 429가 발생하며 Meta의 지침은 약 500ms에서 시작하는 지터를 사용하여 Retry-After가 있는 경우 이를 준수하는 지수 백오프입니다.
이러한 4가지 사실은 muse-wonder-1.0을 대규모로 호출하는 모든 것을 어떻게 설계할지 결정합니다. 이 게시물에서는 제한이 실제로 의미하는 바, 1M 토큰 컨텍스트가 4M TPM 예산을 소모하는 방식, 헤더를 읽는 방법, 재시도 경로를 구축하고 테스트하는 방법, 분당 3,000 요청이 부족할 때 해야 할 일을 다룹니다. API 기본 사항은 Muse Wonder API 가이드부터 시작하세요.
속도 제한
| 한도 | 값 | 범위 |
|---|---|---|
| 분당 요청 수 | 3,000 | 팀당, 모델당 |
| 분당 토큰 수 | 4,000,000 | 팀당, 모델당 |
| 백그라운드 제출 | 분당 600개 | 팀당, 위 사항에 추가로 |
| 컨텍스트 창 | 1,048,576 토큰 | 요청당 |
| 사용 계층 | 게시됨 없음 | |
| 한도 증가 | 문서화된 프로세스 없음 |
동일한 3,000/4M 수치는 Muse Spark 1.3에 적용됩니다. Spark의 Contributor 변형은 분당 150 요청과 3M TPM으로 낮게 제한됩니다. 각 모델에는 자체 풀이 있으므로 많은 Wonder 트래픽이 Spark 레인을 고갈시키지 않으며 그 반대의 경우도 마찬가지입니다. Meta의 삽입된 스티어링 컨텍스트는 TPM에 포함되지 않으며 usage에 나타나지 않습니다.
요청 수보다 먼저 토큰이 소진됩니다
분당 4M 토큰이라면 요청 제한이 에이전트에게 제약 조건이 되는 경우는 드뭅니다. 세 가지 예시:
| 워크로드 | 요청당 토큰 수 | TPM이 바인딩되기 전 분당 요청 수 |
|---|---|---|
| 짧은 채팅 턴 | 3,000 | 1,333 |
| 문서 검토 | 50,000 | 80 |
| 긴 에이전트 턴, 400K 컨텍스트 | 400,000 | 10 |
| 전체 창 요청 | 1,000,000 | 4 |
큰 컨텍스트를 가진 소수의 에이전트를 실행하는 팀은 12개의 동시 요청으로 4M TPM에 도달할 수 있습니다. 캐시된 입력도 TPM에 포함됩니다. 캐시 할인은 요금 청구 할인이지 속도 제한 할인이 아닙니다. 추론 토큰은 max_output_tokens와 청구서에 포함되며 출력 토큰도 TPM에 포함됩니다.
실질적인 결과는 요청 수가 아니라 컨텍스트 크기로 TPM을 예산 책정하는 것입니다. 매 턴 300K 토큰 대화를 다시 보내는 에이전트는 매번 300K 토큰 요청입니다. 이러한 에이전트 10개가 분당 한 번씩 실행되면 팀 할당량의 4분의 3을 소비합니다.
숫자를 바탕으로 동시성 계획
용량 계산은 한 줄입니다. 동시 에이전트 수 × 턴당 토큰 수 × 각 에이전트의 분당 턴 수는 4,000,000 미만이어야 합니다. 배포하기 전에 가장 부하가 많은 레인에서 계산하세요.
| 에이전트 | 턴당 토큰 수 | 각 에이전트의 분당 턴 수 | 필요한 TPM | 여유 공간 |
|---|---|---|---|---|
| 4 | 150,000 | 2 | 1,200,000 | 70% |
| 8 | 250,000 | 1 | 2,000,000 | 50% |
| 12 | 300,000 | 1 | 3,600,000 | 10% |
| 20 | 300,000 | 1 | 6,000,000 | 한도 초과 |
최소 40%의 여유 공간을 남겨두세요. 에이전트 턴은 급증하는 경향이 있고 일시적인 오류 후 재시도 폭풍은 1분 동안 수요를 두 배로 늘리며 팀의 다른 모든 사람도 같은 풀에서 소비하고 있습니다. 세 번째 행은 서류상으로는 괜찮아 보이지만 두 에이전트가 처음으로 동시에 재시도하면 실제로 실패합니다.
두 가지 레버가 방정식의 왼쪽을 줄입니다. 컴팩션은 턴당 토큰 수가 무한정 증가하지 않도록 합니다. 컨텍스트 창 게시물에서 설명한 것처럼 실행이 임계값을 넘으면 오래된 도구 결과를 요약하거나 삭제하세요. 또한 Responses API의 상태 비저장 암호화 재생을 사용하면 다시 보내는 내용을 정확하게 제어할 수 있으며, previous_response_id를 사용하는 서버 관리 기록은 모든 것을 다시 보냅니다.
모든 키가 하나의 풀을 공유
Meta는 팀별로 제한을 지정합니다. 스테이징용 키, 프로덕션용 키, 팀원의 노트북용 키는 모두 동일한 3,000/4M에서 가져옵니다. 여기에는 두 가지 결과가 있습니다.
첫째, 한 명의 개발자가 실행하는 부하 테스트가 프로덕션을 제한할 수 있습니다. 실험을 시간적으로 분리하거나 조직이 허용하는 경우 별도 팀에서 분리하세요. 둘째, 키별 모니터링은 전체 그림을 보여주지 않습니다. 모든 호출자에서 x-ratelimit-* 헤더를 집계하지 않으면 한도보다 훨씬 아래에 있는 것처럼 보이는 키에서 429가 발생하는 것을 보게 됩니다.
헤더 읽기
토큰 기반 응답에는 x-ratelimit-* 헤더가 포함됩니다. 모든 호출에서 기록하세요. 중요한 패턴은 1분 이내에 모든 호출자에서 남은 용량이 0을 향해 감소하는 추세이며, 이는 429가 도착하기 전에 속도를 늦추라는 신호입니다. 전사 응답에는 이러한 헤더가 없지만 Wonder의 응답에는 있습니다.
429가 도착하면 Meta 문서는 구체적입니다. 약 500ms부터 시작하는 지터로 지수적으로 백오프하고 Retry-After가 있으면 최소한 그 시간만큼 기다리세요. Retry-After를 무시하고 고정 간격으로 계속 요청하는 재시도 루프는 팀원 모두에게 중단 시간을 더 길게 만듭니다.
재시도 경로 구축
import random, time
from openai import OpenAI, RateLimitError
client = OpenAI(base_url="https://api.meta.ai/v1", [REDACTED CREDENTIAL] call(input_text, attempts=6):
delay = 0.5
for i in range(attempts):
try:
return client.responses.create(model="muse-wonder-1.0", input=input_text,
reasoning={"effort": "medium"}, max_output_tokens=4096)
except RateLimitError as e:
retry_after = e.response.headers.get("retry-after")
wait = float(retry_after) if retry_after else delay + random.uniform(0, delay)
time.sleep(wait)
delay = min(delay * 2, 30)
raise RuntimeError("rate limited after retries")
세 가지 설계 포인트가 있습니다. 긴 중단이 20분 수면으로 변하지 않도록 백오프에 상한을 두세요. 재시도를 멱등성으로 유지하세요. Responses 호출이 사용자 쪽에서 아것도 생성하지 않으면 반복해도 안전하지만, 에이전트의 도구 호출에 부작용이 있는 경우 도구가 아니라 모델 호출을 재시도하세요. 그리고 재시도를 트레이스에 표시하여 느린 모델과 제한된 모델을 구별할 수 있도록 하세요. 도구 호출 추적 가이드에서 로그할 내용을 다룹니다.
긴 꼬리에 배경 응답 사용
긴 작업은 연결을 유지할 필요가 없습니다. background: true는 응답을 대기열에 넣고 "status": "queued"를 반환하며 GET /v1/responses/{id}?stream=true를 폴링하여 수명 주기 이벤트를 확인할 수 있습니다. 백그라운드 제출에는 주요 제한 외에 분당 600개의 자체 허용량이 있으므로 배치 스타일 작업을 그곳으로 이동하면 대화형 트래픽을 위한 RPM이 확보됩니다. 제약 조건은 POST에 stream: true를 사용할 수 없다는 점, 1 MiB 본문 상한, POST /v1/responses/{id}/cancel로 취소한다는 점입니다.
3,000 RPM이 부족할 때
Meta는 계층 사다리나 한도를 높이는 양식을 게시하지 않습니다. 오늘날의 선택지:
- 요청당 토큰 수를 줄입니다. 프롬프트 캐싱은 청구서는 줄이지만 TPM은 줄이지 않습니다. 컨텍스트를 다듬으면 두 가지 모두 줄어듭니다. 컨텍스트 창 게시물에서 도구 결과 다듬기를 다룹니다.
- 모델에 분산합니다. Spark 1.3은 가격의 3분의 1로 자체 3,000/4M 풀을 가지고 있습니다. Wonder의 품질이 필요하지 않은 작업을 그곳으로 라우팅하세요.
- 게이트웨이를 사용합니다. Vercel AI Gateway와 Cloudflare Workers AI는 meta/muse-wonder-1.0을 제공합니다. 별도의 허용량을 제공하는지 여부는 게이트웨이가 프로비저닝되는 방식에 따라 다릅니다. 의존하기 전에 확인하세요.
- 대기열과 평활화를 사용합니다. 팀의 전체 예산을 알고 있는 API 앞의 토큰 버킷 리미터는 각각 추측하는 여섯 개 서비스보다 더 나은 성능을 발휘합니다.
Apidog에서 한도 처리 테스트
3,001개 요청에서 재시도 버그를 발견하지 마세요. Apidog에서:
- MODEL_API_KEY를 비밀 변수로 사용하여 Responses 요청을 작성하고 x-ratelimit-* 헤더를 환경 변수로 읽는 사후 처리기를 추가하여 시나리오에서 남은 용량이 최저 수준 이하로 떨어지지 않도록 주장할 수 있습니다.
- /v1/responses의 목(mock)을 만들고, 429와 Retry-After: 2 헤더를 반환하는 목 기대값을 X-Test-Scenario: throttle과 같은 헤더를 가진 요청에 대해 설정합니다. 클라이언트를 해당 목으로 지정하고, 최소 2초 기다린 후 다음 시도에서 성공하는지 확인합니다.
- 모의에 대해 요청 볼륨을 늘리는 성능 테스트를 실행하여 API가 작동하기 전에 리미터가 작동하는지 확인합니다.
- Apidog CLI를 사용하여 CI에 시나리오를 배치하면 재시도 코드에 대한 변경 사항을 전달하지 않고는 제공할 수 없습니다.
하나의 프로젝트에서 목과 어설션을 설정하려면 Apidog를 다운로드하세요.
자주 묻는 질문
Muse Wonder 속도 제한은 키당인가요, 계정당인가요? 팀당입니다. 팀의 모든 키는 모델당 하나의 3,000 RPM/4M TPM 풀을 공유합니다.
캐시된 입력이 TPM에 포함됩니까? 예. 캐싱은 해당 토큰의 가격을 낮출 뿐 분당 토큰 한도에 대한 가중치를 낮추지 않습니다.
더 높은 한도를 요청할 수 있나요? Meta의 가격 및 속도 제한 페이지에는 계층과 프로세스가 나열되어 있지 않습니다. 변경 사항은 페이지를 확인하세요. 프론티어 출시는 몇 주 안에 계층을 추가하는 경우가 많습니다.
어떤 상태 코드와 헤더를 받나요? HTTP 429, 선택적으로 Retry-After, 그리고 토큰 기반 응답에는 x-ratelimit-* 헤더가 포함됩니다.
다음 단계
가장 부하가 많은 에이전트 턴의 요청당 토큰 수를 측정하고 동시성을 곱한 후 4,000,000과 비교하세요. 답이 가깝다면 팀이 프로덕션과 풀을 공유하기 전에 이번 주에 리미터와 목 테스트를 구축하세요.