Pemeriksaan kesihatan kami memulakan semula pelayan model yang sihat sebanyak lapan kali dalam satu hari
Operasi
Pada 22 Julai, sebuah watchdog memulakan semula pelayan model setempat kami sebanyak lapan kali. Tiada satu pun daripada permulaan semula itu berpunca daripada kemalangan. Pemeriksaan yang sepatutnya memastikan model terus beroperasi adalah punca yang menjatuhkannya.
Apa yang berlaku
Pelayan model menjalankan vLLM pada satu mesin NVIDIA GB10 dan menghasilkan kira-kira 8 token sesaat untuk satu permintaan. Setiap lima minit, sebuah watchdog menghantar permintaan sembang sebenar dan menunggu sehingga 45 saat untuk jawapan. Lima pemeriksaan yang gagal berturut-turut bermaksud pelayan tergantung, dan watchdog memulakan semula pelayan tersebut. Satu permulaan semula mengambil masa beberapa minit untuk model kembali beroperasi sambil kira-kira 19 GB berat dimuat semula.
Pada hari itu, satu kerja kelompok membuatkan dua hingga empat permintaan sibuk pada pelayan selama beberapa minit setiap kali. Permintaan watchdog menunggu dalam barisan di belakang mereka, kehabisan masa, dan dikira sebagai kegagalan. Selepas lima pemeriksaan sedemikian, pelayan yang sihat dimulakan semula. Kami mempunyai fail penanda "sibuk" yang dihormati oleh watchdog, tetapi kerja kelompok tidak pernah menetapkannya.
Bagaimana satu permulaan semula palsu membawa kepada permulaan semula seterusnya
Setiap permulaan semula gagal untuk permintaan yang sedang berjalan dengan ralat 500 ("cannot schedule new futures after shutdown"). Sebuah watchdog kedua mengira ralat 500 dan memulakan semula pelayan apabila terdapat terlalu banyak ralat, dan semakin banyak ralat yang dilihatnya, semakin cepat ia bertindak. Jadi setiap permulaan semula palsu menyebabkan permulaan semula seterusnya berlaku lebih awal. Kesemuanya, empat watchdog berasingan boleh memulakan semula pelayan itu, pada pemasa 5, 10, 15 dan 30 minit.
Peraturan yang kami ambil daripada kejadian itu
Pemeriksaan kesihatan tidak boleh menggunakan sumber yang dijaganya. Sumber terhad bagi pelayan model ialah slot untuk permintaan yang sedang berjalan. Pemeriksaan yang mengambil salah satu slot tersebut, atau menunggu slot, adalah sebahagian daripada beban yang sepatutnya dinilai oleh pemeriksaan itu. Periksa dengan murah hati, dan mulakan semula hanya apabila anda dapat menunjukkan bahawa pelayan itu tergantung.
Pemeriksaan yang menggantikannya
vLLM menerbitkan penghitungnya sendiri di /metrics. Pemeriksaan baharu membacanya terlebih dahulu:
- Permintaan berjalan dan enjin membuat kemajuan: sihat dan sibuk. Tiada permintaan ujian dihantar.
- Permintaan berjalan dan tiada kemajuan antara dua bacaan: tergantung. Ini adalah kes yang masih memulakan semula pelayan.
- Tiada apa-apa berjalan: terbiar. Hanya selepas itu pemeriksaan meminta jawapan pendek, yang diberikan oleh enjin terbiar dengan segera.
Versi pertama mengira token yang dijana sebagai kemajuan. Ia lulus lapan ujian, dan pada larian langsung pertamanya, ia mendapati pelayan sibuk dan sihat: 2 permintaan berjalan, 107 token baharu antara dua bacaan.
Apa yang kami ubah sejak itu
- Langkah enjin, bukan token output. Semasa vLLM membaca prompt yang panjang, ia tidak menghasilkan token output untuk seketika tetapi masih mengambil langkah. Mengira langkah (bilangan vllm:iteration_tokens_total) menghalang prompt panjang daripada kelihatan seperti pelayan yang tersekat.
- Dua tempoh tunggu sebelum "tersekat", supaya jeda pendek tidak dikira sebagai kegagalan.
- Penghidupan semula antara dua bacaan dikesan melalui masa permulaan proses dalam metrik yang sama; pemeriksaan tersebut kemudian meminta jawapan dan bukannya membandingkan pengira daripada dua proses yang berbeza.
- Proksi diperiksa melalui /models sahaja. Di sebalik proksi sambungan-minimum, setiap bacaan /metrics boleh datang daripada backend yang berbeza, seperti yang kami dapati apabila kami menjalankan salinan model pada setiap dua mesin. Backend diperiksa secara langsung.
Perbezaannya mudah dilihat. Semasa kami menulis nota ini, kedua-dua pelayan model kami sedang menjalankan 12 permintaan setiap satu, iaitu hadnya. Satu permintaan ujian akan menunggu dalam barisan. Pemeriksaan baharu melaporkan kedua-duanya sibuk dan sihat, pada 126 dan 101 token sesaat, tanpa menghantar satu permintaan pun.
Factory Floor 1.0.2 menyertakan pemeriksaan ini sebagai models/llm-health.py, dengan ujian untuk pelayan yang tidak aktif, sibuk, tersekat dan dihidupkan semula, pelayan tanpa metrik, proksi dan backend yang mati.