Muse Wonderのレート制限：3,000 RPM、4M TPMをチーム全体で共有

Muse Wonder のメタモデル API のレート制限は、1 分あたり 3,000 リクエスト、1 分あたり 4,000,000 トークンです。どちらも API キーごとではなく、モデルおよびチームごとに適用されます。組織が作成するすべてのキーは同じプールから取得されます。バックグラウンド応答には、1 分あたり 600 件の新規送信が別途許可されます。公開されている使用量レベルはなく、追加をリクエストする方法も文書化されていません。制限を超えると HTTP 429 が発生し、Meta のガイダンスは約500ミリ秒から開始するジッター付き指数バックオフであり、Retry-After が存在する場合はこれを尊重します。

これら 4 つの事実は、muse-wonder-1.0 を大規模に呼び出すものをどのように構築するかを決定します。この投稿では、実際の制限の意味、1M トークンのコンテキストが 4M TPM バジェットをどのように消費するか、ヘッダーの読み取り方法、再試行パスの構築とテストの方法、3,000 RPM では不十分な場合の対処方法について説明します。API の基本については、Muse Wonder API ガイドから始めてください。

ボタン

制限

制限	値	範囲
1 分あたりのリクエスト数	3,000	チームごと、モデルごと
1 分あたりのトークン数	4,000,000	チームごと、モデルごと
バックグラウンド送信	毎分 600	チームごと、上記に加えて
コンテキストウィンドウ	1,048,576 トークン	リクエストごと
使用量レベル	公開なし
制限引き上げ	ドキュメント化されたプロセスなし

同じ 3,000 / 4M の数値は Muse Spark 1.3 にも適用されます。Spark の Contributor バリアントは、150 RPM と 3M TPM という低い上限に制限されています。各モデルには独自のプールがあるため、Wonder の大量トラフィックが Spark レーンを圧迫することはなく、その逆もありません。Meta の挿入されたステアリングコンテキストは TPM にカウントされず、usage にも表示されません。

リクエスト数よりも先にトークンが枯渇する

4M トークン/分の場合、エージェントにとってリクエスト制限が制約になることはまれです。3 つの例:

ワークロード	リクエストあたりのトークン数	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 個あり、毎分 1 回動作すると、チームの割り当ての 4 分の 3 を消費します。

数値から同時実行性を計画する

キャパシティの計算は 1 行です。同時エージェント数 × 1 ターンあたりトークン数 × 毎分ターン数を 4,000,000 未満に保つ必要があります。デプロイ前に最も負荷の高いレーンで計算してください。

エージェント	1 ターンあたりトークン数	各エージェントの毎分ターン数	必要な 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 分間の需要を倍増させ、チームの他のメンバーも同じプールから消費しています。3 行目は紙面上は問題なく見えても、2 つのエージェントが同時に再試行した初回に実際には失敗します。

2 つのレバーで式の左辺を縮小できます。コンパクションは、1 ターンあたりのトークン数を無制限に増やさないようにします。実行がしきい値を超えたら、コンテキストウィンドウの投稿で説明されているように、古いツール結果を要約または破棄してください。また、Responses API のステートレスな暗号化リプレイを使用すると、再送信する内容を正確に制御できます。previous_response_id を使ったサーバー管理履歴では、すべてが再送信されます。

すべてのキーで 1 つのプール

Meta はチームごとに制限をスコープします。ステージング用キー、本番用キー、チームメイトのノート PC 用キーはすべて同じ 3,000 / 4M から取り出されます。これには 2 つの帰結があります。

まず、1 人の開発者によるロードテストが本番をスロットルする可能性があります。実験を時間的に、または組織で許可されている場合は別チームで分離してください。次に、キーごとの監視では全体像はわかりません。すべての呼び出し元で x-ratelimit-* ヘッダーを集計しないと、制限よりかなり下に見えるキーで 429 が発生します。

ヘッダーを読む

トークンベースの応答には x-ratelimit-* ヘッダーが含まれます。すべての呼び出しでログに記録してください。重要なパターンは、1 分以内にすべての呼び出し元で残容量がゼロに向かう傾向です。これが 429 到着前に減速するシグナルです。文字起こし応答にはこれらのヘッダーがありませんが、Wonder の応答にはあります。

429 が到着したとき、Meta のドキュメントは明確です。約 500 ミリ秒から開始するジッター付き指数バックオフを行い、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")

3 つの設計ポイントがあります。バックオフに上限を設け、長い障害が 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 前のトークンバケットリミッターは、それぞれが推測する 6 つのサービスよりも優れたパフォーマンスを発揮します。

Apidog で制限処理をテストする

3,001 リクエストで再試行バグを発見しないでください。Apidog で:

MODEL_API_KEY を秘密変数として使用して Responses リクエストを作成し、x-ratelimit-* ヘッダーを環境変数に読み込む後処理を追加し、シナリオが残容量が下限を下回らないことをアサートできるようにします。
/v1/responses のモックを作成し、429 と Retry-After: 2 ヘッダーを返すモック期待値を、X-Test-Scenario: throttle のようなヘッダーを持つリクエストに対して設定します。クライアントをそのモックに向けて、少なくとも2秒待機し、次の試行で成功することを確認します。
パフォーマンステストを実行し、モックに対してリクエスト量を増やして、API がそうする前にリミッターが作動することを確認します。
Apidog CLI でシナリオを CI に組み込み、再試行コードへの変更が合格しない限りリリースできないようにします。

1 つのプロジェクトでモックとアサーションを設定するには、Apidog をダウンロードしてください。

よくある質問

Muse Wonder のレート制限はキーごとですか、アカウントごとですか? チームごとです。チーム内のすべてのキーが、モデルごとに 3,000 RPM / 4M TPM プールを 1 つ共有します。

キャッシュされた入力は TPM にカウントされますか? はい。キャッシングはそれらのトークンの価格を下げるものであり、毎分トークン制限に対する重みを下げるものではありません。

より高い制限をリクエストできますか? Meta の価格およびレート制限ページには、ティアもプロセスも記載されていません。変更についてはページを確認してください。フロンティアローンチは、数週間以内にティアを追加することがよくあります。

どのステータスコードとヘッダーが返されますか? HTTP 429、オプションで Retry-After、およびトークンベース応答では x-ratelimit-* ヘッダーです。

次のステップ

最も負荷の高いエージェントターンのリクエストあたりトークン数を測定し、同時実行数を掛けて、4,000,000 と比較してください。答えが近い場合は、チームがプールを本番と共有する前に、今週リミッターとモックテストを作成してください。