Giới hạn tốc độ của Muse Wonder trên Meta Model API là 3.000 yêu cầu mỗi phút và 4.000.000 token mỗi phút. Cả hai áp dụng cho mỗi mô hình và mỗi nhóm, không phải cho mỗi khóa API: mọi khóa tổ chức của bạn tạo ra đều lấy từ cùng một nhóm. Các phản hồi nền trước nhận được phụ cấp riêng là 600 lượt gửi mới mỗi phút. Không có bậc sử dụng nào được công bố và không có cách thức tài liệu hóa nào để yêu cầu thêm. Khi bạn vượt quá giới hạn, bạn nhận được HTTP 429 và hướng dẫn của Meta là lùi lại theo cấp số nhân với jitter bắt đầu khoảng 500 ms, tuân thủ Retry-After khi có.
Bốn sự thật này quyết định cách bạn kiến trúc bất kỳ thứ gì gọi muse-wonder-1.0 ở quy mô lớn. Bài đăng này đề cập đến ý nghĩa thực tế của các giới hạn, cách ngữ cảnh 1M token tiêu thụ ngân sách 4M TPM, cách đọc tiêu đề, cách xây dựng và kiểm thử đường dẫn thử lại cũng như cần làm gì khi 3.000 RPM là chưa đủ. Để nắm cơ bản về API, hãy bắt đầu với hướng dẫn API Muse Wonder.
Giới hạn
| Giới hạn | Giá trị | Phạm vi |
|---|---|---|
| Yêu cầu mỗi phút | 3,000 | Theo nhóm, theo mô hình |
| Token mỗi phút | 4,000,000 | Theo nhóm, theo mô hình |
| Lượt gửi nền | 600 mỗi phút | Theo nhóm, cộng thêm phần trên |
| Cửa sổ ngữ cảnh | 1,048,576 token | Theo yêu cầu |
| Bậc sử dụng | Không công bố | |
| Tăng giới hạn | Không có quy trình tài liệu hóa |
Các con số 3.000/4M giống nhau áp dụng cho Muse Spark 1.3; biến thể Contributor của Spark bị giới hạn thấp hơn ở 150 RPM và 3M TPM. Mỗi mô hình có nhóm riêng, vì vậy lượng truy cập Wonder lớn không làm cạn kiệt làn Spark và ngược lại. Ngữ cảnh điều hướng được chèn của Meta không được tính vào TPM và không xuất hiện trong usage.
Mã thông báo hết trước khi có yêu cầu
Với 4M token mỗi phút, giới hạn yêu cầu hiếm khi là giới hạn ràng buộc đối với một agent. Ba ví dụ minh họa:
| Khối lượng công việc | Token mỗi yêu cầu | Yêu cầu mỗi phút trước khi TPM ràng buộc |
|---|---|---|
| Lượt chat ngắn | 3,000 | 1,333 |
| Xem xét tài liệu | 50,000 | 80 |
| Lượt agent dài, ngữ cảnh 400K | 400,000 | 10 |
| Yêu cầu toàn cửa sổ | 1,000,000 | 4 |
Một nhóm chạy một vài agent với ngữ cảnh lớn có thể đạt 4M TPM bằng một dozen yêu cầu đồng thời. Đầu vào đã cache vẫn tính vào TPM; ưu đãi cache là ưu đãi thanh toán, không phải ưu đãi giới hạn tốc độ. Token suy luận tính vào max_output_tokens và hóa đơn của bạn, và token đầu ra cũng tính vào TPM.
Hệ quả thực tế: lập ngân sách TPM theo kích thước ngữ cảnh, không phải theo số lượng yêu cầu. Một agent gửi lại hội thoại 300K token mỗi lượt là một yêu cầu 300K token mỗi lần, và mười agent như vậy bước một lần mỗi phút tiêu thụ ba phần tư hạn mức của nhóm.
Lập kế hoạch đồng thời từ các con số
Toán học dung lượng là một dòng: agent đồng thời, nhân token mỗi lượt, nhân lượt mỗi phút, phải duy trì dưới 4.000.000. Hãy tính cho làn nặng nhất của bạn trước khi triển khai.
| Agent | Token mỗi lượt | Lượt mỗi phút mỗi agent | TPM cần | Dư địa |
|---|---|---|---|---|
| 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 | vượt giới hạn |
Chừa ít nhất 40% dư địa. Các lượt agent mang tính bùng phát, cơn bão thử lại sau lỗi tạm thời làm đôi nhu cầu trong một phút và bất kỳ ai khác trong nhóm cũng lấy từ cùng nhóm. Hàng thứ ba trông ổn trên giấy nhưng thất bại trong thực tế lần đầu hai agent thử lại cùng lúc.
Hai đòn bẩy thu nhỏ vế trái của phương trình. Nén giữ token mỗi lượt không tăng không giới hạn: tóm tắt hoặc bỏ kết quả công cụ cũ khi một lần chạy vượt ngưỡng, như bài đăng cửa sổ ngữ cảnh mô tả. Và phát lại có mã hóa không trạng thái trên Responses API cho phép bạn kiểm soát chính xác nội dung gửi lại, trong khi lịch sử do máy chủ quản lý với previous_response_id gửi lại mọi thứ.
Một nhóm chung cho mọi khóa
Meta xác định giới hạn theo nhóm. Một khóa cho staging, một khóa cho production và một khóa cho máy tính của đồng nghiệp đều lấy từ cùng 3.000/4M. Điều này có hai hệ quả.
Thứ nhất, bài kiểm tra tải từ một nhà phát triển có thể điều tiết production. Cô lập các thử nghiệm kịp thời, hoặc trong một nhóm riêng nếu tổ chức của bạn cho phép. Thứ hai, giám sát theo khóa sẽ không cho bạn thấy toàn bộ bức tranh. Tổng hợp các tiêu đề x-ratelimit-* trên mọi caller, nếu không bạn sẽ thấy 429 trên một khóa có vẻ thấp hơn nhiều so với giới hạn của nó.
Đọc tiêu đề
Phản hồi dựa trên token mang các tiêu đề x-ratelimit-*. Ghi lại chúng trên mọi cuộc gọi. Mẫu quan trọng là dung lượng còn lại xu hướng về không trên mọi caller trong một phút, đây là tín hiệu để bạn giảm tốc trước khi 429 đến. Phản hồi chuyển ngữ không mang các tiêu đề này; phản hồi của Wonder thì có.
Khi 429 đến, tài liệu của Meta rất cụ thể: lùi lại theo cấp số nhân với jitter bắt đầu khoảng 500 mili giây và nếu có Retry-After, hãy đợi ít nhất khoảng thời gian đó. Vòng lặp thử lại bỏ qua Retry-After và ngừng hoạt động ở một khoảng thời gian cố định khiến thời gian ngừng hoạt động của mọi người trong nhóm của bạn kéo dài hơn.
Xây dựng đường dẫn thử lại
import random, time
from openai import OpenAI, RateLimitError
client = OpenAI(base_url="https://api.meta.ai/v1", [REDACTED CREDENTIAL] 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")
Ba điểm thiết kế. Giới hạn backoff để lỗi kéo dài không biến thành giấc ngủ 20 phút. Giữ các lần thử lại idempotent: cuộc gọi Responses không tạo gì ở phía bạn thì an toàn để lặp lại, nhưng nếu cuộc gọi công cụ của agent có tác dụng phụ, hãy thử lại cuộc gọi mô hình, không phải công cụ. Và hiển thị các lần thử lại trong trace để phân biệt mô hình chậm với mô hình bị điều tiết; hướng dẫn truy vết cuộc gọi công cụ đề cập những gì cần ghi.
Sử dụng phản hồi nền cho phần đuôi dài
Công việc dài không cần giữ kết nối. background: true xếp hàng phản hồi, trả về "status": "queued" và cho phép bạn thăm dò GET /v1/responses/{id}?stream=true để lấy sự kiện vòng đời. Lượt gửi nền có phụ cấp riêng 600 mỗi phút ngoài các giới hạn chính, vì vậy chuyển công việc dạng batch sang đó giải phóng RPM cho lưu lượng tương tác. Ràng buộc: không stream: true trên POST, giới hạn body 1 MiB và bạn hủy bằng POST /v1/responses/{id}/cancel.
Khi 3.000 RPM là chưa đủ
Meta không công bố thang bậc hay biểu mẫu nâng giới hạn. Các lựa chọn hôm nay:
- Giảm token mỗi yêu cầu. Prompt caching giảm hóa đơn nhưng không giảm TPM; cắt ngắn ngữ cảnh làm cả hai. Bài đăng cửa sổ ngữ cảnh đề cập cắt ngắn kết quả công cụ.
- Phân tán theo mô hình. Spark 1.3 có nhóm 3.000/4M riêng với giá bằng một phần ba. Định tuyến công việc không cần chất lượng Wonder sang đó.
- Dùng gateway. Vercel AI Gateway và Cloudflare Workers AI phục vụ meta/muse-wonder-1.0. Việc đó có cho bạn phụ cấp riêng hay không phụ thuộc vào cách gateway được cấp phát; kiểm tra với họ trước khi dựa vào nó.
- Xếp hàng và làm mượt. Bộ giới hạn token-bucket phía trước API biết toàn bộ ngân sách nhóm sẽ vượt qua sáu dịch vụ cùng đoán.
Kiểm thử xử lý giới hạn trong Apidog
Đừng phát hiện lỗi thử lại ở yêu cầu thứ 3.001. Trong Apidog:
- Xây yêu cầu Responses với MODEL_API_KEY làm biến bí mật và thêm hậu xử lý đọc các tiêu đề x-ratelimit-* vào biến môi trường để kịch bản có thể khẳng định dung lượng còn lại không bao giờ xuống dưới mức sàn.
- Tạo mock của /v1/responses với kỳ vọng mock trả về 429 và tiêu đề Retry-After: 2 khi yêu cầu mang tiêu đề như X-Test-Scenario: throttle. Trỏ client của bạn sang mock và khẳng định nó chờ ít nhất hai giây và thành công ở lần thử tiếp theo.
- Chạy kiểm thử hiệu năng tăng khối lượng yêu cầu gegen mock để xác nhận bộ giới hạn của bạn kích hoạt trước khi API would.
- Đặt kịch bản vào CI với Apidog CLI để thay đổi mã thử lại không thể phát hành nếu không vượt qua.
Tải Apidog để thiết lập mock và các khẳng định trong một dự án.
Câu hỏi thường gặp
Giới hạn tốc độ Muse Wonder theo khóa hay theo tài khoản? Theo nhóm. Mọi khóa trong một nhóm dùng chung một pool 3.000 RPM/4M TPM cho mỗi mô hình.
Đầu vào đã cache có tính vào TPM không? Có. Caching giảm giá của những token đó, không giảm trọng số của chúng against giới hạn token mỗi phút.
Tôi có thể yêu cầu giới hạn cao hơn không? Trang giá và giới hạn tốc độ của Meta không liệt kê bậc hay quy trình. Kiểm tra trang để biết thay đổi; các bản phát hành frontier thường thêm bậc trong vài tuần.
Tôi nhận mã trạng thái và tiêu đề nào? HTTP 429, tùy chọn với Retry-After, cộng các tiêu đề x-ratelimit-* trên phản hồi dựa trên token.
Bước tiếp theo
Đo token mỗi yêu cầu của lượt agent nặng nhất, nhân với đồng thời và so với 4.000.000. Nếu câu trả lời gần bằng, hãy xây bộ giới hạn và kiểm thử mock tuần này, trước khi nhóm dùng chung pool với production.