AI Gateway 2026: Switchyard, LiteLLM или Portkey

14 августа 2026 года: быстрый вывод по выбору

В официальной документации Switchyard описаны преобразование между форматами OpenAI и Anthropic, маршрутизация запросов между провайдерами, статистика использования и сценарии для Claude Code и других кодинговых агентов. LiteLLM позиционируется как единый интерфейс для большого числа моделей с прокси, виртуальными ключами, учётом расходов и логикой повторных попыток. Portkey делает акцент на управляемом шлюзе, наблюдаемости, резервных маршрутах, политиках доступа и корпоративных рабочих процессах. (официальный репозиторий Switchyard, документация LiteLLM, документация Portkey AI Gateway)

Практический вывод: для локального прокси кодингового агента и маршрутизации по этапам сначала стоит оценивать Switchyard; для широкой совместимости с поставщиками и зрелого прокси — LiteLLM; для команды, которой важны управляемая панель, аудит, наблюдаемость и процессы governance, — Portkey. Это не рейтинг по абстрактной «мощности», а распределение продуктов по разным эксплуатационным задачам.

Последнее обновление: 14 августа 2026 года. Функции сверены по официальным репозиториям, документации, установочным материалам, лицензиям и журналам публикаций. Открытая версия, облачный сервис и корпоративные возможности рассмотрены раздельно.

Эта статья предназначена:

• командам, которым нужен единый API для нескольких моделей;
• платформенным инженерам, управляющим ключами, откатами и журналами использования;
• разработчикам, которые хотят настроить маршрутизацию моделей для Claude Code и других AI-агентов;
• техническим руководителям, принимающим решение между самохостингом и управляемым сервисом.

Если задача ограничивается одним приложением и одним провайдером, полноценный AI Gateway может добавить лишний слой конфигурации. Но при появлении нескольких ключей, резервного поставщика, локальной модели или требований к аудиту прямые вызовы быстро становятся труднее сопровождать.

Сначала определите метрики, а не название продукта

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

У команды обычно возникают как минимум пять ограничений.

1. Разные протоколы клиентов. Кодинговый агент может ожидать формат Anthropic Messages, приложение — OpenAI-совместимый интерфейс, а локальный сервер — собственный набор полей. Простая прокладка, которая отвечает на базовый текстовый запрос, не гарантирует совместимость с tool calling, streaming и structured output.

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

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

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

5. Скрытые расходы самохостинга. В стоимость входит не только запуск контейнера. Нужно учитывать хранение конфигурации, секретов, журналов, резервных копий, обновления, откат версии и проверку того, что новая версия не изменила преобразование запроса.

Важно: наличие OpenAI-совместимого endpoint не означает полной совместимости с каждым клиентом. Перед миграцией следует отдельно проверить потоковую передачу, вызов инструментов, JSON-схемы, обработку ошибок и нестандартные поля провайдера.

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

Switchyard выделяется не универсальным каталогом моделей, а задачей адаптации трафика между клиентом и backend. В официальном репозитории описаны преобразования между OpenAI Chat, Anthropic Messages и OpenAI Responses, а также запуск Claude Code через прокси с выбором модели и базового URL. Это делает его особенно интересным для команды, которая хочет оставить привычный клиентский протокол, но направить запрос к другому endpoint. (официальный репозиторий Switchyard)

LiteLLM предлагает два основных пути: Python SDK внутри приложения и Proxy Server как централизованный шлюз. Документация описывает преобразование запросов к различным endpoint, единый формат ответа, streaming, обработку ошибок и подключение наблюдаемости через callbacks. Такой подход удобен, если шлюз должен обслуживать не только агента, но и несколько обычных приложений. (руководство LiteLLM Proxy Server)

Portkey также предоставляет универсальный API и интеграцию с официальными SDK, а в описании шлюза отдельно указаны текстовые, мультимодальные, аудио- и embedding-сценарии. Для выбора в пользу Portkey важно проверить не только сам gateway, но и границу между локально развёрнутым компонентом и управляемой частью платформы. (возможности Portkey AI Gateway)

Перед выбором стоит пройти такой тест:

• отправить обычный текстовый запрос;
• включить streaming и проверить завершение потока;
• вызвать инструмент с обязательными аргументами;
• запросить структурированный JSON-ответ;
• передать системные инструкции и метаданные;
• проверить, что ошибка провайдера возвращается в ожидаемом формате;
• сравнить поведение при пустом, частично заполненном и неожиданном поле.

