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

Поддерживаемые LLM-провайдеры

Glarus AI — модельно-агностичная платформа. Заказчик сам выбирает LLM под свои требования: юрисдикция данных, бюджет, качество ответов, наличие GPU в контуре. Поддерживаемые провайдеры регистрируются централизованно при установке системы, переключение между моделями для пользователя происходит в один клик в окне чата.

Рекомендуемые для российского контура классы провайдеров:

  1. Российские облачные LLM (MWS GPT) — данные физически остаются в РФ, соответствие 152-ФЗ обеспечивается провайдером, VPN не требуется.
  2. Локально развёрнутые LLM (Ollama и совместимые OpenAI-совместимые серверы on-prem) — данные не покидают периметр заказчика. Максимальный уровень изоляции.

Иностранные облачные LLM (Claude, OpenAI, Gemini) технически поддерживаются — их можно подключить через российские прокси-сервисы с OpenAI-совместимым API. Для сценариев с персональными данными этот путь не рекомендуется — см. соответствие требованиям РФ.

Единственное техническое требование к любому провайдеру — наличие API-ключа и совместимость с OpenAI- или Anthropic-подобным HTTP-протоколом.

Сравнительная таблица

Провайдер Класс Юрисдикция данных VPN из РФ 152-ФЗ без доп. мер Реестр ПО Tool calls / MCP Пример моделей
MWS GPT российский РФ (УЗ-1) не требуется да да да 70+ моделей — DeepSeek, Qwen, Llama, GigaChat, Cotype и др.
Локальная модель (Ollama) on-premise периметр заказчика не требуется да n/a да (через OpenAI-совместимый API) Llama 3.3, Qwen 2.5, DeepSeek-R1, T-Pro и др.
Иностранные облачные через российский прокси внешний США / ЕС не требуется (выходит прокси) нет — нужен DPA, согласие субъекта ПД нет да Claude, GPT-4o, Gemini

Подключение

Доступные провайдеры и модели регистрируются администратором установки или инженером поддержки Glarus. Заказчик указывает нужного провайдера, модели и объём использования. После регистрации модели появляются в селекторе чата и в настройках агентов; при включённом BYOK пользователь вводит свой ключ самостоятельно.

Для подключения провайдера Glarus требуется стандартный набор параметров:

  • Base URL эндпойнта провайдера;
  • API-ключ (или Authorization Key, IAM-токен — зависит от провайдера);
  • дополнительно для локальных моделей — сетевой доступ из контура Glarus AI до хоста LLM.

