لماذا تُعاد تشغيل نماذج الذكاء الاصطناعي المُحاواة حتى عندما يُبلّغ المضيف عن توفر ذاكرة حرة؟

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

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

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

للحاوية حد ذاكرة مختلف عن المضيف

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

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

يمكن أيضًا تداخل الحدود: فقد توجد حاوية النموذج داخل خدمة compose أو شريحة systemd أو آلة افتراضية أو مجموعة تنسيق. ويمكن لأضيق حد نشط أن يفعّل استعادة الذاكرة أو إنهاء العملية بسبب نفاد الذاكرة قبل اقتراب المضيف الفعلي من الاستنفاد العام.

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

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

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

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

قد يتنكر فشل GPU وسياسة إعادة التشغيل في صورة نفاد ذاكرة المضيف

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

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

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

-15% OFF

طابق سبب الخروج مع كل حد من حدود الذاكرة

أعد إنتاج تحميل نموذج واحد مع تسجيل container memory.current وmemory.max وmemory.events وRSS للعملية والملفات المعينة وMemAvailable للمضيف وإجماليات توقف الضغط وذاكرة GPU وزمن استجابة مسبار السلامة ورمز خروج العملية وعدد مرات إعادة تشغيل المشرف، باستخدام ساعة واحدة.

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

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

مركز التكنولوجيا والذكاء الاصطناعي

المزيد للقراءة

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.