DEV Community

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

Posted on • Originally published at apidog.com

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

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

جرّب Apidog اليوم

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

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

القيود الأربعة التي تحتاج إلى قياسها

تطبق OpenAI عدة حدود على كل مفتاح API. في تطبيق إنتاجي، راقب هذه الأبعاد تحديدًا:

  • RPM: عدد الطلبات في الدقيقة.
  • TPM: إجمالي رموز الإدخال والإخراج في الدقيقة.
  • RPD: عدد الطلبات في اليوم، ويظهر غالبًا في المستويات المجانية أو الأولى.
  • IPM / TPD / حدود الدفعات: حدود خاصة بنقاط نهاية الصور، الصوت، التضمينات، والـ Batch API.

عند تجاوز الحد، تحصل عادةً على 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"
  }
}
Enter fullscreen mode Exit fullscreen mode

لا تتعامل مع 429 كخطأ واحد. اقرأ الحقول التالية أولًا:

  • type: هل المشكلة في tokens أم requests؟
  • message: يوضح البعد الذي تم تجاوزه، مثل TPM أو RPM.
  • code: غالبًا rate_limit_exceeded، لكنه قد يشير أحيانًا إلى مشكلة حصة أو فوترة.

للمرجع العام حول HTTP 429 راجع وثائق MDN 429 ومواصفات RFC 6585. وللسلوك الخاص بـ OpenAI، راجع صفحة حدود المعدل الرسمية.

كيف تعمل المستويات

يقع مفتاح GPT API ضمن مستوى استخدام OpenAI. المستوى يحدد الحدود الفعلية مثل RPM وTPM. الانتقال بين المستويات يعتمد عادةً على:

  1. إجمالي الإنفاق.
  2. مرور مدة معينة منذ أول دفعة.

صورة تقريبية لمستويات نماذج النصوص:

المستوى عتبة الإنفاق عتبة الانتظار طلبات نصية في الدقيقة رموز نصية في الدقيقة
مجاني لا يوجد لا يوجد 3 40k
1 5 دولارات مدفوعة لا يوجد 500 30k–200k حسب النموذج
2 50 دولارًا مدفوعة 7 أيام 5,000 450k
3 100 دولار مدفوعة 7 أيام 5,000 1M
4 250 دولارًا مدفوعة 14 يومًا 10,000 2M
5 1,000 دولار مدفوعة 30 يومًا 10,000 2M+

هذه الأرقام توضيحية. لا تبنِ تصميم الإنتاج عليها مباشرة. اقرأ الحدود الحالية من لوحة التحكم أو من رؤوس الاستجابة قبل تقدير السعة.

تبعات عملية مهمة:

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

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

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

كل استجابة من واجهة GPT API تحتوي غالبًا على رؤوس تحدد الحدود الحالية. راقب هذه الرؤوس:

  • x-ratelimit-limit-requests: حد الطلبات.
  • x-ratelimit-remaining-requests: الطلبات المتبقية في النافذة الحالية.
  • x-ratelimit-limit-tokens: حد الرموز.
  • x-ratelimit-remaining-tokens: الرموز المتبقية.
  • x-ratelimit-reset-requests: متى تتم إعادة تعبئة حاوية الطلبات.
  • x-ratelimit-reset-tokens: متى تتم إعادة تعبئة حاوية الرموز.

مثال قيم قد تراها:

x-ratelimit-limit-requests: 500
x-ratelimit-remaining-requests: 499
x-ratelimit-limit-tokens: 30000
x-ratelimit-remaining-tokens: 29840
x-ratelimit-reset-requests: 6s
x-ratelimit-reset-tokens: 1m30s
Enter fullscreen mode Exit fullscreen mode

هذه القيم هي المصدر العملي للحقيقة عند اختبار نموذج أو مفتاح أو منظمة.

الخطوة 1: إنشاء طلب GPT في Apidog

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

استخدم:

POST https://api.openai.com/v1/chat/completions
Enter fullscreen mode Exit fullscreen mode

في تبويب Headers أضف:

المفتاح القيمة
Authorization Bearer {{OPENAI_API_KEY}}
Content-Type application/json

استخدم متغير البيئة {{OPENAI_API_KEY}} بدل لصق المفتاح داخل الطلب. بهذه الطريقة يمكنك التبديل بين مفاتيح شخصية، مفاتيح فريق، أو بيئات مختلفة دون تعديل الطلب نفسه.

في تبويب Body اختر JSON واستخدم طلبًا صغيرًا:

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

اضغط Send، ثم افتح تبويب Headers في الاستجابة وابحث عن:

x-ratelimit-limit-requests
x-ratelimit-remaining-requests
x-ratelimit-limit-tokens
x-ratelimit-remaining-tokens
Enter fullscreen mode Exit fullscreen mode

احفظ هذه القيم. ستستخدمها كأساس في اختبارات التحميل التالية.

إذا أردت إعدادًا أوسع يتضمن المصادقة، التدفق، واستدعاءات الأدوات، راجع دليل اختبار ChatGPT API باستخدام Apidog.

