Облачные модели: OpenAI, Anthropic, Gemini и OpenRouter

В прошлом уроке мы разобрали подключение OpenAI-совместимого API на примере OpenRouter и проверку ответа в чате. Теперь разберёмся, как устроены прямые подключения к OpenAI, Anthropic и Google Gemini, чем они отличаются от работы через единый шлюз и что нужно поменять в настройках, если у вас есть ключ от одного из этих сервисов.

Сопоставим четыре маршрута, а для проверки выберем один доступный вам вариант. Можно оставить уже работающий OpenRouter: регистрировать четыре кабинета и настраивать все платформы подряд не нужно.

Выберем, кому отправить вопрос

В списке моделей разных сервисов легко встретить похожие названия от OpenAI, Anthropic или Google. Но само имя разработчика модели не говорит о том, на чей сервер уйдёт запрос и с какого счёта спишутся средства. В настройках подключения мы всегда выбираем и адресата (конкретный API-сервис и аккаунт), и формат обмена запросами и ответами (протокол).

Сравним две цепочки, по которым может пойти один и тот же учебный вопрос про список дел:

• Прямой API разработчика: Open WebUI → API выбранного разработчика (OpenAI, Anthropic или Gemini). Запрос уходит напрямую на платформу создателя модели, а доступ и оплата проверяются по правилам вашего аккаунта в этом сервисе.
• Шлюз-агрегатор: Open WebUI → OpenRouter → поставщик модели. Как указано в документации OpenRouter, шлюз принимает запрос по единому адресу, участвует в обработке сообщения и перенаправляет его поставщику модели. При этом используется ваш ключ и баланс OpenRouter, а не прямой ключ OpenAI или Anthropic.

Для обычного текстового чата все четыре маршрута в Open WebUI настраиваются через один и тот же раздел OpenAI-совместимых подключений. Согласно инструкции по подключению OpenAI, руководству по Anthropic и справочнику по совместимым провайдерам, совпадение формата запроса позволяет отправлять сообщения по общим правилам, даже если ключ выдал Google или Anthropic.

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

1. Нужные возможности API. Для обычного диалога предусмотрены все четыре маршрута, но доступ зависит от аккаунта и версии приложения. Специфические функции конкретной платформы на совместимом маршруте могут поддерживаться не полностью.
2. Допустимый путь данных. Решите, подходит ли для вашей задачи дополнительный посредник между вашим сервером Open WebUI и разработчиком модели.
3. Имеющийся аккаунт и ключ. Часто удобнее использовать тот сервис, где у вас уже открыт доступ к API и понятны лимиты.
4. Контроль расходов. Если удобнее вести единый баланс для разных семейств моделей, выбирают шлюз; если нужны прямые условия и квоты конкретного разработчика, подключают его API напрямую.

Сопоставим адрес, ключ и каталог модели

Для подключения нужны базовый URL сервиса, ключ его аккаунта и точный идентификатор модели (Model ID) из его каталога. Эти три значения должны относиться к одному сервису. Нельзя взять адрес от прямого API, а ключ или формат имени модели оставить от шлюза.

В таблице собраны параметры для четырёх маршрутов. Приведённые идентификаторы моделей взяты из официальных каталогов по состоянию на 16 октября 2026 года: они показывают, как записывается ID для каждого маршрута. Это примеры, без рекомендаций по качеству или цене и без гарантии доступа на вашем тарифе.

При смене провайдера сверим идентификатор, адрес и условия API:

