حدود معدل الاستخدام في Muse Wonder: 3,000 طلب في الدقيقة و4 ملايين رمز في الدقيقة تشترك فيها الفريق بالكامل

حدود معدل الاستخدام في Muse Wonder على Meta Model API هي 3000 طلب في الدقيقة و4000000 رمز في الدقيقة. ينطبق كلاهما على كل نموذج وكل فريق، وليس على مفتاح واجهة برمجة التطبيقات: كل مفتاح تنشئه مؤسستك يتم سحبه من نفس المجموعة. تحصل استجابات الخلفية على بدل منفصل قدره 600 إرسال جديد في الدقيقة. لا توجد مستويات استخدام منشورة ولا توجد طريقة موثقة لطلب المزيد. عندما تتجاوز الحد، تحصل على HTTP 429، وتوجيهات Meta عبارة عن تراجع أسي مع بدء الارتعاش بحوالي 500 مللي ثانية، مع احترام Retry-After عند وجوده.

تحدد هذه الحقائق الأربع كيفية تصميم أي شيء يستدعي muse-wonder-1.0 على نطاق واسع. يغطي هذا المنشور ما تعنيه الحدود عمليًا، وكيف يستهلك سياق بحجم مليون رمز ميزانية TPM تبلغ 4 ملايين، وكيفية قراءة الرؤوس، وكيفية إنشاء مسار إعادة المحاولة واختباره، وما يجب فعله عندما لا يكون 3,000 RPM كافيًا. بالنسبة لأساسيات واجهة برمجة التطبيقات، ابدأ بـ دليل Muse Wonder API.

الحدود

تنطبق نفس أرقام 3000/4M على Muse Spark 1.3؛ تم تحديد الإصدار المساهم من Spark عند 150 RPM و 3M TPM. يحتوي كل طراز على تجمع خاص به، لذا فإن حركة المرور الكثيفة في Wonder لا تؤدي إلى تجويع مسار Spark والعكس صحيح. لا يتم احتساب سياق التوجيه المحقون في Meta مقابل TPM ولا يظهر في usage.

تنفد الرموز المميزة قبل انتهاء الطلبات

عند 4 مليون رمز في الدقيقة، نادرًا ما يكون حد الطلب هو الحد الملزم للوكيل. ثلاثة الرسوم التوضيحية:

يمكن لفريق يدير مجموعة من الوكلاء بسياقات كبيرة أن يصل إلى 4M TPM من خلال عشرات الطلبات المتزامنة. لا يزال يتم احتساب الإدخال المخزن مؤقتًا ضمن TPM؛ خصم التخزين المؤقت هو خصم على الفواتير، وليس خصمًا على حد المعدل. يتم احتساب الرموز المميزة للاستدلال ضمن max_output_tokens وفاتورتك، ويتم احتساب الرموز المميزة للمخرج ضمن TPM أيضًا.

النتيجة العملية: موازنة TPM حسب حجم السياق، وليس حسب عدد الطلبات. الوكيل الذي يعيد إرسال محادثة مكونة من 300 ألف رمز في كل دورة هو طلب مكون من 300 ألف رمز في كل مرة، وعشرة من هذه الوكلاء يتقدمون مرة واحدة في الدقيقة يستهلكون ثلاثة أرباع بدل الفريق.

خطة التزامن من الأرقام

حساب السعة هو سطر واحد: الوكلاء المتزامنون، مضروبًا في الرموز لكل دورة، مضروبًا في الدورات في الدقيقة، يجب أن يظل أقل من 4,000,000. اعمل عليه لأثقل مسار لديك قبل النشر.

اترك هامشًا بنسبة 40% على الأقل. دورات الوكيل متقطعة، وتؤدي عاصفة إعادة المحاولة بعد خطأ عابر إلى مضاعفة الطلب لمدة دقيقة، وأي شخص آخر في الفريق يسحب من نفس المجموعة. يبدو الصف الثالث جيدًا على الورق ويفشل عمليًا في المرة الأولى التي يعيد فيها وكيلان المحاولة في وقت واحد.

