В прошлом месяце я взялся за проект интеллектуальной службы поддержки, и заказчик потребовал одновременное подключение трёх больших моделей — DeepSeek, Tongyi Qianwen и Doubao — с обоснованием «у кого дешевле, у того и берём, а если у одного лимит исчерпан, переключаемся на другого». Звучит разумно, но на практике выяснилось: способы аутентификации, принципы биллинга и стратегии тайм-аутов и повторов у трёх SDK — это три совершенно разные логики. DeepSeek использует Bearer Token, Tongyi работает через API-KEY и подпись DashScope, а у Doubao поля аутентификации вообще другие. В биллинге одни считают входные и выходные токены раздельно, другие — суммарно, а третьи дают скидку за попадание в кэш. С тайм-аутами ещё хуже: у одного по умолчанию 30 секунд, у другого 60, а количество повторов и стратегию backoff приходится прописывать отдельно для каждого.
Когда код был дописан, я посчитал: только адаптерный слой для обёртки трёх клиентов занял больше 800 строк, не считая маппинга кодов ошибок. Именно поэтому понятие «модельный шлюз» с прошлого года постоянно всплывает в китайском AI-инженерном сообществе. Если сформулировать в одной фразе: модельный шлюз — это промежуточный слой, который скрывает различия между API разных больших моделей и предоставляет верхнеуровневому бизнесу единый интерфейс.
Прямое подключение, собственный шлюз, агрегационная платформа — инженерная цена трёх подходов
Начнём с прямого подключения официальных SDK. Три модели — это три набора аутентификации, три набора обработки ошибок, три набора логики повторов. В бизнес-коде сплошные if-else, определяющие, к кому идти. Добавляешь новую модель — переписываешь адаптерный слой. Мы прикинули: поддержка адаптерного кода для трёх прямых подключений занимает примерно 15% всей бэкенд-работы по проекту. А если моделей станет пять и больше, эта доля выйдет из-под контроля.
Собственный шлюз — второй вариант. Основная идея — написать свой слой прокси, который пересылает запросы к API разных провайдеров. Плюс в управляемости, минус в том, что придётся самостоятельно решать конвертацию протоколов, ротацию ключей, очереди с ограничением частоты и сбор статистики использования. Мы внутренне оценивали: чтобы собственный шлюз был пригоден для продакшена, нужно минимум два инженера на шесть-восемь недель, а дальше — постоянная поддержка изменений версий API у каждого провайдера. Для небольших и средних команд эта арифметика невыгодна.
Третий вариант — агрегационные платформы AI API. Такие платформы унифицируют API множества больших моделей и предоставляют наружу единый интерфейс. Инженерные затраты минимальны, срок подключения обычно измеряется днями. В нашем проекте мы использовали SiCore TokenWorks — он совместим с OpenAI SDK, достаточно поменять одну строку base_url для переключения. Здесь есть одна ловушка: у разных агрегационных платформ разные стратегии по умолчанию для тайм-аутов и повторов, поэтому перед подключением обязательно убедитесь, что платформа поддерживает настройку тайм-аута. Иначе редкие длительные ответы в продакшене будут обрываться на уровне платформы, причём по тексту ошибки не поймёшь, это тайм-аут шлюза или тайм-аут модели.
Четыре ключевые возможности модельного шлюза
Нормализация протоколов — это база. Форматы запросов, форматы ответов и коды ошибок разных провайдеров приводятся к одному стандарту. В идеале верхнеуровневый бизнес знает только один формат интерфейса, а переключение модели — это изменение конфигурации, а не кода. Именно поэтому интерфейс, совместимый с OpenAI, стал популярен в Китае: инструментальная экосистема в основном его поддерживает.
Стратегия маршрутизации — в этом и заключается ценность шлюза. Можно маршрутизировать по типу задачи: например, простые вопросы-ответы идут в Doubao, сложные рассуждения — в DeepSeek. Можно маршрутизировать по стоимости: куда сейчас дешевле, туда и идём. А можно по доступности: если у одного провайдера исчерпан лимит, автоматически переключаемся на резервного. Когда мы тестировали мультимодельную маршрутизацию SiCore TokenWorks, обнаружили, что стратегия распределения по сложности задачи в сценарии службы поддержки заметно снижает общую стоимость вызовов, потому что масса простых вопросов не требует модели с самыми сильными способностями к рассуждению.
Ограничение частоты с деградацией и агрегация использования — обязательные требования продакшена. Ограничение частоты должно распознавать ошибку 429 и автоматически ставить запрос в очередь на повтор. Деградация должна переключать на резервную модель, когда сервис одного провайдера недоступен. Агрегация использования — это сведение разрозненных по разным провайдерам объёмов вызовов, расхода токенов и затрат в единую картину для удобного учёта себестоимости и контроля бюджета. Если делать это самостоятельно, объём работы немаленький, особенно в части агрегации использования: у разных провайдеров разные принципы биллинга, и логику сверки придётся писать отдельно.
Поэтапное внедрение по зрелости бизнеса
Если проект только стартует и подключается всего одна модель, прямого подключения официального SDK достаточно, шлюз не нужен — лишний слой только добавит ещё одну точку отказа. А когда бизнес стабилизируется и понадобится вторая модель, тогда и стоит рассмотреть введение шлюзового слоя — на этом этапе стоимость переключения ещё низкая.
Если бизнес уже подключил три и более моделей и есть требования к доступности, рекомендую сразу идти на агрегационную платформу AI API, переложив затраты на адаптацию и эксплуатацию на внешнюю сторону. При выборе смотрите на три вещи: совместимость с OpenAI SDK, поддержку настройки тайм-аутов и повторов, прозрачность статистики использования. Что касается собственного шлюза — если только нет особых требований по комплаенсу или у команды нет достаточных ресурсов на эксплуатацию, вкладываться в него на ранней стадии бизнеса не рекомендуется.
Модельный шлюз решает проблему инженерной сложности подключения множества моделей, а не проблему их способностей. Правильно выбранное решение позволяет команде вернуть силы к самой бизнес-логике.