የኛው የጤና ምርመራ በአንድ ቀን ውስጥ ጤናማ የሆነውን የሞዴል ሰርቨር ስምንት ጊዜ እንደገና አስጀምሮታል
ኦፕስ
በ22 ጁላይ አንድ የክትትል ስርዓት የአካባቢውን የሞዴል ሰርቨር ስምንት ጊዜ እንደገና አስጀምሮታል። ከእነዚህ እንደገና ማስጀመሮች አንዱም እንኳን በኋላው ላይ የተከሰተ ስህተት (crash) የለበትም። ሞዴሉን በላይ ለማቆየት የተደረገው ምርመራ ራሱ ለማውረዱ ምክንያት ሆኗል።
ምን ተከሰተ
የሞዴል ሰርቨሩ በአንድ NVIDIA GB10 ማሽን ላይ vLLM በመጠቀም ለአንድ ጥያቄ በሰከንድ ወደ 8 ቶከኖች አመርትቷል። በየአምስት ደቂቃው አንድ የክትትል ስርዓት እውነተኛ የቻት ጥያቄ ላክሎ ለመልስ እስከ 45 ሰከንድ ተጽፏል። በተከታታይ አምስት ምርመራዎች ከተሳሳቱ ሰርቨሩ ተቆጥሮ የክትትል ስርዓቱ እንደገና አስጀምሮታል። እንደገና ማስጀመር ወደ 19 ጊጋባይት የሚገመት የሞዴል ክብደት (weights) እንደገና ሲጫን ለብዙ ደቂቃዎች ሞዴሉን አጥፍቷል።
በዚያ ቀን አንድ የቡድን ስራ (batch job) ለደቂቃዎች በሰርቨሩ ላይ ከሁለት እስከ አራት ጥያቄዎችን ስራ ላይ አድርጎታል። የክትትል ስርዓቱ ጥያቄ ከእነዚህ በኋላ በረድፍ (queue) ሆኖ ጊዜው አልቋው እንደ ስህተት ተቆጥሯል። እንደዚህ ያሉ አምስት ምርመራዎች ከተከናወኑ በኋላ ጤናማ የሆነው ሰርቨር እንደገና ተጀምሯል። የክትትል ስርዓቱ የሚያከብረው "busy" የሚባል የፋይል ምልክት (flag) ቢኖረንም የቡድን ስራው ግን ምንም ጊዜ አልገለጸውም።
አንድ የተሳሳተ እንደገና ማስጀመር ወደ ቀጣዩ እንዴት እንደመራ
እያንዳንዱ እንደገና ማስጀመር በሂደት ላይ ያሉትን ጥያቄዎች በ500 ስህተት ("cannot schedule new futures after shutdown") አሳልፏል። ሁለተኛው የክትትል ስርዓት 500 ስህተቶችን ቆጥሮ በብዛት ሲኖሩ ሰርቨሩን እንደገና አስጀምሮታል፤ የሚያየው ስህተት በብዛት ሲኖር በፍጥነት ድርጊት ይወስዳል። ስለዚህ እያንዳንዱ የተሳሳተ እንደገና ማስጀመር ቀጣዩን በፍጥነት እንዲመጣ አድርጓል። በአጠቃላይ አራት የተለያዩ የክትትል ስርዓቶች በ5፣ 10፣ 15 እና 30 ደቂቃ የጊዜ ሰሌዳዎች ሰርቨሩን ሊያስጀምሩ ይችላሉ።
ከዚህ የወሰድነው መርህ
አንድ የጤና ምርመራ የሚጠብቀውን ነገር መጠቀም የለበትም። የሞዴል ሰርቨር ውስን ሀብት በሂደት ላይ ያሉ ጥያቄዎች ስሎቶች (slots) ናቸው። ከእነዚህ ስሎቶች አንዱን የሚወስድ ወይም የሚጠብቅ ምርመራ የሚገመግመውን ጫና (load) የሚጨምር ነው። በአነስተኛ ወጪ ይፈትሹ፣ እና ሰርቨሩ ተቆጥሮ እንዳለ ማረጋገጥ ከቻሉ በስተቀር እንደገና አያስጀምሩ።
የተተካው ምርመራ
vLLM የራሱን ቆጣሪዎች (counters) በ /metrics ያሳውቃል። አዲሱ ምርመራ በመጀመሪያ እነሱን ያነባል፡
- በሂደት ላይ ያሉ ጥያቄዎች እና እድገት የሚያሳይ ሞተር፡ ጤናማ እና ስራ ላይ። ምንም የሙከራ ጥያቄ አይላክም።
- በሁለት ንባቦች መካከል በሂደት ላይ ያሉ ጥያቄዎች እና ምንም እድገት የሌለበት፡ ተቆጥሮ። ይህ አሁንም እንደገና የሚያስጀምርበት ሁኔታ ነው።
- ምንም የማይሰራ ነገር የለም፡ ባዶ (idle)። ከዚያ በኋላ ብቻ ምርመራው አጭር መልስ ይጠይቃል፣ ባዶ የሆነ ሞተር ወዲያውኑ ይሰጠዋል።
የመጀመሪያው እትም የተፈጠሩ ቶከኖችን እንደ እድገት ቆጥሯል። ስምንት ሙከራዎችን አልፏል፣ እና በመጀመሪያው ትክክለኛ ስራው ላይ ሰርቨሩን ስራ ላይ እና ጤናማ ሆኖ አግኝቶታል፡ 2 ጥያቄዎች በሂደት ላይ፣ በሁለቱ ንባቦች መካከል 107 አዳዲስ ቶከኖች።
ከዚህ በኋላ የቀየርነው
- የማሽከርከሪያ ደረጃዎችን ይቆጥሩ እንጂ የውጤት ቶከኖችን አይደለም። vLLM ረጅም ጥያቄ (prompt) ሲያነብ ለጊዜው የውጤት ቶከኖችን አያመነጭም፣ ነገር ግን ደረጃዎችን ይወስዳል። ደረጃዎችን መቁጠር (የ vllm:iteration_tokens_total ብዛት) ረጅም ጥያቄ እንደ ተቆመ ሰርቨር እንዳይታይ ያደርጋል።
- "ተቆሟል" ከማለታችን በፊት ሁለት ጊዜ መጠበቅ፣ ስለዚህ አጭር ማቆም እንደ ስህተት አይቆጠርም።
- በሁለቱ ማንበቢያዎች መካከል የሚደረግ እንደገና ማስጀመር በተመሳሳይ መለኪያዎች ውስጥ ባለው የሂደት የመጀመሪያ ጊዜ (process start time) ይገኛል፤ ፍተሻው ከዚያ ሁለት የተለያዩ ሂደቶችን ካውንተሮች ማወዳደር ይልቅ መልስ ይጠይቃል።
- ፕሮክሲ በ /models ብቻ ይፈተሻል። በ least-connection ፕሮክሲ ጀርባ፣ የ /metrics እያንዳንዱ ማንበብ ከተለያየ backend ሊመጣ ይችላል፣ ይህንንም ማረጋገጣችንን ሞዴሉን በሁለት ማሽኖች ላይ እያንዳንዱ ለየብቻ ስናሽከረክር አግኝተነዋል። በኋላ ያሉት (backends) በቀጥታ ይፈተሻሉ።
ልዩነቱ በቀላሉ ይታያል። ይህንን ማስታወሻ ስንጽፍበት ጊዜ፣ ሁለቱም የሞዴል ሰርቨሮቻችን እያንዳንዳቸው 12 ጥያቄዎችን (የሚችሉትን ከፍተኛ ብዛት) እያከናወኑ ነበር። የሙከራ ጥያቄ በረድፍ (queue) ውስጥ ይጠብቅ ነበር። አዲሱ ፍተሻ ሁለቱንም ሰርቨሮች ስራ ላይ እንደሆኑ እና ጤናማ እንደሆኑ፣ በሰከንድ 126 እና 101 ቶከኖች ፍጥነት ላይ እያሉ፣ ሳይላክ ሪፖርት አድርጎልናል።
Factory Floor 1.0.2 ይህንን ፍተሻ እንደ models/llm-health.py ያቀርባል፣ ለተቀመጡ፣ ለሰራተኛ፣ ለተቆሙ እና ለእንደገና የተጀመሩ ሰርቨሮች፣ ለመለኪያዎች (metrics) ለሌላቸው ሰርቨሮች፣ ለፕሮክሲ እና ለሞተ backend የሚሆኑ ሙከራዎችን (tests) ያካትታል።