Как устроены модели в ИИ Студии¶

ИИ Студия — это не одна нейросеть и не оболочка вокруг одной модели. Это корпоративная рабочая среда: она хранит пользователей, чаты, проекты, документы, знания, права доступа и подключённые сервисы. Модель является заменяемым вычислительным компонентом, который получает подготовленный контекст и формирует ответ.

Поэтому одну и ту же Студию можно использовать с компактной локальной моделью на NVIDIA T4, более мощной моделью на A100 или GPU Platform V4, специализированной моделью для программирования либо с YandexGPT/Alice AI. Пользователь продолжает работать в одном интерфейсе.

Что вы узнаете¶

После этой страницы вы будете понимать:

почему в Студии несколько моделей;
чем локальная модель отличается от модели Yandex AI;
что такое активная модель;
кто имеет право менять фактический модельный маршрут;
как работает Центр управления моделями;
как Студия подбирает модель под реальное оборудование;
почему размер вариант весов — не то же самое, что требуемая VRAM;
почему большая модель не всегда является лучшим рабочим выбором;
как Студия не допускает скрытого перехода из локального контура в облачный;
как узнать, какая модель действительно сформировала конкретный ответ.

Три уровня, которые важно не путать¶

ИИ Студия¶

Это весь продукт целиком. Она отвечает за:

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

Модель¶

Модель получает уже подготовленный запрос и формирует текстовый ответ.

Примеры:

универсальная локальная модель;
локальная модель для программирования;
модель для длинного контекста;
Alice AI LLM;
YandexGPT Pro;
YandexGPT Lite.

Среда выполнения модели¶

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

Главная идея

Пользователь работает с ИИ Студией, а не с vLLM, llama.cpp, портами, CUDA-параметрами или каталогами весов модели.

Почему нет одной «лучшей модели для всех»¶

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

Модель, которая теоретически сильнее, может быть плохим эксплуатационным выбором, если она:

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

Поэтому НайсСофт квалифицирует конкретный вариант развёртывания, а не только название модели: источник вариант весов, формат весов, точность или квантизацию, среду выполнения, рабочий контекст, лицензию и аппаратный профиль.

Центр управления моделями¶

Центр управления моделями — административная часть Студии, которая объединяет:

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

В текущем интерфейсе администратор работает с областями Обзор, Yandex Cloud, Yandex AI, Каталог и управлением допусками моделей.

Кто выбирает фактическую модель¶

В текущей архитектуре реальный источник модели выбирает администратор.

Это важно: обычный сотрудник не должен одним нажатием:

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

Поэтому:

USER использует настроенную Студию и разрешённых помощников;
ADMIN управляет фактическим модельным маршрутом через Центр управления моделями.

Если компании нужны разные модельные сценарии для подразделений, они задаются централизованными политиками, помощниками и модельной архитектурой, а не произвольным управлением GPU каждым сотрудником.

Стабильный маршрут активной модели¶

Внутри Студии используется стабильный логический маршрут nicesoft-active. Пользователю техническое имя знать не обязательно, но принцип полезен:

Чат ИИ Студии
      │
      ▼
активный маршрут
      │
      ├── локальная модель на GPU
      ├── Yandex AI Studio
      └── заранее настроенный внешний совместимый модельный сервер

Администратор может заменить фактическую модель, не перенастраивая пользовательские рабочие места.

Это позволяет:

обновлять модель централизованно;
менять её после модернизации GPU;
использовать Bootstrap на первом запуске;
скрывать служебные ключи и внутренние адреса от браузера.

Какая модель ответила именно на это сообщение¶

Стабильный маршрут не скрывает происхождение ответа. Для сформированного сообщения Студия сохраняет снимок фактической модели:

источник: локальный, Yandex AI или внешний;
идентификатор и понятное название;
тип среды выполнения;
класс обработки данных.

Если сегодня ответ создан локальной Qwen, а завтра администратор включил Alice AI LLM, старый ответ не должен внезапно стать «ответом Alice». Историческая атрибуция фиксируется в момент генерации.

Локальная модель¶

Локальная модель запускается на GPU внутри инфраструктуры организации:

Пользователь → ИИ Студия → локальная модель → ответ

Сам модельный запрос не требуется отправлять поставщику внешнего ИИ API.

Но локальная модель не означает автоматически полное отсутствие внешнего трафика: если пользователь отдельно включает интернет-поиск или внешний сервис, соответствующая часть взаимодействия подчиняется правилам этого сервиса.

Подробнее: Локальные модели.

Yandex AI Studio¶

Если администратор активировал модель Яндекса, путь меняется:

Пользователь → ИИ Студия → защищённый шлюз → Yandex AI Studio → ответ

Необходимый текст запроса и контекст передаются в Яндекс Облако. Студия помечает этот режим как внешний управляемый (managed-external). Отключение журналирования данных у API не превращает облачное вычисление в локальное.

Подробнее: Модели Яндекса.

Никакого скрытого перехода в облако¶

Один из принципов Студии — не менять границу данных молча.

Локальная модель не должна автоматически переключаться на Yandex AI только потому, что:

локальная модель не запустилась;
GPU занят;
закончилась VRAM;
модель была удалена;
облачная модель кажется сильнее.

Для перехода на Yandex AI требуется явное административное действие.

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

Как Студия определяет подходящую модель¶

Мастер использует фактический аппаратный отчёт. Учитываются:

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

Правило «это A100, значит ставим модель X» недостаточно. Студия проверяет реальный сервер.

Размер файла модели и VRAM — разные величины¶

Частая ошибка: увидеть вариант весов 10 ГБ и решить, что 10 ГБ VRAM достаточно.

Во время работы память требуется также для:

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

Поэтому Центр управления моделями показывает расчётный рабочий envelope, а не только размер загрузки.

AWQ, BF16 и FP8 простыми словами¶

BF16 — высокая точность весов, обычно требует больше памяти;
FP8 — более компактный формат для подходящих современных GPU;
AWQ / INT4 — сильнее сжатые веса, позволяющие запускать полезные 7B/8B-модели даже на T4 16 ГБ.

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

Жизненный цикл локальной модели¶

Есть в каталоге
   ↓
Проверена совместимость
   ↓
Скачивание
   ↓
Проверенная установка
   ↓
Запуск среды выполнения
   ↓
Readiness
   ↓
Активная модель

Студия не считает модель готовой только потому, что файлы появились на диске.

Что происходит после перезапуска сервера¶

Выбор локальной модели хранится серверно. После рестарта Model Manager проверяет:

какая модель была выбрана;
установлены ли её файлы;
запущен ли правильный среда выполнения;
действительно ли он обслуживает нужный model ID;
готов ли inference.

Если файлы на месте, но процесс не запущен, механизм согласования состояния пытается восстановить выбранный модельный маршрут.

Что дальше¶

Для пользователя:

Для администратора:

Профиль	Смысл
Универсальная	обычный корпоративный чат, тексты, документы
Программирование	код, конфигурации, отладка
Агентные задачи	многошаговые сценарии и сервисы
Длинный контекст	большой объём текста и длительный контекст
Vision-ready	исходная модель имеет мультимодальный потенциал