Muse Wonder速率限制解析：3000 RPM与400万TPM的团队共享池

Muse Wonder在Meta Model API上的速率限制是3000 RPM和400万TPM。这两个数字都以团队为单位、按模型计算，而不是按API密钥分配——组织内创建的每个密钥都从同一个池中取用。

这一设计决定了任何大规模调用 muse-wonder-1.0 的系统必须围绕团队级配额来架构，而非假设独立密钥意味着独立容量。

rss source: Batas laju Muse Wonder: 3.000 RPM dan 4M TPM, dibagikan ke seluruh tim

速率限制的具体数值与含义

限制项	数值	范围
每分钟请求数	3000	每团队、每模型
每分钟Token数	400万	每团队、每模型
后台提交	600/分钟	每团队，在主限制之外
上下文窗口	1,048,576 Token	每请求
使用层级	未公开	—
限制提升	无文档化流程	—

关键推论隐藏在Token预算与请求形态的交互中。当短对话轮次每次仅消耗约1300 Token时，RPM限制（3000）先于TPM限制（400万）触发；但一旦进入长上下文场景，局面完全逆转——400K上下文的智能体轮次每次消耗40万Token，每分钟只能发出10次请求，TPM成为绝对瓶颈。

请求形态	Token/请求	TPM限制下的最大RPM
短对话轮次	1,333	3,000
文档审阅	50,000	80
长智能体轮次（400K上下文）	400,000	10
全窗口请求	1,000,000	4

运行多个长上下文智能体的团队可能在仅十几次并发请求时就触及400万TPM上限。缓存输入仍然计入TPM——缓存是计费折扣，不是速率限制折扣。推理Token计入 max_output_tokens 和账单，输出Token同样计入TPM。

实际后果是：按上下文规模而非请求数量来预算TPM。每轮都重发30万Token对话的智能体，每次请求就是30万Token的消耗。

RPM（Requests Per Minute，每分钟请求数）与 TPM（Tokens Per Minute，每分钟Token数）是模型API限流的两个正交维度。RPM约束的是调用频次，与请求体大小无关；TPM约束的是单位时间内消耗的Token总量，无论这些Token来自输入还是输出。二者同时生效，任一先触顶即返回429。Token的统计单位通常沿用BPE（Byte Pair Encoding）分词后的数量，而不是字符数或单词数，因此同一段中文与英文文本的Token数并不等价。值得注意的是，推理模型产生的“思考Token”（reasoning tokens）也计入TPM与账单，即使它们不出现在最终回复中。理解这两个维度的独立性，是判断自己的负载究竟会先撞上哪一堵墙的前提。

多智能体并发下的TPM预算规划

智能体数	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%的剩余空间。智能体轮次具有突发性，临时错误后的重试风暴可能在一分钟内使请求量翻倍，而团队其他成员从同一池中取用。12个智能体、300K上下文、每分钟各1轮的行在纸面上看似安全（仅剩10%余量），但一旦两个智能体同时重试就会失败。

有两个杠杆可以缩小等式左侧。压缩机制防止每轮Token无限增长：当流程超过阈值后，摘要或丢弃旧工具结果。Responses API上的无状态加密重放允许精确控制重发内容，而使用 previous_response_id 的服务器托管历史则会重发全部内容。选择哪种方式直接决定TPM消耗速度。

所有密钥共享同一个配额池

Meta按团队设置限制。用于预发布的密钥、用于生产的密钥、同事笔记本电脑上的密钥，全部从同一个3000 RPM/400万TPM池中取用。这带来两个直接后果。

第一，单个开发者的负载测试可能限流生产环境。要么在时间上隔离实验，要么在组织允许的情况下使用独立团队。第二，按密钥监控无法呈现完整图景。需要在所有调用方聚合 x-ratelimit-* 头，否则会在看似远低于限制的密钥上看到429。

读取响应头与构建重试路径

基于Token的响应携带 x-ratelimit-* 头。关键模式是剩余容量在一分钟内跨所有调用方趋近于零——这是在429到来之前减速的信号。转录响应不携带这些头，Wonder响应携带。

429到达时，Meta文档的规定很具体：使用指数退避加抖动，起始约500ms；如果存在 Retry-After 头，至少等待该时长。忽略 Retry-After 并以固定间隔冲击API的重试循环会延长团队所有人的故障时间。

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")
            if retry_after:
                wait = float(retry_after)
            else:
                wait = delay + random.uniform(0, delay)
                delay = min(delay * 2, 30)
            time.sleep(wait)
    raise RuntimeError("rate limited after retries")

