Выбор модели LLM для внедрения в продукт

Мы в ispmanager задумали внедрить в продукт LLM, чтобы она давала рекомендации по оптимизации сервера. Расскажу, как мы искали модель под эту задачу, почему не флагманские решения, во сколько обойдётся облако против локального размещения и по каким правилам стоит подключать AI к инфраструктуре.

Как должна работать LLM в ispmanager

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

• анализировать СУБД и веб-окружение сайта, давать рекомендации по оптимизации;
• разбирать ошибки, для начала те, которые возникают при конфигтесте: что не так в конфиге и что исправить;
• дописывать конфигурации веб-сервера под конкретную задачу.

Модель не должна влезать в пользовательские данные. Все работает через безопасную прослойку, которая сначала cобирает и предобрабатывает факты (очищает от лишних данных, рассчитывает значения, форматирует), затем передает их модели. Модель читает и возвращает результат. 

В интерфейсе ispmanager модель должна работать через кнопку, а не в формате чата. Кнопка привязывает LLM к одной задаче. Это проще и безопаснее: 

• Кнопка заточена под узкие задуманные нами задачи, а пользователь не может общаться на посторонние темы. Расход токенов ниже и предсказуем.
• Модель не ходит в инструменты, не выполняет код и команды, не меняет файлы на сервере.

Требования к LLM

Мы определили требования к модели, чтобы она решала задуманные нами задачи в ispmanager. 

1. Понимать код и конфигурации — это база. Модель должна разбираться в синтаксисе SQL, файлах my.cnf, логах ошибок и скриптах, чтобы решать поставленные задачи. 
2. Многоязычный вывод либо перевод — ispmanager мультиязычный, а модель должна говорить на языке пользователя.
3. Свободная лицензия MIT или Apache 2.0 — ​​мы хотим иметь возможность дообучать или поднимать модель на своем сервере.
4. Возможность рассуждения. Модель должна открывать логику: «сначала я проверил X, потом увидел Y, поэтому рекомендую Z». Это должно давать более точное решение задач. 
5. Структурированный вывод: модель должна генерировать JSON-файл вместо текста, чтобы нам можно было красиво вывести ответ в интерфейсе ispmanager, а не просто давать сухой текст.  
6. Достаточно умная, чтобы не приходилось дообучать. В первую очередь проверяем, подойдет ли нам готовая модель. Если модель отвечает плохо, сначала итерируем над промптами и пайплайном. Бóльшую часть прироста качества даёт лучший контекст, уточнение промптов и предобработка данных, а не файнтюн. Вдобавок OpenAI-совместимый API делает модель заменяемым элементом: выйдет модель лучше с той же лицензией (MIT или Apache 2.0) — меняем текущую на новую и прогоняем на эталонных данных.Проблема с дообучением в том, что для него все равно придётся собрать несколько тысяч примеров на базовой модели. 
7. Но не настолько умная, чтобы стоить дорого. Мы предположили, что флагманские модели брать не обязательно. Задачи узкие, данные предварительно можно обработать, хватит LLM среднего размера 20-40 миллиардов параметров.

Безопасность 

Мы встраиваем AI в продукт, который работает с конфигами, базами данных и логами на реальных серверах клиентов. У пользователя должен оставаться контроль над исполнением — модель предлагает действия для достижения результата, но итоговое решение только за человеком. АI-фичи должны работать с предсказуемым выводом, адаптированным под задачу. Решение должно быть безопасным. Исходя из этого, мы сформулировали требования, обязательные для каждой интеграции AI в ispmanager.