Switchyard и LiteLLM: что лучше для Claude Code? Если основная цель — быстро поставить локальный прокси между Claude Code и несколькими совместимыми backend, Switchyard выглядит более естественным кандидатом: его документация прямо описывает такой запуск и преобразование протоколов. Если же Claude Code — только один из клиентов, а рядом уже есть API-приложения, внутренние сервисы и несколько команд, LiteLLM обычно лучше подходит как общий прокси-слой. Окончательное решение следует принимать после проверки инструментов и потоковых ответов на реальном рабочем сценарии, а не по названию поддерживаемого API.

Сопоставьте модели, частные endpoint и локальное выполнение

У Switchyard сильная сторона — соединение клиента с конкретными целями, включая OpenAI-совместимые endpoint, vLLM, NVIDIA NIM и Ollama, перечисленные в официальном описании проекта. Там же указаны сценарии, в которых один и тот же агент может обращаться к разным моделям, использовать A/B-сравнение или передавать запросы через профиль маршрутизации.

LiteLLM ориентирован на широкий слой адаптеров. В официальном руководстве перечислены облачные и локальные варианты подключения, а Proxy Server позволяет описывать model deployment в конфигурации. Однако динамический список интеграций следует проверять непосредственно в документации текущей версии: наличие community-адаптера не равно обещанию долгосрочной поддержки основной командой. (официальное руководство LiteLLM)

Portkey предлагает единый интерфейс для большого числа моделей и также допускает подключение собственных или частных endpoint. При этом часть возможностей может относиться к управляемой платформе, self-hosted gateway или корпоративной архитектуре, поэтому нельзя переносить утверждение о функции из одного уровня поставки на другой. В материалах Portkey отдельно описаны варианты гибридного развёртывания. (архитектура гибридного развёртывания Portkey)

При проверке покрытия команда должна фиксировать не только название модели, но и следующие свойства:

• поддерживаемый протокол входа;
• способ передачи ключа;
• наличие streaming;
• поддержка инструментов;
• формат structured output;
• ограничения на контекст и параметры;
• совместимость с локальным endpoint;
• поведение при временной недоступности цели;
• возможность записать выбранный backend в журнал.

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

Настройте маршрутизацию, откат и проверку качества

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

LiteLLM документирует router с повторными попытками и fallback между deployment. В конфигурации можно описывать группы моделей, резервные направления и параметры повторного обращения. Для распределённых инсталляций необходимо также учитывать внешнее состояние, если несколько экземпляров должны согласованно выполнять балансировку. (конфигурация LiteLLM Router)

Portkey описывает fallback, automatic retries, load balancing, conditional routing, тайм-ауты и circuit breaker. В gateway-конфигурациях можно задавать цели, веса и условия выбора. Это сильная сторона для платформы, где маршрутизация является не только техническим переключателем, но и частью управляемого процесса.

Switchyard делает акцент на явных профилях и маршрутах, а также на классификаторе и маршрутизации по этапам. В документации указаны параметры weak model, classifier model, profile и минимального уровня уверенности. Это удобно для кодингового агента, где короткий запрос, анализ репозитория и сложная модификация кода могут требовать разных целей. Но интеллектуальный роутер нельзя считать автоматически более качественным: ему нужна проверка на реальных задачах и измерение ошибок классификации.

Как AI Gateway реализует откат и маршрутизацию? Надёжная схема выглядит так:

1. Сначала определяется класс запроса: обычный текст, tool calling, structured output, кодовая задача или длинный контекст.
2. Для каждого класса задаётся список совместимых моделей, а не просто список доступных моделей.
3. Ошибки аутентификации, лимита, тайм-аута и недопустимого формата разделяются.
4. Повтор выполняется только для временных ошибок; повторять невалидный запрос без изменения параметров обычно бессмысленно.
5. После отката сохраняется причина переключения и итоговый backend.
6. Результат резервной модели проверяется по схеме, тестам или признакам успешного завершения задачи.

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

Разделите ключи, бюджет и наблюдаемость

LiteLLM прямо указывает на виртуальные ключи, аутентификацию, авторизацию, отслеживание расходов по проектам, лимиты и административную панель Proxy Server. Для платформенной команды это важнее, чем просто единый endpoint: можно выдавать доступ приложениям и командам без передачи исходных ключей каждого провайдера.

Portkey также описывает бюджетные и скоростные лимиты, виртуальные ключи, журналирование и governance-функции. Однако нужно проверить, относится ли нужная возможность к открытому gateway, облачному уровню или корпоративному предложению. Эти уровни не следует смешивать в одной строке сравнения.

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

