أعاد مراقب الصحة تشغيل خادم نموذج سليم ثماني مرات في يوم واحد
العمليات
في 22 يوليو، أعاد مراقب تشغيل خادم النموذج المحلي ثماني مرات. لم يكن وراء أي من هذه عمليات إعادة التشغيل أعطال. الفحص الذي كان من المفترض أن يبقي النموذج يعمل هو ما أسقطه.
ماذا حدث
شغّل خادم النموذج vLLM على جهاز NVIDIA GB10 واحد وأنتج حوالي 8 رموز في الثانية لطلب واحد. كل خمس دقائق، كان المراقب يرسل إليه طلب محادثة حقيقيًا وينتظر حتى 45 ثانية للحصول على الإجابة. خمس عمليات فحص فاشلة متتالية تعني خادمًا متوقفًا، وكان المراقب يعيد تشغيله. استغرقت إعادة التشغيل دقائق عدة لإزالة النموذج بينما تم تحميل حوالي 19 جيجابايت من الأوزان مرة أخرى.
في ذلك اليوم، أبقى مهمة دفعية طلبين إلى أربعة مشغولة على الخادم لدقائق في كل مرة. انتظر طلب المراقب في الطابور خلفها، ونفد وقته، واحتُسب كفشل. بعد خمس عمليات فحص كهذه، تمت إعادة تشغيل خادم سليم. كان لدينا ملف علامة "مشغول" يحترمه المراقب، لكن المهمة الدفعية لم تضعه أبدًا.
كيف أدت إعادة تشغيل خاطئة واحدة إلى التالية
فشلت كل إعادة تشغيل في الطلبات الجارية مع خطأ 500 ("لا يمكن جدولة مهام جديدة بعد الإيقاف"). عدّ مراقب ثانٍ أخطاء 500 وأعاد تشغيل الخادم عندما كانت كثيرة جدًا، وكلما رأى أخطاء أكثر، تصرف بشكل أسرع. لذا جعلت كل إعادة تشغيل خاطئة التالية تأتي بشكل أسرع. في المجموع، كان بإمكان أربعة مراقبين منفصلين إعادة تشغيل ذلك الخادم، على مؤقّتات 5 و10 و15 و30 دقيقة.
القاعدة التي استخلصناها من ذلك
يجب ألا يستخدم فحص الصحة ما يحرسه. المورد النادر لخادم النموذج هو فتحاته للطلبات الجارية. الفحص الذي يأخذ إحدى هذه الفتحات، أو ينتظر واحدة، يصبح جزءًا من الحمل الذي من المفترض أن يحكم عليه. افحص بتكلفة منخفضة، وأعد التشغيل فقط عندما تستطيع إثبات أن الخادم عالق.
الفحص الذي حل محله
ينشر vLLM عدّاداته الخاصة على المسار /metrics. يقرأ الفحص الجديد هذه العدّادات أولاً:
- الطلبات الجارية والتقدم الذي يحققه المحرك: سليم ومشغول. لا يتم إرسال طلب اختبار.
- الطلبات الجارية وبدون تقدم بين قراءتين: عالق. هذه هي الحالة التي لا تزال تعيد التشغيل.
- لا شيء يعمل: خامل. فقط عندئذ يطلب الفحص إجابة قصيرة، والتي يعطيها المحرك الخامل فورًا.
كان الإصدار الأول يحسب الرموز المُولَّدة بوصفها تقدّمًا. وقد اجتاز 8 اختبارات، وفي أول تشغيل فعلي له وجد الخادم مشغولًا وسليمًا: 2 طلب قيد التشغيل، و107 رموز جديدة بين القراءتين.
ما الذي غيّرناه منذ ذلك الحين
- خطوات المحرك، لا رموز المخرجات. بينما يقرأ vLLM مطالبة طويلة، لا يُنتج أي رموز مخرجات لفترة من الوقت لكنه يظلّ يخطو خطوات. يحول عدّ الخطوات (عدد
vllm:iteration_tokens_total) دون أن تبدو المطالبة الطويلة كأنها خادم عالق. - فترتا انتظار قبل اعتبار الحالة "متوقفة"، حتى لا تُحسب وقفة قصيرة كفشل.
- يُكتشف إعادة التشغيل بين القراءتين من خلال وقت بدء العملية في المقاييس نفسها؛ ثم يطلب الفحص إجابةً بدلاً من مقارنة العدادات من عمليتين مختلفتين.
- يتم فحص الوسيط عبر
/modelsفقط. خلف وسيط يعتمد على أقل عدد من الاتصالات، يمكن أن تأتي كل قراءة من/metricsمن خلفية مختلفة، كما اكتشفنا عندما شغّلنا نسخة من النموذج على كل من جهازين. يتم فحص الخلفيات مباشرة.
الفرق واضح. عندما كتبنا هذه الملاحظة، كان كلا خادمي النموذج لدينا يشغّلان 12 طلبًا لكل منهما، وهو الحد الأقصى. كان من شأن طلب اختبار أن ينتظر في قائمة الانتظار. أبلغ الفحص الجديد عن كلا الخادمين كمشغولين وسليمين، بمعدل 126 و101 رمزًا في الثانية، دون إرسال طلب.
Factory Floor 1.0.2 يوزّع هذا الفحص كملف models/llm-health.py، مع اختبارات للخوادم الخاملة، والمشغولة، والمتوقفة، والمعاد تشغيلها، وخادم بدون مقاييس، ووكيل، وخلفية ميتة.