ការត្រួតពិនិត្យសុខភាពរបស់យើងបានចាប់ផ្តើមម៉ាស៊ីនបម្រើម៉ូដែលដែលមានសុខភាពល្អឡើងវិញ 8 ដងក្នុងមួយថ្ងៃ

ប្រតិបត្តិការ2026-10-31

នៅថ្ងៃទី 22 ខែកក្កដា ម៉ាស៊ីនត្រួតពិនិត្យមួយបានចាប់ផ្តើមម៉ាស៊ីនបម្រើម៉ូដែលក្នុងស្រុករបស់យើងឡើងវិញ 8 ដង។ គ្មានការចាប់ផ្តើមឡើងវិញណាមួយក្នុងចំណោមនោះមានការដួលរលំនៅពីក្រោយឡើយ។ ការត្រួតពិនិត្យដែលគួរតែរក្សាម៉ូដែលឱ្យដំណើរការ គឺជាអ្វីដែលបានធ្វើឱ្យវាឈប់ដំណើរការ។

អ្វីដែលបានកើតឡើង

ម៉ាស៊ីនបម្រើម៉ូដែលបានដំណើរការ vLLM នៅលើម៉ាស៊ីន NVIDIA GB10 មួយ និងផលិតបានប្រហែល 8 token ក្នុងមួយវិនាទីសម្រាប់សំណើតែមួយ។ រៀងរាល់ 5 នាទី ម៉ាស៊ីនត្រួតពិនិត្យបានផ្ញើសំណើជជែកពិតប្រាកដទៅវា និងរង់ចាំរហូតដល់ 45 វិនាទីសម្រាប់ចម្លើយ។ ការត្រួតពិនិត្យបរាជ័យ 5 ដងជាប់គ្នាមានន័យថាម៉ាស៊ីនបម្រើត្រូវបានបិទភ្ជាប់ ហើយម៉ាស៊ីនត្រួតពិនិត្យបានចាប់ផ្តើមវាឡើងវិញ។ ការចាប់ផ្តើមឡើងវិញបានធ្វើឱ្យម៉ូដែលបាត់បង់រយៈពេលប៉ុន្មាននាទី ខណៈដែលទម្ងន់ប្រហែល 19 GB ត្រូវបានផ្ទុកឡើងវិញ។

នៅថ្ងៃនោះ កិច្ចការបាត់ (batch job) មួយបានធ្វើឱ្យសំណើពីរទៅបួនកំពុងដំណើរការនៅលើម៉ាស៊ីនបម្រើអស់រយៈពេលប៉ុន្មាននាទីក្នុងមួយពេល។ សំណើរបស់ម៉ាស៊ីនត្រួតពិនិត្យបានរង់ចាំនៅក្នុងជួរនៅពីក្រោយពួកវា អស់ពេលវេលា ហើយត្រូវបានរាប់ថាជាបរាជ័យ។ បន្ទាប់ពីការត្រួតពិនិត្យបែបនេះ 5 ដង ម៉ាស៊ីនបម្រើដែលមានសុខភាពល្អត្រូវបានចាប់ផ្តើមឡើងវិញ។ យើងមានឯកសារសញ្ញា "busy" មួយដែលម៉ាស៊ីនត្រួតពិនិត្យគោរពតាម ប៉ុន្តែកិច្ចការបាត់មិនបានកំណត់វាទេ។

របៀបដែលការចាប់ផ្តើមឡើងវិញក្លែងក្លាយមួយនាំឱ្យមានការចាប់ផ្តើមឡើងវិញបន្ទាប់

ការចាប់ផ្តើមឡើងវិញនីមួយៗបានធ្វើឱ្យសំណើដែលកំពុងដំណើរការបរាជ័យដោយកំហុស 500 ("cannot schedule new futures after shutdown")។ ម៉ាស៊ីនត្រួតពិនិត្យទីពីរបានរាប់កំហុស 500 ហើយបានចាប់ផ្តើមម៉ាស៊ីនបម្រើឡើងវិញនៅពេលដែលមានចំនួនច្រើនពេក ហើយកាន់តែមានកំហុសច្រើន វាកាន់តែធ្វើសកម្មភាពលឿន។ ដូច្នេះ ការចាប់ផ្តើមឡើងវិញក្លែងក្លាយនីមួយៗបានធ្វើឱ្យការចាប់ផ្តើមឡើងវិញបន្ទាប់មកលឿនជាងមុន។ សរុបមក ម៉ាស៊ីនត្រួតពិនិត្យដាច់ដោយឡែក 4 អាចចាប់ផ្តើមម៉ាស៊ីនបម្រើនោះឡើងវិញ តាមម៉ោងកំណត់ 5, 10, 15 និង 30 នាទី។

គោលការណ៍ដែលយើងទទួលបានពីវា

ការត្រួតពិនិត្យសុខភាពមិនត្រូវប្រើប្រាស់ធនធានដែលវាត្រួតពិនិត្យទេ។ ធនធានកម្ររបស់ម៉ាស៊ីនបម្រើម៉ូដែលគឺជាចន្លោះសម្រាប់សំណើដែលកំពុងដំណើរការ។ ការត្រួតពិនិត្យដែលយកចន្លោះមួយក្នុងចំណោមចន្លោះទាំងនោះ ឬរង់ចាំចន្លោះមួយ គឺជាផ្នែកមួយនៃបន្ទុកដែលវាត្រូវវាយតម្លៃ។ ត្រួតពិនិត្យដោយថ្លៃតិច ហើយចាប់ផ្តើមឡើងវិញតែនៅពេលដែលអ្នកអាចបង្ហាញថាម៉ាស៊ីនបម្រើត្រូវបានបិទភ្ជាប់។

