البدء البارد لنماذج LLM في Kubernetes: 200 ثانية من أصل 294 لا تذهب إلى تحميل الأوزان

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

لماذا يستغرق تشغيل نموذج LLM كل هذا الوقت؟

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

توقع كاتب التحليل أن يستهلك تحميل الأوزان معظم الوقت. لكن القياسات العامة أظهرت عكس ذلك. لدى Tensorfuse، استغرق تشغيل Llama 3.1 8B على L40S مدة 294 ثانية. ولم يستغرق تنزيل النموذج ونقل الأوزان إلى وحدة GPU سوى 94 ثانية. أما الثواني الـ200 المتبقية فذهبت إلى التجميع، والتقاط CUDA graphs، وتهيئة المحرك، وعمليات الاستيراد.

ما الذي يمكن تخزينه مؤقتا؟

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

يعد الكاتب في المقال الكامل بشرح الجانب العملي:

• من أين يحصل KEDA على إشارة الحمل عندما لا توجد أي حاويات؛
• ما الذي يستحق التخزين المؤقت مسبقا؛
• ما قيم مهلات الانتظار التي تسمح للطلب الأول بانتظار النموذج؛
• ملفات تعريف KEDA HTTP Add-on، وDaemonSet للتحميل المسبق، وإعدادات vLLM.

تمثل إشارة الحمل نقطة مستقلة ومهمة. فعندما لا توجد حاويات، لا يمكن الحصول على مقاييس منها، ولذلك يلزم وضع مكون أمام الخدمة. يعترض KEDA HTTP Add-on الطلب تحديدا، ويطلق الحاوية، ويبقي الاتصال مفتوحا إلى أن يصبح النموذج جاهزا. وتعد مهلات الانتظار حاسمة هنا: يجب ألا يقطع العميل أو البوابة أو ingress الاتصال قبل اكتمال إحماء النموذج.

القيود والخلاصة

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

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

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