Muse Wonder 속도 제한: 3.000 RPM 및 4백만 TPM, 팀 단위 공유

Meta Model API의 Muse Wonder 제한은 분당 3,000 요청(RPM) 및 분당 4,000,000 토큰(TPM)입니다. 이 두 가지는 모델별, 팀별로 적용되며 API 키별로는 적용되지 않습니다: 조직의 모든 키가 동일한 풀을 사용합니다. 백그라운드 응답은 추가적으로 분당 600개의 새로운 전송 건수 할당량을 받습니다. 현재 공개된 사용 등급이나 제한 상향 조정에 대한 문서화된 프로세스는 없습니다. 초과 시 HTTP 429를 받게 되며, Meta는 약 500ms 간격으로 Jitter가 적용된 지수 백오프(exponential backoff)를 권장하며, Retry-After 헤더가 있는 경우 이를 고려해야 합니다.

Apidog을 오늘 사용해 보세요

이러한 사실들은 muse-wonder-1.0의 호출을 대규모로 아카이브하는 방법을 결정합니다. 이 글에서는 제한 사항이 실제로 무엇을 의미하는지, 1M 토큰 컨텍스트가 4M TPM 예산을 어떻게 소모하는지, 헤더를 어떻게 읽는지, 재시도(retries)를 어떻게 생성하고 테스트하는지, 그리고 3,000 RPM이 부족할 때 무엇을 해야 하는지를 설명합니다. API 기본 사항은 Muse Wonder API 가이드에서 시작하세요.

제한 사항

토큰이 요청보다 먼저 소진됩니다

분당 4백만 토큰(Mio. Token)은 에이전트의 요청 한계에서 가장 큰 제약 요인일 때가 드뭅니다. 필요한 요청 수는 컨텍스트 크기에 직접적으로 달려 있습니다:

따라서 요청 수로 아닌 컨텍스트 크기로 TPM을 예산 책정해야 합니다. 매 라운드마다 30만 토큰 분량의 대화를 다시 보내는 에이전트는 매번 30만 토큰짜리 요청을 생성합니다. 이러한 에이전트 열 개가 분당 한 번씩 작동한다면, 팀 할당량의 4분의 3을 소모하게 됩니다.

수치에 기반하여 병렬성 계획하기

용량 계산은 간단합니다:

동시 에이전트 수
× 라운드당 토큰
× 분당 라운드 수
...

배포하기 전에 가장 강력한 파이프라인에 대해 이 값을 계산하십시오:

두 가지 레버리지가 필요량을 줄여줍니다:

• 압축(Komprimierung): 라운드당 토큰 요구량이 무한정 증가하는 것을 방지합니다. 이전 도구 결과를 요약하거나, 실행이 컨텍스트 창에 포함된 임계값을 초과하면 폐기합니다.
• 상태 비저장 암호화 재현(Zustandsloses verschlüsseltes Replay): Responses API를 사용하면 무엇을 다시 보낼지 정확하게 제어할 수 있습니다. 반면, previous_response_id를 사용하는 서버 관리 기록은 모든 것을 다시 전송합니다.

모든 키를 위한 공유 풀

Meta는 팀별로 사용량을 제한합니다. 스테이징용 키, 프로덕션용 키, 그리고 팀 동료의 노트북에 있는 키 모두 동일한 3,000 RPM 및 4백만 TPM을 사용합니다.

여기서 두 가지 규칙이 도출됩니다:

1. 개발자의 부하 테스트가 프로덕션을 저하시킬 수 있습니다. 조직에서 허용하는 경우 실험을 시간적으로 또는 별도의 팀으로 격리하십시오.
2. 키별 모니터링은 전체 그림을 보여주지 않습니다. 모든 호출자에 걸쳐 x-ratelimit-* 헤더를 집계해야 합니다. 그렇지 않으면 제한에 훨씬 못 미치는 것처럼 보이는 키에서 429 오류가 발생할 수 있습니다.

헤더 읽기

토큰 기반 응답에는 x-ratelimit-* 헤더가 포함됩니다. 모든 호출에서 이를 기록하십시오. 결정적인 패턴은 남아 있는 용량이 한 분 안에 모든 호출자에 걸쳐 0에 가까워진다는 것입니다. 이것이 다음 429 오류를 방지하기 위해 속도를 늦춰야 하는 신호입니다. 트랜스크립션 응답에는 이 헤더가 포함되지 않으며, Wonder의 응답에만 포함됩니다.

429 오류 발생 시 Meta의 권장 사항은 구체적입니다: 약 500ms 간격으로 지터(Jitter)를 사용한 지수 백오프(exponential backoff)를 사용하고, 헤더가 있는 경우 Retry-After에 지정된 시간만큼 최소한 기다리십시오. Retry-After를 무시하고 고정 간격으로 계속 요청하는 재시도 루프는 전체 팀의 속도 제한을 연장시킵니다.

견고한 재시도 경로를 위해 Retry-After, 지수 백오프(exponential backoff), 지터(Jitter) 및 대기 시간 상한선을 결합합니다:

import os
import random
import time
...

세 가지 설계 포인트가 중요합니다:

1. 백오프 제한: 긴 장애가 트레이스에 20분 동안 지속되는 것을 방지하여, 느린 모델과 속도 제한이 걸린(throttled) 상태를 구별할 수 있게 합니다. Tool-Call 추적 가이드에서 무엇을 로깅해야 하는지 설명합니다.

장기 실행 작업에는 백그라운드 응답 사용하기

장기 실행 작업은 연결을 유지할 필요가 없습니다. background: true는 응답을 큐(queue)에 '반환'하고, 생명주기 이벤트에 대해 GET /v1/responses/{id}?stream=true를 조회할 수 있게 합니다.

백그라운드 전송은 기본 제한 외에도 분당 600개의 별도 할당량을 가집니다. 따라서 배치 작업을 처리함으로써 인터랙티브 트래픽의 RPM을 확보할 수 있습니다.

제한 사항에 유의하세요:

• stream: true는 POST에서 허용되지 않습니다.
• 요청 본문은 1 MiB로 제한됩니다.
• 취소는 POST /v1/responses/{id}/cancel로 수행합니다.

3,000 RPM으로 충분하지 않을 때

Meta는 현재 속도 제한 상향을 위한 단계나 양식을 공개하고 있지 않습니다. 오늘날 사용 가능한 옵션은 다음과 같습니다:

• 요청당 토큰 수 줄이기. 프롬프트 캐싱(Prompt-Caching)은 청구 금액을 줄이지만 TPM을 줄이지는 못합니다. 컨텍스트를 축소하면 둘 다 줄어듭니다. 컨텍스트 창 기여도에서 Tool 결과 축소에 대해 다룹니다.
• 모델에 걸쳐 작업 분산하기. Muse Spark 1.3은 가격의 3분의 1 수준으로 자체적인 3,000/4M 풀을 가지고 있습니다. Wonder 모델의 품질이 필요하지 않은 작업은 이쪽으로 라우팅하세요.
• 게이트웨이 사용하기. Vercel AI Gateway와 Cloudflare Workers AI는 meta/muse-wonder-1.0에 서비스를 제공합니다. 이것이 별도의 할당량을 주는지 여부는 게이트웨이 배포 관리에 따라 다릅니다 - Apidog에서 확인하세요.

요청 3,001번에서 재시도 오류를 발견하지 마세요. Apidog에서:

1. MODEL_API_KEY를 비밀 변수로 사용하여 응답 요청을 생성합니다. 잔여 용량이 임계값 이하로 떨어지지 않는 시나리오가 주장할 수 있도록, x-ratelimit-* 헤더를 환경 변수에 저장하는 후처리기를 추가합니다.
2. 요청에 X-Test-Scenario: throttle와 같은 헤더가 포함될 경우 HTTP 429 오류와 함께 Retry-After: 2 헤더를 반환하도록 /v1/responses의 Mock을 생성합니다. 클라이언트를 이 Mock에 설정하고, 최소한 2초 동안 대기한 후 다음 시도에서 성공하는지 확인합니다.
3. 요청 볼륨을 Mock에 대해 증가시키는 성능 테스트를 수행하여, 실제 API가 속도 제한(throttle)하기 전에 리미터가 활성화되는지 확인합니다.
4. Apidog-CLI를 사용하여 이 시나리오를 CI에 통합하여, 반복 코드의 변경 사항이 기존 테스트와 함께 배포될 수 있도록 합니다.

Apidog를 다운로드하여 프로젝트 내에서 Mock 및 단언(Assertion)을 설정하세요.

자주 묻는 질문 (FAQ)

Muse Wonder의 속도 제한은 키별인가요, 아니면 계정별인가요?

팀 단위입니다. 팀 내 모든 키가 모델당 3,000 RPM 및 4백만 TPM 풀을 공유합니다.

중간 저장된 입력(intermediate cached input)이 TPM에 포함되나요?

예. 캐싱은 해당 토큰의 가격을 낮출 뿐, 토큰-분 단위 제한 대비 가중치를 낮추지는 않습니다.

더 높은 한도를 요청할 수 있나요?

Meta의 가격 및 속도 제한 페이지에는 현재 등급이나 프로세스가 명시되어 있지 않습니다. 변경 사항이 있는지 페이지를 확인하세요. 새로운 모델은 몇 주 안에 사용량 등급을 추가하는 경우가 많습니다.

초과했을 때 어떤 상태 코드와 헤더를 받나요?

HTTP 429이며, 선택적으로 Retry-After가 포함되고 토큰 기반 응답에는 x-ratelimit-* 헤더가 포함됩니다.

다음 단계

가장 강력한 에이전트 라운드의 요청당 토큰 수를 측정하고, 이를 병렬성(Parallelität)과 곱하여 그 결과를 400만과 비교하십시오. 만약 답변이 이 값에 근접하다면, 팀이 동일한 풀을 프로덕션 환경과 공유하기 전에 이번 주에 제한 장치와 모의 테스트를 생성하십시오.