حدود معدل استخدام API GPT: المستويات، قيود الاستخدام، وكيفية اختبارها باستخدام Apidog

تقوم بنشر دالة تستدعي واجهة برمجة تطبيقات GPT. تعمل بشكل جيد في بيئة الاختبار. ولكن عندما يستخدمها أول مائة مستخدم في بيئة الإنتاج، تمتلئ سجلاتك بأخطاء 429 Too Many Requests. الآن تتساءل: هل هو عدد الطلبات في الدقيقة، أم عدد الرموز في الدقيقة، أم حدود يومية؟ هل ما زلت في المستوى الأول؟ وهل النموذج الذي حولت إليه الأسبوع الماضي لديه قيود أكثر صرامة من النموذج القديم؟

إذا كنت قد عملت مع OpenAI من قبل، فأنت تعلم أن قصة حدود المعدل أصبحت أكثر تعقيدًا مع كل نموذج جديد. لدى GPT-5.5 حدود مختلفة عن GPT-4.1، وتُحسب نماذج الصور بشكل مختلف عن نماذج النصوص، ويتغير مستوى استخدامك بصمت مع زيادة إنفاقك. يوفر لك Apidog مساحة عمل واحدة لفحص رؤوس استجابة كل طلب، ومحاكاة حركة المرور المتزامنة، وتأكيد الحد الذي تضربه بالضبط قبل نشر التعليمات البرمجية التي تستخدمه. قم بتنزيل Apidog إذا لم يكن لديك بعد؛ سير العمل أدناه يعمل على الخطة المجانية.

القيود الأربعة التي تهمك حقًا

تطبق OpenAI عدة حدود للمعدل على كل مفتاح API الخاص بـ GPT. سترى جميع القيود الأربعة مطبقة على أي تطبيق إنتاجي:

• RPM (الطلبات في الدقيقة): عدد استدعاءات واجهة برمجة التطبيقات التي يمكنك إرسالها في الدقيقة. وهو أدنى حد في معظم المستويات.
• TPM (الرموز في الدقيقة): إجمالي الرموز المدخلة والمخرجة التي يمكنك معالجتها في الدقيقة. وهو الحد الذي ينساه معظم الناس.
• RPD (الطلبات في اليوم): سقف يومي للمفاتيح المجانية والمفاتيح من المستوى الأول. يختفي في المستويات الأعلى لمعظم نماذج النصوص.
• IPM / TPD / حدود قائمة الانتظار الدفعية: قيود خاصة بالنموذج لتوليد الصور، والصوت، والتضمينات، ونقاط نهاية الدفعات. كل عائلة نقاط نهاية لها سقفها الخاص.

عند رفض طلبك، تُرجع واجهة برمجة التطبيقات HTTP 429 وجسم JSON بهذا الشكل:

{
 "error": {
 "message": "Rate limit reached for gpt-5.5 in organization org-abc on tokens per min (TPM): Limit 30000, Used 28432, Requested 3120.",
 "type": "tokens",
 "param": null,
 "code": "rate_limit_exceeded"
 }
}

لاحظ أن الجسم يخبرك بالبعد الذي تجاوزته: tokens (الرموز)، أو requests (الطلبات)، أو أحيانًا tokens_usage_based (الرموز المستندة إلى الاستخدام). هذا هو أول شيء تقرأه عندما يحدث خطأ ما. يبدو الخطأ الناتج عن تجاوز حد TPM مختلفًا عن الخطأ الناتج عن تجاوز حد RPM، والحل مختلف أيضًا. خطأ 429 ليس مجرد 429.

للحصول على مرجع شامل حول ما يعنيه 429 على مستوى HTTP، راجع وثائق MDN 429 ومواصفات RFC 6585. وللسلوك الخاص بـ OpenAI حول رؤوس إعادة المحاولة وانتقال المستوى، تحتفظ OpenAI بصفحة رسمية لحدود المعدل يجب عليك وضع إشارة مرجعية عليها.

كيف تعمل المستويات ولماذا تستمر في الترقية (أو التعثر)

