Модели и цены — документация Entity Enricher

Модели и цены

Управление провайдерами и моделями LLM, синхронизация моделей из внешних реестров, запуск проверок работоспособности и настройка API-ключей для каждой организации для независимой тарификации.

Управление провайдерами

Entity Enricher поддерживает широкий спектр провайдеров LLM. Каждый провайдер может иметь несколько моделей с индивидуальной ценой, возможностями и конфигурацией.

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

AnthropicOpenAIGoogleMistralDeepSeekGroqTogether AIFireworks AICoherexAINVIDIA NIMOllamaAzure OpenAI

Типы провайдеров

СтандартныйБольшинство провайдеров (Anthropic, OpenAI, Mistral и т. д.) используют стандартные API-эндпоинты с аутентификацией по bearer-токену. Стандартный провайдер также может указывать на пользовательский OpenAI-совместимый эндпоинт — см. «Пользовательские и корпоративные эндпоинты» ниже.
AzureAzure OpenAI использует пользовательские конечные точки развёртывания с настройкой версии API.
OllamaЛокально развёрнутые экземпляры Ollama с настраиваемыми URL-адресами эндпоинтов и автоматическим обнаружением моделей.

Пользовательские и корпоративные конечные точки

Многие команды направляют трафик LLM через корпоративный ИИ-шлюз, региональную конечную точку или провайдера, который не встроен, — например, корпоративный прокси LiteLLM, Cloudflare AI Gateway или Alibaba DashScope (для моделей Qwen). Вы добавляете их как отдельного провайдера Standard (OpenAI-compatible) с пользовательским базовым URL.

Добавление провайдера-шлюза

  1. Создайте провайдера с именем, которое не совпадает ни с одним из встроенных (например, acme-openai-gw). Встроенные имена, такие как openai или anthropic, зарезервированы.
  2. Выберите тип Standard (OpenAI-compatible) и заполните Пользовательский эндпоинт API (базовый URL) — например, https://gateway.example.com/v1. Это поле обязательно для любого провайдера, для которого в Entity Enricher нет встроенного клиента.
  3. Добавьте ключ шлюза как ключ организации для этого провайдера (API Keys → AI Provider Keys), чтобы оплата и ротация выполнялись на уровне организации.
  4. Добавьте модели, которые обслуживает шлюз. Идентификатор модели отправляется дословно, поэтому он должен точно совпадать с тем, что ожидает шлюз.

Полезно знать

  • Встроенные провайдеры скрывают поле endpoint. Anthropic, OpenAI, Mistral и другие распознанные провайдеры уже знают свой endpoint, поэтому настраивать нечего. Если пользовательский провайдер позже станет встроенным, его сохранённый endpoint останется видимым, чтобы вы могли его очистить.
  • Только публичный HTTPS. Конечные точки должны быть публичными URL-адресами https://. Loopback и частные диапазоны (localhost, 10.x, 192.168.x) отклоняются для предотвращения SSRF — сервер с собственным размещением должен быть доступен через интернет. Для локального Ollama используйте специальный туннель Ollama.
  • Формат обмена, совместимый с OpenAI. Запросы к пользовательскому провайдеру маршрутизируются через OpenAI-совместимый API, поэтому конечная точка должна поддерживать протокол OpenAI /v1 (chat completions, /models).
  • Проверка подключения обращается к {endpoint}/models, чтобы проверить ключ и базовый URL перед запуском обогащения.

Ограничения параллелизма (на ключ)

У каждого provider есть настройка Максимум одновременных вызовов на ключ (переопределение его лимита запросов). Она ограничивает, сколько вызовов LLM выполняет параллельно один ключ API — охватывая все процессы, использующие ключ: параллельное выполнение enrichment multi-expertise, classification, arbitration и генерацию schema / образцов.

  • Ограничение по ключу, а не по провайдеру. Каждый ключ организации и общий глобальный ключ получают собственный независимый бюджет, поэтому параллельные вызовы одного ключа никогда не вытесняют вызовы другого.
  • Возвращается к разумному значению по умолчанию, если не задано (значения по умолчанию для каждого провайдера, обычно 3–5 одновременных вызовов).
  • Вступает в силу со следующего задания — перезапуск не требуется.

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

Возможности модели

Каждая model отслеживает свои возможности, которые отображаются в виде значков в селекторе model:

ВозможностьОписание
ЗрениеМожет обрабатывать изображения и визуальные данные
Вызовы инструментовПоддерживает вызов функций / использование инструментов
АудиовходМожет обрабатывать аудиоданные
Ввод PDFМожет обрабатывать документы PDF
Кэширование промптовПоддерживает кэширование промптов для снижения затрат
РассуждениеВозможности расширенного мышления / цепочки рассуждений

Автоматическая синхронизация цен

Поддерживайте актуальность цен на модели, синхронизируя их из внешних реестров. Процесс синхронизации автоматически обнаруживает новые модели, изменения цен и удалённые модели.

Реестр LiteLLM

Источник цен по умолчанию. Загружает данные из поддерживаемого сообществом реестра LiteLLM на GitHub с реальными именами моделей API, ценами, длинами контекста и возможностями.

Охватывает ~30 провайдеров. Не включает отображаемые имена, бенчмарки и скорость генерации.

PricePerToken

Альтернативный источник с pricepertoken.com. Включает отображаемые имена, бенчмарки (оценки по программированию и математике) и скорость генерации (токенов в секунду).

Охватывает ~20 провайдеров. Предоставляет более подробные метаданные, чем LiteLLM.

Процесс синхронизации

  1. Предпросмотр (dry-run) — Посмотрите, что изменится, перед применением. Просмотр новых моделей, обновлений цен и деактиваций.
  2. Сопоставление в рамках источника — Каждый источник влияет только на модели из этого источника. Ручные модели никогда не затрагиваются.
  3. Стабильные ключи синхронизации — Модели сопоставляются по стабильному идентификатору, а не по имени. Вы можете переименовывать модели, не нарушая синхронизацию.
  4. Транзакционное применение — Все изменения применяются в рамках одной транзакции базы данных для обеспечения согласованности.
  5. Автосоздание провайдера — Если синхронизированная модель принадлежит неизвестному провайдеру, провайдер создаётся автоматически.

Проверки работоспособности модели

Заблаговременно проверяйте доступность моделей, запуская минимальный prompt проверки работоспособности. Это позволяет выявлять неработающие модели до того, как пользователи столкнутся с ошибками во время enrichment.

ПройденМодель успешно отвечает. Если ранее она была автоматически деактивирована, она снова активируется.
Не найденоМодель возвращает ошибку «не найдено». Она автоматически деактивируется, чтобы предотвратить будущие сбои.
Другая ошибкаОшибки аутентификации, тайм-ауты и превышения лимитов запросов регистрируются, но не приводят к деактивации.

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

Автодеактивация

Когда вызов обогащения завершается ошибкой «model not found», модель автоматически деактивируется, чтобы предотвратить повторные сбои. Это происходит в реальном времени во время обычных операций обогащения.

Причина деактивацииКем заданоАвтоматически реактивировано?
Модель не найденаОшибки обогащения или проверки работоспособностиДа (через синхронизацию цен или валидацию)
Удалено при синхронизацииСинхронизация тарифов (model исчезла)Да (если модель снова появляется в реестре)
ВручнуюПереключатель администратора в интерфейсеНет (только ручная повторная активация)

Используйте собственный ключ (BYOK)

Организации могут настроить собственные API-ключи LLM-провайдеров для независимого биллинга и учёта использования. Система использует двухуровневое разрешение ключей с выбором по принципу LRU:

1-й
Пул ключей организации

Ключи для каждой организации, настраиваемые на странице API-ключей. Поддерживает несколько ключей на провайдера с ротацией LRU. Зашифровано с помощью Fernet.

2-й
Пул глобальных ключей

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

Каждое enrichment фиксирует, какой ключ был использован, поэтому вы можете отслеживать затраты по каждому ключу. Ключи поддерживают проверку работоспособности, счётчики использования и автоматически отключаются при постоянных сбоях (недействительный ключ, требуется оплата). Ключи с превышением лимита запросов временно приостанавливаются, пока используются другие ключи из пула. Узнайте, как управлять ключами, в руководстве API Keys.

Импорт и экспорт

Экспортируйте всю конфигурацию провайдеров и моделей в формате JSON для резервного копирования или переноса на другой экземпляр. Импорт всегда выполняется как upsert: существующие провайдеры и модели сопоставляются по имени и обновляются на месте, а новые добавляются — ничего не удаляется.

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

Дальнейшие шаги