Запустите Onyx на кастомном OpenAI-совместимом LLM-провайдере.

Короткий ответ: Add Custom LLM Provider в панели администрирования.

Документация Onyx прямо говорит, что кастомный провайдер работает, пока он выставляет OpenAI-совместимые эндпоинты, и пример формы Base URL — это ровно шлюзоподобный https://yourprovider.com/v1. Поток такой: откройте Admin Panel через иконку профиля, перейдите в Configuration, затем Language Models, и выберите Add Custom LLM Provider. В этой форме важны четыре решения. Display Name — косметический. Provider Name должен совпадать с ключом провайдера LiteLLM, потому что Onyx маршрутизирует вызовы моделей через LiteLLM под капотом; для OpenAI-совместимого шлюза это openai. Base URL — это эндпоинт шлюза, включая суффикс /v1. А раздел Model Configurations — это то место, где вы регистрируете каждый id модели, который хотите видеть доступным, написанный ровно так, как его подаёт каталог. Сохраните, выберите умолчание — и чаты немедленно начнут маршрутизироваться через шлюз.

Admin Panel -> Configuration -> Language Models
  -> Add Custom LLM Provider

Display Name:   APIsRouter
Provider Name:  openai            (LiteLLM provider key)
Base URL:       https://api.apisrouter.com/v1
API Key:        sk-YOUR-APISROUTER-KEY
Model Configurations:
  claude-sonnet-4-6
  claude-haiku-4-5-20251001
  deepseek-v4-pro

Где LLM сидит в архитектуре Onyx.

Onyx (onyx-dot-app на GitHub, около 31K звёзд, ранее Danswer) — open-source AI-платформа для корпоративных знаний: она индексирует источники вроде Slack, Google Drive, Confluence и десятков других коннекторов, затем отвечает на вопросы по ним через чат-UI, ассистентов и агентские workflow. Это один из самых широко развёрнутых стеков self-hosted корпоративного поиска, и именно поэтому её счёт за LLM заслуживает решения о маршрутизации, а не умолчания. Пайплайн чисто разделяется на две части. Индексация и retrieval, включая эмбеддинг документов и rerank, работают на собственном сервере моделей Onyx с локальными моделями по умолчанию; ничто из этого не касается вашего LLM-провайдера. Генерация ответа — это другая половина: как только retrieval собирает релевантные пассажи, LLM их читает и пишет обоснованный ответ, и этот вызов идёт через LiteLLM к тому провайдеру, которого настроил админ. Поток кастомного провайдера меняет назначение ровно этой половины. Поскольку LiteLLM пересылает id модели как простую строку openai-типу провайдера, id, которые вы регистрируете в Model Configurations, могут быть чем угодно, что обслуживает эндпоинт за Base URL: Claude для тщательных обоснованных ответов, DeepSeek для объёма, Gemini для очень длинных контекстов источников. Разные ассистенты могут по умолчанию использовать разные модели, так что ассистент поддержки и инженерный ассистент могут ехать на разных ценовых точках через одну и ту же запись провайдера.

Полная настройка и то, что остаётся нетронутым.

Форма провайдера — это вся интеграция; для неё не нужно править конфиг-файл или пересобирать контейнер. После сохранения задайте модель по умолчанию для workspace и опционально переопределите модель по каждому ассистенту там, где вам нужны разные уровни качества. То, что осознанно остаётся нетронутым: коннекторы сохраняют собственные credentials, индекс не затрагивается, а модель эмбеддинга, настроенная для поиска, не двигается. Это разделение стоит проговорить, потому что оно делает это изменение низкорисковым. Если бы шлюз повёл себя неправильно, поиск и источники всё равно бы работали; ошибалась бы только генерация ответа, а переключение умолчания обратно на предыдущего провайдера — это один выпадающий список. Для команд, автоматизирующих деплои, то же определение провайдера можно засеять через API Onyx, а не прокликать через UI, но путь через панель администрирования — это задокументированная и стабильная поверхность, и одноразовая настройка редко оправдывает большее.

# confirm the gateway lists the ids you plan to register
curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

# confirm a chat completion works end to end
curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-6",
       "messages":[{"role":"user","content":"ping"}]}'

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

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