يسببان اثنان من الرافعات في تقليص الجانب الأيسر من المعادلة. يحافظ الضغط على عدم نمو الرموز لكل دورة بلا حدود: لخص أو احذف نتائج الأدوات القديمة بمجرد تجاوز التشغيل حدًا معينًا، كما يصف منشور نافذة السياق. ويتيح لك إعادة التشغيل المشفر عديم الحالة في Responses API التحكم بدقة في ما تعيد إرساله، حيث يعيد السجل المدار من الخادم باستخدام previous_response_id إرسال كل شيء.

تجمع واحد لجميع المفاتيح

يحدد Meta نطاقات الحدود لكل فريق. مفتاح لبيئة التجهيز ومفتاح للإنتاج ومفتاح لجهاز زميل في الفريق يتم سحبها جميعًا من نفس 3000/4M. لهذا أثران.

أولاً، يمكن لاختبار التحميل من مطور واحد أن يحد من الإنتاج. اعزل التجارب في الوقت المناسب، أو في فريق منفصل إذا سمحت مؤسستك بذلك. ثانيًا، لن تُظهر لك المراقبة لكل مفتاح الصورة الكاملة. اجمع رؤوس x-ratelimit-* عبر كل متصل، وإلا سترى 429 على مفتاح يبدو أنه أقل بكثير من حده.

اقرأ الرؤوس

تحمل الاستجابات القائمة على الرموز رؤوس x-ratelimit-*. سجلها في كل مكالمة. النمط المهم هو السعة المتبقية التي تتجه نحو الصفر عبر جميع المتصلين خلال دقيقة، وهي إشارتك للتباطؤ قبل وصول 429. لا تحمل استجابات النسخ هذه الرؤوس؛ استجابات Wonder تحملها.

عندما يصل 429، تكون مستندات Meta محددة: تراجع أسيًا مع ارتعاش يبدأ حوالي 500 مللي ثانية، وإذا كان Retry-After موجودًا، فانتظر على الأقل هذه المدة. حلقة إعادة محاولة تتجاهل Retry-After وتضرب بفاصل زمني ثابت تجعل الانقطاع أطول لكل فرد في فريقك.

قم ببناء مسار إعادة المحاولة

import random, time
from openai import OpenAI, RateLimitError

