Muse Wonder의 속도 제한: 3,000 RPM 및 4M TPM, 전 팀에 배포

Muse Wonder의 Meta Model API 속도 제한은 분당 3,000 요청(requests per minute)과 분당 4,000,000 토큰(tokens per minute)입니다. 이 두 가지는 API 키별이 아니라 모델별 및 팀별로 적용됩니다: 조직에서 생성되는 모든 키는 동일한 풀에서 가져옵니다. 백그라운드 응답은 분당 600개의 새로운 전송물(deliveries)에 대한 별도의 크레딧을 받습니다. 공개된 사용 등급은 없으며, 더 많은 양을 요청할 수 있는 문서화된 방법도 없습니다. 제한을 초과하면 HTTP 429를 받고, Meta의 지침은 약 500ms부터 시작하는 지터(jitter)가 적용된 지수 백오프(exponential backoff)이며, Retry-After 헤더를 준수해야 합니다.

오늘 Apidog을 사용해 보세요

이 네 가지 사실은 muse-wonder-1.0을 대규모로 호출하는 모든 시스템을 설계하는 방식을 결정합니다. 이 게시물에서는 이러한 제한의 실제 의미, 1M 토큰의 컨텍스트가 어떻게 4M TPM 예산을 소진하는지, 헤더를 읽는 방법, 재시도 경로를 구축하고 테스트하는 방법, 그리고 3,000 RPM이 충분하지 않을 때 무엇을 해야 하는지를 다룹니다. API 기본 사항에 대해서는 Muse Wonder API 가이드를 참고하세요.

제한

실질적인 결과: 요청 수(number of requests)가 아닌 컨텍스트 크기(context size)를 기반으로 TPM을 할당해야 합니다. 매 턴마다 300K 토큰의 대화를 재전송하는 에이전트는 매번 300K 토큰의 요청이며, 이는 적용하기 전에 가장 무거운 열에 있는 10개 에이전트와 같습니다.

최소한 40%의 남은 공간을 확보하세요. 에이전트의 턴은 버스티(bursty)하며, 일시적인 오류 후 재시도 폭풍은 한 분 동안 요청을 두 배로 늘릴 수 있고, 팀의 다른 사람들은 동일한 풀에서 가져갑니다. 세 번째 줄은 종이 위에서는 좋아 보이지만, 두 에이전트가 동시에 재시도하려고 하면 실제로는 실패합니다.

두 개의 레버를 통해 방정식의 왼쪽 부분을 축소할 수 있습니다. 압축(Compaction)은 턴당 토큰이 무한정 증가하는 것을 방지합니다: 컨텍스트 창(context window)에서 설명된 것처럼, 프로세스가 임계값을 초과하면 오래된 도구 결과를 요약하거나 폐기합니다. Responses API의 상태 비저장형 암호화 재전송(stateless encrypted replay)은 무엇이 재전송되는지 정확하게 제어할 수 있게 해주며, previous_response_id를 사용한 서버 관리 기록은 모든 것을 재전송합니다.

모든 키에 대한 단일 풀 (One Pool for All Keys)

Meta는 팀당 제한을 설정합니다. 스테이징(staging)용 키, 프로덕션(production)용 키, 그리고 동료의 노트북에 있는 키 모두 동일한 3,000 RPM/4M TPM 풀에서 가져옵니다. 이는 두 가지 결과를 초래합니다.

첫째, 한 개발자의 부하 테스트가 프로덕션을 제한할 수 있습니다. 실험을 시간적으로 분리하거나 조직이 허용하는 경우 별도의 팀을 사용하세요. 둘째, 키별 모니터링은 전체 그림을 보여주지 못합니다. 모든 호출에서 x-ratelimit-* 헤더를 집계하지 않으면, 한가해 보이는 키에서도 429 오류를 볼 수 있습니다.

헤더 읽기 (Read Header)

토큰 기반 응답은 x-ratelimit-* 헤더를 포함합니다. 모든 호출에서 이 헤더를 기록하세요. 중요한 패턴은 1분 동안 모든 호출자에서 남은 용량이 0으로 감소한다는 것입니다—이것이 429가 오기 전에 속도를 늦춰야 한다는 신호입니다. 전사(transcription) 응답은 이 헤더를 포함하지 않으며, Wonder 응답만 포함합니다.

429가 발생하면 Meta 문서에 명시된 대로: 약 500ms부터 지터(jitter)를 적용하여 지수 백오프(exponential backoff)를 수행하고, Retry-After 헤더가 있으면 최소한 그 시간 동안 기다리세요. Retry-After를 무시하고 일정한 간격으로 API를 호출하는 재시도 루프는 팀의 모든 사람에게 더 긴 장애 시간을 초래할 것입니다.

