Минулого місяця я взявся за проєкт інтелектуальної служби підтримки, і бізнес-замовник вимагав одночасного підключення трьох великих моделей: DeepSeek, Qwen і Doubao. Аргумент був такий: «де дешевше — там і використовуємо, а якщо в одного ліміт — перемикаємося на іншого». Звучить розумно, але коли почали робити, виявилося: способи автентифікації, принципи білінгу та стратегії тайм-аутів і повторних спроб у трьох SDK — це три абсолютно різні логіки. DeepSeek використовує Bearer Token, Qwen працює через API-KEY DashScope з підписом, а поля автентифікації Doubao взагалі інші. У білінгу: десь вхідні та вихідні токени рахуються окремо, десь ціна об'єднується, а десь є знижка за влучання в кеш. З тайм-аутами ще гірше: в одного за замовчуванням 30 секунд, в іншого — 60, а кількість повторних спроб і стратегію відступу доводиться писати окремо для кожного.
Коли я закінчив писати код, то порахував: тільки адаптерний шар для трьох клієнтів зайняв понад 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, підтримку налаштування тайм-аутів і повторних спроб, чіткість статистики використання. Що ж до власного шлюзу — якщо немає особливих вимог до відповідності нормам або достатніх людських ресурсів для експлуатації, не радимо вкладатися в нього на ранньому етапі бізнесу.
Модельний шлюз вирішує проблему інженерної складності підключення багатьох моделей, а не проблему їхніх можливостей. Правильно обране рішення дає команді змогу повернути увагу до самої бізнес-логіки.