Платформа 4.0
Жизненный цикл модели
Загрузка ZIP-пакета, состояния in_validation / in_testing / tested / failed, публикация и обновление зависимых сценариев.
На этой странице
Модель и версия хранятся отдельно
Карточка модели содержит имя, тип задачи, тип модели, описание и атрибуты. Версия имеет собственный идентификатор и обозначение. Файлы пакета хранятся в MinIO, метаданные и состояние — в PostgreSQL. svr-models-registry управляет этим каталогом.
| Сущность | Основные поля |
|---|---|
| Карточка модели | name, task_type_id, mdl_type_id, mdl_section_id, attributes |
| Версия | mdl_id, version, description, run_validation |
| Пакет | model_info.json, coco_categories.json, веса и файлы протокола |
Автоматическая проверка: состояния и события
После загрузки пакета событие model_version_uploaded запускает обработку inf-flows-manager. Он получает файлы, выполняет необходимую конвертацию и контрольный inference. Проверки технической работоспособности и точности на вашей сцене — разные этапы.
- 1model_version_uploaded↓ Начало валидации
Пакет зарегистрирован; задача передана на обработку.
- 2in_validation↓ Успешная проверка структуры
Загрузка файлов, конвертация и проверка метаданных.
- 3in_testing↓ Контрольный запуск успешен
Контрольный inference для заявленных профилей исполнения.
- 4tested
Техническая проверка пройдена; пользователь оценивает результат и принимает решение о публикации.
Ошибка конвертации, валидации или тестирования приводит к failed с диагностическим сообщением. Изменения передаются событием model_version_change_status.
| Состояние | Что делать |
|---|---|
| in_validation | Следить за обработкой и журналом менеджера / конвертера |
| in_testing | Дождаться контрольного inference |
| tested | Проверить качество на репрезентативном ассете |
| failed | Исправить причину по диагностике; повторить проверку через revalidate |
Публикация и использование
После tested реестр публикует model_version_ready. При публикации устанавливается is_published и версия становится доступна для выбора в сценариях. При старте реестр передаёт актуальный опубликованный каталог через models_registry_ready. Фактическая загрузка в GPU происходит при исполнении использующего модель сценария.
Обновление и удаление
Перед заменой версии проверьте использующие её опубликованные сценарии. Групповое обновление через inf-flows-manager последовательно меняет ссылки на модель и создаёт новые опубликованные версии успешно обновлённых сценариев. Проверьте результаты по каждому сценарию, а не только статус общей операции.
- Повторите контрольные запуски после смены модели.
- Проверьте использование версии на камерах перед архивированием и удалением.
- Архивирование сохраняет возможность восстановления в пределах политики хранения; физическое удаление требует устранения зависимостей.
Реестр, категории и зависимости модели
Продуктовое описание предусматривает поиск по названию, версии, категории, атрибутам и дате обновления, комментарии, архивирование и восстановление. Для категории могут задаваться название, цвет, порог уверенности и минимальные размеры детекции. Эти настройки влияют на сценарии, использующие модель: перед заменой проверьте зависимости.
MLflow Model Registry, PostgreSQL и backend API описаны как компоненты контура управления моделями. Конкретная конфигурация хранения и доступность форматов ONNX, PyTorch, TensorFlow или TensorRT определяются runtime поставки; название формата не гарантирует совместимость любого файла.
MLOps-контур Platform 4.0 · открыть
