Muse Wonder速率限制详解：3000 RPM与400万TPM如何团队共享

Muse Wonder API速率限制的核心机制

Meta Model API为Muse Wonder模型设定的速率限制是每分钟3000次请求（RPM）和每分钟400万Token（TPM）。这两个限制按模型、按团队生效，而非按API密钥分配——组织内任何一个密钥发起的调用都会消耗同一个配额池。

后台响应享有额外的配额：每分钟600次新提交，独立于主限制之外。目前Meta未公布任何使用层级（usage tiers），也没有文档化的限额提升流程。一旦超限，API返回HTTP 429状态码，Meta建议采用带抖动的指数退避策略，初始延迟约500毫秒，并留意响应中的Retry-After头部。

Muse Wonder速率限制

同一组限制（3000 RPM / 4M TPM）也适用于Muse Spark 1.3。Spark的Contributor变体则限制在150 RPM和300万TPM。每个模型拥有独立配额池，因此Wonder流量激增不会饿死Spark通道，反之亦然。Meta注入的控制上下文不计入TPM，也不会出现在usage字段中。

Token比请求更早触顶

在每分钟400万Token的预算下，请求数限制对Agent场景而言很少是最紧的瓶颈。实际能发起的请求数直接取决于上下文大小：

工作负载	每请求Token数	TPM成为瓶颈前的RPM
短对话轮次	3000	1333
文档审查	50000	80
长Agent轮次（400K上下文）	400000	10
满窗口请求	1000000	4

一个团队运行多个大上下文Agent时，仅需十几路并发请求就能触及400万TPM。缓存输入仍然计入TPM——缓存折扣是计费优惠，不是速率限制优惠。推理Token计入max_output_tokens和账单，输出Token同样消耗TPM。

因此，TPM预算应按上下文大小分配，而非请求数量。一个每轮都重新发送30万Token对话的Agent，每次都会产生30万Token的请求。十个这样的Agent每分钟各执行一次，就会消耗团队配额的75%。

用数学规划并发量

容量计算公式很紧凑：

并发Agent数 × 每轮Token数 × 每分钟轮数 < 4000000

在部署最强流水线之前，先计算这个值：

Agent数	每轮Token	各Agent每分钟轮数	所需TPM	余量
4	150000	2	1200000	70%
8	250000	1	2000000	50%
12	300000	1	3600000	10%
20	300000	1	6000000	超限

规划时至少留出40%的余量。Agent工作往往呈突发性，暂时性错误后的重试风暴可能让一分钟内的需求翻倍，而且团队中其他人共享同一个配额池。表中第三行纸面上安全，但实践中当两个Agent同时首次执行时就会失败。

两个杠杆可以降低需求：

上下文压缩：防止每轮Token需求无限增长。当运行超过阈值时，总结或丢弃旧的工具调用结果。
无状态加密重放：Responses API允许你精确控制重新发送的内容。而配合previous_response_id的服务端管理历史则会重新发送全部内容。

所有密钥共享一个配额池

Meta按团队限制用量。一个用于预发布环境的密钥、一个用于生产的密钥、同事笔记本电脑上的密钥，全部访问同样的3000 RPM和400万TPM。

由此产生两条规则：

开发人员的压力测试可能拖慢生产环境。在时间上隔离实验，或在组织允许的情况下使用独立团队。
按密钥监控看不到全貌。需要在所有调用方之间聚合x-ratelimit-*头部，否则你可能在某个看似远低于限制的密钥上看到429错误。

读取速率限制头部

基于Token的响应会携带x-ratelimit-*头部。在每次调用时记录它们。关键模式是：剩余容量在一分钟内跨所有调用方趋近于零。这就是在下一个429到来之前减速的信号。转录响应不携带这些头部；Wonder的响应携带。

遇到429时，Meta的建议很具体：使用带抖动的指数退避，初始约500毫秒，如果存在Retry-After头部，至少等待其中指定的时间。忽略Retry-After并以固定间隔持续请求的重试循环，会延长整个团队的限流时间。

构建重试路径

一个健壮的重试路径需组合Retry-After、指数退避、抖动和等待时间上限：

import os
import random
import time

from openai import OpenAI, RateLimitError

client = OpenAI(
    base_url="https://api.meta.ai/v1",
    api_key=os.environ["MODEL_API_KEY"],
)

def call(input_text, attempts=6):
    delay = 0.5
    for attempt in range(attempts):
        try:
            return client.responses.create(
                model="muse-wonder-1.0",
                input=input_text,
            )
        except RateLimitError as e:
            retry_after = e.response.headers.get("retry-after")
            if retry_after:
                wait = float(retry_after)
            else:
                wait = delay + random.uniform(0, delay)
            time.sleep(wait)
            delay = min(delay * 2, 30)
    raise RuntimeError("rate limited after retries")

三个关键设计点：限制退避上限，防止长时间中断导致等待时间失控；区分慢模型与限流状态，在追踪中记录429发生时间；工具调用追踪应记录足够信息以便调试。

长时间任务使用后台响应

长时间运行的任务无需保持连接。设置background: true会将响应放入队列，并允许通过GET /v1/responses/{id}?stream=true轮询生命周期事件。

后台提交在主限制之外拥有每分钟600次的独立配额。因此将批处理工作迁移到后台可以释放交互流量的RPM。

注意以下限制：

POST时不允许stream: true
请求体限制为1 MiB
通过POST /v1/responses/{id}/cancel取消

当3000 RPM不够用时

Meta目前未公布层级和限额提升表单。当前可选的策略：

减少每请求Token数。 Prompt缓存降低账单，但不降低TPM。裁剪上下文两者都降。
跨模型分配工作。 Muse Spark 1.3拥有独立的3000/4M配额池，价格仅为三分之一。将不需要Wonder质量的工作导流过去。
使用网关。 Vercel AI Gateway和Cloudflare Workers AI提供meta/muse-wonder-1.0服务。是否获得独立配额取决于网关的部署方式。

不要等到第3001次请求才发现重试错误。在Apidog中可以：

创建Responses请求，将MODEL_API_KEY设为密钥变量，添加后处理器将x-ratelimit-*头部存入环境变量。
为/v1/responses创建Mock，当请求包含特定头部时返回HTTP 429和Retry-After: 2，验证客户端至少等待2秒并在下次尝试时成功。
运行性能测试，对Mock增加请求量，确认限流器在真实API限流之前触发。

常见问题

Muse Wonder的速率限制是按密钥还是按账户？

按团队。团队内所有密钥共享每个模型的3000 RPM和400万TPM配额池。

缓存输入计入TPM吗？

计入。缓存降低了这些Token的价格，但不改变它们相对于Token分钟限制的权重。

可以申请更高限额吗？

Meta的定价和速率限制页面目前未列出层级和流程。关注该页面变化；新模型通常在几周内补充使用层级。

超限时返回什么状态码和头部？

HTTP 429，可选携带Retry-After，以及基于Token响应上的x-ratelimit-*头部。

下一步

测量你最强Agent轮次的每请求Token数，乘以并发量，将结果与4000000比较。如果接近这个值，本周就创建限流器和Mock测试，趁团队尚未与生产共享同一配额池。