تسعة وكلاء ذكاء اصطناعي وحصة API واحدة: كيف يمنع Rate Governor الأعطال المتسلسلة

عندما يعمل تسعة وكلاء ذكاء اصطناعي في نظام واحد مع حصة مشتركة من واجهة برمجة التطبيقات، تفشل آليات الحماية القياسية. رسالة خطأ واحدة من نوع 429 Too Many Requests تطلق سلسلة من التفاعلات التي قد تُعطل النظام بأكمله. دعونا نحلل السبب في حدوث ذلك وما يجب فعله حيال ذلك.

لماذا لا يحل Jitter المشكلة

في خدمة واحدة، يُعتبر الرجوع الأسي مع التشويش العشوائي (exponential backoff مع jitter) طريقة موثوقة للحماية من الإفراط في استخدام واجهة برمجة التطبيقات. يتلقى الوكيل خطأ 429، ينتظر فترة عشوائية، ويعيد محاولة الطلب. تُوزع الحمل عبر الوقت، ويتم تنعيم الذروة. هذا يعمل عندما يكون هناك وكيل واحد فقط. لكن عندما يشارك تسعة وكلاء حصة واحدة ويطبقون نفس الاستراتيجية، تتغير الرياضيات.

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

• الوكيل أ ينتظر 1.2 ثانية ويعيد المحاولة
• الوكلاء ب، ج، د ينتظرون 0.8–1.5 ثانية ويعيدون المحاولة أيضاً
• إجمالي الحمل أثناء "موجة إعادة المحاولة" يتجاوز الحصة
• موجة جديدة من أخطاء 429 — والدورة تتكرر من جديد

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

بنية Rate Governor

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

العناصر الرئيسية للبنية:

• تجمع الرموز المشترك — عداد واحد للحصة المتاحة، يُحدّث في الوقت الفعلي لجميع الوكلاء
• نظام الأولويات — تحصل المهام الحرجة (رد المستخدم) على الرموز قبل المهام الخلفية (الفهرسة، إثراء البيانات)
• فاصل الدائرة التنبؤي — لا ينتظر أول خطأ 429، بل يتنبأ بالتجاوز بناءً على معدل الطلب الحالي ويقلل التخصيص بشكل استباقي
• بث الحالة — يخطر Governor جميع الوكلاء بالحالة الحالية للحصة حتى يتمكنوا من تكييف تكرار الطلبات بشكل استباقي

يقطع هذا النهج الحلقة المفرغة: لا يتخذ الوكلاء قرارات مستقلة بشأن إعادة المحاولات؛ بل يتنسقون عبر مكون مشترك.

فاصل الدائرة التنبؤي

يتم تفعيل فاصل الدائرة الكلاسيكي بشكل تفاعلي — فقط بعد تلقي خطأ. في نظام متعدد الوكلاء، يحدث هذا متأخراً جداً: عند وصول أول خطأ 429، يكون عدة وكلاء قد وضعوا بالفعل طلبات إعادة محاولة في الطابور. تتبع النسخة التنبؤية معدل استهلاك الرموز. إذا تم استهلاك 80% من الحصة في آخر 10 ثوان، يدخل Governor استباقياً وضع الاختناق — يقلل التخصيص للوكلاء ذوي الأولوية المنخفضة ويعلمهم بالتغيير. يتم تنعيم منحنى الحمل قبل استنزاف حد واجهة برمجة التطبيقات، وقد لا تظهر أخطاء 429 على الإطلاق.

يغير فاصل الدائرة التنبؤي منطق النظام: بدلاً من "لننتظر الخطأ"، نحصل على "لنمنع الخطأ". يتطلب هذا قياس الجودة المستمر — يجب أن يعرف Governor عدد الرموز التي استهلكها كل وكيل في نافذة زمنية متحركة.

"المشكلة ليست في أن كل وكيل يفعل شيئاً خاطئاً. المشكلة هي أن السلوك

الصحيح لتسعة وكلاء في نفس الوقت يتحول إلى سلوك جماعي خاطئ."

ما معنى هذا

Rate Governor هو عنصر إلزامي في أي نظام متعدد الوكلاء مع حد مشترك لواجهة برمجة التطبيقات. بدونه، تعديل عدد الوكلاء لا يحسن الأداء: كل وكيل جديد يزيد فقط من فوضى الأعطال. منسق مركزي مع أولويات وإدارة تنبؤية يحول النظام من صراع مستمر ضد أخطاء 429 إلى عمل مستقر تحت الحمل الحقيقي. هذا مهم بشكل خاص عندما يؤدي الوكلاء مهام ذات أهمية حرجة مختلفة — يضمن المنسق أن العمل العاجل يتم خدمته دائماً أولاً.