التعامل مع AI APIs· الدرس 5 من 7
- 1أول Call — تنادي الموديل من كودّك7 دقيقة
- 2الـ Streaming — الرد بيوصل كلمة كلمة7 دقيقة
- 3الـ Structured Outputs — تطلّع JSON تقدر تعتمد عليه8 دقيقة
- 4الأخطاء والـ Retries — لمّا الـ call يقع9 دقيقة
- 5الـ Rate Limits — سقف الطلبات في الدقيقة6 دقيقة
- 6المفاتيح والـ Secrets — تأمين مفتاح الـ API6 دقيقة
- 7الـ Timeouts والـ Idempotency — طلبات ما تتكرّرش بالغلط8 دقيقة
الـ Rate Limits — سقف الطلبات في الدقيقة
في سطر واحد · كل مزوّد بيحطّ سقف لعدد الطلبات والـ tokens اللي تبعتها في الدقيقة، ولو عدّيته بيرجّعلك 429 ويرفض الطلب.
أول ما منتجك يكبر أو يجيله ضغط مفاجئ، الـ rate limit هو أول حاجة هتضربك. لو مش مستعدّله، مستخدمينك هيشوفوا أخطاء في أهم لحظة.
زي كوبري عليه لافتة «٥٠ عربية في الدقيقة»: العربيات الزيادة بتستنّى في الطابور. لو عايز تعدّي أكتر، يا إمّا تنظّم المرور يا إمّا تطلب كوبري أوسع.
زي عدّادات محطة البنزين: المحطة تقدر تخدم عدد معيّن من العربيات في الساعة، وأي زيادة بتقف في الطابور. مينفعش تعدّي بالعافية — يا بتنظّم دخول العربيات يا بتفتح عدّادات أكتر.
بتبعت ١٠٠ طلب مرّة واحدة والسقف ٦٠ في الدقيقة، فالباقي يرجع 429 — والرد بيجيبلك header اسمه Retry-After بيقولك تستنّى كام ثانية بالظبط، فتحترمه بدل ما تخبط عشوائي؛ والحل الأشمل إنك توزّعهم على الوقت (queue) أو تطلب رفع الـ limit من المزوّد.
المزوّد بيعدّ لكل مفتاح في كل نافذة زمنية حاجتين: عدد الطلبات في الدقيقة (RPM) وعدد الـ tokens في الدقيقة (TPM) — وتعدّي أي واحد فيهم يرجّعلك 429، غالبًا ومعاه Retry-After. الردود كتير بتيجي فيها headers بتقولك فاضلّك كام من الرصيد، فتقدر تراقب قبل ما تخبط في السقف. عندك على الكلاينت بتحطّ queue بينظّم إيقاع الإرسال وconcurrency limit، وعلى المدى الأطول بتطلب من المزوّد tier أعلى.
🧪 جرّب بنفسك: عندك ٢٠ طلب وسقف وهمي ٥ طلبات في الدقيقة — ابني queue صغيرة بتبعتهم على دفعات وتستنّى بين كل دفعة، ولو رجع 429 بتحترم الـ Retry-After. قارن الزمن الكلي بالنسخة اللي بتبعت الكل مرة واحدة وتشوف كام طلب فشل.
(١) تعمل Promise.all على ٢٠٠ عنصر من غير أي حد للتزامن — أول دفعة بتاكل السقف والباقي كله 429. (٢) تنسى الـ TPM: شوية طلبات بـ prompts ضخمة بتخبط في سقف الـ tokens قبل سقف عدد الطلبات بكتير. (٣) تتعامل مع الـ 429 كأنه bug وتعيد فورًا في loop — كده بتطوّل عقوبتك بدل ما تستنّى الـ Retry-After.
أي batch job أو منتج عليه traffic حقيقي — ابني الـ throttling قبل الإطلاق، لأن أول spike هو اللي هيكشفك.
prototype صغير بيبعت طلب ورا طلب مش هيلمس الحدود — متبنيش queue system بدري على الفاضي. بس خلّي معالجة الـ 429 موجودة من أول يوم، لأنها سطور قليلة وبتفرق وقت اللزمة.