الخطوة 2: تأكيد حد RPM بانفجار طلبات صغير

قراءة الرؤوس تخبرك بالحد النظري. لاختبار السلوك عند الاقتراب من الحد، شغّل انفجارًا صغيرًا من الطلبات.

في Apidog:

  1. افتح الطلب المحفوظ.
  2. افتح القائمة بجوار Send.
  3. اختر Run in Test Scenario.
  4. اضبط السيناريو مثلًا على:
الإعداد القيمة
Iterations 50
Concurrency 10
Delay between iterations 0ms

استخدم طلبًا صغيرًا مثل ping حتى يكون الاختبار أقرب إلى اختبار RPM وليس TPM.

النتائج المحتملة:

  1. ظهور 429 أثناء الاختبار

    هذا يؤكد أن حد الطلبات يبدأ عند النقطة التي تشير إليها الرؤوس.

  2. نجاح كل الطلبات

    قد يكون حد RPM أعلى مما توقعت. راجع رؤوس الاستجابة للحصول على القيمة الفعلية.

بعد التشغيل، رتّب النتائج حسب رمز الحالة وافتح أي استجابة 429. اقرأ message لمعرفة هل السبب requests per min أم شيء آخر.

للتعامل مع أخطاء 429 بعد ظهورها، راجع دليل تجاوز حد المعدل.

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

اختبار الانفجار السابق يستخدم طلبات صغيرة، لذلك يقيس غالبًا حد RPM. لاختبار TPM، استخدم طلبات أقل ولكن بحمولة نصية أكبر.

عدّل الجسم مثلًا:

{
  "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
}
Enter fullscreen mode Exit fullscreen mode

ثم شغّل سيناريو أخف:

الإعداد القيمة
Iterations 20
Concurrency 5
Delay between iterations 0ms

إذا كان حد TPM منخفضًا، سترى أخطاء 429 بسبب الرموز قبل الوصول إلى حد الطلبات.

قاعدة القرار:

  • إذا ظهرت المشكلة بسبب RPM: قلل التزامن، أضف طابورًا، أو وزّع الطلبات زمنيًا.
  • إذا ظهرت المشكلة بسبب TPM: قلل حجم الموجه، قص السياق، استخدم التخزين المؤقت عند الإمكان، أو قسّم الطلب إلى مراحل أصغر.

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

اختبار الانفجار جيد لتأكيد الحد، لكنه لا يشبه الإنتاج دائمًا. في الإنتاج لديك:

  • مستخدمون متزامنون.
  • أحجام طلبات مختلفة.
  • انفجارات قصيرة فوق حمل ثابت.
  • موجهات قصيرة وطويلة حسب الحالة.

في Apidog، أنشئ سيناريو اختبار يتناوب بين عدة نسخ من الطلب:

  1. طلب صغير.
  2. طلب متوسط.
  3. طلب كبير.

يمكنك استخدام سكربتات JavaScript قبل وبعد الطلب من أجل:

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

مثال منطق بسيط بعد الاستجابة:

const remainingTokens = Number(response.headers.get("x-ratelimit-remaining-tokens"));

if (!Number.isNaN(remainingTokens) && remainingTokens < 1000) {
  console.log("Remaining tokens are below threshold:", remainingTokens);
}
Enter fullscreen mode Exit fullscreen mode

بعد انتهاء السيناريو، استخدم تقرير رموز الحالة لمعرفة:

  • متى بدأت 429.
  • هل المشكلة مرتبطة بالطلبات أم الرموز.
  • هل p95 latency يتدهور قبل ظهور التقييد.

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

ماذا تفعل عند ظهور 429

بعد تحديد الحد الذي اصطدمت به، طبّق العلاج المناسب.

1. استخدم التراجع وإعادة المحاولة

عند ظهور 429، لا تعِد المحاولة فورًا. اقرأ رؤوس إعادة التعيين واستخدمها لتحديد الانتظار.

مثال Python مبسط:

import time
import requests

def call_with_retry(url, headers, payload, max_retries=5):
    for attempt in range(max_retries):
        response = requests.post(url, headers=headers, json=payload)

        if response.status_code != 429:
            return response

        reset_tokens = response.headers.get("x-ratelimit-reset-tokens")
        reset_requests = response.headers.get("x-ratelimit-reset-requests")

        # fallback بسيط إذا لم تتمكن من تحويل قيمة الرأس
        delay = min(2 ** attempt, 30)

        print(f"Rate limited. Retry in {delay}s. reset_tokens={reset_tokens}, reset_requests={reset_requests}")
        time.sleep(delay)

    return response
Enter fullscreen mode Exit fullscreen mode

استخدام 2 ** attempt أفضل من إعادة المحاولة الفورية، لكن الأفضل هو الاعتماد على x-ratelimit-reset-* عندما تستطيع تحويله إلى مدة قابلة للاستخدام.

2. ضع الطلبات في قائمة انتظار

إذا كانت حركة المرور متقطعة، ضع الطلبات في queue وصرّفها بمعدل أقل من الحد الأقصى.