Минимальный набор журналов для производственной эксплуатации:

• идентификатор запроса без записи секретов;
• команда, проект или виртуальный ключ;
• выбранная модель и фактический backend;
• причина выбора маршрута;
• тип и код ошибки;
• входные и выходные токены, если это разрешено политикой данных;
• задержка до первого фрагмента и полное время ответа;
• факт повтора или fallback;
• результат проверки схемы;
• срок хранения и правило удаления.

LiteLLM и Portkey: в чём разница? LiteLLM чаще выбирают как открытый SDK и прокси, который команда устанавливает и настраивает самостоятельно, особенно когда требуется широкий слой адаптеров и собственная логика платформы. Portkey ближе к управляемой производственной платформе, где gateway сочетается с наблюдаемостью, guardrails, настройками маршрутов и административными рабочими процессами. Разница не сводится к числу моделей: она проходит по границе ответственности за эксплуатацию, хранение журналов и управление политиками.

Опытный подход: сначала определить, какие данные можно журналировать. Если запросы содержат исходный код, персональные данные или внутренние документы, красивый dashboard не компенсирует отсутствие маскирования, ограничений доступа и понятного срока хранения.

Проведите самохостинг через управляемую процедуру

Самохостинг стоит оценивать не по языку реализации, а по операционному циклу.

Шаг 1. Зафиксируйте реальный клиентский контракт

Сохраните примеры запросов от Claude Code, внутреннего API-клиента и тестового скрипта. Для каждого примера отметьте заголовки, streaming, инструменты, системные сообщения, структурированный ответ и нестандартные поля.

Шаг 2. Соберите матрицу backend

Для каждой цели укажите протокол, способ авторизации, поддерживаемые возможности и допустимые классы ошибок. Если capability неизвестна, она должна быть обозначена как «не проверено», а не как поддерживаемая.

Шаг 3. Начните с явного маршрута

Для первого запуска используйте фиксированное соответствие «класс запроса — модель». В Switchyard это может быть профиль или явная цель; в LiteLLM — модельный deployment и router-конфигурация; в Portkey — gateway config. Интеллектуальную маршрутизацию следует включать после появления тестового набора.

Шаг 4. Добавьте безопасный fallback

Резервная цель должна быть совместима с конкретной операцией. Для tool calling нужен backend, который сохраняет инструменты и их аргументы; для structured output — backend, который возвращает проверяемый формат. Недостаточно указать «любую доступную модель».

Шаг 5. Настройте секреты и права

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

Шаг 6. Включите минимальное журналирование

Сначала записывайте маршрут, код ошибки, длительность, факт отката и идентификатор запроса. Полные prompt и response добавляйте только после оценки приватности, маскирования и срока хранения. Политика обработки данных должна быть согласована с внутренними правилами; при необходимости полезно заранее изучить политику конфиденциальности nuvcloud.

Шаг 7. Проведите отказоустойчивую приёмку

Искусственно проверьте отказ ключа, превышение лимита, тайм-аут, недоступный endpoint, повреждённую JSON-схему и ошибку инструмента. Для каждого теста должно быть понятно: выполнен ли повтор, произошёл ли fallback, какой статус получил клиент и появилась ли причина в журнале.

Шаг 8. Подготовьте откат конфигурации

Маршруты, лимиты и правила fallback должны храниться как версионируемая конфигурация. Перед обновлением зафиксируйте рабочий вариант, набор smoke-тестов и условие возврата на предыдущую версию.

Используйте сравнительную матрицу перед переводом трафика

Ниже приведена не оценка «от одного до десяти», а карта соответствия типовым задачам. Она отражает заявленные направления продуктов и не заменяет тестирование конкретной версии.

