В этом материале
Обновление Triton repository нужно проверять вместе с model control mode и version policy.
Обновление Triton repository нужно проверять вместе с model control mode и version policy. Новая папка версии не гарантирует немедленное переключение inference. NONE, POLL и EXPLICIT по-разному реагируют на изменения и управляющие запросы. Для приемки сохраните исходное состояние, выбранное действие и готовность конкретной версии. Это управление жизненным циклом repository, отдельно от общего решения направить часть трафика на canary модель или сравнить качество ответов.
Установите control mode
Руководство model management описывает три режима. NONE игнорирует изменения работающего repository, EXPLICIT требует управляющих действий, а POLL обнаруживает изменения согласно своему механизму. Не смешивайте их в одной процедуре reload. Сначала запишите фактический startup mode и разрешенные операции. Если load request возвращает ошибку, это может быть ожидаемым следствием режима, а не неисправностью файлов модели. Успешное копирование каталога тоже не доказывает, что сервер заметил его и начал готовить новый экземпляр.
Проверьте version policy
Документация model configuration различает All, Latest и Specific. При выборе Latest важна числовая версия, а не время изменения файлов. Папка с меньшим номером может не стать обслуживаемой новой версией только потому, что была добавлена позже. Укажите policy явно в приемочном артефакте. Если клиент не задает версию, проверьте правила выбора, а не выводите ее по публичному имени модели. Имя и номер версии относятся к разным частям запроса и repository контракта.
Пример контролируемого reload
Для тестовой модели заведите две известные версии и policy, допускающую нужную из них. Запишите состояние до изменения, действие load/unload или обновления repository и последующую readiness каждой версии. Это схема эксперимента, не обещание бесшовного reload для любого backend. При EXPLICIT следуйте документированному порядку обновления, не предполагая, что замена файлов активного экземпляра сама запустит reload. Сохраните status управления и функциональный запрос с явно выбранной версией, чтобы отличать готовность процесса Triton от доступности требуемой модели.
Разберите неудачное обновление
Если новая версия unavailable, сохраните диагностическое сообщение и проверьте, осталась ли прежняя доступной в выбранном сценарии. Не обобщайте поведение одного режима на остальные. При POLL учитывайте риск наблюдения частично подготовленного repository и используйте предусмотренную процедуру публикации файлов. Не заставляйте рабочий сервер читать незавершенную копию только ради проверки реакции. Для диагностики создайте отдельный тестовый repository. Логическая ошибка policy может выглядеть как ошибка загрузки, поэтому сначала сопоставьте список доступных версий с заявленным правилом выбора.
Сохраните протокол управления
В отчет включите control mode, version policy, directory layout, управляющие запросы, readiness и functional fixtures. Разделите «файлы обновлены», «load принят», «версия готова» и «клиент использовал ее». Каждое событие имеет отдельное доказательство. При rollback восстановите и артефакты, и policy, иначе старые файлы могут остаться недоступными. Полезный результат показывает последовательность переходов конкретной версии и позволяет повторить обновление без догадок. Он не обещает автоматического canary, неизменного latency или безошибочного hot swap любой модели: эти свойства требуют отдельных проверок backend и трафика после того, как базовый repository lifecycle уже подтвержден на используемой версии Triton.
Связанные материалы
Обновление LLM на GPU: как проверять новую версию небольшим запуском; vLLM запущен, но не готов: процессы, health и первый запрос.