Так как мои настольные игры не совсем простые (а именно обучающие и научные), то вопросы по правилам у родителей возникают регулярно. И как хорошо правила не напиши, научная тематика делает свое «черное» дело и даже минимальное вкрапление методики ставит игроков в ступор по тем или иным моментам правил. Плюс читать правила, FAQ, дополнительные правила и т. п. не всегда оптимальный вариант.

Поэтому захотелось мне прикрутить к сайту нейронку в виде чата с ИИ‑помощником, который бы для каждой игры свои правила объяснял и на вопросы пользователей отвечал.

Хочу отечественное

Первым на ум пришел Сберовский GigaChat, благо уже была идея с помощью него сделать чат‑бот для игры в Битву Големов. И если чат‑бот идет бесплатным, то с API ситуация совсем другая. Зарегался я на сайте Sber Developers для начала как частное лицо и начал думать, как все реализовать.

С виду все отлично — дают для GigaChat Lite 1 000 000 токенов, новые токены стоят 1000 рублей за 5 000 000 и можно пополнять баланс. Для ИП, так как после теста ИИ помощник должен был работать на благо издательства, нужно покупать пакетами по 25 000 000 (благо они год действуют) или по факту потребления 20 копеек за 1000 токенов. Токены считаются в сумме запрос+ответ.

Архитектуру я себе представили такую: JS скрипт + CSS стиль + кусочек HTML оформления, которые встраиваются на страницу (у меня сайт в Tilda и можно просто «бросить» туде блок с HTML кодом), скрипт делает запрос к Сберу к модели (Lite это простой GigaChat или точнее GigaChat2), получает ответ, форматирует его и выводит пользователю. Ну и небольшая память на 4–5 пар сообщений, когда с каждым запросом посылается текст пары вопрос‑ответ предыдущие + сохранение состояния, чтобы при релоаде страницы все не стиралось.

Вайб кодинг с поиском в чате Qwen3 мне в помощь + небольшое допиливание ручками и прототип готов.

Из особенностей работы нужно учесть следующее — вы сначала получаете токен по API ключу, потом уже с этим токеном запрашиваете ендпоинт /chat/completions. Также нужно что‑то делать с самими файлами правил. Первый вариант — через API подгружать файл правил в модель через API, второй — передавать его в тексте системного запроса.

Я выбрал для простоты второй вариант «на попробовать». И.... вылезли ошибки CORS, так как к моделям Сбера с клиентского JS обратиться не получится. Ладно... Такие вещи уже привычные, поэтому (магия Вайбкодинга + небольшое знание Python) и готов CORS прокси сервер, к которому обращаемся для получения токена и который находится на сервере с доменным именем и от его имени запрашивает токен для нашего сайта для работы с нейросетевой моделью

// --- ВСПОМОГАТЕЛЬНАЯ ФУНКЦИЯ: Получение токена GigaChat через HTTPS-ПРОКСИ ---
async function getGigaChatToken() {
// Обращаемся к Nginx, который проксирует запрос на локальный сервер
  const proxyUrl = "https://<мой домен>/gigachat_proxy/get-gigachat-token";          
    try {
          const response = await fetch(proxyUrl);
          if (!response.ok) {
            const errorData = await response.json();
            throw new Error(`Ошибка получения токена: ${response.status}. ${errorData.error} ${errorData.details || ''}`);
          }
            
          const data = await response.json();
          return data.access_token; // Возвращаем полученный токен
     } catch (error) {
            console.error("Ошибка в getGigaChatToken:", error);
            throw error;
            }
     }

Дополнительно «рисуем» эндпоинты для этого, благо nginx есть и через него уже настроен и чат‑бот ВК и CORS сервер картинок для редакторов, нужно только добавить секцию для работы со Сбером.

Запускаем и получаем проблему наследования сертификатов. Так как у Сбера в вызовых API стоят сертификаты Минцифры. Временно отключаем это в коде прокси‑сервера и готовимся вручную качать pem файлы и ставить корневые сертификаты на сервер.

Так — первая проблема пройдена. Токен получен, запрос идет и... опять получаем проблему с CORS, так как и второй запрос у нас идет от клиентского JS. Но тут по проверенной — добавляем в наш Питон‑прокси‑CORS‑сервер вторую часть, которая также передает наш запрос и возвращает его с нужными полями назад. Второй эндпоинт прописываем в nginx и получаем проксируемый запрос, привычный, если вы работали другими моделями по API.

const response = await fetch("https://<мой домен>/gigachat_proxy/chat/completions", {
   method: "POST",
   headers: {
      "Authorization": `Bearer ${gigaChatToken}`,
      "Content-Type": "application/json",
      "Accept": "application/json"
            },
      body: JSON.stringify({
         model: "GigaChat", // <<< ИСПОЛЬЗУЕМ МОДЕЛЬ "GigaChat Lite" >>>
         messages: messagesForGigaChat,
         temperature: 0.7,
         max_tokens: 1024
          })
});

Теперь заработало... Но смотрим на то, как через пару запросов начинает таять наш счетчик оставшихся токенов. За один запрос, так как мы передаем туда правила (для тестовой игры это было примерно 15 килобая текста), мы съедаем около 7000–8000 токенов. Берем калькулятор и начинаем считать, во сколько нам обойдется это удовольствие:

5 000 000 платных токенов при якобы средних 10 000 токенов дает нам 500 запросов. Эти при учете, что мы будем передавать правила небольшого размера и каждый раз передавать только минимальный размер правил. Но для той же Битвы Големов объем только правил при преобразовании в txt формат составляет 43 килобайта. то есть почти в три раза больше и значит тратить мы будем в 2–3 раза больше токенов. Учитывая,что у нас еще и память на 5 пар вопрос‑ответ, уточение запроса будет умножать наши минимальные 8000 на 2, потом снова на 2 и снова на 2 и снова на 2. Не думаю что пользователи будут часть обнулять все и жать на кнопку «Новый чат».

То есть нам нужно будет или не делать память, тогда бот будет туповат и начнет забывать даже то, что он вам только что ответил, или реально тратить десятки тысяч токенов за раз. 150 000 токенов я потратил в режиме тестирования за 5 запросов. Благо тут они были бесплатными, но в боевом режиме с меня списалось бы уже 30 рублей. А если бы я захотел передать модели полные версии правил, FAQ, дополнительные правила, методику для преподавателй, то спокойно бы сжигал и 100 000 токенов за раз и более. Да, можно было бы надеяться, что нажимать будут не так часто, но вопрос, насколько?

Можно было заморочиться и с загрузкой файлов и с эмбедингами с отдельной тарификацией и так далее, но я решил посмотреть (и посчитать) второй вариант.

Плюс такого метода, что вы платите только за реальные запросы пользователей и получаете ответ быстро от модели с 20B параметров (судя по данным выложенной в открытый доступ модели). А попробовать можно бесплатно (для некоммерческого применения).

Минусы — это все идет в одном потоке и перестанет работать, как только у вас закончатся токены, если вы только не работает по постоплате за фактическое потребление.

Свой VGPU сервер

Вторым вариантом является аренда сервера с GPU. Для моих нужд хватит чего‑то с 16 Гб видеопамяти типа A4000, благо арендовать такой сервер можно в районе 9–12 тысяч рублей в месяц. Но при этом у вас нет проблем с токенами, вы можете выбрать ту модель, какую захотите, а при контексте ответа в 2-4K можно сюда уложить даже открытую модель от OpenAI с 20B параметрами и спокойно работают размышляющие 14B модели типа Qwen3. Так как оплата почасовая, отказаться от машины можно в любой момент.

Сказано‑сделано. Берем на тест виртуальную машину с A4000 у HOSTKEY в России. Но вы можете взять у любого хостинг‑провайдера, который вам нравится.

Ставим туда связку Ollama + OpenWebUI. Почему такую и не просто Ollama? Неохота возиться с langchain и прочими штуками для RAG, так как OpenWebUI позволяет создавать как кастомные модели со своим системным промтом и параметрами на основе базовых, так и базы знаний из нескольких файлов. Плюс OpenWebUI позволяет закрыть доступ к машине к эндпоинтам API ключом прямо из коробки, то Ollama так до сих пор не умеет.

Переписываем наш JS скрипт, чтобы он обращался теперь к нашей связке. Если посмотреть в swagger документацию OpenWebUI, то там все достаточно понятно:

const response = await fetch("https://<домен с Ollama>/api/chat/completions", {
  method: "POST",
  headers: {
    "Authorization": "Bearer API",
    "accept": "application/json",
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "simplrobot",
    messages: chatHistory,
    stream: false,
  })
 });

Никакие CORS прокси нам тут не нужны, все работает сразу же. Как нет нужды в сертификатах минцифры, а для работы хватает домена третьего уровня на hostkey.in.

Модель мы создаем кастомную, предварительно поставив в Ollama LLM Qwen3-14B.

Предварительно я создал Базу знаний для модели и конвертировал из PDF в TXT правила игры.

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

Исправляем мелкие косяки, помещаем код на страницу игры в Тильда, размещаем и смотрим на результат:

Если держать модель постоянно в памяти не выгружая, то ответ в режиме размышления выдается в среднем за 15 секунд, но вы всегда можете добавить в системный промт /no_think и тогда модель будет отдавать вам ответ быстрее раза в два.

Что по токенам. Мы получаем примерно 1700 токенов на входе и 3700 на выходе. Размер ответа можно регулировать, у меня контекст установлен в 4K, чтобы модель не выдавала большие «портянки», но и не писала короткие отписки.

Одновременно Ollama обрабатывает также один запрос, но очередь может быть регулируема и составляет по дефолту 512 запросов. То есть даже такой небольшой сервер может выдержать большое число человек. Плюс есть внутреннее кэширование запросов и ответов, поэтому цена большой толпы на сайте, которым стал вдруг нужен ИИ‑помощник только увеличение времени на ответ.

В среднем за сутки сервер может перереварить более 17 000 000 токенов суммарно. Если брать месячную стоимость сервера, то для модели GigaChat Lite вы получите в сумму аренды сервера 50 000 000 токенов. Здесь считайте сами. Плюс удобная настройка самой модели, возможность подключения MCP серверов, легкое добавление и обновление файлов правил, методик и других материалов и возможность поэкспериментировать с моделями. Возможно для ваших нужд подойдет модель с меньшим числом параметров (та же Qwen3 8B), которая будет работать в 1.5-2 раза быстрее.

Минусом будет то, что платить вам придется постоянно и достаточно большую сумму в месяц, независимо пользуются у вас ботом или нет.

Какого то вывода не будет — решайте сами. Если уверены, что чат‑бот вам нужен на сайте эпизодично и не доверяете опен‑сурсу и хостерам, то используйте готовый сервис с API (не обязательно GigaChat, можете развернуть на ChatGPT или DeepSeek). Если же хотите получить полный контроль и иметь поле для экспериментов — то self hosted LLM ваш выбор.