يقع مفتاح GPT API الخاص بك ضمن مستوى استخدام OpenAI. تحدد المستويات الأرقام الفعلية وراء حدود RPM و TPM الخاصة بك. تنتقل إلى مستويات أعلى بناءً على أمرين: إجمالي الإنفاق على حسابك، وكم مضى على أول دفعة لك. هناك ستة مستويات، من المجاني حتى المستوى 5، والشكل التقريبي يبدو كالتالي لنماذج النصوص:

الأرقام أعلاه توضيحية؛ فالحدود الدقيقة تتغير بمرور الوقت وتختلف حسب النموذج. اقرأ حدودك الحالية مباشرة من لوحة التحكم أو، الأفضل من ذلك، من رؤوس استجابة واجهة برمجة التطبيقات الخاصة بك (المغطاة أدناه) قبل تحديد حجم عبء العمل.

اثنتان من التبعات العملية:

1. تتم ترقيتك تلقائيًا عند الدفع. المستويات ليست اختيارية. بمجرد أن يتجاوز إنفاقك عتبة المستوى وتمر عتبة الانتظار، يتم تشغيل طلبك التالي مقابل الحدود الجديدة. لا توجد إشعارات، ولا خطوات ترحيل.
2. يمكن أن يتم تخفيض مستواك. إذا أصبح حسابك غير نشط لفترة طويلة أو فشلت طريقة الدفع الخاصة بك، يمكنك العودة إلى مستوى أدنى. اختبر في بيئة الإنتاج بعد أي تغيير في الفواتير.

لمقارنة أنظمة المستويات لدى موفري النماذج الآخرين، راجع شرح حدود معدل استخدام OpenAI API، ودليل حدود معدل استخدام Claude API، ودليل حدود معدل استخدام Grok-3 API. النموذج الذهني هو نفسه عبر الموفرين؛ الأرقام والأبعاد المحددة ليست كذلك.

اقرأ حدودك الحالية من رؤوس الاستجابة

ليس عليك التنقيب في لوحات التحكم للعثور على حدودك الحالية. فكل استجابة من واجهة برمجة تطبيقات GPT تحملها في الرؤوس. ابحث عن هذه الأربعة:

• x-ratelimit-limit-requests: حد RPM الخاص بك لنقطة النهاية هذه.
• x-ratelimit-remaining-requests: عدد الطلبات المتبقية لديك لهذه الدقيقة.
• x-ratelimit-limit-tokens: حد TPM الخاص بك.
• x-ratelimit-remaining-tokens: عدد الرموز المتبقية لديك لهذه الدقيقة.

عادةً ما يكون هناك أيضًا x-ratelimit-reset-requests و x-ratelimit-reset-tokens، وكلاهما يعطيك مدة قابلة للقراءة حتى يتم إعادة تعبئة الحاوية (على سبيل المثال 6s، 1m30s).

أنظف طريقة لقراءة هذه البيانات هي إرسال طلب إكمال دردشة واحد، ومشاهدة الرؤوس تعود، والتأكد من أنك في المستوى الذي تعتقد أنك فيه. Apidog يجعل ذلك بنقرة واحدة.

الخطوة 1: تهيئة طلب GPT في Apidog

افتح Apidog، أنشئ مشروعًا جديدًا، وأضف طلبًا جديدًا بداخله.

الطريقة: POST عنوان URL: https://api.openai.com/v1/chat/completions

في تبويب الرؤوس (Headers):

تستمد صيغة الأقواس المزدوجة قيمتها من متغير بيئة Apidog، مما يعني أن مفتاحك لا يوجد أبدًا داخل الطلب نفسه. قم بتعيين المتغير مرة واحدة ضمن "البيئات" (Environments)، وقم بالتبديل بين البيئات للتبديل بين المفاتيح الشخصية ومفاتيح الفريق، وسيتم التقاط بقية المجموعة تلقائيًا. وتعمل نفس الحيلة لمعرفات المنظمة والمشروع التي تسمح لك OpenAI بتضمينها لإسناد الفواتير.

في تبويب "الجسم" (Body)، اختر JSON والصق:

{
 "model": "gpt-5.5",
 "messages": [
 {"role": "user", "content": "ping"}
 ],
 "max_tokens": 10
}

