Naš preverjanje zdravja je v enem dnevu osemkrat znova zagnalo zdrav strežnik modelov
Operacije
22. julija je varuh osemkrat znova zagnal naš lokalni strežnik modelov. Noben od teh zagonov ni bil posledica zrušitve. Preverjanje, ki naj bi vzdrževalo delovanje modela, je bilo tisto, ki ga je rušilo.
Kaj se je zgodilo
Strežnik modelov je poganjal vLLM na eni napravi NVIDIA GB10 in za eno zahtevo proizvajal približno 8 tokenov na sekundo. Vsakih pet minut mu je varuh poslal resnično klepetno zahtevo in za odgovor čakal do 45 sekund. Pet zaporednih neuspešnih preverjanj je pomenilo zataknjen strežnik, zato ga je varuh znova zagnal. Ponovni zagon je za nekaj minut odstranil model, medtem ko se je znova naložilo približno 19 GB uteži.
Tega dne je serijsko opravilo dve do štiri zahteve na strežniku obremenjevalo minute naenkrat. Zahteva varuha je čakala v vrsti za njimi, porabila čas in bila šteta za neuspešno. Po petih takih preverjanjih je bil zdrav strežnik ponovno zagnan. Imeli smo datoteko z oznako "zaseden", ki jo je varuh upošteval, a serijsko opravilo je nikoli ni nastavilo.
Kako je en napačen ponovni zagon vodil do naslednjega
Vsak ponovni zagon je tekoče zahteve zaključil z napako 500 ("ni mogoče razporediti novih prihodnjih obveznosti po zaustavitvi"). Drugi varuh je štel napake 500 in znova zagnal strežnik, ko jih je bilo preveč, ter je ravnal hitreje, čim več napak je zaznal. Tako je vsak napačen ponovni zagon pospešil naslednjega. Skupno so štirje ločeni varuhi lahko znova zagnali ta strežnik na časovnikih 5, 10, 15 in 30 minut.
Pravilo, ki smo ga iz tega izvlekli
Preverjanje zdravja ne sme uporabljati tistega, kar varuje. Redek vir strežnika modelov so njegova mesta za tekoče zahteve. Preverjanje, ki zavzame eno od teh mest ali čaka na eno, je del obremenitve, ki naj bi jo ocenjevalo. Preverjajte poceni in znova zaženite le, če lahko dokažete, da je strežnik zataknjen.
Preverjanje, ki ga je nadomestilo
vLLM objavlja svoje števec na /metrics. Novo preverjanje jih najprej prebere:
- Zahteve v teku in napredek pogona: zdravo in zasedeno. Testna zahteva se ne pošlje.
- Zahteve v teku in brez napredka med dvema branjema: zataknjeno. To je primer, ki še vedno sproži ponovni zagon.
- Nič v teku: nedejavno. Šele nato preverjanje zahteva kratek odgovor, ki ga nedejavni pogon takoj da.
Prva različica je kot napredek štela ustvarjene tokene. Uspešno je opravila osem testov, pri prvem živem zagonu pa je našla strežnik zaseden in zdrav: 2 zahtevi v teku, 107 novih tokenov med dvema branjema.
Kaj smo od takrat spremenili
- Koraki pogona, ne izhodni žetoni. Medtem ko vLLM bere dolgo pozivno sporočilo, za nekaj časa ne ustvari nobenih izhodnih žetonov, a še vedno izvaja korake. Štetje korakov (število vllm:iteration_tokens_total) prepreči, da bi dolgo pozivno sporočilo delovalo kot zataknjen strežnik.
- Dve čakanji pred »zataknjenim«, da kratek premor ne šteje kot napaka.
- Ponovni zagon med dvema branjema je zaznan s časom zagona procesa v istih metrikah; preverjanje nato zahteva odgovor namesto primerjave števcov iz dveh različnih procesov.
- Posrednik se preverja samo prek /models. Za posrednikom z najmanj povezavami lahko vsako branje /metrics pride z drugega zalednega strežnika, kot smo ugotovili, ko smo pognali kopijo modela na vsakem od dveh računalnikov. Zaledni strežniki se preverjajo neposredno.
Razlika je lahko vidna. Ko smo pisali to opombo, sta oba naša strežnika modelov poganjala po 12 zahtev, kar je njuna omejitev. Testna zahteva bi čakala v vrsti. Novo preverjanje je oba poročalo kot zasedena in zdrava, pri 126 in 101 žetonu na sekundo, brez pošiljanja ene same.
Factory Floor 1.0.2 vsebuje to preverjanje kot models/llm-health.py, s testi za nedejavne, zasedene, zataknjene in ponovno zagnane strežnike, strežnik brez metrik, posrednik in mrtv zaledni strežnik.