Сначала вывод: модельный шлюз — это не просто «подключить несколько API». Это слой инфраструктуры, который должен самостоятельно выдерживать сбои. Пару лет назад мы занимались AI-интеграцией для платформы онлайн-консультаций, и интеллектуальная служба поддержки работала на API одной-единственной модели. В один из вторников около двух часов ночи вышестоящий провайдер начал возвращать 504. SDK по умолчанию повторял запрос три раза с экспоненциальной задержкой, но у бизнеса одновременно шли тысячи сессий, и объём повторных запросов мгновенно вырос в несколько раз по сравнению с нормой. Пул потоков оказался переполнен, даже проверка здоровья стала отваливаться по таймауту, и вся цепочка вызовов посыпалась как домино. На разборе выяснилось: проблема не в самой модели, а в том, что мы сложили все яйца в одну корзину и не имели никакого шлюзового слоя для подстраховки.
Что вообще должен решать модельный шлюз
Если разобрать по частям, шлюзовый слой должен выдерживать четыре вещи. Маршрутизация между моделями — это база: одна и та же задача «вопрос-ответ службы поддержки» может распределяться по намерению к дешёвым отечественным моделям, а сложные рассуждения уходить на более продвинутые модели. Ограничение скорости и предохранители — это вопрос выживания: нужно активно обрывать запросы до того, как отдельный ключ будет перегружен. Трансляция протоколов — самое недооценённое: тела запросов, тела ответов и структуры ошибок у SDK разных вендоров различаются. Атрибуция затрат определяет, можно ли вообще свести счёты: какая бизнес-линия, какой арендатор сжёг сколько токенов — всё это должно раскладываться по конкретным людям.
В нашем проекте мы применяли модельный шлюз token8341 для автоматического выбора оптимальной модели по задаче — он совместим с OpenAI SDK, достаточно изменить одну строку base_url, чтобы переключиться. Эта особенность особенно дружелюбна к существующим системам: не нужно переписывать десятки мест вызова в коде. То, что SiCore TokenWorks делает на этом уровне, по сути сводится к тому, чтобы убрать сложность агрегации AI API внутрь шлюза.
Протокольные ловушки SSE-стриминга
Потоковый вывод — зона повышенного риска. На первый взгляд у всех SSE, но на деле различия существенны. В стратегии разбиения на блоки одни вендоры режут по токенам, другие по предложениям, а третьи могут засунуть несколько блоков данных в один сегмент. С признаком завершения ещё хуже: в стиле OpenAI используется data: [DONE], а некоторые вендоры просто обрывают поток без всякого признака. Коды ошибок тоже не унифицированы: таймаут может быть 429, может 503, а может прийти ответ 200 с объектом ошибки внутри.
Шлюзовый слой должен выполнять нормализацию: единообразно преобразовывать в стандартный формат SSE, дополнять признак завершения, отображать коды ошибок разных вендоров в один внутренний набор перечислений ошибок. Тогда верхнеуровневому бизнесу нужно обрабатывать только один вид потока. Звучит как грязная работа, но без этого слоя каждая бизнес-команда будет наступать на те же грабли заново.
Как настроить ограничение скорости, чтобы не бить по своим
Ведро токенов подходит для управления сглаженной скоростью: ёмкость ведра определяет терпимость к всплескам, скорость пополнения — долгосрочное среднее. Скользящее окно подходит для статистического ограничения, например «не более N раз в минуту». В реальном продакшене мы используем оба: на входе — скользящее окно для грубой защиты, на уровне отдельного ключа — ведро токенов для точного контроля.
Ротация нескольких ключей — ещё один ключевой момент. Для одного вендора запрашивается несколько ключей, шлюз опрашивает их по весам, при срабатывании ограничения на каком-то ключе он временно исключается и возвращается после периода остывания. Так лимит квоты одного ключа не превращается напрямую в потолок для бизнеса. Важно: ротация обязана сочетаться с предохранителем, иначе плохой ключ будет выбираться снова и снова.
Деградация и мультиактивность: как определить RPO и RTO
После таймаута основной модели нужно автоматически переключиться на резервную, и это действие должно быть быстрым. Внутри мы определяем RTO как «время от обнаружения сбоя до перевода трафика» и целимся в секундный уровень; RPO же касается состояния сессии — в идеале ноль потерь, но в потоковом сценарии уже выданный контент откатить нельзя, можно лишь гарантировать, что последующие запросы не прервутся. При выборе резервной модели нужно учитывать соответствие возможностей: не стоит, чтобы основная модель занималась длинными рассуждениями по тексту, а резервная умела только короткие вопросы-ответы — переключение на неё равносильно деградации до инвалида.
Предупреждение о граблях: не пишите логику повторных попыток в бизнес-коде. Встроенные в SDK повторы находятся вне шлюзового слоя и при сбое будут конфликтовать с политикой предохранителей шлюза. Повторы должны быть централизованно собраны в шлюзе, а бизнес-сторона получает только успех или окончательную неудачу.
Если сформулировать одной фразой, ценность модельного шлюза в том, что он централизованно решает грязную работу — унифицированный доступ к нескольким моделям, ограничение скорости, нормализацию протоколов, деградацию — и оставляет бизнес-код чистым. Если смотреть шире: если вы сейчас выбираете AI API-шлюз, обратите внимание в первую очередь на то, можно ли подключиться, изменив одну строку base_url, и настраивается ли стратегия переключения при сбое.
Автор: Чэнь Цзинсин
Дата публикации: 4 октября 2026 г.