• Обоснованные ответы требовательны к входным данным: модель читает извлечённые пассажи, которые значительно превосходят по объёму написанный ответ. Поэтому цена за входной токен задаёт стоимость вопроса сильнее, чем цена вывода.
• claude-sonnet-4-6 — сильное умолчание для workspace: дисциплинированно остаётся внутри извлечённых источников и устойчиво к выдумыванию политики, которой нет в документах.
• Высоконагруженные ассистенты (IT-хелпдеск, HR FAQ) хорошо работают на claude-haiku-4-5-20251001 или deepseek-v4-pro, где объёмные цены держат стоимость на место предсказуемой.
• Длинные исходные документы благоволят id с длинным контекстом; gemini-3.1-pro-preview стоит протестировать для ассистентов, затягивающих в контекст большие дизайн-документы или договоры.
• Зарегистрируйте несколько id в одной записи провайдера и назначьте их по ассистентам. Уровни качества по командам превосходят одну глобальную компромиссную модель.

Оплата по факту · дешевле официальных цен

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Сбои, специфичные именно для Onyx.

Provider Name — это не свободнотекстовая метка. Он должен совпадать с ключом провайдера LiteLLM, и для шлюза этот ключ — openai. Придуманное имя даёт сбой во время запроса с ошибкой провайдера LiteLLM, даже если форма сохранилась нормально. Base URL хочет суффикс /v1. Собственная документация Onyx показывает формы эндпоинта, заканчивающиеся на /v1; без него путь chat-completions резолвится неверно, и запросы дают 404 на шлюзе. Id моделей живут в Model Configurations. Модель, которую вы там никогда не регистрировали, не может быть выбрана как умолчание, а опечатка в зарегистрированном id проявляется как ошибка model-not-found при первом использовании, а не в момент сохранения. Листинг /v1/models шлюза — авторитетное написание. Если в вашем UI администрирования отсутствует поле Base URL в форме custom-models, вы столкнулись с зарегистрированной регрессией UI в некоторых релизах 2026 года, а не с отсутствующей фичей; обновление восстанавливает поле. И помните, какую половину вы переместили: если результаты поиска выглядят неверными или устаревшими, это индексация и коннекторы, которые никогда не касаются кастомного провайдера. Через шлюз маршрутизируются только сгенерированные ответы.

Кто направляет Onyx через шлюз.

• Self-hosted команды, заменяющие аккаунты по каждому вендору одним эндпоинтом, одним ключом и использованием по ключу, которое чисто отображается на workspace или отдел.
• Предприятия, стандартизировавшие Onyx для внутреннего поиска, которым нужны обоснованные ответы качества Claude без отдельных биллинговых отношений с Anthropic.
• Платформенные команды, запускающие несколько ассистентов на разных уровнях качества, оцениваемых по ассистенту через зарегистрированные id моделей у одного провайдера.
• Оценщики, сравнивающие качество ответов между семействами моделей на идентичных корпусах, где каждый кандидат — это зарегистрированный id, а не новая интеграция провайдера.
• Разработчики без доступа к биллингу конкретного вендора. Доступ на основе пополнения без требования карты убирает зависимость от регистрации у каждого провайдера.

Проверьте эндпоинт и отладьте первый чат.

Две проверки curl выше покрывают половину со шлюзом, прежде чем вы тронете форму: id, которые вы планируете зарегистрировать, должны появиться в /v1/models, а прямой chat completion должен ответить. Внутри Onyx сбои локализуются быстро. Ошибка провайдера, называющая LiteLLM, означает, что Provider Name — невалидный ключ; установите его в openai. Ошибка аутентификации на первом чате означает, что API Key не принадлежит эндпоинту в Base URL. Ошибка model-not-found — это несовпадение id между Model Configurations и каталогом. Ответы, которые генерируются, но игнорируют ваши документы, — это проблема retrieval или коннектора, целиком выше по цепочке от LLM-провайдера. Как только чаты начинают работать, консоль APIsRouter показывает модель на запрос, счётчики токенов и расходы. Для инструмента workspace, где каждый вопрос несёт извлечённый контекст, это число токенов на вопрос — честная основа для планирования мощности, а один ключ на workspace превращает лог использования в отчёт о затратах на уровне отдела.

Частые вопросы