• Синтаксис идентификаторов и актуальность каталогов. В шлюзе OpenRouter перед названием модели указывается префикс поставщика через слеш (например, openai/gpt-4.1-mini). При прямом подключении к OpenAI, Anthropic или Gemini такие префиксы (openai/, anthropic/, google/) добавлять не нужно: берутся чистые идентификаторы из каталога Claude или списка моделей Gemini. Сроки жизни моделей и доступ к прежним поколениям у прямого API и у шлюза различаются. Всегда сверяйте точный ID и доступность модели со своим аккаунтом в выбранном сервисе.
• Форма адреса Gemini без конечного слеша. В документации Google по совместимости с OpenAI SDK в примерах кода для клиентских библиотек базовый адрес записывается со слешем на конце (.../v1beta/openai/). Однако в инструкции Open WebUI для совместимых провайдеров указана форма без завершающего слеша: https://generativelanguage.googleapis.com/v1beta/openai, так как лишний слеш в поле интерфейса мешает корректной загрузке списка моделей. В поле Open WebUI используем вариант из его документации.
• Отдельный счёт и правила для API. Ключ и расчёт за токены всегда относятся к тому сервису, чей URL вы указали. В случае OpenAI подписка на веб-чат и доступ по API оплачиваются раздельно: как разъясняется в справке OpenAI по биллингу ChatGPT и API, подписка ChatGPT не переносит баланс на платформу API. Перед отправкой запросов проверьте актуальные условия тарификации, квоты и лимиты в личном кабинете того API, чей ключ вы используете.

Проверим, что означает совместимость

Если модель ответила в чате через прямое подключение, базовый обмен сообщениями работает. Для нашего проверочного вопроса про список дел этого достаточно. Совместимый маршрут (OpenAI-compatible) при этом может поддерживать не все возможности родного, или нативного, API разработчика.

У каждой платформы есть свои границы при работе через стандартный чат Open WebUI:

• OpenAI. Согласно руководству по подключению OpenAI в Open WebUI, обычный диалог в интерфейсе использует преимущественно формат Chat Completions. Наличие прямого ключа не означает, что обычный чат автоматически задействует все специфические функции более нового нативного интерфейса Responses API.
• Anthropic (Claude). В документации Open WebUI по Anthropic отмечено, что платформа поддерживается встроенными средствами без установки дополнительных плагинов. Встроенная интеграция приложения и родной протокол разработчика модели решают разные задачи: для обычного браузерного чата Open WebUI обращается к совместимому маршруту, а отдельный сквозной маршрут /api/v1/messages предназначен для внешних клиентов и не превращает стандартное окно чата в нативный Messages API. Как указано в документации Claude по совместимости с OpenAI SDK, на совместимом уровне игнорируются строгие схемы структурированного вывода (strict / response_format), не поддерживается кэширование промптов (prompt caching) и не возвращается полное содержимое блоков размышлений (thinking output).
• Google Gemini. Инструкция Google по совместимости разделяет совместимый формат и собственный интерфейс Gemini API, рекомендуя последний для приложений, которые не привязаны к библиотекам OpenAI. При этом документация Open WebUI по совместимым подключениям предупреждает о конкретном ограничении текущей интеграции: обычный обмен сообщениями с Gemini работает, но вызов инструментов (tool calling) и функции памяти (Memory) на этом маршруте могут завершаться ошибкой из-за особенностей передачи схем и подписей размышлений в потоковом режиме. Это ограничение совместимого маршрута в Open WebUI. У самой платформы Gemini инструменты есть. Поэтому в нашей проверке дополнительные инструменты и функции памяти должны быть выключены.

В старых руководствах или обсуждениях для подключения Claude и Gemini можно встретить совет установить расширение Pipe. Как описано в справочнике по функциям Pipe, Pipe представляет собой загружаемый администратором Python-код, который выполняется на сервере и позволяет написать собственный адаптер к API. Это отдельное серверное расширение со своими требованиями к обслуживанию, а не штатная вкладка настроек. Для обычного текстового чата по четырём маршрутам из нашей таблицы устанавливать Pipe не требуется.

Проверим и права ключа в аккаунте поставщика. Например, документация Claude по совместимости указывает, что для ключей с доступом сразу к нескольким рабочим пространствам (workspaces) API требует передавать дополнительный идентификатор рабочего пространства, а в справочнике OpenAI API доступ может зависеть от настроек организации и проекта. Обычное окно добавления подключения в Open WebUI рассчитано на стандартный ключ; если ваш корпоративный или мультипространственный ключ требует особых заголовков, сначала сверьтесь с настройками своего кабинета API.

Добавим один выбранный маршрут

Правила хранения ключей, общего серверного бюджета и чтения кодов ошибок мы разобрали в уроке «Подключаем OpenAI-совместимый API». Здесь изменим параметры для выбранного сервиса.

