Подготовка и развёртывание Джины у клиента

Схема размещения — шаблон · Пример схемы · Условия и результаты запуска — шаблон.

Процедура применяется, когда Джина разворачивается в инфраструктуре клиента. Размещение моделей выбирается отдельно: Джина может использовать локальные модели или выбранный облачный сервис. Локальная установка моделей описана в отдельном гайде.

ИИ-инженер работает с DevOps клиента; РП клиента организует предоставление ресурсов и доступов. Конкретные компоненты, параметры и команды определяются документацией выбранной версии Джины.

1. Определить поставку Джины и требования

ИИ-инженер получает у вендора документацию выбранной версии Джины: установку, конфигурацию, зависимости, исполнителей, интеграции, рабочее место инженера и диагностику.

По документации определить требования платформы к вычислительным ресурсам, памяти, диску, сети и способу размещения. Отдельно выписать требования к API моделей, режимам инструментов, контексту и входным форматам; передать их участникам, выбирающим модели. Неизвестные параметры и отсутствующие инструкции оформить вопросами вендору.

Результат: версия и источники документации, требования платформы и список открытых вопросов. Записать в схему размещения и план подготовки зависимостей.

2. Подготовить ресурсы и доставку Джины

DevOps по запросу РП клиента обеспечивает ресурсы, адреса, хранилища, аккаунты и сетевые связи согласно требованиям поставки. Выбор VM, контейнеров или другого способа определяется поддерживаемой поставкой и условиями клиента.

ИИ-инженер с DevOps проверяет получение дистрибутива Джины и её зависимостей. Для закрытого контура определить допустимый способ доставки. Драйверы и runtime готовятся, если они требуются выбранным компонентам платформы.

Результат: среда установки, комплект поставки и проверенные предпосылки в плане подготовки зависимостей. При отсутствии необходимых ресурсов или инструкций зависимая установка ожидает их; независимые работы продолжаются.

3. Развернуть и проверить Джину

ИИ-инженер и DevOps выполняют установку по инструкции поставки: обязательные компоненты и зависимости, конфигурацию, секреты, сетевые адреса и хранение результатов.

Проверить готовность компонентов и вход, создать проект клиента, подключить предусмотренных исполнителей и рабочее окружение. Настроить полномочия администратора, аккаунтов Джины и участников для необходимых операций. Сохранить версию и диагностические подтверждения без секретов.

Результат: развёрнутая платформа и проект клиента. Версию, адреса и проверки записать в форму условий онбординга, доступы участников — в реестр оркестратора.

4. Подключить модели и проверить запуск агента

Предусловие: Джина развёрнута, выбранные сервисы моделей доступны и проверены по реестру моделей. Если модели устанавливаются у клиента, использовать результаты проверки локального инференса.

ИИ-инженер подключает модели к проекту Джины. Проверить endpoints из фактического контура выполнения агентов, авторизацию и назначения моделей, затем текстовую, визуальную и инструментальную операции через Джину. Облачный маршрут используется только при принятом решении о таком размещении; запасной маршрут не предполагается.

Проверить характерный входной объём и начальный параллелизм в согласованных пределах. При недостаточности ресурсов записать ограничение и решение. Это техническая проба, а не нагрузочное исследование всего продукта.

Выполнить штатный проверочный запуск агента с сохранением результата и доступного журнала. Такой запуск подтверждает работу платформы, но не заменяет продуктовый проход онбординга.

Результат: подтверждения подключений в реестре моделей, версия платформы, ID запуска, результат и журнал — в условиях онбординга.

5. Подключить системы и рабочее место инженера

Настроить выбранные Git, трекер, чат, CI/CD, хранилище артефактов и первую DEV, необходимые первой работе. Адреса и настройки берутся из принятых решений о системах проекта.

Подготовить локального агента инженера либо АРМ в оркестраторе по поддерживаемой инструкции. Проверить чтение hub и проектных материалов, разрешённое изменение литературы и просмотр журналов.

Результат: проверенные подключения в реестрах Git и других систем, готовое рабочее место в условиях онбординга. Готовность первой среды и продуктовой задачи проверяется по чек-листу PoC; адаптация проектных агентов начинается на онбординге.