Muse Wonder速率限制解析：3000 RPM与400万TPM共享配额

Meta Model API的Muse Wonder存在一个容易被忽视的工程约束：速率限制按团队、按模型共享，而非按API密钥独立计算。团队内所有密钥——生产、预发、甚至同事笔记本上的测试密钥——都消耗同一个配额池。

Muse Wonder速率限制概览

速率限制的具体数值

Muse Wonder的官方限制如下：

限制项	数值	作用域
请求数/分钟	3,000	按团队、按模型
Token数/分钟	4,000,000	按团队、按模型
后台提交	600/分钟	按团队，在上述限制之外
上下文窗口	1,048,576 tokens	按请求

Muse Spark 1.3使用相同的3000 RPM和4M TPM数值，但Spark的Contributor变体限制更低，仅150 RPM和3M TPM。每个模型拥有独立配额池，因此Wonder的高流量不会挤占Spark的通道，反之亦然。Meta注入的指令上下文不计入TPM，也不出现在usage字段中。

TPM 与 RPM 的核算方式是理解后续所有容量推算的基础。RPM（Requests Per Minute）只统计到达 API 的请求次数，与请求体大小无关；TPM（Tokens Per Minute）则统计每个请求消耗的 Token 总量，由输入 Token 与输出 Token 相加得出。所谓输入 Token，既包括用户消息，也包括系统提示、工具定义、以及上文 Agent 轮次中回传的全部对话历史；输出 Token 则包括可见文本和推理（reasoning）Token。Meta 注入的指令上下文不计入 TPM，这意味着一部分固定开销被豁免，但用户可控的上下文仍全额计费。实践中，TPM 的消耗速率往往远高于 RPM，因为一次长上下文调用可能相当于几百次短对话，这也是为什么大上下文 Agent 场景下必须先按 TPM 而非请求数做容量规划。

Token比请求更快耗尽

在4M TPM的前提下，对于Agent类应用，请求数限制很少成为瓶颈。以下是四类代表性负载的对比：

负载类型	每请求Token数	触及TPM前的请求数/分钟
短对话轮次	3,000	1,333
文档审查	50,000	80
400K上下文的Agent长轮次	400,000	10
满载上下文请求	1,000,000	4

几个Agent应用在300K Token上下文下并发运行，仅需十余个并发请求就能触及4M TPM上限。需要特别注意：缓存命中的输入仍然计入TPM——缓存折扣降低的是账单费用，而非速率消耗。推理Token计入max_output_tokens和账单，输出Token同样消耗TPM。

工程上的直接推论是：按上下文规模而非请求数量来规划TPM预算。一个每轮都重发300K Token对话的Agent，每次调用都消耗300K Token。十个Agent每分钟各推进一次，就已经占用了团队四分之三的配额。

提示缓存（Prompt Caching） 是本节的隐含前提，值得单独说明其与速率限制的边界。缓存机制的工作原理是：当请求的系统提示或前缀与近期某次请求完全一致时，服务端复用已计算的中间状态，从而降低延迟并给予账单折扣。但需要澄清的是一个常见误区——缓存命中并不等于不消耗配额。Meta 的计量口径是，缓存命中的输入 Token 仍然全额计入 TPM，折扣只体现在最终费用上。换句话说，缓存是一种省钱手段，不是省配额手段。真正能同时降低账单与速率消耗的，只有减少每请求的上下文规模，例如摘要旧对话、丢弃过期的工具结果，或改用无状态加密回放来精确控制重发内容。因此，在规划 TPM 预算时，不能把缓存命中率当作可抵扣的余量。

并发容量计算

容量估算可以浓缩为一个公式：

并发Agent数 × 每轮Token数 × 每分钟轮次数 < 4,000,000

以下是几组典型配置的余量分析：

Agent数	每轮Token	各自每分钟轮次	所需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%的余量。Agent轮次本身不均匀，瞬时错误后的重试风暴可能在一分钟内将需求翻倍，而且团队中任何其他人都在消耗同一个配额池。第三行看似可行，但当两个Agent同时重试时就会失败。

压缩策略可以控制每轮Token的增长：当运行超过阈值时，摘要或丢弃旧的工具结果。Responses API中的无状态加密回放允许精确控制重发内容，而通过previous_response_id的服务器端托管历史则会重发全部内容。

单配额池的隐性风险

Meta按团队定义限制，这意味着两个容易被忽视的后果。

