Muse Wonder'ın Meta Model API'sindeki hız sınırları, dakikada 3.000 istek ve dakikada 4.000.000 jetondur. Her ikisi de API anahtarı başına değil, model ve ekip başına geçerlidir: kuruluşunuzun oluşturduğu her anahtar aynı havuzdan alınır. Arka plan yanıtlarına dakikada 600 yeni gönderimlik ayrı bir izin verilir. Yayınlanmış bir kullanım katmanı yoktur ve daha fazlasını talep etmenin belgelenmiş bir yolu yoktur. Bir sınırı aştığınızda, HTTP 429 alırsınız ve Meta'nın rehberliği, yaklaşık 500 ms'de başlayan jitter ile üstel geri çekilme ve Retry-After varsa buna saygı göstermektir.
Bu dört gerçek, ölçekli olarak muse-wonder-1.0 çağıran her şeyi nasıl mimarleceğinizi belirler. Bu yazı, limitlerin pratikte ne anlama geldiğini, 1M token bağlamının 4M TPM bütçesini nasıl tükettiğini, başlıkların nasıl okunacağını, yeniden deneme yolunun nasıl oluşturulacağını ve test edileceğini ve 3.000 RPM yeterli olmadığında ne yapılacağını kapsar. API temelleri için Muse Wonder API kılavuzuyla başlayın.
Sınırlar
| Limit | Değer | Kapsam |
|---|---|---|
| Dakikadaki istek sayısı | 3,000 | Ekip başına, model başına |
| Dakikadaki jeton sayısı | 4,000,000 | Ekip başına, model başına |
| Arka plan gönderimleri | Dakikada 600 | Ekip başına, yukarıdakilere ek olarak |
| Bağlam penceresi | 1,048,576 jeton | İstek başına |
| Kullanım katmanları | Yayımlanmamış | |
| Limit artışları | Belgelenmiş süreç yok |
Aynı 3.000/4M rakamları Muse Spark 1.3 için de geçerlidir; Spark'ın Contributor varyantı 150 RPM ve 3M TPM ile daha düşük bir sınırla sınırlandırılmıştır. Her modelin kendi havuzu vardır, bu nedenle yoğun Wonder trafiği bir Spark şeridini aç bırakmaz ve tersi de geçerlidir. Meta'nın enjekte edilen yönlendirme bağlamı TPM'ye sayılmaz ve usage içinde görünmez.
İstekler tamamlanmadan jetonlar tükeniyor
Dakikada 4M jetonla, istek limiti nadiren bir ajan için bağlayıcı olandır. Üç örnek:
| İş yükü | İstek başına jeton | TPM bağlayıcı hale gelmeden önce dakikadaki istek |
|---|---|---|
| Kısa sohbet turları | 3,000 | 1,333 |
| Belge incelemesi | 50,000 | 80 |
| Uzun ajan turu, 400K bağlam | 400,000 | 10 |
| Tam pencere isteği | 1,000,000 | 4 |
Büyük bağlamlarla bir avuç ajan çalıştıran bir ekip, eşzamanlı bir düzine istekle 4M TPM'ye ulaşabilir. Önbelleğe alınan girdi hâlâ TPM'ye sayılır; önbellek indirimi bir faturalandırma indirimiidir, hız limiti indirimi değildir. Akıl yürütme jetonları max_output_tokens ve faturanıza sayılır ve çıktı jetonları da TPM'ye sayılır.
Pratik sonuç: TPM'yi istek sayısına göre değil bağlam boyutuna göre bütçeleştirin. Her turda 300K jetonluk bir konuşmayı yeniden gönderen ajan, her seferinde 300K jetonluk bir istektir ve dakikada bir kez adım atan on böyle ajan, ekibin ödeneğinin dörtte üçünü tüketir.
Sayılardan eşzamanlılık planlayın
Kapasite matematiği tek satırdır: eşzamanlı ajanlar, tur başına jeton sayısıyla, dakikadaki tur sayısıyla çarpıldığında 4.000.000'un altında kalmalıdır. Dağıtmadan önce en yoğun şeridiniz için hesaplayın.
| Ajanlar | Tur başına jeton | Her birinin dakikadaki tur sayısı | Gereken TPM | Pay |
|---|---|---|---|---|
| 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 | limitin üzerinde |
En az %40 pay bırakın. Ajan turları patlamalıdır, geçici bir hatadan sonra yeniden deneme fırtınası bir dakika boyunca talebi ikiye katlar ve ekipteki diğer herkes aynı havuzdan çekilir. Üçüncü satır kağıt üzerinde iyi görünür ama iki ajan ilk kez aynı anda yeniden denediğinde pratikte başarısız olur.
İki kaldıraç denklemin sol tarafını küçültür. Sıkıştırma, tur başına jetonların sınırsız büyümesini önler: bir çalışma eşiği aştığında bağlam penceresi yazısında açıklandığı gibi eski araç sonuçlarını özetleyin veya bırakın. Responses API'deki durum bilgisiz şifreli yeniden oynatma, tam olarak neyi yeniden göndereceğinizi kontrol etmenizi sağlar; previous_response_id ile sunucu tarafından yönetilen geçmiş her şeyi yeniden gönderir.
Tüm anahtarlar için tek havuz
Meta limitleri ekip başına kapsar. Hazırlama için bir anahtar, üretim için bir anahtar ve bir ekip arkadaşının dizüstü bilgisayarı için bir anahtar, aynı 3.000/4M'den çeker. Bunun iki sonucu vardır.
Birincisi, tek bir geliştiriciden gelen yük testi üretimi kısıtlayabilir. Denemeleri zaman içinde veya kuruluşunuz izin veriyorsa ayrı bir ekipte izole edin. İkincisi, anahtar başına izleme tüm resmi göstermez. Her çağırıcı genelinde x-ratelimit-* başlıklarını toplayın, aksi halde sınırının oldukça altında görünen bir anahtarda 429'lar görürsünüz.
Başlıkları okuyun
Jeton tabanlı yanıtlar x-ratelimit-* başlıklarını taşır. Her çağrıda bunları günlüğe kaydedin. Önemli olan desen, bir dakika içinde tüm çağırıcılarda kalan kapasitenin sıfıra yönelmesidir; bu, 429 gelmeden önce yavaşlamanızın sinyalidir. Transkripsiyon yanıtları bu başlıkları taşımaz; Wonder'ın yanıtları taşır.
Bir 429 geldiğinde Meta'nın belgeleri özeldir: yaklaşık 500 ms'de başlayan jitter ile üstel geri çekilin ve Retry-After varsa en az o kadar bekleyin. Retry-After'yı yok sayan ve sabit bir aralıkla vuran bir yeniden deneme döngüsü, ekibinizdeki herkes için kesintiyi uzatır.
Yeniden deneme yolunu oluşturun
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")
Üç tasarım noktası. Uzun bir kesinti 20 dakikalık uykuya dönüşmesin diye geri çekilmeyi sınırlayın. Yeniden denemeleri etkisiz tutun: tarafınızda hiçbir şey oluşturmayan bir Responses çağrısı tekrarlamak için güvenlidir, ancak ajanınızın araç çağrıları yan etkilere sahipse aracı değil model çağrısını yeniden deneyin. Ve yavaş bir model ile kısıtlanmış bir modeli ayırt edebilmeniz için izlerinizde yeniden denemeleri gösterin; araç çağrısı izleme kılavuzu nelerin günlüğe kaydedileceğini kapsar.
Uzun kuyruk için arka plan yanıtlarını kullanın
Uzun işlerin bağlantı tutması gerekmez. background: true yanıtı kuyruğa alır, "status": "queued" döndürür ve yaşam döngüsü olayları için GET /v1/responses/{id}?stream=true adresini yoklamanıza olanak tanır. Arka plan gönderimleri, ana limitlere ek olarak dakikada 600'lük kendi ödeneğine sahiptir, bu nedenle toplu tarz işleri oraya taşımak etkileşimli trafik için RPM serbest bırakır. Kısıtlamalar: POST üzerinde stream: true yok, 1 MiB gövde sınırı ve POST /v1/responses/{id}/cancel ile iptal edersiniz.
3.000 RPM yeterli olmadığında
Meta bir kademe merdiveni ya da limitleri artırmak için bir form yayımlamaz. Bugünkü seçenekleriniz:
- İstek başına jetonları azaltın. İstem önbelleğe alma faturanızı keser ama TPM'nizi kesmez; bağlamı kısaltmak ikisini de yapar. Bağlam penceresi yazısı araç sonuçlarının kısaltılmasını kapsar.
- Modellere yayın. Spark 1.3, fiyatın üçte biriyle kendi 3.000/4M havuzuna sahiptir. Wonder'ın kalitesini gerektirmeyen işi oraya yönlendirin.
- Bir ağ geçidi kullanın. Vercel AI Gateway ve Cloudflare Workers AI meta/muse-wonder-1.0 hizmetini sunar. Bunun size ayrı bir ödenek verip vermediği, ağ geçidinin nasıl sağlandığına bağlıdır; güvenmeden önce onlarla kontrol edin.
- Kuyruğa alın ve yumuşatın. Ekibin tüm bütçesini bilen API önündeki token-bucket sınırlayıcı, her biri tahmin eden altı hizmetten daha iyi performans gösterir.
Apidog'da limit işlemeyi test edin
3.001 istekte yeniden deneme hatalarınızı keşfetmeyin. Apidog'da:
- Responses isteğini MODEL_API_KEY ile gizli değişken olarak oluşturun ve bir senaryonun kalan kapasitenin hiçbir zaman bir taban altına düşmediğini iddia edebilmesi için x-ratelimit-* başlıklarını ortam değişkenlerine okuyen bir son işlemci ekleyin.
- /v1/responses için bir mock oluşturun; bu mock, Retry-After: 2 başlığıyla birlikte 429 döndüren bir beklentiye sahip olsun ve X-Test-Scenario: throttle gibi bir başlık taşıyan istek için tetiklensin. İstemcinizi bu mock'a yönlendirin ve en az iki saniye bekleyip sonraki denemede başarılı olduğunu doğrulayın.
- Mock'a karşı istek hacmini artıran ve sınırlayıcınızın API'den önce devreye girdiğini doğrulayan bir performans testi çalıştırın.
- Senaryoyu Apidog CLI ile CI'ya koyun, böylece yeniden deneme kodundaki bir değişiklik onu geçmeden gönderilemez.
Mock ve iddiaları tek bir projede ayarlamak için Apidog'u indirin.
Sık sorulan sorular
Muse Wonder hız limitleri anahtar başına mı hesap başına mı? Ekip başına. Bir ekipteki tüm anahtarlar, model başına tek bir 3.000 RPM/4M TPM havuzunu paylaşır.
Önbelleğe alınan girdi TPM'ye sayılır mı? Evet. Önbelleğe alma bu jetonların fiyatını düşürür, dakikadaki jeton limitine karşı ağırlığını düşürmez.
Daha yüksek bir limit talep edebilir miyim? Meta'nın fiyatlandırma ve hız limitleri sayfası kademe veya süreç listelemiyor. Değişiklikler için sayfayı kontrol edin; sınır teknolojisi lansmanları çoğu zaman birkaç hafta içinde kademe ekler.
Hangi durum kodunu ve başlıkları alırım? HTTP 429, isteğe bağlı olarak Retry-After ve jeton tabanlı yanıtlarda x-ratelimit-* başlıkları.
Sonraki adım
En yoğun ajan turunuzun istek başına jetonlarını ölçün, eşzamanlılıkla çarpın ve 4.000.000 ile karşılaştırın. Cevap yakınsa, ekip havuzu üretimle paylaşmadan önce bu hafta sınırlayıcıyı ve mock testini oluşturun.