MWS GPT

  1. Заказчик регистрируется на mws.ru/services/mws-gpt/, создаёт проект, получает API-ключ в личном кабинете.
  2. В заявке на подключение передаёт инженеру поддержки Glarus: Base URL (https://api.gpt.mws.ru/v1, уточняется в личном кабинете MWS), API-ключ, список нужных моделей из каталога MWS GPT (включает более 70 LLM — DeepSeek, Qwen, Llama, GigaChat, Cotype и др.).
  3. После регистрации провайдер и выбранные модели становятся доступны в селекторе моделей чата Glarus AI.
  4. Проверка подключения — задать любой тестовый вопрос выбранной модели в чате Glarus AI; если агент отвечает, модель подключена.

Локальная модель (Ollama)

Самый безопасный по данным сценарий — LLM работает прямо на сервере заказчика.

  1. На машине в контуре заказчика устанавливается Ollama и скачивается нужная модель. Пример: ollama pull qwen2.5:32b-instruct (или llama3.3:70b, или deepseek-r1:70b — подбирается под GPU).
  2. Ollama по умолчанию слушает http://localhost:11434, OpenAI-совместимый эндпойнт — http://localhost:11434/v1.
  3. В заявке на подключение заказчик указывает инженеру поддержки Glarus: сетевой адрес Ollama (или другого совместимого сервера) внутри своего контура.
  4. После регистрации модели становятся доступны в селекторе моделей чата. Проверка — тестовый вопрос в чате Glarus AI.

Иностранные облачные LLM через российский прокси

Для полноты: если заказчик принял риски трансграничной передачи ПД и имеет DPA с провайдером, Claude / OpenAI / Gemini подключаются через OpenAI-совместимый эндпойнт российского прокси-сервиса (например, https://api.proxyapi.ru/openai/v1 — подробности в документации провайдера прокси). Юридические последствия и рекомендация по отказу от этого пути — в "Соответствие требованиям РФ: 152-ФЗ, DPA".

Собственные API-ключи пользователей (BYOK)

BYOK (Bring Your Own Key) позволяет каждому пользователю подключить собственные учётные данные LLM-провайдера. Доступные провайдеры и модели настраиваются администратором установки; для личного ключа у подключения задаётся apiKey: user_provided. Регистрация провайдера и ввод персонального ключа — разные действия.

  1. Выберите настроенного провайдера в чате и откройте «Указать ключ к API».
  2. Введите свои учётные данные. Поддерживаются OpenAI, Anthropic, Google, Azure OpenAI, AWS Bedrock и настроенные OpenAI-совместимые подключения. Набор полей зависит от подключения: API-ключ; параметры Azure; ключ Google или JSON Service Account; учётные данные Bedrock либо Bearer token. Дополнительный Base URL вводится пользователем только если это разрешено настройкой подключения.
  3. Выберите срок хранения: 30 минут, 2 или 12 часов, 1, 7 или 30 дней либо бессрочно (never); исходный выбор — 12 часов. Сохраните ключ. После истечения срока понадобится новый ключ.
  4. Для удаления сохранённого ключа откройте диалог и нажмите «Отозвать», затем подтвердите действие. Это удаляет ключ из установки Glarus AI; для отзыва самого секрета у провайдера используйте кабинет провайдера.

Ключ хранится в MongoDB установки в зашифрованном виде. Текущий механизм пользовательских ключей использует AES-CBC: при CREDS_KEY длиной 32 байта (64 шестнадцатеричных символа) это AES-256-CBC; требуется также настроенный CREDS_IV. Эти параметры настраиваются администратором и хранятся отдельно от пользовательских ключей.

API чтения пользовательского ключа возвращает только expiresAt — срок, признак бессрочного хранения или отсутствие ключа. Значение сохранённого ключа в интерфейс не возвращается. При первоначальном вводе используется обычное текстовое поле: символы не заменяются звёздочками. Шифрование при хранении и отсутствие повторного показа не означают скрытый ввод.

Журнал расхода при BYOK

При включённом transactions.enabled (по умолчанию true) журнал transactions в MongoDB содержит пользователя user, модель model, время createdAt, тип токенов tokenType, количество rawAmount, расчётное значение tokenValue и идентификатор диалога conversationId, когда он передан. Расход входных и выходных токенов может записываться отдельно; одна запись не равна одному вопросу. Значения расхода имеют отрицательный знак, пополнения — отдельный тип credits.

Администратор с правом чтения MongoDB может посмотреть последние записи в mongosh. Пример только читает данные, не извлекает API-ключи и не является встроенным экраном аудита:

db.transactions.find(
  { tokenType: { $in: ["prompt", "completion"] } },
  { _id: 0, user: 1, model: 1, createdAt: 1,
    conversationId: 1, tokenType: 1,
    rawAmount: 1, tokenValue: 1 }
).sort({ createdAt: -1 }).limit(50)

Права чтения журнала и правила работы с данными пользователей определяет администратор. О значении расчётного расхода см. «Стоимость использования и лимиты»; пример месячного отчёта — в разделе «Учёт обращений и расхода токенов».

Стоимость использования и лимиты

Эксплуатационные затраты складываются из лицензий Glarus BI и Glarus AI, использования выбранной языковой модели, хостинга и поддержки. В режиме собственных ключей заказчик оплачивает LLM напрямую провайдеру по его тарифу, без наценки Glarus AI на токены. Лицензии, инфраструктура и поддержка согласуются отдельно. Для локальной модели учитываются вычислительные ресурсы её размещения.

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

Настройка баланса и автопополнения

Персональный баланс настраивается администратором. По умолчанию balance.enabled: false и autoRefillEnabled: false: наличие функции не означает, что она включена в конкретной установке. Пример настройки внутренних расчётных единиц, а не денежного платежа:

balance:
  enabled: true
  startBalance: 20000
  autoRefillEnabled: true
  refillIntervalValue: 30
  refillIntervalUnit: days
  refillAmount: 10000
transactions:
  enabled: true

startBalance задаёт начальный баланс, refillAmount — размер пополнения, а refillIntervalValue и refillIntervalUnit — минимальный интервал между пополнениями. Автопополнение проверяется при запросе: если его расчётная стоимость исчерпывает баланс и интервал уже прошёл, добавляются единицы. Это не фоновое начисление строго по календарю и не пополнение счёта у LLM-провайдера.

При включённой функции пользователь видит остаток и параметры автопополнения в настройках «Баланс». Если доступного остатка недостаточно и пополнение не помогло, запрос отклоняется с сообщением о недостаточном балансе. Баланс ограничивает внутреннее использование по расчётной стоимости, но не заменяет денежные лимиты и учёт у провайдера.

Частота сообщений ограничивается отдельно. Администратор включает LIMIT_MESSAGE_USER и/или LIMIT_MESSAGE_IP и задаёт MESSAGE_USER_MAX, MESSAGE_USER_WINDOW, MESSAGE_IP_MAX, MESSAGE_IP_WINDOW. Окно задаётся в минутах; исходные значения каждого включённого лимитера — 40 сообщений за 1 минуту. Это предел частоты запросов, а не денежный бюджет.

Сводного дашборда затрат и готовых алертов расходов в поставке нет. Администратор может анализировать журнал MongoDB; техническую нагрузку наблюдать через «Мониторинг Glarus AI (Prometheus)». Тарифы провайдера, объём контекста, длина ответа и число вызовов модели влияют на фактические затраты.


Дополнительная информация