أسطورة الـ serverless التي تقول "أنك تدفع فقط مقابل الملي ثانية التي يعمل فيها الكود الخاص بك" تنهار عندما تحاول تشغيل وكيل ذكاء اصطناعي (AI agent) على AWS Lambda. في الواقع، أكبر البنود في الفاتورة ليست رسوم الحوسبة في Lambda، بل زمن انتقال البداية الباردة (cold-start latency)، وحلقات إعادة المحاولة (retry loops)، واستهلاك الرموز (token usage) الذي تولده تلك الحلقات.

لماذا تضلل الصورة المعتادة للـ serverless وكلاء الذكاء الاصطناعي

يعامل معظم المطورين وظيفة Lambda كبيئة حوسبة معزولة (sandbox) بحتة: حافظ على سرعة المعالج (handler)، واضبط حجم ذاكرة معتدل، وراقب بقاء الفاتورة ثابتة. هذا ينجح مع نقاط نهاية HTTP البسيطة، ولكن الوكيل الذي يستدعي نموذج لغة، ويقيم الاستجابة، وربما يعيد محاولة الدورة بأكملها، لا يتطابق بنسبة واحد لواحد مع استدعاء Lambda واحد. يضاعف سير العمل الداخلي للوكيل عدد استدعاءات النموذج، وكل استدعاء إضافي يضيف تكلفة رموز (tokens) يمكن أن تطغى على رسوم الحوسبة.

البدايات الباردة هي السعر الخفي

عندما يتم توفير حاوية Lambda لأول مرة، يتعين عليها فك حزمة النشر (deployment package). يسحب الوكيل المعني مجموعة كبيرة من مكتبات Python، لذا قد تكون الصورة (image) كبيرة الحجم. إن استبعاد أدوات التطوير فقط — مثل مكتبة أتمتة المتصفح المستخدمة للاختبار المحلي فقط — يقلل من حجم الصورة، مما يؤدي بدوره إلى تقصير وقت فك الحزم. الحزمة الأكثر رشاقة تعني أن الوظيفة تصبح جاهزة للتعامل مع الطلب بشكل أسرع، مما يقلل الوقت المستغرق في انتظار تسخين الحاوية.

الرافعة الثانية هي مكان وجود كود التهيئة (initialization code). من خلال بناء مخطط الوكيل (agent's graph) عند وقت استيراد الوحدة (module import time)، يتم القيام بالعمل الشاق مرة واحدة لكل بدء تشغيل للحاوية بدلاً من كل طلب. الاستدعاءات الدافئة (Warm invocations) تتخطى هذا العمل تماماً. المقايضة هي بداية باردة أطول قليلاً، لكن العائد هو وقت إعداد يقترب من الصفر لكل طلب بعد أن تصبح الحاوية دافئة.

الذاكرة تعمل أيضاً كمقبض للتحكم في زمن الانتقال

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

تكلفة الحلقة: إعادة المحاولات تضاعف استهلاك الرموز

يتبع الوكيل حلقة "عامل-مقيم" (worker-evaluator loop). يقوم العامل بإنشاء استجابة، ويقوم المقيم بفحصها، وإذا أشار المقيم إلى وجود خطأ، يتم إرسال المهمة مرة أخرى إلى العامل. يمكن أن تتكرر الحلقة ما يصل إلى خمس مرات قبل الاستسلام. هذا يعني أن طلباً خارجياً واحداً يمكن أن يؤدي إلى:

  • ما يصل إلى خمس استدعاءات لنموذج العامل
  • ما يصل إلى خمس استدعاءات لنموذج المقيم
  • أي عدد من استدعاءات الأدوات التي يقرر الوكيل القيام بها

تظل فاتورة Lambda قابلة للتنبؤ لأن AWS تفرض رسوماً حسب الملي ثانية من التنفيذ، ولكن فاتورة الرموز (tokens) يمكن أن تتأرجح بشكل كبير اعتماداً على عدد مرات إعادة المحاولة المطلوبة.

فخ انتهاء المهلة: API Gateway مقابل Lambda

يفرض API Gateway مهلة زمنية صارمة مدتها 29 ثانية على طلب HTTP الذي يمثله. يمكن لحلقة وكيل مكونة من خمس دورات أن تتجاوز هذا الحد بسهولة، حتى لو تم تكوين وظيفة Lambda الأساسية لنافذة تنفيذ مدتها خمس دقائق. تجاوز API Gateway باستخدام روابط وظائف Lambda (Lambda Function URLs) يزيل سقف الـ 29 ثانية، مما يسمح للوظيفة بإنهاء حلقتها دون انقطاع.

ما يجب على المطورين تخصيص ميزانية له

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

  • حجم حزمة النشر وزمن انتقال البداية الباردة الناتج عنها
  • إعداد الذاكرة الذي يحدد وحدة المعالجة المركزية وبالتالي سرعة الاستيراد
  • العدد المتوقع لإعادة المحاولات في حلقة "العامل-المقيم"، والتي تدفع استهلاك الرموز بشكل مباشر
  • اختيار الواجهة الأمامية (API Gateway مقابل Function URL) لتجنب انتهاء المهلة المبكر

تجاهل أي من هذه المتغيرات قد يتركك مع فاتورة لا تشبه إطلاقاً تلك التي توقعتها.