三个设计要点：限制指数退避上限，避免长时间故障演变为20分钟休眠；保持重试幂等——Responses调用在本地不产生任何东西时安全可重，但智能体工具调用若有副作用，应重试模型调用而非工具本身；在追踪中暴露重试，以便区分模型慢和模型被限流。

指数退避加抖动（Exponential Backoff with Jitter）是应对限流与瞬时故障的通用重试策略：每次失败后等待时间按倍数增长（如500ms、1s、2s、4s），上限封顶以防无限拉长；抖动指在计算出的等待时长上叠加一个随机量，避免多个客户端在同一时刻集体重试造成“重试风暴”。Retry-After 是HTTP标准响应头，服务器用它明确告知客户端应等待多少秒后再发起下一次请求，其优先级高于自行计算的退避值。重试幂等性则要求被重试的操作不产生重复副作用——纯模型调用天然可重，但涉及写文件、下单、发消息等工具调用时，应只重试模型决策环节而不要重复执行工具本身。

用后台响应处理长尾工作

长任务不必持有连接。background: true 将响应排队，返回 "status": "queued"，并允许轮询 GET /v1/responses/{id}?stream=true 获取生命周期事件。后台提交有独立的每分钟600次配额，在主限制之外，因此将批处理风格的工作迁移过去可以为交互流量释放RPM。

边界明确：POST时不支持 stream: true，请求体上限1 MiB，取消通过 POST /v1/responses/{id}/cancel 完成。

3000 RPM不够用时的选项

Meta没有公开层级阶梯或提额表单。当前的可行路径包括：

减少每请求Token。 Prompt缓存降低账单但不降低TPM；裁剪上下文则两者兼降。
分流到其他模型。 Spark 1.3拥有独立的3000 RPM/400万TPM池，价格仅为三分之一。不需要Wonder质量的工作可以路由过去。
使用网关。 Vercel AI Gateway和Cloudflare Workers AI提供 meta/muse-wonder-1.0。是否提供独立配额取决于网关的供应方式，依赖之前需与网关提供商确认。
排队与平滑。 了解整个团队预算的Token桶限流器放在API前面，远优于六个服务各自猜测。

Prompt缓存（Prompt Caching）是一种将请求中重复出现的固定前缀（如系统提示、长文档、few-shot示例）在服务端复用其计算结果、从而免去重复预填充的优化。它降低的是延迟和输入Token的计费价格，但被缓存命中的Token依然会占用TPM额度，因为限流器统计的是请求的逻辑Token量，而非实际执行的计算量。这也解释了为什么“缓存输入仍计入TPM”是一条容易踩坑的规则：团队常误以为开启缓存后限流压力会同步下降，实际上只是账单变便宜了。若目标是真正压低TPM占用，必须从请求体本身下手——裁剪历史、摘要旧轮次、或使用无状态重放只发送必要增量。

在Apidog中测试限流处理

不要在第一次达到第3001个请求时才发现重试代码的bug。在Apidog中：

构建Responses请求，将 MODEL_API_KEY 作为密钥变量，添加后处理器读取 x-ratelimit-* 头到环境变量。场景随后可以断言剩余容量从未低于阈值。
创建 /v1/responses 的mock，期望在请求携带 X-Test-Scenario: throttle 头时返回429和 Retry-After: 2 头。将客户端指向mock，断言它至少等待两秒并在下次尝试成功。
运行性能测试，对mock提升请求量，确认限流器在API之前生效。
通过Apidog CLI将场景纳入CI，使重试代码的改动无法不经通过就发布。

常见问题

Muse Wonder的速率限制是按密钥还是按账户？ 按团队。同一团队的所有密钥共享每个模型一个3000 RPM/400万TPM池。

缓存输入计入TPM吗？ 是。缓存降低这些Token的价格，但不降低它们对每分钟Token限制的权重。

可以申请更高限制吗？ Meta的定价和速率限制页面未列出层级或流程。定期检查页面以获取变化；前沿模型发布通常会在几周内添加层级。

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

下一步

测量最重智能体轮次的每请求Token数，乘以并发率，与400万对比。如果结果已接近上限，本周就构建限流器和mock测试——在全体团队与生产共享同一个池之前。