SGLang Model Gateway: как проверить готовность при отказе worker

Что именно проверяем?

Допустим, два отдельных процесса с одной моделью отвечают на учебные запросы. Worker — такой процесс, а Gateway — один адрес, который направляет запросы к доступным worker. После остановки одного процесса полезно отдельно проверить три вещи: видит ли Gateway оставшийся worker, считает ли себя готовым и даёт ли новый короткий ответ. Это не то же самое, что гарантия сохранения ответа, который уже начал формироваться. s1 s2 s4

Один worker и выбор модели, ОС и оборудования описаны в стартовом гайде SGLang. В гайде по двум копиям указаны Linux, два подходящих NVIDIA GPU, учебная модель и настройка портов. У документации нет универсального минимума оперативной или видеопамяти для вашего теста; сначала добейтесь ответа от одной копии. Сеть нужна для установки и загрузки выбранной модели, а доступность адресов на своей машине не доказывает полной автономности всего стека. s1

Как посмотреть исходное состояние?

1. Запустите два worker и Gateway на отдельном стенде по связанному гайду. Укажите Gateway явно --host 127.0.0.1 --port 30000: закреплённые Python-аргументы иначе задают 0.0.0.0, то есть прослушивание всех интерфейсов. Если процессы на разных машинах, одного loopback-адреса недостаточно: нужны частная сеть и отдельная проверка доступа; этот учебный маршрут только для одной машины. s1 s3
2. В браузере этой же машины откройте http://127.0.0.1:30000/workers. Найдите два зарегистрированных worker и проверьте их is_healthy; просто две записи ещё не доказывают успешного ответа. Затем откройте http://127.0.0.1:30000/readiness: для обычной маршрутизации закреплённый код возвращает status: ready, число healthy_workers и total_workers, если есть хотя бы один здоровый worker. Запишите начальные значения. s1 s2
3. Отправьте короткий учебный запрос через Gateway, а не напрямую на порт worker, как показано в связанном гайде. Свой маленький вход: «Встреча назначена на вторник. Какой день встречи?» Проверьте, что ответ непустой, без HTTP-ошибки и содержит правильный день — вторник; точную фразу модели редакция не получала. Список /workers или статус ready сами по себе не доказывают работу модели. s1

Как безопасно проверить остановку одного worker?

На изолированном стенде завершите через Ctrl+C процесс одного из двух worker, не Gateway. Повторно откройте /workers и /readiness после того, как проверка здоровья заметит изменение. Для обычного режима код /readiness считает Gateway готовым, пока остаётся хотя бы один здоровый worker: статус может оставаться ready, но healthy_workers должен уменьшиться. Интервал обнаружения зависит от установленных настроек и состояния процесса; не обещайте мгновенного переключения. s1 s2 s3

Теперь отправьте новый короткий запрос через Gateway. Проверьте HTTP-ответ и текст модели. Если второй worker остался здоровым и новый ответ пришёл, ваш тест переключения прошёл. Но уже начатый ответ мог оборваться: код повторяет запрос не при каждой ошибке, а с учётом её типа и настроек. Не называйте такой опыт гарантией бесшовной работы. Если второй worker тоже остановлен или признан нездоровым, обычный маршрут /readiness возвращает HTTP 503 (not ready), тогда как /health проверяет жизнь самого Gateway и может отвечать HTTP 200. s2 s4

Что делать, если результат другой?

• /workers показывает только один worker до теста: проверьте порты и ответы обоих процессов на своей машине; проверка отказа двух worker ещё не началась. s1
• После остановки /readiness остаётся ready с двумя здоровыми worker: не делайте вывод об устойчивости. Дождитесь обновления проверки здоровья и сверяйте журнал Gateway, фактические URL и процессы. Значения интервала в документации и закреплённых Python-аргументах различаются; ориентируйтесь на параметры установленной версии. s1 s2 s3
• Новый запрос не отвечает: сохраните HTTP-ошибку и состояние worker. Не объявляйте failover рабочим лишь по ready; перепроверьте, что запрос идёт на 30000, а оставшийся worker способен ответить напрямую. s1 s2

Граница безопасности: учебный loopback не заменяет разграничение доступа в настоящей сети. В закреплённом коде /server_info и /v1/models входят в публичные маршруты Gateway; прямой доступ к worker также защищается отдельно. Не открывайте этот стенд в интернет и не считайте один API-ключ полной защитой. Для полноценного нагрузочного и аварийного испытания фиксируйте версии, метрики, время обнаружения и результаты каждого нового запроса на своём стенде. s2 s3