# Checkpoint engine в SGLang: как ждать реальные веса перед readiness

При работе SGLang с checkpoint engine готовность процесса нужно отделять от получения реальных весов.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/sglang-checkpoint-readiness-gate/
Language: ru

При работе SGLang с checkpoint engine готовность процесса нужно отделять от получения реальных весов. Dummy initial load может позволить подготовить runtime раньше доставки checkpoint, но не подтверждает пригодность inference. Для такого сценария задайте gate, который открывается после необходимой загрузки и функциональной проверки. Обычный health check без учета выбранного пути загрузки способен дать преждевременное разрешение на отправку рабочих запросов.

## Что означает dummy load

[Руководство checkpoint engine](https://docs.sglang.io/docs/advanced_features/checkpoint_engine) описывает интеграцию передачи весов и именованных checkpoints. Служебное начальное состояние предназначено для определенного workflow и не должно восприниматься как загруженная публичная модель. Зафиксируйте источник весов, ожидаемое имя и revision. Один локальный model directory не объясняет, что фактически было передано runtime. Если процесс умеет принимать обновления, момент запуска и момент появления нужных параметров становятся разными событиями, которые следует наблюдать и документировать отдельно.

## Выберите readiness gate

В [server arguments](https://docs.sglang.io/docs/advanced_features/server_arguments) есть `checkpoint-engine-wait-weights-before-ready` для ожидания начальных весов. Проверяйте точную поддержку и поведение установленной версии. Такой параметр не заменяет политику выкладки модели: он решает конкретную startup задачу. В отличие от общего canary подхода, здесь сначала требуется доказать, что экземпляр вообще получил предназначенный checkpoint. Сохраните условие готовности в orchestration configuration, чтобы следующий оператор не вернул ранний health probe по привычке от обычной загрузки неизменных весов.

## Пример последовательности приемки

Опишите состояния «runtime подготовлен», «веса ожидаются», «получен named checkpoint», «готовность разрешена» и «контрольный запрос выполнен». Для каждого укажите источник наблюдения и timeout. Это схема проверки интеграции, а не утверждение о действующих средствах Retrivium. До получения нужного checkpoint test controller не должен направлять обычный inference. Негативный сценарий с задержанной доставкой важен: gate обязан оставаться закрытым, а не объявлять успех только потому, что процесс долго работает без исключения и успешно отвечает сетевой probe.

## Подтвердите идентичность загрузки

Сопоставьте metadata доставки с ожидаемым checkpoint и журналом принимающего процесса. Затем выполните заранее сохраненный functional fixture. Сам ответ не доказывает точное совпадение всех tensor bytes, а внешний checksum файлов не доказывает применение весов в GPU runtime. Это разные свидетельства, которые следует соединить в отчете. Если именованный checkpoint не совпадает, остановите приемку выбранной версии вместо попытки объяснить необычный ответ sampling настройками или незаметного изменения ожидаемого результата под фактический вывод сервера.

## Отделите startup от последующих обновлений

Начальное ожидание весов и дальнейшая замена параметров имеют разные переходы состояния. Не переносите гарантию initial readiness автоматически на каждый последующий update. Для дополнительного workflow нужна собственная проверка того, когда разрешены запросы и какой checkpoint они используют. Сохраните версии, metadata, последовательность событий и rollback источник. Практический результат — воспроизводимый gate с понятной причиной закрытого состояния. Он позволяет увидеть, что сервер ждет доставку, получил неправильный артефакт либо не прошел functional check, а не сводит все случаи к общему «сервер не готов». Такой разбор также предотвращает ошибочное использование dummy состояния как производственной модели при внешне успешной инициализации runtime.

## Связанные материалы

[Обновление LLM на GPU: как проверять новую версию небольшим запуском](/ru/journal/model-update-canary/); [vLLM запущен, но не готов: процессы, health и первый запрос](/ru/journal/vllm-health-ready/).