هل بلغت حد RPM أم TPM؟
تطبّق OpenAI حدين: عدد الطلبات في الدقيقة وعدد التوكنات في الدقيقة. قد تبلغ TPM بعد بضعة طلبات تحمل مستندات طويلة، بينما تبلغ تطبيقات الدردشة ذات الطلبات القصيرة حد RPM أولاً. راجع الترويسات ونمط الاستخدام: عالج RPM بمباعدة الطلبات، وعالج TPM باختصار التعليمات وضبط max_tokens.
وتذكّر أن عدة خدمات قد تستخدم مفتاح API أو مشروعاً واحداً، فتُحتسب طلباتها معاً حتى لو كان حمل كل خدمة منفردة ضمن الحد.
الخطأ الذي سيظهر لك
{
"error": {
"message": "Rate limit reached for requests",
"type": "rate_limit_exceeded",
"code": "rate_limit_exceeded"
}
}
لا تخلطه بخطأ insufficient_quota الذي يستخدم الحالة 429 أيضاً، لكنه يدل على الحصة أو الفوترة ولا يفيده الانتظار. افحص نوع الخطأ في جسم الرد.
إعادة محاولة متدرجة
# Python — exponential backoff with full jitter
import random, time
from openai import OpenAI, RateLimitError
client = OpenAI()
def create_with_backoff(max_retries=6, **kwargs):
for attempt in range(max_retries):
try:
return client.chat.completions.create(**kwargs)
except RateLimitError as e:
if "insufficient_quota" in str(e):
raise # billing — waiting won't help
wait = min(60, 2 ** attempt) * random.random()
time.sleep(wait) # jitter prevents retry stampedes
raise RuntimeError("still rate-limited after retries")
أضف تفاوتاً عشوائياً إلى مدة الانتظار حتى لا تعيد جميع العمليات المحاولة في اللحظة نفسها وتبلغ الحد من جديد.
القريب 503: "Slow Down"
قد تؤدي الزيادة المفاجئة في الحركة إلى خطأ 503 بدلاً من 429. توصي OpenAI بالعودة إلى معدل الطلبات السابق وتثبيته 15 دقيقة على الأقل، ثم الزيادة تدريجياً.
حين تكون أخطاء 429 مزمنة لا عرَضية
تفيد إعادة المحاولة في الارتفاعات المؤقتة. أما إذا تكرر الخطأ كل ساعة، فاضبط الحمل بطابور وتخزين مؤقت للتعليمات المتكررة، وافصل الأحمال المختلفة في مشاريع مستقلة عند الحاجة، أو وجّه المهام المناسبة إلى نموذج أقل كلفة. استخدم ترتيب النماذج لبناء قائمة بدائل والحاسبة لمقارنة التكلفة.