Настраиваем ваш текущий экземпляр Open WebUI. Он может быть запущен через docker run, Docker Compose на Windows, macOS или Linux либо через приложение Open WebUI Desktop. Если у вас уже настроен и работает OpenRouter, а других ключей нет, вы можете оставить существующее подключение без изменений и сразу перейти к проверочному разделу. Если же вы хотите подключить прямой ключ от OpenAI, Anthropic или Gemini, добавьте его как отдельное соединение, не стирая рабочий OpenRouter: так вам будет проще различать маршруты.

1. Войдите с правами администратора и откройте Settings → Admin → Connections (Настройки → Панель администратора → Подключения).
2. В знакомом блоке Manage OpenAI API Connections нажмите Add Connection (Добавить подключение). Отдельных вкладок под бренды Anthropic или Gemini искать не нужно: все четыре варианта для обычного чата добавляются в этом разделе (точные подписи могут немного отличаться в зависимости от версии и перевода интерфейса).
3. Заполните три поля значениями для одного сервиса из таблицы:
   • В поле URL вставьте базовый адрес выбранного маршрута (для Gemini проверьте отсутствие слеша на конце: https://generativelanguage.googleapis.com/v1beta/openai).
   • В поле API Key вставьте ключ, выпущенный в кабинете этого же сервиса. При прямом подключении к OpenAI, если в форме отображается поле Provider, оставьте значение Default.
   • В поле Model IDs укажите один точный идентификатор модели, который доступен вашему аккаунту в каталоге выбранного провайдера, и подтвердите его добавление в список.
4. Нажмите Verify Connection для проверки отклика списка моделей, а затем сохраните подключение кнопкой Save. Помните, что добавленный вручную идентификатор модели лишь фильтрует список в интерфейсе и сам по себе не открывает доступ на стороне провайдера.

Если в разных соединениях совпадают ID моделей, новому соединению можно задать отдельный Prefix ID в дополнительных настройках и сохранить его. Документация Open WebUI описывает это поле как способ различать одинаковые модели: приложение добавляет префикс перед ID через точку, а перед отправкой провайдеру убирает его. В поле Model IDs остаётся исходный ID из каталога. Префикс direct вводим без слеша. Существующее рабочее подключение OpenRouter менять не требуется.

Проверим выбранное подключение

Убедимся, что запрос уходит именно по выбранному маршруту и возвращает обычный текстовый ответ:

1. Откройте новый чат (New Chat) для обычного текстового вопроса, без дополнительных инструментов (Tools) и встроенной памяти (Memory). Где отключаются эти функции, зависит от версии Open WebUI и настроек модели.
2. В верхнем селекторе моделей выберите запись нужного подключения. Если вы задали ему Prefix ID, выберите имя с этим префиксом. Например, префикс direct и ID gpt-6-luna дадут запись direct.gpt-6-luna. Само совпадение названия модели в разных соединениях ещё не определяет маршрут.
3. Отправьте тот же короткий проверочный вопрос без личных или секретных данных:

Ответь одним коротким предложением: для чего нужен список дел?

Дождитесь, пока модель допишет ответ в чате. Формулировка может быть любой по стилю, главное, чтобы вернулось законченное осмысленное предложение без сообщения об ошибке. Если у выбранного вами сервиса в личном кабинете есть журнал использования (Usage или Activity), загляните туда: новая запись подтвердит, что запрос прошёл именно через этот аккаунт и его лимиты.

Полный ответ подтверждает, что базовый URL, ваш ключ и выбранный ID модели работают вместе для обычного текстового чата. При этом такой тест не подтверждает работу инструментов (tools), памяти (Memory), специфических функций нативных API (Responses, Messages или generateContent) и доступность других моделей из каталога.

Если вместо ответа появилась ошибка соединения, авторизации или лимитов, не отправляйте платный запрос повторно несколько раз подряд. Проверьте, что URL, ключ и ID модели взяты из одной строки таблицы и соответствуют вашему аккаунту, а для расшифровки кодов 401, 402, 403, 404 и 429 воспользуйтесь таблицей диагностики из предыдущего урока про OpenAI-совместимый API. Если же ошибка возникла при попытке включить специфическую функцию провайдера, проверьте ограничения совместимого маршрута в документации соответствующей интеграции.

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