Muse Wonder 速率限制：3,000 RPM、4M TPM，由整个团队共享

Meta Model API 上 Muse Wonder 的速率限制为每分钟 3,000 个请求、每分钟 4,000,000 个 Token。两者都按模型、按团队生效，而不是按 API key：你的组织创建的每个 key 都从同一个池子里取用。后台响应另有单独额度，每分钟 600 个新提交。官方没有公布任何用量档位，也没有文档化的提额申请途径。超限时会返回 HTTP 429，Meta 的建议是从约 500 ms 起做带抖动的指数退避，并在存在 Retry-After 时遵循它。

这四个事实决定了你如何架构任何大规模调用 muse-wonder-1.0 的系统。本文讲这些限制在实际中意味着什么，100 万 Token 的上下文如何吃掉 400 万 TPM 的预算，如何读取响应头，如何构建并测试重试路径，以及 3,000 RPM 不够用时该怎么办。想了解 API 基础，请先看 Muse Wonder API 指南。

AI Coding 交流群

如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。

各项限制

Muse Spark 1.3 适用同样的 3,000 / 4M 数值；Spark 的 Contributor 版本上限更低，为 150 RPM 和 3M TPM。每个模型都有各自的池子，因此 Wonder 的高负载不会挤占 Spark 通道，反之亦然。Meta 注入的引导上下文不计入 TPM，也不会出现在 usage 中。

Token 会先于请求数耗尽

在每分钟 400 万 Token 的前提下，请求数限制对 Agent 而言很少成为瓶颈。举三个例子：

一个团队只跑几个大上下文 Agent，十几路并发请求就可能撞上 4M TPM。缓存输入仍计入 TPM；缓存折扣是计费折扣，不是速率限制折扣。推理 Token 计入你的 max_output_tokens 和账单，输出 Token 同样计入 TPM。

实际后果是：按上下文大小而非请求数来规划 TPM。一个每轮都重发 300K Token 对话的 Agent，每次请求就是 300K Token；十个这样的 Agent 每分钟走一步，就会吃掉团队配额的四分之三。

用这些数字规划并发

容量算法就一行：并发 Agent 数 × 每轮 Token 数 × 每分钟轮数，必须保持在 4,000,000 以下。部署前先为你最重的通道算一遍。

至少留出 40% 的余量。Agent 轮次是突发式的，一次瞬时错误后的重试风暴会让某一分钟的需求翻倍，而且团队里其他人也在用同一个池子。第三行纸面上看着没问题，但一旦两个 Agent 同时重试，实践中就会崩。

有两个杠杆可以缩小等式的左边。压缩（compaction）防止每轮 Token 数无限增长：一次运行超过阈值后，就总结或丢弃旧的工具结果，上下文窗口那篇文章有讲。而 Responses API 上无状态的加密重放让你能精确控制重发的内容，相比之下，使用 previous_response_id 的服务端管理历史会重发全部内容。

所有 key 共用一个池子

Meta 按团队划分限制范围。用于预发布环境的 key、用于生产的 key，以及同事笔记本上的 key，都从同样的 3,000 / 4M 里取用。这带来两个后果。

第一，某个开发跑一次压测就可能拖慢生产环境。把实验按时间隔离，或者如果组织允许，放到单独的团队里。第二，按 key 的监控看不到全貌。要汇总所有调用方的 x-ratelimit-* 响应头，否则你会看到一个看似远低于限制的 key 却在报 429。

读取响应头

基于 Token 的响应会带上 x-ratelimit-* 响应头。每次调用都要记录它们。真正要关注的模式是：一分钟内所有调用方的剩余容量都趋向于零，这就是在 429 到来之前减速的信号。转录（transcription）响应不带这些响应头；Wonder 的响应带。

当 429 真的到来时，Meta 的文档说得很具体：从约 500 ms 起做带抖动的指数退避；如果存在 Retry-After，至少等待那么久。一个忽略 Retry-After、以固定间隔猛冲的重试循环，会让团队里每个人遭遇的故障都更久。

