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

Источник: https://modelium.tech/zhurnal/sglang-model-gateway-router/

SGLang Model Gateway принимает запросы и направляет их к отдельным процессам с моделью — worker. На собственном изолированном стенде состояние можно смотреть через /workers, а готовность маршрутизатора — через /readiness. При обычной маршрутизации одного здорового worker достаточно для статуса ready, но это не доказывает, что уже начатый ответ переживёт отказ. Редакция не запускала этот опыт.

**Инженерная проверка, не домашний рецепт.** Нужен уже работающий изолированный стенд с двумя отдельными worker SGLang, маршрутизатором, доступом к процессам и совместимым железом. [Базовый гайд с двумя копиями модели](/zhurnal/sglang-data-parallel/) описывает запуск. Эта инструкция сверена с документацией и кодом на Git-коммите `678913a0`; Modelium не устанавливал Gateway, не скачивал модель и не отключал worker. Не останавливайте рабочий сервер компании. [s1](#src-s1) [s2](#src-s2)

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

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

Один worker и выбор модели, ОС и оборудования описаны в [стартовом гайде SGLang](/zhurnal/sglang/). В [гайде по двум копиям](/zhurnal/sglang-data-parallel/) указаны Linux, два подходящих NVIDIA GPU, учебная модель и настройка портов. У документации нет универсального минимума оперативной или видеопамяти для вашего теста; сначала добейтесь ответа от одной копии. Сеть нужна для установки и загрузки выбранной модели, а доступность адресов на своей машине не доказывает полной автономности всего стека. [s1](#src-s1)

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

- Запустите два worker и Gateway **на отдельном стенде** по связанному гайду. Укажите Gateway явно `--host 127.0.0.1 --port 30000`: закреплённые Python-аргументы иначе задают `0.0.0.0`, то есть прослушивание всех интерфейсов. Если процессы на разных машинах, одного loopback-адреса недостаточно: нужны частная сеть и отдельная проверка доступа; этот учебный маршрут только для одной машины. [s1](#src-s1) [s3](#src-s3)

- В браузере этой же машины откройте `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](#src-s1) [s2](#src-s2)

- Отправьте короткий учебный запрос **через Gateway**, а не напрямую на порт worker, как показано в связанном гайде. Свой маленький вход: «Встреча назначена на вторник. Какой день встречи?» Проверьте, что ответ непустой, без HTTP-ошибки и содержит правильный день — вторник; точную фразу модели редакция не получала. Список `/workers` или статус `ready` сами по себе не доказывают работу модели. [s1](#src-s1)

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

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

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

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

- `/workers` показывает только один worker **до** теста: проверьте порты и ответы обоих процессов на своей машине; проверка отказа двух worker ещё не началась. [s1](#src-s1)

- После остановки `/readiness` остаётся `ready` с двумя здоровыми worker: не делайте вывод об устойчивости. Дождитесь обновления проверки здоровья и сверяйте журнал Gateway, фактические URL и процессы. Значения интервала в документации и закреплённых Python-аргументах различаются; ориентируйтесь на параметры установленной версии. [s1](#src-s1) [s2](#src-s2) [s3](#src-s3)

- Новый запрос не отвечает: сохраните HTTP-ошибку и состояние worker. Не объявляйте failover рабочим лишь по `ready`; перепроверьте, что запрос идёт на `30000`, а оставшийся worker способен ответить напрямую. [s1](#src-s1) [s2](#src-s2)

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

## Источники

1. [SGLang Model Gateway: официальный guide на закреплённом Git-коммите](https://raw.githubusercontent.com/sgl-project/sglang/678913a0f029394ad1f4ee64d1439421e9ea56ef/docs/docs/advanced_features/sgl_model_gateway.mdx) — получено 2026-10-22
2. [SGLang Model Gateway: серверные маршруты и readiness, закреплённый код](https://raw.githubusercontent.com/sgl-project/sglang/678913a0f029394ad1f4ee64d1439421e9ea56ef/sgl-model-gateway/src/server.rs) — получено 2026-10-22
3. [SGLang Model Gateway: Python RouterArgs, закреплённый код](https://raw.githubusercontent.com/sgl-project/sglang/678913a0f029394ad1f4ee64d1439421e9ea56ef/sgl-model-gateway/bindings/python/src/sglang_router/router_args.py) — получено 2026-10-22
4. [SGLang Model Gateway: маршрутизация и повторы, закреплённый код](https://raw.githubusercontent.com/sgl-project/sglang/678913a0f029394ad1f4ee64d1439421e9ea56ef/sgl-model-gateway/src/routers/http/router.rs) — получено 2026-10-22