Перейти к содержанию

Переключение активной модели

Фактический модельный маршрут — централизованный ресурс ИИ Студии. Его переключает администратор через Центр управления моделями.

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

USER и ADMIN

Обычный пользователь

  • работает с чатами;
  • использует разрешённых помощников;
  • видит фактическую модель ответа;
  • не устанавливает вариант весов;
  • не меняет глобальный provider;
  • не запускает/останавливает среда выполнения GPU.

Администратор

  • устанавливает локальные модели;
  • активирует установленную модель;
  • подключает Yandex AI;
  • выбирает managed-модель Яндекса;
  • удаляет вариант весов;
  • контролирует соответствие и среда выполнения.

Что не теряется при смене модели

Переключение не удаляет:

  • пользователей;
  • историю;
  • проекты;
  • документы;
  • базы знаний;
  • права.

Меняется модельный маршрут, который обрабатывает новые запросы.

Историческая атрибуция сохраняется

Пример:

Понедельник: Qwen3 8B AWQ → ответ A
Вторник: ADMIN включил Alice AI LLM
Среда: открыт старый чат

Ответ A остаётся помеченным Qwen3 8B AWQ. Смена глобального route не переписывает историю.

Локальная → другая установленная локальная

Перед началом проверьте:

  • новая модель совместима;
  • статус установлена;
  • нет критичной генерации;
  • нет другой подготовка модели operation.

Шаги

  1. Откройте Модели → Каталог.
  2. Найдите модель.
  3. Проверьте соответствие.
  4. Нажмите Активировать.
  5. Дождитесь смены среда выполнения.
  6. Откройте Обзор.
  7. Проверьте конкретное имя модели.
  8. Выполните новый smoke-test.

Что происходит внутри

Model Manager:

  1. сохраняет желаемую модель как pending;
  2. определяет среда выполнения;
  3. останавливает конфликтующий среда выполнения;
  4. запускает выбранный artifact;
  5. ждёт inference_ready;
  6. проверяет совпадение идентификатора модели в среде выполнения;
  7. переводит модель в active.

Это защищает от ситуации, когда интерфейс уже показывает новую модель, а среда выполнения ещё отвечает старой.

Установка новой модели = установка и последующая активация

При штатной установке из каталога Model Manager запоминает выбранную модель как желаемую. После verified install reconciler запускает её и переводит маршрут автоматически.

Не запускайте вторую модель параллельно: server-side lock защищает от конфликтующих подготовка модели-операций.

Локальная → Yandex AI

Это изменение границы данных.

Перед началом:

  • Yandex AI подключён;
  • probe успешен;
  • политика разрешает облачную обработку;
  • понятна тарификация;
  • выбрана конкретная curated-модель.

Шаги

  1. Откройте Модели → Yandex AI.
  2. Проверьте интеграцию.
  3. Выполните Проверить доступ.
  4. Выберите модель.
  5. Подтвердите активацию.
  6. Дождитесь READY.
  7. Проверьте Обзор.
  8. Создайте новый тестовый чат.
  9. Проверьте подпись модели Яндекса.

Danger

После переключения новый модельный контекст обрабатывается Yandex AI Studio.

Почему лучше создать новый чат после local → cloud

Продолжение старого чата может передать облачной модели часть старого контекста.

Безопаснее:

  1. завершить локальный разговор;
  2. открыть новый чат;
  3. передать только данные, разрешённые для облачной обработки.

Yandex AI → локальная

  1. Откройте Каталог.
  2. Найдите установленную локальную модель.
  3. Проверьте соответствие.
  4. Нажмите Активировать.
  5. Дождитесь готовность.
  6. Проверьте источник Локальная модель.
  7. Начните новый конфиденциальный чат.

Возврат локально не отменяет факт предыдущей облачной обработки; он влияет на последующие запросы.

Удаление активной модели

Студия поддерживает безопасное удаление даже выбранной локальной модели.

Порядок:

  1. удаляемая модель выводится из маршрута;
  2. среда выполнения останавливается;
  3. файлы удаляются;
  4. ищется другая уже установленная совместимая локальная рабочая модель;
  5. если она есть — активируется;
  6. при отсутствии локальной может использоваться только заранее явно настроенный внешний модельный сервер;
  7. без резервной модели остаётся состояние модель не выбрана.

Bootstrap/test-модель не должна автоматически становиться рабочей резервной моделью.

Резервный маршрут с приоритетом локальной модели

Если доступны:

  • другая установленная локальная модель;
  • ранее настроенный внешний провайдер,

Model Manager предпочитает локальную рабочую модель. Это помогает не менять границу обработки данных неожиданно.

После перезапуска сервера

Выбор хранится серверно. После restart Model Manager:

  1. читает desired state;
  2. проверяет файлы;
  3. проверяет среда выполнения;
  4. запускает выбранную локальную модель при необходимости;
  5. ждёт готовность;
  6. восстанавливает маршрут.

Ручная активация после каждого обычного reboot не требуется.

Активна, но чат не отвечает

Проверьте:

  • готовность среды выполнения;
  • совпадает ли model ID;
  • OOM;
  • состояние pending activation;
  • Model Router;
  • логи Model Manager.

См. Ошибки моделей.

Smoke-test после каждой административной смены

  1. Создайте новый чат.
  2. Отправьте короткий вопрос.
  3. Дождитесь полного ответа.
  4. Проверьте фактическую модель.
  5. Сделайте второй запрос в том же чате.
  6. При локальном режиме убедитесь, что нет неожиданного Yandex provider.
  7. При Yandex AI убедитесь, что источник явно облачный.

Не переключайте крупные модели слишком часто

Частая смена:

  • выгружает/загружает десятки гигабайт VRAM;
  • создаёт окна недоступности;
  • путает пользователей;
  • осложняет сравнение качества;
  • ухудшает воспроизводимость.

Лучше закрепить понятную модельную политику организации.

Коммуникация сотрудникам

При значимой смене модели сообщите:

  • дату;
  • новое название;
  • локальная или облачная;
  • изменились ли правила по конфиденциальным данным;
  • для каких задач выбрана;
  • куда сообщать о регрессиях.

Что дальше