构建重试路径

import random, 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 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")

三个设计要点。给退避设上限，别让一次长时间故障变成 20 分钟的睡眠。保持重试幂等：一个不会在你这边产生任何副作用的 Responses 调用可以安全重复，但如果你 Agent 的工具调用带副作用，要重试的是模型调用，而不是工具调用。把重试暴露在 trace 里，这样你就能区分是模型慢还是被限流；工具调用追踪指南讲了该记录什么。

用后台响应处理长尾请求

长任务不必一直占着连接。background: true 会把响应排队，返回 "status": "queued"，并让你轮询 GET /v1/responses/{id}?stream=true 获取生命周期事件。后台提交在主限制之外还有自己每分钟 600 的额度，因此把批处理类工作挪过去，就能为交互式流量腾出 RPM。限制条件：POST 上不带 stream: true，body 上限 1 MiB，用 POST /v1/responses/{id}/cancel 取消。

当 3,000 RPM 不够用时

Meta 没有公布任何档位阶梯，也没有提额表单。目前你的选择：

• 减少每次请求的 Token 数。 prompt 缓存能降低账单，但不降低 TPM；裁剪上下文则两者都能降。上下文窗口那篇文章讲了如何裁剪工具结果。
• 分散到多个模型。 Spark 1.3 有自己的 3,000 / 4M 池子，价格只有三分之一。把不需要 Wonder 质量的工作路由过去。
• 使用网关。 Vercel AI Gateway 和 Cloudflare Workers AI 都提供 meta/muse-wonder-1.0。至于这样是否能给你单独的额度，取决于网关是如何开通的；在依赖它之前先向对方确认。
• 排队并平滑。 在 API 前面放一个了解团队整体预算的令牌桶限流器，效果会好过六个服务各自瞎猜。

在 Apifox 中测试限流处理

别等到第 3,001 个请求才发现重试的 bug。在 Apifox 中：

1. 用 MODEL_API_KEY 作为密钥变量构建 Responses 请求，并加一个后置操作，把 x-ratelimit-* 响应头读进环境变量，这样测试场景就能断言剩余容量从不低于某个下限。
2. 为 /v1/responses 创建一个 mock，mock 期望返回 429 和 Retry-After: 2 响应头，触发条件是请求带上诸如 X-Test-Scenario: throttle 这样的 header。把客户端指向这个 mock，并断言它至少等待两秒、并在下一次尝试时成功。
3. 跑一个性能测试，逐步加大打到 mock 上的请求量，以确认你的限流器会在 API 之前触发。
4. 用 Apifox CLI 把该测试场景放进 CI，这样重试代码的改动不通过它就发不出去。

下载 Apifox，在一个项目里把 mock 和断言都搭好。

常见问题

Muse Wonder 的速率限制是按 key 还是按账号？按团队。一个团队里的所有 key 共用每个模型一个的 3,000 RPM / 4M TPM 池。

缓存输入计入 TPM 吗？计入。缓存降低的是这些 Token 的价格，而不是它们在每分钟 Token 限制中的分量。

我能申请更高的限制吗？Meta 的定价与速率限制页面没有列出任何档位，也没有相关流程。留意该页面的变动；前沿模型发布后往往几周内就会加档位。

我会收到什么状态码和响应头？HTTP 429，可能带上 Retry-After，在基于 Token 的响应上还会带上 x-ratelimit-* 响应头。

下一步

测量你最重的 Agent 轮次每次请求的 Token 数，乘以并发数，再与 4,000,000 比较。如果结果很接近，这周就把限流器和 mock 测试搭起来，赶在团队把池子和生产环境共享之前。

HiFox ：将 Agent 变成真正的队友

另外，我们也在思考，AI 如何从个人提效走进团队协作。

HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台：你可以像给同事分派任务一样指派 Agent，在任务看板中跟踪进度、查看结果，让 Agent 成为团队里的队友。

👉 立即体验 Hifox：https://hifox.com

AI Coding 交流群

如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。