AWS تستعرض خمسة أنماط لمرونة التطبيقات التوليدية للذكاء الاصطناعي على Amazon Bedrock

نشرت مدونة AWS Machine Learning تحليلًا لخمسة أنماط عملية لبناء تطبيقات ذكاء اصطناعي توليدي مرنة وقادرة على الصمود على Amazon Bedrock، بدءًا من الميزات المدمجة في الخدمة وصولًا إلى تنسيق عدة نماذج عبر بوابة LLM.

ما المشكلات التي تعالجها هذه الأنماط؟

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

من ميزات Bedrock المدمجة إلى بوابة LLM

تترتب الأنماط بحسب تعقيدها المتزايد. يبدأ المسار من الإمكانات الأصلية في Amazon Bedrock، وهي خدمة مُدارة من AWS للوصول إلى النماذج الأساسية عبر واجهة API موحدة، وينتهي بالتنسيق متعدد النماذج عبر بوابة LLM مستقلة قادرة على توزيع الطلبات بين عدة نماذج ومزودين. صُمّم هذا التدرج بوصفه خطة تطبيق عملية: يمكن للفريق أن يبدأ بآليات Bedrock المدمجة البسيطة، ثم يضيف بنية تحتية أكثر تعقيدًا تدريجيًا، ولا يفعل ذلك إلا حين يتطلبه الحمل ومتطلبات الموثوقية فعلًا.

• يصف المقال خمسة أنماط لمرونة تطبيقات الذكاء الاصطناعي التوليدي على AWS
• يتدرج المسار من الميزات الأصلية في Amazon Bedrock إلى بوابة LLM مع تنسيق متعدد النماذج
• إحدى المشكلات المعالجة هي استنفاد الحصص عند ارتفاعات الحركة المفاجئة
• المشكلة الثانية هي توافر الخدمة عبر التوزيع الجغرافي للاستدلال
• المشكلة الثالثة هي تأثير «الجار المزعج» في البيئات متعددة المستأجرين

لماذا يهم ذلك مهندسي أنظمة الإنتاج؟

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

يستحق دور بوابة LLM بوصفها المرحلة الأخيرة في هذا التدرج اهتمامًا خاصًا. تعمل هذه البوابة طبقةً وسيطة بين التطبيق وعدة نماذج أو مزودي استدلال. يمكنها إعادة توجيه الطلبات إلى نموذج احتياطي عند تعطل النموذج الرئيسي، وموازنة الحمل بين المناطق، والحرص على ألا يستهلك عميل واحد كامل الحصة المتاحة. وبحسب وصف AWS، يصبح هذا التنسيق متعدد النماذج الخطوة المنطقية التالية حين لا تعود الإمكانات المدمجة في Amazon Bedrock كافية لبلوغ مستوى الموثوقية المطلوب.

ماذا يعني ذلك؟

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

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