Limites de débit de Muse Wonder : 3 000 RPM et 4 M TPM, partagées par toute l’équipe

Les limites de débit de Muse Wonder sur l'API Meta Model sont de 3 000 requêtes par minute et de 4 000 000 de jetons par minute. Les deux s’appliquent par modèle et par équipe, et non par clé API : chaque clé créée par votre organisation puise dans le même pool. Les réponses en arrière-plan bénéficient d'une allocation distincte de 600 nouvelles soumissions par minute. Il n’existe aucun niveau d’utilisation publié ni aucun moyen documenté d’en demander davantage. Lorsque vous dépassez une limite, vous recevez HTTP 429, et la recommandation de Meta est un backoff exponentiel avec gigue commençant autour de 500 ms, en respectant Retry-After lorsqu’il est présent.

Ces quatre faits déterminent comment vous architectez tout ce qui appelle muse-wonder-1.0 à grande échelle. Cet article couvre ce que les limites signifient en pratique, comment un contexte de 1 M de jetons consomme un budget de 4 M TPM, comment lire les en-têtes, comment construire et tester le chemin de nouvelle tentative et quoi faire lorsque 3 000 RPM ne suffisent pas. Pour les bases de l’API, commencez par le guide de l'API Muse Wonder.

Les limites

Les mêmes chiffres de 3 000/4 M s’appliquent à Muse Spark 1.3 ; la variante Contributor de Spark est plafonnée à 150 RPM et 3M TPM. Chaque modèle possède son propre pool, afin que le trafic intense des Wonder ne prive pas une voie Spark et vice versa. Le contexte de pilotage injecté par Meta n’est pas pris en compte dans le TPM et n’apparaît pas dans usage.

Les jetons sont épuisés avant les demandes

Avec 4 M de jetons par minute, la limite de requêtes est rarement celle qui contraint un agent. Trois illustrations :

Une équipe qui exécute quelques agents avec de grands contextes peut atteindre 4 M TPM avec une douzaine de requêtes simultanées. L’entrée mise en cache compte toujours pour le TPM ; la remise de cache est une remise de facturation, pas une remise de limite de débit. Les jetons de raisonnement comptent dans votre max_output_tokens et votre facture, et les jetons de sortie comptent aussi pour le TPM.

La conséquence pratique : budgétez le TPM par taille de contexte, pas par nombre de requêtes. Un agent qui renvoie une conversation de 300K jetons à chaque tour est une requête de 300K jetons chaque fois, et dix tels agents agissant une fois par minute consomment les trois quarts de l'allocation de l'équipe.

Planifier la simultanéité à partir des chiffres

Le calcul de capacité tient en une ligne : agents simultanés, fois jetons par tour, fois tours par minute, doit rester sous 4 000 000. Faites le calcul pour votre voie la plus chargée avant de déployer.

Laissez au moins 40 % de marge. Les tours d'agent sont rafales, une tempête de nouvelles tentatives après une erreur passagère double la demande pendant une minute, et tous les autres membres de l'équipe puisent dans le même pool. La troisième ligne semble correcte sur le papier et échoue en pratique la première fois que deux agents réessayent en même temps.

Deux leviers réduisent le côté gauche de l'équation. La compactation empêche les jetons par tour de croître sans limite : résumez ou supprimez les anciens résultats d'outils lorsqu'une exécution dépasse un seuil, comme le décrit l'article de fenêtre de contexte. Et la relecture chiffrée sans état sur l'API Responses vous permet de contrôler exactement ce que vous renvoyez, où l'historique géré par le serveur avec previous_response_id renvoie tout.

Un pool commun pour toutes les clés

Meta limite les limites par équipe. Une clé pour le staging, une clé pour la production et une clé pour l'ordinateur portable d'un coéquipier puisent toutes dans le même 3 000/4 M. Cela a deux conséquences.

Premièrement, un test de charge d'un développeur peut limiter la production. Isolez les expériences dans le temps, ou dans une équipe distincte si votre organisation le permet. Deuxièmement, la surveillance par clé ne vous montrera pas l'ensemble du tableau. Agrégez les en-têtes x-ratelimit-* sur chaque appelant, sinon vous verrez des 429 sur une clé qui semble être bien en dessous de sa limite.

Lire les en-têtes

Les réponses basées sur les jetons comportent des en-têtes x-ratelimit-*. Journalisez-les à chaque appel. Le schéma qui compte est la capacité restante tendant vers zéro sur tous les appelants en une minute, votre signal pour ralentir avant l'arrivée du 429. Les réponses de transcription ne comportent pas ces en-têtes ; celles de Wonder oui.