client = OpenAI(base_url="https://api.meta.ai/v1", [REDACTED CREDENTIAL]"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 دقيقة. حافظ على عمليات إعادة المحاولة كسمة idempotent: استدعاء Responses لا ينشئ أي شيء من جانبك يكون آمنًا للتكرار، ولكن إذا كانت استدعاءات أداة وكيلك لها آثار جانبية، فأعد محاولة استدعاء النموذج وليس الأداة. وأظهر عمليات إعادة المحاولة في آثارك حتى تتمكن من التمييز بين نموذج بطيء ونموذج مقيد؛ يغطي دليل تتبع استدعاء الأداة ما يجب تسجيله.

استخدم استجابات الخلفية للذيل الطويل

الوظائف الطويلة لا تحتاج إلى الاستمرار في الاتصال. يقوم background: true بوضع الاستجابة في قائمة الانتظار، وإرجاع "status": "queued"، ويتيح لك استقصاء GET /v1/responses/{id}?stream=true لأحداث دورة الحياة. تقديمات الخلفية لها بدل خاص بها يبلغ 600 في الدقيقة بالإضافة إلى الحدود الرئيسية، لذا فإن نقل العمل على دفعات إلى هناك يحرر RPM لحركة المرور التفاعلية. القيود: لا يوجد stream: true على POST، وحد أقصى لحجم الجسم يبلغ 1 MiB، وتقوم بالإلغاء باستخدام POST /v1/responses/{id}/cancel.

عندما لا يكون 3000 RPM كافيًا

لا تنشر Meta سلم طبقات ولا نموذجًا لزيادة الحدود. خياراتك اليوم:

• قلل الرموز لكل طلب. يقلل تخزين المطالبات المؤقت فاتورتك ولكن ليس TPM الخاص بك؛ يؤدي تقليم السياق إلى كليهما. يغطي منشور نافذة السياق تقليم نتائج الأدوات.
• انتشر عبر النماذج. يحتوي Spark 1.3 على تجمعه الخاص بنسبة 3000/4M بثلث السعر. وجه العمل الذي لا يحتاج إلى جودة Wonder إلى هناك.
• استخدم بوابة. تخدم بوابة Vercel AI وCloudflare Workers AI meta/muse-wonder-1.0. يعتمد ما إذا كان ذلك يمنحك بدلًا منفصلًا على كيفية توفير البوابة؛ تحقق معهم قبل الاعتماد عليه.
• طابور وسلس. محدد دلو الرمز المميز أمام واجهة برمجة التطبيقات (API) الذي يعرف أن الميزانية الكاملة للفريق سوف يتفوق على ست خدمات في كل تخمين.

اختبار التعامل مع الحد في Apidog

لا تكتشف أخطاء إعادة المحاولة عند 3001 طلب. في Apidog:

1. أنشئ طلب الاستجابات باستخدام MODEL_API_KEY كـ المتغير السري، وأضف معالجًا لاحقًا يقرأ رؤوس x-ratelimit-* في متغيرات البيئة بحيث يمكن للسيناريو التأكد من عدم انخفاض السعة المتبقية أبدًا عن الحد الأدنى.
2. قم بإنشاء نموذج وهمي لـ /v1/responses مع توقع وهمي يُرجع 429 ورأس Retry-After: 2 عندما يحمل الطلب رأسًا مثل X-Test-Scenario: throttle. قم بتوجيه عميلك إلى النموذج الوهمي وتأكد من أنه ينتظر ثانيتين على الأقل وينجح في المحاولة التالية.
3. قم بتشغيل اختبار الأداء الذي يزيد حجم الطلب مقابل النموذج الوهمي لتأكيد مشاركة المحدد قبل أن تقوم واجهة برمجة التطبيقات بذلك.
4. ضع السيناريو في CI باستخدام Apidog CLI بحيث لا يمكن تنفيذ أي تغيير في كود إعادة المحاولة دون تمريره.

تحميل Apidog لإعداد الصور والتأكيدات في مشروع واحد.

الأسئلة المتداولة

هل حدود معدل Muse Wonder لكل مفتاح أم لكل حساب؟ لكل فريق. تشترك جميع المفاتيح في الفريق في مجموعة واحدة بسرعة 3,000 RPM / 4M TPM لكل طراز.

هل يتم احتساب المدخلات المخزنة مؤقتًا ضمن TPM؟ نعم. يؤدي التخزين المؤقت إلى خفض سعر تلك الرموز المميزة، وليس وزنها مقابل حد الرمز المميز لكل دقيقة.

هل يمكنني طلب حد أعلى؟ لا تسرد صفحة التسعير وحدود المعدل الخاصة بـ Meta أية مستويات أو عملية. تحقق من الصفحة لمعرفة التغييرات؛ غالبًا ما تضيف إصدارات النماذج المتقدمة مستويات في غضون أسابيع.

ما رمز الحالة والعناوين التي أحصل عليها؟ HTTP 429، اختياريًا مع Retry-After، بالإضافة إلى رؤوس x-ratelimit-* على الاستجابات المستندة إلى الرمز المميز.

الخطوة التالية

قم بقياس الرموز المميزة لكل طلب من أثقل وكيل لديك، واضربها بالتزامن، وقارنها بـ 4,000,000. إذا كانت الإجابة متقاربة، فقم ببناء المحدد والاختبار الوهمي هذا الأسبوع، قبل أن يشارك الفريق المجموعة مع الإنتاج.