اضغط "إرسال" (Send). يجب أن تحصل على إكمال عادي. الآن انقر على تبويب "الرؤوس" (Headers) في لوحة الاستجابة وتصفح للوصول إلى الصفوف x-ratelimit-*. هذه الأرقام الأربعة هي حقيقتك الحالية. التقط لقطة شاشة لها. إنها الأساس الذي ستختبر عليه.

إذا كنت تفضل الاطلاع على إعداد طلب إكمال الدردشة بتفاصيل أكثر، فإن دليلنا حول كيفية اختبار ChatGPT API باستخدام Apidog يغطي المصادقة، والتدفق، واستدعاءات الأدوات بشكل شامل.

الخطوة 2: تأكيد الحدود بانفجار متعمد

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

يأتي Apidog مزودًا ببرنامج تشغيل الاختبارات (Tests runner) الذي يمكنه إطلاق نفس الطلب N مرة بشكل متزامن. افتح طلبك المحفوظ، وانقر على القائمة المنسدلة بجوار "إرسال" (Send)، واختر "تشغيل في سيناريو اختبار" (Run in Test Scenario). قم بتعيين ما يلي:

• التكرارات (Iterations): 50 (أو أي رقم يتجاوز RPM المحدد لديك بشكل مريح)
• التزامن (Concurrency): 10
• التأخير بين التكرارات (Delay between iterations): 0 ملي ثانية

قم بتشغيله. هناك نتيجتان مفيدتان:

1. بعض الطلبات تُرجع 429 قبل انتهاء الانفجار. جيد. هذا يؤكد أن الحد الأقصى من رأس الاستجابة وحالة حسابك متزامنان.
2. تنجح جميع الطلبات الـ 50 وتظهر الرؤوس remaining-requests تتناقص كما هو متوقع. معدل RPM لديك أعلى مما كنت تعتقد؛ تحقق من لوحة الاستجابة للحصول على القيمة الدقيقة.

يسجل برنامج تشغيل الاختبارات في Apidog كل استجابة، بحيث يمكنك الفرز حسب رمز الحالة وسحب كل 429 إلى عرض واحد. انقر على صف 429 واقرأ جسمه. يخبرك حقل message ما إذا كنت قد تجاوزت حد RPM أو TPM أو حدًا يوميًا. هذا هو البعد الذي تحدده في كود الإنتاج الخاص بك.

للحصول على مقدمة حول ما يجب فعله بمجرد تجاوز الحد، يتناول دليل تجاوز حد المعدل كل نوع من أخطاء 429 التي من المحتمل أن تراها.

الخطوة 3: فصل تجاوزات RPM عن تجاوزات TPM

يقيس الانفجار الأول أعلاه RPM، لأن كل طلب صغير جدًا. لاختبار TPM، تحتاج إلى إطلاق عدد أقل من الطلبات ولكن كل طلب يكون أكبر. قم بتحرير جسم طلبك بحيث تحمل messages حمولة أكبر بكثير:

{
 "model": "gpt-5.5",
 "messages": [
 {"role": "system", "content": "<3,000 tokens of context here>"},
 {"role": "user", "content": "Summarise the above in one sentence."}
 ],
 "max_tokens": 200
}

قم بتشغيل سيناريو آخر، هذه المرة ربما مع 20 تكرارًا بتزامن 5. إذا كنت في المستوى الأول بحد أقصى لـ TPM يبلغ 30 ألفًا، فسوف تتجاوز حدود الرموز قبل وقت طويل من تجاوز حدود الطلبات.

يعد هذا الفصل مهمًا لأن الحل مختلف. إذا كان عبء عملك الفعلي يرسل العديد من الطلبات الصغيرة، فقم بإصلاح RPM: ضع في قائمة الانتظار، أو دفعة، أو قم بالمباعدة. إذا كان يرسل عددًا أقل من الطلبات الكبيرة، فقم بإصلاح TPM: قص رسائل النظام، أو تخزين السياقات مؤقتًا باستخدام آلية prompt_cache، أو تقسيم الطلب.

الخطوة 4: محاكاة المستخدمين المتزامنين