재시도 경로 구축하기

import os
import random
import time
...

세 가지 중요한 설계 포인트가 있습니다. 지수 백오프를 제한하여 긴 장애 시간이 20분간의 수면 상태로 변하지 않도록 하세요. 재시도를 항상 아이뎀포턴트(idempotent)하게 유지하세요: 아무것도 하지 않는 Responses 호출은 안전하게 반복할 수 있지만, 에이전트 도구 호출에 부작용(side effect)이 있는 경우 모델 호출을 다시 시도하고 도구를 다시 시도하지 마세요. 마지막으로, 추적(trace)에서 재시도를 표시하여 느린 모델과 제한된 모델을 구별할 수 있도록 하세요. 도구 호출 추적 가이드에는 기록해야 할 내용이 포함되어 있습니다.

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

긴 작업이라고 해서 연결을 유지할 필요는 없습니다. background: true를 사용하면 응답이 대기열(queue)에 추가되고, `

• 요청당 토큰을 줄이세요. Prompt caching은 청구액을 줄여주지만, TPM(Tokens Per Minute)은 줄이지 않습니다. 컨텍스트를 간소화하면 두 가지 모두에 도움이 됩니다. Context window는 도구 호출의 결과(result)를 간소화하는 방법을 다룹니다.
• 다른 모델로 분산하세요. Spark 1.3은 자체적으로 3,000 RPM/4M TPM 풀을 보유하고 있으며 가격은 3분의 1 수준입니다. Wonder급 품질이 필요하지 않은 작업은 이쪽으로 라우팅하세요.
• 게이트웨이를 사용하세요. Vercel AI Gateway와 Cloudflare Workers AI는 meta/muse-wonder-1.0을 제공합니다. 게이트웨이가 어떻게 제공되는지에 따라 별도의 혜택을 받을 수 있으므로, 의존하기 전에 반드시 게이트웨이 제공업체에 확인하세요.
• 큐잉 및 평활화(Smooth). 전체 팀 예산을 파악하고 있는 API 앞에 토큰 버킷 제한기(token-bucket rate limiter)를 두는 것이, 각각 추측하는 여섯 개의 서비스보다 더 좋습니다.

Apidog에서 제한 처리 테스트하기

3,001번째 요청에서 재시도 버그를 발견하지 마세요. Apidog에서는:

1. MODEL_API_KEY를 비밀 변수로 사용하는 Responses 요청을 구축한 다음, x-ratelimit-* 헤더를 환경 변수로 읽는 후처리 프로세서(post-processor)를 추가하세요. 이 시나리오는 남은 용량이 임계값 이하로 떨어지지 않음을 선언할 수 있게 합니다.
2. X-Test-Scenario: throttle와 같은 헤더가 포함된 요청이 들어올 때 429 응답과 Retry-After: 2 헤더를 반환하도록 모의(mock) /v1/responses를 만드세요. 클라이언트를 이 모의로 지정한 다음, 최소 두 초 동안 기다렸다가 다음 시도에서 성공한다는 것을 선언하세요.
3. 모의에 대한 요청 볼륨을 높여 성능 테스트를 실행하여 API가 하기 전에 제한기가 활성화되는지 확인하세요.
4. Apidog CLI와 함께 CI에 시나리오를 추가하여 재시도 코드 변경 사항이 통과하지 않으면 전송되지 않도록 하세요.

Apidog을 다운로드하여 하나의 프로젝트에서 모의 및 단언(assertion)을 설정하세요.

자주 묻는 질문

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

팀 단위입니다. 팀 내 모든 키는 모델별로 3,000 RPM/4M TPM을 공유하는 하나의 풀을 사용합니다.

캐시된 입력도 TPM에 포함되나요?

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

더 높은 제한을 요청할 수 있나요?

Meta의 가격 및 속도 제한 페이지에는 계층이나 프로세스가 명시되어 있지 않습니다. 변경 사항은 해당 페이지를 확인하십시오. 프론티어(frontier) 출시 시 몇 주에 걸쳐 계층이 추가되는 경우가 많습니다.

어떤 상태 코드와 헤더를 받게 되나요?

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

다음 단계

가장 무거운 에이전트(agent)의 요청당 토큰을 측정하고, 이를 동시성 수준에 곱한 다음, 400만과 비교하십시오. 결과가 제한에 근접하다면, 이번 주에 속도 제한기(rate limiter)를 구축하여 모의 테스트(mock test)를 진행하십시오—전체 팀이 프로덕션 환경에서 동일한 풀을 공유하기 전에 말입니다.