其一，开发者的负载测试可能拖垮生产环境。应将实验在时间上隔离，或者在组织允许的情况下使用独立团队。其二，按密钥监控无法反映全局。必须在每个调用方收集x-ratelimit-*响应头并汇总，否则你会在某个看似远低于个体限制的密钥上收到429错误。

响应头读取与重试策略

基于Token的响应会返回x-ratelimit-*响应头，应在每次调用时记录。关键模式是：所有调用方的剩余容量在同一分钟内趋近于零——这是429到来前主动降速的信号。转录响应不包含这些响应头，但Wonder的响应包含。

收到429时，Meta的文档给出了明确指引：从约500ms开始实施带随机抖动的指数退避，如果存在Retry-After响应头，至少等待该时长。忽略Retry-After或使用固定间隔的重试循环，会为整个团队延长中断时间。

以下Python重试代码体现了三个关键设计决策：

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 _ 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 error:
            retry_after = error.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")

三个设计要点：退避时间需要设置上限，避免长时间中断演变为20分钟的暂停；重试保持幂等，Responses调用本身安全可重试，但如果Agent工具存在副作用，应重试模型调用而非工具调用；在追踪中记录重试事件，以区分模型响应慢与限流导致的延迟。

指数退避与随机抖动（Exponential Backoff with Jitter） 是限流场景下最通用的重试模式，其核心在于两点。第一，退避时间随失败次数指数增长（如 0.5s、1s、2s、4s…），避免在服务端已经过载时继续以固定频率冲击，从而给配额池恢复留出空间。第二，在每次退避值上叠加一个随机量（抖动），使同一团队内多个并发调用方的重试时刻彼此错开。如果没有抖动，多个 Agent 可能在同一毫秒同步重试，形成新的尖峰，反而延长限流的持续时间。Retry-After 响应头是服务端给出的权威等待时长，优先级高于本地计算的退避值；忽略它或使用更短的固定间隔，等于主动对抗服务端的容量缓冲。将退避上限设为 30 秒左右，可以避免单次限流演变为长达数分钟乃至 20 分钟的服务不可用。

后台响应处理长任务队列

长时间任务无需保持连接打开。设置background: true后，响应进入队列，调用返回"status": "queued"，可通过GET /v1/responses/{id}?stream=true接收生命周期事件。

后台提交拥有独立的600次/分钟配额，在主限制之外。将批处理任务迁移到该通道可以为交互式流量释放RPM。需要注意的限制：POST请求中不能使用stream: true；请求体上限为1 MiB；取消操作为POST /v1/responses/{id}/cancel。

后台响应（Background Responses） 的机制本质上是将同步的请求/响应模式转换为异步的任务队列模式。常规调用需要保持 HTTP 连接打开直到模型生成完毕，而设置 background: true 后，POST 请求立即返回一个处于 "status": "queued" 状态的响应对象，真正的推理在服务端独立推进。客户端随后通过 GET /v1/responses/{id}?stream=true 订阅生命周期事件，按需获取完成结果。这种模式的价值在于解耦了提交与等待：批处理任务可以一次性投递大量任务而不占用交互式连接的并发额度，同时独立于主配额的 600 次/分钟后台通道也释放了 RPM 压力。约束方面，后台提交不能携带 stream: true，请求体限制为 1 MiB，取消操作通过 POST /v1/responses/{id}/cancel 完成。

3000 RPM不够用时的应对

Meta未公布分级方案，也没有文档化的提额流程。当前可用的选项包括：

压缩每请求Token数。 提示缓存降低账单但不降低TPM。缩减上下文则两者兼降。

跨模型分流。 Spark 1.3拥有独立的3000 RPM和4M TPM配额池，价格仅为三分之一。不需要Wonder质量的任务可以路由过去。

使用网关。 Vercel AI Gateway和Cloudflare Workers AI都提供meta/muse-wonder-1.0。是否能获得独立配额取决于网关的配置方式，需要自行验证。

对于测试环节，可以在Apidog中构建Responses请求，添加后处理器读取x-ratelimit-*响应头并存入环境变量，使测试场景能够断言剩余容量不低于阈值。创建一个模拟/v1/responses的桩服务，在请求包含特定标记时返回429和Retry-After: 2响应头，然后将该值乘以预期并发数并与4,000,000对比。如果结果接近上限，应在团队与生产环境共享配额池之前完成限流器实现和模拟测试。