Sağlık kontrolümüz, sağlıklı bir model sunucusunu bir günde sekiz kez yeniden başlattı
Operasyonlar
22 Temmuz'da bir gözetim mekanizması yerel model sunucumuzu sekiz kez yeniden başlattı. Bu yeniden başlatmaların hiçbirinin arkasında bir çökme yoktu. Modeli ayakta tutması gereken kontrol, onu düşüren şeydi.
Ne oldu
Model sunucusu tek bir NVIDIA GB10 makinesinde vLLM çalıştırıyordu ve tek bir istek için saniyede yaklaşık 8 token üretiyordu. Her beş dakikada bir gözetim mekanizması sunucuya gerçek bir sohbet isteği gönderiyor ve yanıt için en fazla 45 saniye bekliyordu. Üst üste beş başarısız kontrol, sunucunun takıldığını gösterir ve gözetim mekanizması sunucuyu yeniden başlatırdı. Bir yeniden başlatma, yaklaşık 19 GB ağırlığın tekrar yüklenmesi sırasında modeli birkaç dakika boyunca erişime kapatırdı.
O gün bir toplu iş, sunucuda dakika süreyle iki ila dört isteği meşgul tutuyordu. Gözetim mekanizmasının isteği kuyrukta bunların arkasında bekledi, zamanı doldu ve başarısız sayıldı. Beş böyle kontrolün ardından, sağlıklı bir sunucu yeniden başlatıldı. Gözetim mekanizmasının dikkate aldığı bir "meşgul" bayrak dosyamız vardı, ancak toplu iş bunu hiç ayarlamadı.
Tek bir yanlış yeniden başlatmanın bir sonrakine nasıl yol açtığı
Her yeniden başlatma, devam eden istekleri bir 500 hatasıyla ("kapanıştan sonra yeni futures zamanlanamıyor") başarısız kılıyordu. İkinci bir gözetim mekanizması 500 hatalarını sayıyor ve çok fazla olduğunda sunucuyu yeniden başlatıyordu; ne kadar çok hata görürse o kadar erken harekete geçiyordu. Böylece her yanlış yeniden başlatma, bir sonrakini daha erken getiriyordu. Toplamda, dört ayrı gözetim mekanizması, 5, 10, 15 ve 30 dakikalık zamanlayıcılarla o sunucuyu yeniden başlatabiliyordu.
Oradan çıkardığımız kural
Bir sağlık kontrolü, koruduğu şeyi kullanmamalıdır. Bir model sunucusunun kıt kaynağı, devam eden istekler için ayrılan slotlardır. Bu slotlardan birini alan veya birini bekleyen bir kontrol, değerlendirmesi gereken yükün bir parçasıdır. Ucuzca kontrol edin ve ancak sunucunun takıldığını gösterebildiğinizde yeniden başlatın.
Onun yerini alan kontrol
vLLM kendi sayaçlarını /metrics adresinde yayınlar. Yeni kontrol önce bunları okur:
- Devam eden istekler ve ilerleme kaydeden motor: sağlıklı ve meşgul. Test isteği gönderilmez.
- Devam eden istekler ve iki okuma arasında ilerleme yok: takılı. Hâlâ yeniden başlatan durum budur.
- Hiçbir şey çalışmıyor: boşta. Yalnızca bu durumda kontrol kısa bir yanıt ister; boşta bir motor bunu anında verir.
İlk sürüm, üretilen tokenları ilerleme olarak sayıyordu. Sekiz testi geçti ve ilk canlı çalışmasında sunucuyu meşgul ve sağlıklı buldu: 2 istek çalışıyor, iki okuma arasında 107 yeni token.
O zamandan beri değiştirdiklerimiz
- Çıktı tokenları değil, motor adımları. vLLM uzun bir istem okurken bir süre çıktı tokenı üretmez ama yine de adım atar. Adımları saymak (vllm:iteration_tokens_total sayısı), uzun bir istemin takılmış bir sunucu gibi görünmesini engeller.
- "Takıldı" demek için iki bekleme, böylece kısa bir duraklama başarısızlık sayılmaz.
- İki okuma arasındaki bir yeniden başlatma, aynı metriklerdeki süreç başlangıç zamanıyla yakalanır; kontrol daha sonra sayaçları iki farklı süreçten karşılaştırmak yerine yanıt ister.
- Bir vekil sunucu yalnızca /models üzerinden kontrol edilir. En az bağlantı vekil sunucusunun arkasında, /metrics okumalarının her biri farklı bir arka uçtan gelebilir; bunu modelin bir kopyasını iki makineden her birinde çalıştırdığımızda gördük. Arka uçlar doğrudan kontrol edilir.
Farkı görmek kolay. Bu notu yazarken, her iki model sunucumuz da sınırları olan 12'şer isteği işliyordu. Bir test isteği kuyrukta beklerdi. Yeni kontrol, bir tane göndermeden ikisini de meşgul ve sağlıklı olarak, saniyede 126 ve 101 token ile bildirdi.
Factory Floor 1.0.2, bu kontrolü models/llm-health.py olarak, boşta, meşgul, takılmış ve yeniden başlatılmış sunucular, metrikleri olmayan bir sunucu, bir vekil sunucu ve ölü bir arka uç için testlerle birlikte sunar.