Quand un 429 arrive, les documents de Meta sont précis : reculez exponentiellement avec gigue commençant autour de 500 ms, et si Retry-After est présent, attendez au moins ce délai. Une boucle de nouvelle tentative qui ignore Retry-After et martèle à intervalle fixe rend la panne plus longue pour tous les membres de votre équipe.

Construire le chemin de nouvelle tentative

import random, time
from openai import OpenAI, RateLimitError

client = OpenAI(base_url="https://api.meta.ai/v1", [REDACTED CREDENTIAL]"])

def 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")

Trois points de conception. Plafonnez le backoff pour qu'une panne longue ne devienne pas un sommeil de 20 minutes. Gardez les nouvelles tentatives idempotentes : un appel Responses qui ne crée rien de votre côté peut être répété en toute sécurité, mais si les appels d'outils de votre agent ont des effets secondaires, réessayez l'appel du modèle, pas l'outil. Et affichez les nouvelles tentatives dans vos traces pour distinguer un modèle lent d'un modèle limité ; le guide de traçage des appels d'outils couvre ce qu'il faut journaliser.

Utilisez les réponses en arrière-plan pour la longue traîne

Les tâches longues n'ont pas besoin de maintenir une connexion. background: true met la réponse en file d'attente, renvoie "status": "queued" et vous permet d'interroger GET /v1/responses/{id}?stream=true pour les événements du cycle de vie. Les soumissions en arrière-plan disposent de leur propre allocation de 600 par minute en plus des limites principales, donc déplacer le travail par lots là libère du RPM pour le trafic interactif. Contraintes : pas de stream: true sur le POST, une limite de corps de 1 MiB et vous annulez avec POST /v1/responses/{id}/cancel.

Quand 3 000 RPM ne suffisent pas

Meta ne publie ni échelle de niveaux ni formulaire pour augmenter les limites. Vos options aujourd'hui :

• Réduire les jetons par requête. Le cache de prompt réduit votre facture mais pas votre TPM ; réduire le contexte fait les deux. L'article de fenêtre de contexte couvre la réduction des résultats d'outils.
• Répartir sur les modèles. Spark 1.3 possède son propre pool de 3 000/4 M au tiers du prix. Dirigez-y le travail qui n'a pas besoin de la qualité de Wonder.
• Utiliser une passerelle. Vercel AI Gateway et Cloudflare Workers AI servent meta/muse-wonder-1.0. Si cela vous donne une allocation distincte dépend de la façon dont la passerelle est provisionnée ; vérifiez auprès d'eux avant de vous y fier.
• File d'attente et lissage. Un limiteur à seau de jetons devant l'API connaissant tout le budget de l'équipe surpasse six services devinant chacun.

Tester la gestion des limites dans Apidog

1. Construisez la requête Responses avec MODEL_API_KEY comme variable secrète et ajoutez un post-processeur qui lit les en-têtes x-ratelimit-* dans des variables d'environnement pour qu'un scénario puisse affirmer que la capacité restante ne descende jamais sous un plancher.
2. Créez un mock de /v1/responses avec une expectation mock qui renvoie 429 et un en-tête Retry-After: 2 lorsqu'une requête porte un en-tête tel que X-Test-Scenario: throttle. Pointez votre client vers le mock et affirmez qu'il attend au moins deux secondes et réussit à la tentative suivante.
3. Exécutez un test de performance qui augmente le volume de requêtes contre le mock pour confirmer que votre limiteur s'active avant que l'API ne le fasse.
4. Mettez le scénario dans CI avec l'interface en ligne de commande Apidog pour qu'une modification du code de nouvelle tentative ne puisse pas être livrée sans réussir.

Téléchargez Apidog pour configurer le mock et les assertions dans un seul projet.

Questions fréquemment posées

Les limites de débit de Muse Wonder sont-elles par clé ou par compte ? Par équipe. Toutes les clés d’une équipe partagent un pool TPM de 3 000 RPM/4 M par modèle.

L’entrée mise en cache compte-t-elle pour le TPM ? Oui. Le cache réduit le prix de ces jetons, pas leur poids face à la limite de jetons par minute.

Puis-je demander une limite plus élevée ? La page tarifs et limites de débit de Meta ne liste ni niveaux ni processus. Vérifiez la page pour les changements ; les lancements de frontière ajoutent souvent des niveaux en quelques semaines.

Quel code d'état et quels en-têtes reçois-je ? HTTP 429, éventuellement avec Retry-After, plus les en-têtes x-ratelimit-* sur les réponses basées sur les jetons.

Étape suivante

Mesurez les jetons par requête du tour d'agent le plus lourd, multipliez par la simultanéité et comparez à 4 000 000. Si la réponse est proche, construisez le limiteur et le test mock cette semaine, avant que l'équipe ne partage le pool avec la production.