Критерий выбора	Switchyard	LiteLLM	Portkey
Главный сценарий	Прокси для AI-агентов, преобразование протоколов и маршрутизация по профилям	Универсальный SDK и Proxy Server для множества моделей и приложений	Gateway с управляемой маршрутизацией, наблюдаемостью и governance
Claude Code	Сильный кандидат для локального прокси и смены backend	Подходит, если Claude Code является частью общей платформы	Подходит при необходимости централизованных политик и контроля
API и преобразование	OpenAI Chat, Anthropic Messages и OpenAI Responses заявлены в репозитории	Единый интерфейс и преобразование к нескольким endpoint	Универсальный API и интеграции с SDK
Fallback и retries	Явные маршруты, профили и стадийная логика	Router, повторы и fallback между deployment	Fallback, retries, conditional routing, load balancing и circuit breaker
Локальные backend	Подходит для OpenAI-совместимых endpoint, vLLM, NVIDIA NIM и Ollama	Поддерживает локальные и облачные варианты через конфигурацию	Допускает self-hosted и частные endpoint, но границу managed/self-hosted нужно проверить
Ключи и бюджеты	Требует отдельной проверки нужного уровня управления	Виртуальные ключи, проекты, бюджеты и лимиты заявлены для Proxy Server	Виртуальные ключи, лимиты и governance зависят от уровня поставки
Наблюдаемость	Статистика и маршрутная информация в рамках проекта	Логи, расходы, задержки и callbacks	Наблюдаемость и трассировка являются центральной частью платформы
Самохостинг	Удобен для команды, готовой управлять локальным прокси	Подходит для платформенной инфраструктуры с конфигурацией и операционным контуром	Возможен, но необходимо разделять открытый gateway, managed service и enterprise-функции
Кому выбирать	Индивидуальный разработчик или команда AI-кодинга	Растущее AI-приложение и внутренняя модельная платформа	Предприятие, которому важны аудит, контроль и управляемый процесс

Для личного кодингового агента разумно начать со Switchyard, если требуется локальная маршрутизация и минимальный промежуточный слой. Для быстро растущего приложения LiteLLM обычно рациональнее, когда уже есть несколько моделей, проектов и потребность в едином прокси. Для корпоративной платформы Portkey стоит рассматривать при условии, что команда заранее проверила размещение журналов, права доступа, экспорт данных и разделение функций между self-hosted и облачной частью.

Примите решение после теста, а не до него

Какой AI Gateway лучше подходит команде разработчиков? Для небольшой команды, которая хочет подключить несколько моделей к одному агенту, важнее простота маршрута, сохранность инструментов и понятный откат. Для платформенной команды важнее виртуальные ключи, проектные бюджеты, централизованный аудит и повторяемая конфигурация. Поэтому один и тот же продукт может быть хорошим выбором для прототипа и неудобным для организации с несколькими владельцами сервисов.

Какой self-hosted AI Gateway выбрать? Switchyard стоит проверять первым для локального агентного сценария и профильной маршрутизации. LiteLLM — для более широкого набора провайдеров, SDK и централизованного прокси. Portkey — для команды, которой нужна управляемая gateway-платформа, но перед решением необходимо подтвердить, какие функции доступны именно в самостоятельно размещаемой версии.

Перед сменой production-трафика следует поставить галочки напротив всех пунктов:

• [ ] базовый запрос и streaming проходят через каждый выбранный backend;
• [ ] tool calling сохраняет имена инструментов и аргументы;
• [ ] structured output проходит проверку схемой;
• [ ] ошибка лимита не вызывает бесконечный цикл повторов;
• [ ] fallback не отправляет несовместимый запрос к резервной модели;
• [ ] в журнале видны выбранный маршрут и причина переключения;
• [ ] ключи не возвращаются клиенту и не попадают в открытые логи;
• [ ] срок хранения журналов согласован с требованиями приватности;
• [ ] конфигурация маршрутов версионируется;
• [ ] команда знает условие отката на предыдущую версию.

Если текущая схема построена на прямых вызовах из каждого приложения, у неё обычно проявляются три недостатка: секреты распределены по сервисам, fallback реализован неодинаково, а причины выбора модели трудно восстановить после инцидента. Временный облачный обход этих проблем может ускорить старт, но не всегда даёт нужный контроль над данными и конфигурацией. Поэтому для подготовки собственного шлюза стоит заранее оценить изолированную среду, срок аренды инфраструктуры, способ передачи учётных данных и процедуру аварийной приёмки. Для этого можно изучить условия nuvcloud, проверить доступ к панели управления nuvcloud и сопоставить расходы с реальной длительностью тестового цикла.

Аренда Mac-среды через nuvcloud может быть удобнее, когда команде нужен временный изолированный стенд для проверки gateway, Claude Code, локального клиента или сценария отказа без немедленной покупки отдельного оборудования. При длительной стабильной нагрузке, необходимости физического доступа к устройствам или постоянной эксплуатации собственного inference-узла самопокупка может оказаться рациональнее. Но для сравнительного теста, миграции и контролируемой проверки перед продакшеном временная среда снижает риск привязать решение к неподтверждённой конфигурации.