Autopilot: أتمتة إدارة البنية التحتية للذكاء الاصطناعي التوليدي (GenAI)

ما هو Autopilot

غالبًا ما تتضمن عمليات تعلم الآلة (MLOps) عمليات معقدة ويدوية تستهلك الوقت والموارد. يهدف Autopilot من Truefoundry إلى التخلص من هذه الأعباء التشغيلية، مما يمكّن المطورين من التركيز فقط على كتابة التعليمات البرمجية وعلماء البيانات من تحسين نماذجهم. يتعامل Autopilot تلقائيًا مع تحسين الموارد وإصلاحات الموثوقية ويضمن سير عمل سلس بأقل تدخل بشري.

لماذا نحتاج إلى هذا؟

يمكن تقسيم الجوانب التشغيلية لأي دورة حياة لتطوير البرمجيات إلى ثلاث مراحل مختلفة -

1. اليوم 0 – التصميم والتخطيط: تحديد البنية، واستراتيجيات التزويد، وسياسات الأمان، وأطر التوسع قبل النشر.
2. اليوم 1 – النشر والتنفيذ: إعداد البنية التحتية، ونشر التطبيقات، وتهيئة المراقبة، وإنشاء مسارات CI/CD.
3. اليوم 2 – العمليات والصيانة: المراقبة المستمرة، والتوسع التلقائي للموارد، وتطبيق تصحيحات الأمان، وإدارة الحوادث.

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

المرحلة 1: فصل التطوير والعمليات

هذه هي المرحلة التي يبدأ بها الفريق عادةً. تتضمن المراحل الثلاث للعمليات عادةً ما يلي في هذه المرحلة.

• اليوم 0: يركز المطورون على تصميم التطبيقات، بينما تتولى فرق العمليات البنية التحتية والأمان.
• اليوم 1: يقوم المطورون بتجميع التطبيقات وإعدادها للنشر، بينما يركز فريق العمليات على توفير الموارد وتهيئتها.
• اليوم 2: تتولى فرق العمليات إدارة التوسع والمراقبة وتصحيحات الأمان، بينما لا يزال المطورون يستكشفون المشكلات ويحلونها.

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

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

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

AI Gateway Evaluation Checklist

A practical guide used by platform & infra teams

المرحلة الثانية: إنشاء منصة داخلية

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

لهذه المرحلة بعض العيوب -

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

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

المرحلة الثالثة: أتمتة المنصة

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

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

لماذا الآن؟

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

الخدمات المصغرة

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

الأنظمة الوكيلة

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

دراسة حالة

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

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

‍

ماذا يمكن للطيار الآلي أن يفعل حاليًا؟

‍

تحسين وحدة المعالجة المركزية والذاكرة والتخزين

يقوم الطيار الآلي بأتمتة تكوين وحدة المعالجة المركزية والذاكرة للتطبيق. يقوم الطيار الآلي بذلك من خلال النظر في مصدرين للمدخلات -

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

صحة المجموعة

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

سعة العقدة

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

التحجيم التلقائي

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

‍

ماذا بعد؟

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

• التحجيم التلقائي الدوري - يمكن أن يسمح لنا التنبؤ بالتحجيم التلقائي الدوري وتطبيقه، مع الأخذ في الاعتبار حركة المرور التاريخية، بتمكين التحجيم التلقائي حتى لأعباء العمل المتقلبة.
• توصية بالإيقاف التلقائي - يمكن أن يؤدي تصفية وإيقاف الخدمات أو أعباء العمل غير المستخدمة إلى توفير هائل في التكاليف.
• قياس الأداء التلقائي — بينما تقدير موارد الخدمة ممكن بالفعل، يمكن إجراء تقدير أفضل عن طريق تشغيل اختبارات الأداء بحركة مرور حية أو محاكاة ومراقبة مقاييس الأعمال المتأثرة. يسعى Autopilot إلى أتمتة هذه العملية، والتي يمكن أن تستغرق وقتًا طويلاً جدًا لمعظم فرق التطوير.
• تحسين البنية التحتية للمجموعات - يبلغ متوسط استخدام وحدة المعالجة المركزية للمجموعات عبر الصناعة 10%. رابط . بينما يمثل سوء تهيئة التطبيقات لوحدة المعالجة المركزية جزءًا كبيرًا من ذلك، فإن جزءًا كبيرًا أيضًا هو عدم الكفاءة في توزيع الحمل على البنية التحتية الأساسية. يمكن أن يكون هذا في شكل العديد من العقد غير المستغلة بالكامل، أو عدد كبير جدًا من العقد الصغيرة التي تهدر المساحة على مجموعات الخدمات (daemonsets) وما إلى ذلك. يمكن أن يساعد إصلاح تكوينات توفير البنية التحتية والاستفادة من أدوات مثل karpenter على مستوى السحابة كثيرًا في تحسين هذا الجانب.

الخلاصة

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

‍