ការត្រួតពិនិត្យដែលជំនួសវា

vLLM បោះពុម្ពផ្សាយតួនាទីរបស់វាខ្លួនឯងនៅ /metrics។ ការត្រួតពិនិត្យថ្មីអានពួកវាជាមុនសិន៖

• សំណើកំពុងដំណើរការ និងម៉ាស៊ីនដែលកំពុងវឌ្ឍនភាព៖ មានសុខភាពល្អ និងកំពុងមមាញឹក។ គ្មានសំណើសាកល្បងត្រូវបានផ្ញើទេ។
• សំណើកំពុងដំណើរការ ប៉ុន្តែគ្មានវឌ្ឍនភាព រវាងការអានពីរ៖ ត្រូវបានបិទភ្ជាប់។ នេះជាករណីដែលនៅតែចាប់ផ្តើមឡើងវិញ។
• គ្មានអ្វីកំពុងដំណើរការ៖ អស់ការងារ។ តែនៅពេលនោះទេ ការត្រួតពិនិត្យសុំចម្លើយខ្លីមួយ ដែលម៉ាស៊ីនអស់ការងារផ្តល់ឱ្យភ្លាមៗ។

កំណែដំបូងបានរាប់ token ដែលបានបង្កើតថ្មីជាវឌ្ឍនភាព។ វាបានឆ្លងកាត់ការសាកល្បង 8 ដង ហើយនៅពេលដំណើរការផ្ទាល់ដំបូង វាបានរកឃើញម៉ាស៊ីនបម្រើកំពុងមមាញឹក និងមានសុខភាពល្អ៖ សំណើ 2 កំពុងដំណើរការ, token ថ្មី 107 រវាងការអានទាំងពីរ។

អ្វីដែលយើងបានផ្លាស់ប្តូរតាំងពីពេលនោះមក

• ជំហានរបស់ម៉ាស៊ីន មិនមែនជាតូកង់លទ្ធផលទេ។ ខណៈដែល vLLM អានសំណួរវែង វាមិនបញ្ចេញតូកង់លទ្ធផលអស់រយៈពេលមួយ ប៉ុន្តែនៅតែបន្តធ្វើជំហាន។ ការរាប់ជំហាន (ចំនួន vllm:iteration_tokens_total) ជួយកុំឱ្យសំណួរវែងមើលទៅដូចជាសេវាកម្មជាប់។
• រង់ចាំពីរដងមុននឹងចាត់ទុកថាជាប់ ដូច្នេះការឈប់ខ្លីមួយមិនត្រូវបានចាត់ទុកថាជាបរាជ័យទេ។
• ការចាប់ផ្តើមឡើងវិញរវាងការអានពីរត្រូវបានចាប់យក ដោយពេលវេលាចាប់ផ្តើមដំណើរការនៅក្នុងសូចនាករដូចគ្នា បន្ទាប់មកការត្រួតពិនិត្យនឹងស្នើសុំចម្លើយជំនួសឱ្យការប្រៀបធៀបតួរាប់ពីដំណើរការពីរផ្សេងគ្នា។
• ត្រួតពិនិត្យតាមរយៈ /models តែប៉ុណ្ណោះ។ នៅពីក្រោយប្រូកស៊ីដែលប្រើវិធីចែកចាយតាមចំនួនការតភ្ជាប់តិចបំផុត ការអាន /metrics នីមួយៗអាចមកពីប្រភពផ្ទៃខាងក្រោយផ្សេងគ្នា ដូចដែលយើងបានរកឃើញនៅពេលយើង ដំណើរការច្បាប់ចម្លងនៃគំរូនៅលើម៉ាស៊ីនពីរ។ ប្រភពផ្ទៃខាងក្រោយត្រូវបានត្រួតពិនិត្យដោយផ្ទាល់។

ភាពខុសគ្នាគឺងាយស្រួលមើល។ ខណៈដែលយើងសរសេរកំណត់ហេតុនេះ ម៉ាស៊ីនបម្រើគំរូទាំងពីររបស់យើងកំពុងដំណើរការសំណើ 12 នីមួយៗ ដែលជាដែនកំណត់របស់វា។ សំណើសាកល្បងមួយនឹងត្រូវរង់ចាំនៅក្នុងជួរ។ ការត្រួតពិនិត្យថ្មីបានរាយការណ៍ថាទាំងពីរកំពុងមមាញឹក និងមានសុខភាពល្អ ក្នុងអត្រា 126 និង 101 តូកង់ក្នុងមួយវិនាទី ដោយមិនបានផ្ញើសំណើសាកល្បងទេ។

Factory Floor 1.0.2 ផ្តល់ការត្រួតពិនិត្យនេះជា models/llm-health.py ជាមួយនឹងការធ្វើតេស្តសម្រាប់ម៉ាស៊ីនបម្រើដែលនៅស្ងៀម មមាញឹក ជាប់ និងចាប់ផ្តើមឡើងវិញ ម៉ាស៊ីនបម្រើដែលគ្មានសូចនាករ ប្រូកស៊ី និងប្រភពផ្ទៃខាងក្រោយដែលស្លាប់។