النمط العملي:

  • اضبط حدًا داخليًا أقل من حد OpenAI الحقيقي.
  • استخدم عامل أمان مثل 70% أو 80% من الحد.
  • افصل بين محدد RPM ومحدد TPM.

مثال شبه منطقي:

allowed_rpm = openai_rpm_limit * 0.8
allowed_tpm = openai_tpm_limit * 0.8

قبل إرسال أي طلب:
  - تحقق من عدد الطلبات المستخدمة في آخر دقيقة
  - تحقق من عدد الرموز المتوقع استخدامها
  - إذا تجاوزت الحد الداخلي، انتظر أو أدخل الطلب في queue
Enter fullscreen mode Exit fullscreen mode

للتعمق في أنماط التنفيذ، راجع كيفية تنفيذ تحديد معدل واجهة برمجة التطبيقات وتنفيذ تحديد المعدل في واجهات برمجة التطبيقات.

3. استخدم Batch API للأعمال غير المتزامنة

إذا كان عبء العمل لا يحتاج استجابة فورية، مثل:

  • إثراء بيانات ليلية.
  • تصنيف مستندات.
  • إعادة بناء تضمينات.
  • معالجة ملفات كبيرة.

فانقله إلى Batch API بدل استهلاك حصتك المتزامنة الخاصة بتجربة المستخدم.

للتفريق بين التقييد وتحديد المعدل، راجع التقييد مقابل تحديد المعدل.

أخطاء GPT 429 الشائعة

Rate limit reached ... on requests per min (RPM)

المشكلة: عدد الاستدعاءات في الدقيقة كبير جدًا.

الحلول:

  • قلل التزامن.
  • لا تستخدم map متوازية على كل السجلات دفعة واحدة.
  • استخدم worker pool بحجم محسوب.
  • أضف queue أمام استدعاءات GPT.

قاعدة بسيطة:

max_workers = floor(RPM / 2)
Enter fullscreen mode Exit fullscreen mode

استخدم عامل أمان، خصوصًا إذا كانت هناك خدمات أخرى تشارك نفس المنظمة أو المفتاح.

Rate limit reached ... on tokens per min (TPM)

المشكلة: الطلبات تستهلك رموزًا كثيرة.

الحلول:

  • قلل طول system prompt.
  • لا ترسل مستندات كاملة داخل السياق دون تقطيع.
  • قلل max_tokens.
  • اختصر نتائج RAG.
  • خزّن الأجزاء الثابتة عند توفر آلية مناسبة.
  • قسّم الطلب الكبير إلى طلبات أصغر إذا كان ذلك مناسبًا.

You exceeded your current quota, please check your plan and billing details

هذا يبدو مثل 429، لكنه غالبًا ليس مشكلة rate limit تشغيلية. تحقق من:

  • حد الإنفاق الشهري.
  • بطاقة الدفع.
  • الرصيد المدفوع مسبقًا.
  • حالة الفوترة.

الحل هنا في لوحة الفوترة، وليس في إعادة المحاولة أو تقليل التزامن.

قائمة تحقق سريعة قبل نشر ميزة تستخدم GPT

استخدم هذه القائمة قبل الإطلاق:

  • [ ] أرسلت طلبًا واحدًا لكل نموذج مستخدم وقرأت رؤوس x-ratelimit-*.
  • [ ] خزّنت قيم RPM وTPM الحالية في وثائق الفريق.
  • [ ] شغّلت اختبار RPM بطلب صغير.
  • [ ] شغّلت اختبار TPM بطلب كبير.
  • [ ] أضفت retry مع backoff.
  • [ ] أضفت queue أو limiter إذا كانت الحركة متقطعة.
  • [ ] قللت max_tokens إلى سقف واقعي.
  • [ ] عزلت مفاتيح الإنتاج عن مفاتيح الاختبار عند الحاجة.
  • [ ] حفظت سيناريو Apidog في مشروع مشترك للفريق.

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

هل يكلف Apidog أي شيء لاختبار حدود معدل GPT؟

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

هل يمكنني اختبار حدود المعدل دون استهلاك رموز حقيقية؟

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

لماذا يبدو مفتاحي من المستوى الأول أبطأ من مفتاح زميل في المستوى نفسه؟

لأن الحدود غالبًا على مستوى المنظمة، لا المفتاح فقط. إذا كان مفتاحك داخل منظمة مشتركة مع استخدام كثيف، فأنت تشارك نفس الحصة. شغّل نفس الطلب من المفتاحين وقارن x-ratelimit-remaining-tokens.

كيف أعرف حد كل نموذج؟

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

هل تُحتسب طلبات البث بشكل مختلف؟

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

هل يمكنني مشاركة اختبار حد المعدل مع فريقي؟

نعم. احفظ الطلب وسيناريو الاختبار في مشروع Apidog مشترك. يمكن لكل عضو تشغيل الاختبار بمفتاحه عبر تبديل البيئة، مما يجعل تشخيص "هل المشكلة في مفتاحي أم في المفتاح العام؟" أسرع بكثير.

Top comments (0)