Batasan kecepatan Muse Wonder pada Meta Model API adalah 3.000 permintaan per menit dan 4.000.000 token per menit. Keduanya berlaku per model dan per tim, bukan per kunci API: setiap kunci yang dibuat organisasi Anda diambil dari pool yang sama. Respons latar belakang mendapat tunjangan terpisah sebesar 600 kiriman baru per menit. Tidak ada tingkatan penggunaan yang dipublikasikan dan tidak ada cara terdokumentasi untuk meminta lebih banyak. Ketika Anda melebihi batas, Anda mendapatkan HTTP 429, dan panduan Meta adalah backoff eksponensial dengan jitter mulai sekitar 500 ms, dengan mematuhi Retry-After jika ada.
Empat fakta ini menentukan cara Anda merancang apa pun yang memanggil muse-wonder-1.0 dalam skala besar. Pos ini mencakup arti batas dalam praktik, bagaimana konteks 1M token menghabiskan anggaran 4M TPM, cara membaca header, cara membangun dan menguji jalur percobaan ulang, serta apa yang harus dilakukan ketika 3.000 RPM tidak cukup. Untuk dasar-dasar API, mulailah dengan panduan Muse Wonder API.
Batas
| Batas | Nilai | Cakupan |
|---|---|---|
| Permintaan per menit | 3,000 | Per tim, per model |
| Token per menit | 4,000,000 | Per tim, per model |
| Kiriman latar belakang | 600 per menit | Per tim, di atas hal di atas |
| Jendela konteks | 1,048,576 token | Per permintaan |
| Tingkatan penggunaan | Tidak ada yang dipublikasikan | |
| Peningkatan batas | Tidak ada proses terdokumentasi |
Angka 3.000/4M yang sama berlaku untuk Muse Spark 1.3; varian Contributor dari Spark dibatasi lebih rendah pada 150 RPM dan 3M TPM. Setiap model memiliki pool sendiri, sehingga lalu lintas Wonder yang padat tidak membuat jalur Spark kekurangan sumber daya, begitu pula sebaliknya. Konteks steering yang disuntikkan Meta tidak dihitung terhadap TPM dan tidak muncul dalam usage.
Token habis sebelum permintaan habis
Pada 4M token per menit, batas permintaan jarang menjadi batas yang mengikat untuk sebuah agen. Tiga ilustrasi:
| Beban kerja | Token per permintaan | Permintaan per menit sebelum TPM mengikat |
|---|---|---|
| Giliran obrolan pendek | 3,000 | 1,333 |
| Tinjauan dokumen | 50,000 | 80 |
| Giliran agen panjang, konteks 400K | 400,000 | 10 |
| Permintaan jendela penuh | 1,000,000 | 4 |
Tim yang menjalankan beberapa agen dengan konteks besar dapat mencapai 4M TPM dengan selusin permintaan bersamaan. Input yang di-cache tetap dihitung dalam TPM; diskon cache adalah diskon penagihan, bukan diskon batas laju. Token penalaran dihitung dalam max_output_tokens dan tagihan Anda, dan token output juga dihitung dalam TPM.
Konsekuensi praktisnya: anggarkan TPM berdasarkan ukuran konteks, bukan jumlah permintaan. Agen yang mengirim ulang percakapan 300K token setiap giliran adalah permintaan 300K token setiap kali, dan sepuluh agen seperti itu melangkah sekali per menit mengonsumsi tiga perempat tunjangan tim.
Rencanakan konkurensi dari angka
Matematika kapasitas satu baris: agen bersamaan, dikalikan token per giliran, dikalikan giliran per menit, harus tetap di bawah 4.000.000. Hitung untuk jalur terberat Anda sebelum menerapkan.
| Agen | Token per giliran | Giliran per menit masing-masing | TPM yang dibutuhkan | Ruang sisa |
|---|---|---|---|---|
| 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 | melebihi batas |
Sisakan setidaknya 40% ruang sisa. Giliran agen bersifat bursty, badai percobaan ulang setelah kesalahan sementara menggandakan permintaan selama satu menit, dan orang lain di tim mengambil dari pool yang sama. Baris ketiga terlihat baik di atas kertas tetapi gagal dalam praktik pertama kali dua agen mencoba ulang sekaligus.
Dua tuas memperkecil sisi kiri persamaan. Kompaksi menjaga token per giliran agar tidak tumbuh tanpa batas: ringkas atau buang hasil alat lama setelah proses melewati ambang batas, seperti yang dijelaskan pos jendela konteks. Dan replay terenkripsi tanpa status pada Responses API memungkinkan Anda mengontrol persis apa yang dikirim ulang, sementara riwayat yang dikelola server dengan previous_response_id mengirim ulang semuanya.
Satu pool untuk semua kunci
Meta menetapkan batas per tim. Kunci untuk staging, kunci untuk produksi, dan kunci untuk laptop rekan satu tim semuanya diambil dari 3.000/4M yang sama. Ini memiliki dua konsekuensi.
Pertama, uji beban dari satu pengembang dapat membatasi produksi. Pisahkan eksperimen dalam waktu, atau dalam tim terpisah jika organisasi Anda mengizinkan. Kedua, pemantauan per kunci tidak akan menunjukkan gambaran lengkap. Agregasi header x-ratelimit-* di setiap pemanggil, atau Anda akan melihat 429 pada kunci yang tampaknya jauh di bawah batasnya.
Baca header
Respons berbasis token membawa header x-ratelimit-*. Catat pada setiap panggilan. Pola yang penting adalah kapasitas tersisa menurun menuju nol di semua pemanggil dalam satu menit, yang merupakan sinyal untuk memperlambat sebelum 429 tiba. Respons transkripsi tidak membawa header ini; respons Wonder membawa.
Saat 429 tiba, dokumentasi Meta spesifik: back off secara eksponensial dengan jitter mulai sekitar 500 ms, dan jika Retry-After ada, tunggu setidaknya selama itu. Loop percobaan ulang yang mengabaikan Retry-After dan menghantam pada interval tetap membuat pemadaman lebih lama untuk semua orang di tim Anda.
Bangun jalur percobaan ulang
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")
Tiga poin desain. Batasi backoff agar pemadaman panjang tidak menjadi tidur 20 menit. Jaga percobaan ulang tetap idempoten: panggilan Responses yang tidak membuat apa pun di sisi Anda aman diulang, tetapi jika panggilan alat agen Anda memiliki efek samping, coba ulang panggilan model, bukan alatnya. Dan tampilkan percobaan ulang dalam trace agar Anda bisa membedakan model lambat dari model yang dibatasi; panduan pelacakan panggilan alat mencakup apa yang harus dicatat.
Gunakan respons latar belakang untuk ekor panjang
Pekerjaan panjang tidak perlu menahan koneksi. background: true mengantrekan respons, mengembalikan "status": "queued", dan memungkinkan Anda polling GET /v1/responses/{id}?stream=true untuk peristiwa siklus hidup. Kiriman latar belakang memiliki tunjangan sendiri 600 per menit selain batas utama, sehingga memindahkan pekerjaan bergaya batch ke sana membebaskan RPM untuk lalu lintas interaktif. Batasan: tidak ada stream: true pada POST, batas isi 1 MiB, dan Anda membatalkan dengan POST /v1/responses/{id}/cancel.
Ketika 3.000 RPM tidak cukup
Meta tidak mempublikasikan tangga tingkatan atau formulir untuk menaikkan batas. Opsi Anda hari ini:
- Kurangi token per permintaan. Prompt caching mengurangi tagihan Anda tetapi bukan TPM Anda; memangkas konteks melakukan keduanya. Pos jendela konteks membahas pemangkasan hasil alat.
- Sebar across model. Spark 1.3 memiliki pool 3.000/4M sendiri dengan sepertiga harga. Rutekan pekerjaan yang tidak membutuhkan kualitas Wonder ke sana.
- Gunakan gateway. Vercel AI Gateway dan Cloudflare Workers AI menyajikan meta/muse-wonder-1.0. Apakah itu memberi Anda tunjangan terpisah bergantung pada bagaimana gateway disediakan; periksa dengan mereka sebelum mengandalkannya.
- Antrean dan haluskan. Pembatas token-bucket di depan API yang mengetahui seluruh anggaran tim akan mengungguli enam layanan yang masing-masing menebak.
Uji penanganan batas di Apidog
Jangan temukan bug percobaan ulang Anda pada 3.001 permintaan. Di Apidog:
- Bangun permintaan Responses dengan MODEL_API_KEY sebagai variabel rahasia dan tambahkan post-processor yang membaca header x-ratelimit-* ke variabel lingkungan sehingga skenario dapat menyatakan kapasitas tersisa tidak pernah turun di bawah batas bawah.
- Buat mock dari /v1/responses dengan ekspektasi mock yang mengembalikan 429 dan header Retry-After: 2 saat permintaan membawa header seperti X-Test-Scenario: throttle. Arahkan klien Anda ke mock dan nyatakan bahwa ia menunggu setidaknya dua detik dan berhasil pada percobaan berikutnya.
- Jalankan tes performa yang menaikkan volume permintaan terhadap mock untuk mengonfirmasi pembatas Anda aktif sebelum API melakukannya.
- Masukkan skenario ke CI dengan Apidog CLI agar perubahan pada kode percobaan ulang tidak dapat dikirim tanpa lulus.
Unduh Apidog untuk menyiapkan mock dan asersi dalam satu proyek.
Pertanyaan yang sering diajukan
Apakah batas laju Muse Wonder per kunci atau per akun? Per tim. Semua kunci dalam satu tim berbagi satu pool 3.000 RPM/4M TPM per model.
Apakah input yang di-cache dihitung dalam TPM? Ya. Caching menurunkan harga token tersebut, bukan bobotnya terhadap batas token per menit.
Bisakah saya meminta batas lebih tinggi? Halaman harga dan batas laju Meta tidak mencantumkan tingkatan atau proses. Periksa halaman untuk perubahan; peluncuran frontier sering menambahkan tingkatan dalam beberapa minggu.
Kode status dan header apa yang saya dapatkan? HTTP 429, opsional dengan Retry-After, ditambah header x-ratelimit-* pada respons berbasis token.
Langkah berikutnya
Ukur token per permintaan dari giliran agen terberat Anda, kalikan dengan konkurensi, dan bandingkan dengan 4.000.000. Jika jawabannya mendekati, bangun pembatas dan tes mock minggu ini, sebelum tim berbagi pool dengan produksi.