تقيس اختبارات الانفجار الحد الأقصى الخاص بك. تبدو حركة مرور الإنتاج مختلفة: العديد من المستخدمين، وأحجام طلبات متغيرة، وانفجارات فوق خط أساس مستقر.

في Apidog، أنشئ سيناريو اختبار يقوم بالتكرار عبر ثلاثة أو أربعة اختلافات للطلب (صغير، متوسط، كبير) مع فترات انتظار عشوائية بين التكرارات. يدعم المُشغّل (runner) نصوص JavaScript قبل وبعد الطلب، بحيث يمكنك:

• اختيار طول رسالة عشوائي لكل تكرار.
• قراءة x-ratelimit-remaining-tokens بعد كل استجابة وإلغاء السيناريو عندما ينخفض ​​إلى ما دون عتبة معينة.
• تسجيل زمن الاستجابة بشكل منفصل للاستجابات 200 مقابل 429 حتى تتمكن من رؤية كيف يؤثر التقييد على p95.

عندما ينتهي السيناريو، يعطيك التقرير رسمًا بيانيًا لرموز الحالة. هذا الرسم البياني هو الأداة الأكثر فائدة التي يمكنك تثبيتها في دفتر التشغيل. في اللحظة التي يقول فيها زميل عمل "هل تم تقييد معدل طلباتنا؟"، يمكنك إعادة تشغيله ومقارنة النتائج.

ماذا تفعل عندما يتم تقييدك

بمجرد قياس مكان الحاجز، لديك ثلاثة خيارات صادقة.

التراجع. قم بتضمين كل استدعاء GPT في محاولة إعادة مع محاولة تراجع أسي. اقرأ رأس x-ratelimit-reset-tokens من استجابة 429 واستخدمه كتأخير لإعادة المحاولة الأولى؛ هذا الرأس هو إجابة OpenAI الحرفية على "انتظر هذه المدة". يعمل time.sleep(2 ** attempt) البسيط أيضًا، ولكنه يهدر ثوانٍ لم يكن عليك انتظارها.

قائمة الانتظار. إذا كانت حركة المرور لديك متقطعة، فضع الطلبات في قائمة انتظار وقم بتصريفها بمعدل أقل بقليل من الحد الأقصى الخاص بك. المحدد المستند إلى "دلو الرموز" (token-bucket limiter) والمثبت عند أقل بقليل من TPM الخاص بك هو النمط القياسي. نتعمق في مفاضلات التنفيذ في كيفية تنفيذ تحديد معدل واجهة برمجة التطبيقات وتنفيذ تحديد المعدل في واجهات برمجة التطبيقات.

الدفعة. تعمل واجهة برمجة تطبيقات الدفعات (Batch API) من OpenAI بحدود أعلى وبنصف سعر المكالمات المتزامنة. إذا كان عبء عملك يتحمل مهلة 24 ساعة (إثراء ليلي، تصنيف المستندات، إعادة بناء التضمينات)، فانقله إلى الدفعات وحرر حصتك المتزامنة لحركة المرور التي يواجهها المستخدم.

إذا كنت ترغب في قراءة أعمق حول التمييز بين التقييد (throttling) وتحديد المعدل (rate-limiting) قبل اختيار أحدهما، فإن التقييد مقابل تحديد المعدل هو أقصر طريق عبر المصطلحات.

أخطاء GPT 429 الشائعة وما تعنيه

تغطي ثلاث نكهات من أخطاء 429 حوالي 90% من الحالات الواقعية.

تم الوصول إلى حد المعدل ... على الطلبات في الدقيقة (RPM) يعني أن التعليمات البرمجية الخاصة بك تطلق عددًا كبيرًا جدًا من الاستدعاءات في الدقيقة بغض النظر عن حجمها. أضف التحكم في التزامن. لا تطلق كل سجل في map متوازية؛ حدد مجمع العاملين الخاص بك بـ RPM مقسومًا على عامل أمان اثنين.

