Ang aming health check ay nag-restart ng isang malusog na model server na walong beses sa isang araw
Ops
Noong 22 Hulyo, isang watchdog ang nag-restart ng aming local model server na walong beses. Walang crash ang nasa likod ng kahit isang restart. Ang check na dapat panatilihin ang model ay ang mismong nagpapabagsak dito.
Ano ang nangyari
Ang model server ay tumatakbo ng vLLM sa isang NVIDIA GB10 machine at nagpro-produce ng humigit-kumulang 8 tokens bawat segundo para sa isang request. Tuwing limang minuto, isang watchdog ang nagpapadala ng tunay na chat request at naghihintay ng hanggang 45 segundo para sa sagot. Ang limang nabigong check nang sunod-sunod ay nangangahulugang hung server, at ini-restart ng watchdog ito. Ang isang restart ay nag-aalis ng model sa loob ng ilang minuto habang naglo-load muli ang humigit-kumulang 19 GB ng weights.
Noong araw na iyon, isang batch job ang nagpapabigat ng dalawa hanggang apat na requests sa server sa loob ng ilang minuto bawat beses. Ang request ng watchdog ay naghintay sa queue sa likod ng mga ito, naubusan ng oras, at itinuring na nabigo. Pagkatapos ng limang ganitong checks, ang isang malusog na server ay na-restart. Mayroon kaming "busy" flag file na sinusunod ng watchdog, ngunit hindi ito iniset ng batch job.
Paano ang isang maling restart ay humantong sa susunod
Bawat restart ay nabigo ang mga kasalukuyang requests na may 500 error ("cannot schedule new futures after shutdown"). Ang pangalawang watchdog ay bumibilang ng mga 500 error at nag-restart ng server kapag masyadong marami, at habang mas maraming errors ang nakikita nito, mas maaga itong kumikilos. Kaya ang bawat maling restart ay nagpapadali sa susunod na gawin. Sa kabuuan, apat na magkakaibang watchdog ang maaaring mag-restart ng server na iyon, sa 5, 10, 15 at 30 minutong timers.
Ang patakaran na aming kinuha dito
Ang health check ay hindi dapat gumamit ng pinoprotektahan nito. Ang limitadong resource ng model server ay ang mga slot para sa mga kasalukuyang requests. Ang check na kumukuha ng isa sa mga slot na iyon, o naghihintay para dito, ay bahagi ng load na dapat nitong husgahan. Gumawa ng murang check, at mag-restart lamang kapag kayang ipakita na stuck ang server.
Ang check na pumalit dito
Ang vLLM ay nagpo-publish ng sarili nitong counters sa /metrics. Ang bagong check ay binabasa ang mga ito muna:
- Mga kasalukuyang requests at pag-unlad ng engine: malusog at abala. Walang test request na ipinapadala.
- Mga kasalukuyang requests at walang pag-unlad sa pagitan ng dalawang pagbasa: stuck. Ito ang kaso na patuloy na nagre-restart.
- Walang tumatakbo: idle. Doon lamang humihingi ang check ng maikling sagot, na agad ibinibigay ng idle engine.
Ang unang bersyon ay binibilang ang mga generated tokens bilang pag-unlad. Nakapasa ito sa walong tests, at sa unang live run nito ay natuklasan nitong abala at malusog ang server: 2 requests na tumatakbo, 107 bagong tokens sa pagitan ng dalawang pagbasa.
Ang mga binago namin simula noon
- Mga hakbang ng engine, hindi output tokens. Habang binabasa ng vLLM ang isang mahabang prompt, hindi ito nagpapakita ng output tokens sa loob ng ilang sandali ngunit patuloy pa ring gumagawa ng mga hakbang. Ang pagbilang ng mga hakbang (ang bilang ng vllm:iteration_tokens_total) ay nagpapahintulot sa mahabang prompt na huwag mukhang isang server na na-stuck.
- Dalawang paghihintay bago ituring na "stuck", upang ang maikling pagpapatigil ay hindi maituring na kabiguan.
- Ang pag-restart sa pagitan ng dalawang pagbasa ay nahuhuli sa pamamagitan ng oras ng pagsisimula ng proseso sa parehong metrics; ang tsek ay humihingi ng sagot sa halip na ihambing ang mga counter mula sa dalawang magkaibang proseso.
- Ang proxy ay tinitsek lamang sa pamamagitan ng /models. Sa likod ng least-connection proxy, ang bawat pagbasa ng /metrics ay maaaring galing sa ibang backend, gaya ng amang natuklasan nang patakbuhin namin ang isang kopya ng model sa bawat isa sa dalawang makina. Ang mga backend ay tinitsek nang direkta.
Madaling makita ang pagkakaiba. Habang isinusulat namin ang talatang ito, ang parehong model server namin ay tumatakbo ng 12 requests bawat isa, ang kanilang limitasyon. Ang isang test request ay maghihintay sa queue. Ang bagong tsek ay iniulat ang parehong busy at healthy, sa 126 at 101 tokens bawat segundo, nang hindi nagpapadala ng isa.
Factory Floor 1.0.2 ay naglalaman ng tseking ito bilang models/llm-health.py, kasama ang mga test para sa idle, busy, stuck at restarted servers, isang server na walang metrics, isang proxy at isang dead backend.