بررسی سلامت ما یک سرور مدل سالم را هشت بار در یک روز راه‌اندازی مجدد کرد
عملیات
در 22 ژوئیه یک واچ‌داگ سرور مدل محلی ما را هشت بار راه‌اندازی مجدد کرد. هیچ‌کدام از این راه‌اندازی‌های مجدد پشت خود کرشی نداشتند. همان بررسی‌ای که قرار بود مدل را بالا نگه دارد، همان چیزی بود که آن را پایین می‌آورد.
چه اتفاقی افتاد
سرور مدل روی یک دستگاه NVIDIA GB10 با vLLM اجرا می‌شد و برای یک درخواست تکی حدود 8 توکن در ثانیه تولید می‌کرد. هر پنج دقیقه یک واچ‌داگ یک درخواست چت واقعی برای آن می‌فرستاد و تا 45 ثانیه برای پاسخ صبر می‌کرد. پنج بررسی ناموفق پشت سر هم به معنای سرور هنگ‌کرده بود و واچ‌داگ آن را راه‌اندازی مجدد می‌کرد. یک راه‌اندازی مجدد، مدل را برای چند دقیقه از دسترس خارج می‌کرد در حالی که حدود 19 گیگابایت وزن‌ها دوباره بارگذاری می‌شدند.
آن روز یک کار دسته‌ای دو تا چهار درخواست را برای دقایقی روی سرور مشغول نگه می‌داشت. درخواست واچ‌داگ در صف پشت آن‌ها منتظر می‌ماند، زمانش تمام می‌شد و به عنوان یک خطا ثبت می‌شد. پنج بررسی از این دست بعد، یک سرور سالم راه‌اندازی مجدد شد. ما یک فایل پرچم «مشغول» داشتیم که واچ‌داگ به آن احترام می‌گذاشت، اما کار دسته‌ای هرگز آن را تنظیم نمی‌کرد.
چگونه یک راه‌اندازی مجدد کاذب به راه‌اندازی مجدد بعدی منجر شد
هر راه‌اندازی مجدد درخواست‌های در حال انجام را با خطای 500 شکست می‌داد («cannot schedule new futures after shutdown»). یک واچ‌داگ دوم خطاهای 500 را می‌شمرد و وقتی تعدادشان زیاد می‌شد، سرور را راه‌اندازی مجدد می‌کرد، و هرچه خطاهای بیشتری می‌دید، زودتر اقدام می‌کرد. بنابراین هر راه‌اندازی مجدد کاذب، راه‌اندازی مجدد بعدی را زودتر فرا می‌خواند. در مجموع، چهار واچ‌داگ جداگانه می‌توانستند آن سرور را روی تایمرهای 5، 10، 15 و 30 دقیقه‌ای راه‌اندازی مجدد کنند.
قاعده‌ای که از آن گرفتیم
یک بررسی سلامت نباید از چیزی که محافظت می‌کند استفاده کند. منبع کمیاب یک سرور مدل، اسلات‌های آن برای درخواست‌های در حال انجام است. بررسی‌ای که یکی از آن اسلات‌ها را می‌گیرد یا برای یکی منتظر می‌ماند، بخشی از باری است که قرار است آن را قضاوت کند. ارزان بررسی کنید و فقط زمانی راه‌اندازی مجدد کنید که بتوانید نشان دهید سرور گیر کرده است.
بررسی‌ای که جایگزین آن شد
vLLM شمارنده‌های خودش را در /metrics منتشر می‌کند. بررسی جدید ابتدا آن‌ها را می‌خواند:
- درخواست‌های در حال اجرا و پیشرفت موتور: سالم و مشغول. هیچ درخواست آزمایشی ارسال نمی‌شود.
- درخواست‌های در حال اجرا و بدون پیشرفت بین دو خواندن: گیر کرده. این همان حالتی است که همچنان راه‌اندازی مجدد می‌کند.
- هیچ‌چیز در حال اجرا نیست: بیکار. فقط در این صورت بررسی یک پاسخ کوتاه می‌خواهد که یک موتور بیکار فوراً ارائه می‌دهد.
نسخه اول توکن‌های تولیدشده را به عنوان پیشرفت می‌شمرد. از هشت آزمون سربلند بیرون آمد و در اولین اجرای زنده، سرور را مشغول و سالم یافت: 2 درخواست در حال اجرا، 107 توکن جدید بین دو خواندن.
تغییراتی که از آن زمان اعمال کردیم
- گام‌های موتور، نه توکن‌های خروجی. در حالی که vLLM یک پرامپت طولانی را می‌خواند، مدتی هیچ توکن خروجی تولید نمی‌کند اما همچنان گام برمی‌دارد. شمارش گام‌ها (تعداد vllm:iteration_tokens_total) مانع از آن می‌شود که یک پرامپت طولانی شبیه به سروری به‌نظر برسد که گیر کرده است.
- دو مکث قبل از «گیر کردن»، تا یک توقف کوتاه به‌عنوان خطا محسوب نشود.
- راه‌اندازی مجدد بین دو خواندن شناسایی می‌شود از طریق زمان شروع فرآیند در همان متریک‌ها؛ سپس بررسی، به‌جای مقایسه شمارنده‌های دو فرآیند متفاوت، درخواست پاسخ می‌کند.
- یک پروکسی فقط از طریق /models بررسی می‌شود. پشت یک پروکسی با الگوریتم کمترین اتصال، هر خواندن از /metrics می‌تواند از یک بک‌اند متفاوت باشد، همان‌طور که وقتی کپی‌ای از مدل را روی هر دو ماشین اجرا کردیم کشف کردیم. بک‌اندها مستقیماً بررسی می‌شوند.
تفاوت به‌راحتی قابل مشاهده است. هنگامی که این یادداشت را می‌نوشتیم، هر دو سرور مدل ما 12 درخواست را هم‌زمان اجرا می‌کردند که سقف مجاز آن‌ها بود. یک درخواست آزمایشی باید در صف منتظر می‌ماند. بررسی جدید، هر دو سرور را مشغول و سالم گزارش کرد، با سرعت 126 و 101 توکن در ثانیه، بدون آنکه درخواستی ارسال کند.
Factory Floor نسخه 1.0.2 این بررسی را به‌صورت models/llm-health.py ارائه می‌کند، همراه با تست‌هایی برای سرورهای بیکار، مشغول، گیرکرده و راه‌اندازی‌مجددشده، سروری بدون متریک، یک پروکسی و یک بک‌اند از‌کارافتاده.