تم الوصول إلى حد المعدل ... على الرموز في الدقيقة (TPM) يعني أن استدعاءاتك كبيرة جدًا. راجع الموجه (prompt). تأتي معظم تجاوزات TPM من موجهات النظام التي نمت بمرور الوقت أو من مسارات RAG التي تحشو مستندات كاملة في السياق. قم بالتقليم أو التخزين المؤقت أو التقسيم.

لقد تجاوزت حصتك الحالية، يرجى التحقق من خطتك وتفاصيل الفواتير يبدو وكأنه 429 ولكنه في الواقع حاجز فواتير، وليس حدًا للمعدل. لقد وصل حسابك إلى حد إنفاق شهري صارم، أو فشلت بطاقة الدفع المسجلة، أو وصل الرصيد المدفوع مسبقًا إلى الصفر. الحل يكمن في لوحة تحكم الفواتير، وليس في التعليمات البرمجية الخاصة بك.

الأسئلة الشائعة

هل يكلف Apidog أي شيء لاختبار حدود معدل GPT؟ لا. تغطي الخطة المجانية اختبار الطلبات الفردية وتشغيل الاختبارات المتزامنة الصغيرة. أنت تحتاج إلى خطة مدفوعة فقط إذا كنت تريد أحمال اختبار أكبر، أو مساحات عمل جماعية، أو عمليات تشغيل مجدولة. راجع تسعير Apidog للحصول على التفاصيل.

هل يمكنني اختبار حدود المعدل دون استهلاك رموز حقيقية؟ جزئيًا. أرخص فحص أساسي هو طلب لمرة واحدة مع max_tokens: 1 ورسالة مكونة من حرف واحد؛ يكلف أجزاء من سنت وتعود الرؤوس كاملة. بالنسبة لاختبارات الانفجار، فإنك تستهلك رموزًا حقيقية، ولكن يمكنك إبقاء كل استدعاء صغيرًا جدًا. إذا كنت تريد تجربة غير متصلة بالإنترنت بالكامل، فاستخدم خادم Apidog الوهمي لمحاكاة شكل استجابة 429 وإثبات أن منطق إعادة المحاولة الخاص بك يعمل دون استدعاء OpenAI على الإطلاق.

لماذا يبدو مفتاحي من المستوى الأول أبطأ من مفتاح زميل في المستوى الأول؟ حدود المستويات هي لكل منظمة، وليست لكل مفتاح. إذا كان مفتاحك في منظمة مشتركة مع مستخدمين آخرين كثيري الاستخدام، فأنت تتنافس مع حركة مرورهم. يمكن لـ Apidog إظهار ذلك بوضوح: قم بتشغيل نفس الطلب من كلا المفتاحين جنبًا إلى جنب وقارن تضاؤل x-ratelimit-remaining-tokens.

كيف أعرف أي نموذج لديه أي حد؟ اقرأ رؤوس الاستجابة. لا تثق بالجداول العامة في منشورات المدونات (بما في ذلك هذا المنشور). أرسل لكل نموذج طلبًا واحدًا رخيصًا من Apidog وسجل الرؤوس. يمكن أن تكون للنماذج التي تحمل نفس الاسم ولكن إصدارات لقطات مختلفة (على سبيل المثال gpt-5.5 مقابل gpt-5.5-0901) حدود مختلفة.

هل تُحتسب طلبات البث بشكل مختلف؟ نعم لـ TPM. يحجز طلب البث الرموز مقدمًا بناءً على max_tokens، لذلك يمكن أن تستهلك قيمة max_tokens الطويلة ميزانية TPM الخاصة بك حتى لو كان الإكمال الفعلي قصيرًا. قم بتخفيض max_tokens إلى أضيق سقف واقعي. نغطي سلوك البث في كيفية اختبار ChatGPT API باستخدام Apidog.

هل يمكنني مشاركة اختبار حد المعدل الخاص بـ Apidog مع فريقي؟ نعم. احفظ الطلب وسيناريو الاختبار في مشروع مشترك. يمكن لأي شخص في مساحة عملك تشغيل نفس الانفجار مقابل مفتاحه الخاص عن طريق تبديل البيئات. هذا يجعل سؤال "هل تم تقييد مفتاحي أم مفتاحهم؟" سؤالًا يستغرق 10 ثوانٍ.