سيصطدم الذكاء الاصطناعي الوكيلي بحاجز البنية التحتية قبل أن يصطدم بحاجز الذكاء

تتحسن النماذج بوتيرة أسرع من قدرتنا على تلبية ما يُطلب منها.

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

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

روبوت المحادثة والوكيل عبئان مختلفان على النظام

الطلب الحواري هو تواصل ذهابًا وإيابًا مرة واحدة: يُرسل الطلب، وتُستقبل الرموز، ثم يُغلق الاتصال. ويمكنك تجميع الطلبات، وتخزين البادئة مؤقتًا، وقياس معدل الإنجاز برقم واحد.

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

ويكتسب هذا الاختلاف أهميته لسبب لا علاقة له بالذكاء. فبين الخطوات، يحتفظ الوكيل بالحالة: المحادثة، ومخرجات الأدوات، والاستدلال المتراكم. وعلى جانب تقديم الخدمة، تُخزَّن هذه الحالة في ذاكرة وحدة معالجة الرسومات على هيئة ذاكرة التخزين المؤقت للمفاتيح والقيم، وتشغل مساحة من الذاكرة طوال مدة الجلسة، بما في ذلك الثواني التي يقضيها الوكيل في انتظار واجهة برمجة تطبيقات لا تديرها أنت.

وهكذا، لا تعود وحدة قياس السعة هي «الطلبات في الثانية»، بل تصبح «الجلسات المتزامنة المقيمة في الذاكرة». فقد يتمكن نظام يعالج ألف طلب حواري في الثانية بسهولة من خدمة بضع عشرات فقط من جلسات الوكلاء المتزامنة على الأجهزة نفسها.

الانتظار هو الجزء الأعلى كلفة

إليك الجانب المقلق: أثناء استدعاء أداة، لا يفعل الوكيل شيئًا. فلا تُولَّد أي رموز، ولا تُستهلك أي قدرة حاسوبية. ومع ذلك، تظل ذاكرة وحدة معالجة الرسومات مشغولة، لأن إخلاء هذا السياق وإعادة حسابه سيكلفان أكثر من الاحتفاظ به.

تُحجز أغلى أجهزتك لطلب ينتظر، في تلك اللحظة، نتيجة استعلام إلى قاعدة بيانات.

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

التنفيذ المتسلسل يزيد المشكلة سوءًا بلا داعٍ

تنفذ أطر عمل الوكلاء استدعاءات الأدوات واحدًا تلو الآخر في معظم الحالات. يطلب النموذج البحث عن حالة الطقس، فيحصل عليها؛ ثم يطلب التحقق من التقويم، فيحصل على النتيجة؛ ثم يطلب البحث عن رحلة طيران، فيحصل عليها.

وكثيرًا ما لا تعتمد هذه الاستدعاءات الثلاثة بعضها على بعض، وكان بإمكانها أن تُنفَّذ في الوقت نفسه. عند تنفيذها بالتتابع، يساوي زمن الاستجابة مجموع أزمنتها؛ أما عند تنفيذها بالتوازي، فيساوي زمن الاستجابة أطولها.

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

إذا خفّضت مدة الجلسة إلى النصف، فستضاعف تقريبًا السعة المتزامنة، باستخدام وحدات معالجة الرسومات نفسها، ومن دون أي تغيير في النموذج.

تتراكم محاولات الإعادة على نحو لم يصممه أحد

ترث أطر عمل الوكلاء إعدادات إعادة المحاولة الافتراضية من مكتبات HTTP التي تعتمد عليها. وغالبًا ما تكون ثلاث محاولات.

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

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

عندما يتباطأ أحد التبعيات، يؤدي هذا التضخيم إلى تحويل التدهور في الأداء إلى انقطاع للخدمة، وذلك بكلفة لكل محاولة تزيد بمراتب عدة على كلفة إعادة محاولة استدعاء REST.

كيف يبدو هذا الحاجز فعليًا

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

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

في هذه المرحلة، تتوقف بهدوء كثير من العروض التجريبية الداخلية الواعدة.

ما الذي يزيح هذا الحاجز؟

لا شيء غير مألوف، وكل ذلك يتعلق بالبنية التحتية لا بالنمذجة:

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

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

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

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

اجعل إخلاء السياق قليل التكلفة. استخدم ذاكرة KV مؤقتة مكمّمة، وانتباهًا مُقسّمًا إلى صفحات، ومسارات لنقل الجلسات الخاملة إلى مخازن أخرى. هنا يدور الآن أكثر العمل إثارة للاهتمام في مجال تقديم النماذج.

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

نشرت نموذج التنفيذ الذي يستند إليه الاستنتاج الأخير — أي التنفيذ المتزامن لاستدعاءات النماذج المترابطة ضمن ميزانية زمنية واحدة — في «تنفيذ رسوم الاستدلال غير المتزامن لتوجيه النماذج في أنظمة التعلم الآلي»، في المجلد 72، العدد 10 من International Journal of Computer Trends and Technology، أكتوبر 2024. وللاطلاع على دمج النماذج التوليدية في أنظمة اتخاذ القرار المقيّدة بزمن الاستجابة تحديدًا، انظر «منصات التداول واتخاذ القرار المعززة بالنماذج اللغوية الكبيرة: وصل الذكاء التوليدي بأنظمة القرارات المالية»، في المجلد 11، العدد 1s من Journal of Information Systems Engineering and Management، 2026.