В этом материале
Живой процесс, завершённый старт и готовность обслуживать запросы — разные состояния. Неправильный probe может разрушать нормальную загрузку модели.
Большая модель может загружаться дольше обычного приложения. Если проверка liveness ожидает немедленного ответа генерации, оркестратор способен перезапускать процесс до окончания каждого старта. При этом CPU и диск работают, но сервис никогда не становится доступным. Другой перекос — объявить readiness по открытому порту и направить запросы на ещё неподготовленную модель. Три разных probe помогают разделить эти состояния при правильной настройке.
Определите цель каждого probe
Kubernetes описывает startup, readiness и liveness как разные механизмы. Startup защищает длительную инициализацию, readiness управляет пригодностью к трафику, а liveness помогает обнаруживать состояние, требующее перезапуска. Эти роли нельзя заменить одним одинаковым тяжёлым запросом без анализа последствий.
Сначала сформулируйте ожидаемое действие при отрицательном результате. Если модель временно не готова принимать новые обращения, нужен ли рестарт всего процесса? Если процесс действительно застрял, достаточно ли только исключить его из маршрута? Разные ответы требуют разных сигналов, даже когда используется один формат HTTP probe.
Измерьте реальный старт
Запишите путь от запуска контейнера до доступности выбранной модели и интерфейса. Используйте несколько ограниченных наблюдений в обычных условиях площадки. Один удачный тёплый запуск не описывает первый старт с загрузкой файлов или восстановление после изменения окружения.
Жизненный цикл Pod связывает состояние контейнера, проверки и дальнейшее обслуживание. Настройки должны соответствовать измеренному сценарию, но не превращаться в бесконечное ожидание. Сохраните failure thresholds и интервалы вместе с объяснением, какую стадию они защищают и когда тест должен закончиться.
Не путайте порт с готовностью модели
Документация vLLM online serving перечисляет интерфейсы и дополнительные endpoints. Проверяйте реальные возможности установленной версии. Существование health route не означает, что любая выбранная вами проверка подтверждает нужную модель, tokenizer и параметры запуска.
Readiness должна отражать объявленный критерий приложения. Можно начать с лёгкой проверки состояния, а отдельным ограниченным synthetic request подтвердить полезный путь после старта. Не следует выполнять длинную генерацию на каждом scrape: сама диагностика станет регулярной нагрузкой и может влиять на очередь сервиса.
Испытайте ошибочные состояния
Первый fixture задерживает завершение инициализации, сохраняя живой процесс. Второй моделирует временную неготовность к новым запросам. Третий проверяет выбранное условие, при котором нужен рестарт. Это сценарии тестового контура, а не совет вмешиваться в чужую production-машину.
Для каждого сохраните наблюдаемый probe result и действие оркестратора. Если система перезапускает нормальную загрузку, исправляйте смысл сигнала или бюджет старта, а не отключайте проверки полностью. Если трафик приходит раньше готовности, исследуйте readiness и маршрут отдельно от liveness.
Сохраните вывод по конфигурации
Успешный тест показывает соответствие выбранных критериев и версии приложения. Он не подтверждает качество генерации и не гарантирует отсутствие любых зависаний. После изменения модели или способа загрузки повторите стартовую трассу, потому что прежний временной бюджет может перестать быть достаточным.
Связанные темы — vLLM running but not ready и GPU cold start. Они описывают симптомы и время подготовки; probe-контракт определяет, какие автоматические действия безопасно связывать с каждым наблюдаемым состоянием сервера.