1. Без состояния. AI-сервис не хранит контекст. Каждый запрос самодостаточен: факты, конфиги, логи передаем в теле запроса. Многошаговый процесс — это ограниченный цикл, в котором панель управления повторно отправляет полный контекст вместе с новой информацией.
2. Вывод недоверенный, применение на сервере. AI ничего не выполняет и не тестирует. Все ответы модели считаем недоверенными: панель управления сама проверяет корректность, применимость операции и права пользователя.
3. Детерминированная предобработка. Всё, что считается детерминированно — пороги, коэффициенты, применимость правил, — вычисляем до передачи в контекст. Модель рассуждает над готовыми данными и никогда не делает арифметику.
4. Маскирование секретов. Пароли, ключи и чувствительные данные маскируются, например *** или <REDACTED>, до того, как панель отправит данные в AI-сервис. Сам сервис никогда не должен получать секретные данные. Лучше их вообще не передавать

Считаем экономику: железо или облако

Хотелось, чтобы решение стоило недорого. На стоимость влияет модель тарификации и размещение. Здесь два классических варианта: облако или свое железо.

У сервера с GPU фиксированная плата в месяц. У облака оплата по токенам: входные (запрос, начальный промпт, контекст, пользовательский ввод) и выходные (ответ модели, включая токены на рассуждение). Плюс кэшированные токены (выходные токены, которые уже есть в памяти). Их стоимость будет ниже, чем на выходные. У российских поставщиков цены на российские модели на вход и выход обычно совпадают, у зарубежных чаще различаются: Claude Opus 4.8 берёт $5 за 1 млн входных токенов и $25 за выходные, а YandexGPT Pro 5.1 — 800 ₽ и за вход, и за выход.

Посчитали стоимость на самом «тяжёлом» сценарии — анализ веб-окружения с ответом на русском. Цены на июль 2026. Для интереса подсчитали в том числе и стоимость для флагманских моделей.

А вот такую цену за запрос рассчитали при размещении модели на дедике локально. 

На этом объёме свой сервер (RTX 4090 24 GB, 56 900 ₽/мес) проигрывает почти всей выборке и обходит по деньгам только премиальные модели. Причина в природе затрат: сервер платит фиксированную сумму независимо от нагрузки, облако — только за фактические запросы. Пока пользователи не жмут кнопку, сервер простаивает, а деньги идут.

Точка перелома считается просто: фиксированная стоимость сервера делится на стоимость одного запроса в облаке. Против дешёвого GigaChat Lite (1,11 ₽ за запрос) свой сервер окупается только к ~51 000 запросов в месяц, против среднего gpt-oss-120b (5,10 ₽) — к ~11 000. Отсюда вывод расчёта: до 5000 запросов в месяц выгоднее облако. Свой сервер оправдан на бóльших объёмах, а также там, где нужен суверенитет данных или дообучение.

Выбираем семейство LLM 

Под наши параметры подходит семейство моделей Qwen3.6 (китайская Alibaba) и Gemma 4 (американская Google), есть множество вариантов и конфигураций. Qwen-модели больше оптимизированы под задачи с кодом и конфигами с упором на агентский стиль выполнения. Gemma-модели тоже обучены читать и писать код, но они имеют более общий профиль задач с упором на общение с пользователем в формате чата. Для текущих задач Qwen3.6 выглядит выигрышным семейством моделей, по бенчмаркам доходящим до крупных моделей от гигантов рынка.

Определяем архитектуру

С семейством определились, теперь нужно выбрать архитектуру. Два основных варианта: dense (плотные) и Mixture of Experts (MoE, смесь экспертов).

На старте берём MoE-модель. Она выигрывает в скорости: 27 млрд параметров против 3 млрд.

Что потом

Наш фаворит — модель Qwen 3.6 в облаке. Для первого запуска этого достаточно: на первых порах облако дешевле своего сервера, а OpenAI-совместимый API оставляет модель заменяемым элементом — когда объём или требования к данным вырастут, легко переехать на свой сервер.

Финальный выбор стоит делать после прогона на наших эталонных данных с реальными конфигами и ошибками по сценариям выше. Как раз над сбором эталонных данных мы сейчас и работаем. Инфраструктура неоднородна, и единого решения для всех серверов у нас нет — здесь мы пока копаем руду.

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

А как у вас с внедрением LLM? Расскажите о своём опыте: какие модели пробовали, где развернули и что в итоге сработало.