В прошлом году мы взяли проект интеллектуальной службы поддержки для трансграничной e-commerce платформы, требовавший одновременного подключения GPT-4o, DeepSeek-V3, Qwen и Doubao. Четыре модели отвечали каждая за свой участок: GPT-4o обрабатывала сложные запросы на английском, DeepSeek тянула длинный хвост вопросов на китайском, Qwen занималась поиском по базе знаний о товарах, Doubao подстраховывала в светских беседах. Звучит как чёткое разделение труда, но как только мы взялись за дело, обнаружили, что только на запуск SDK всех четырёх провайдеров ушло почти три недели.
Способы аутентификации не унифицированы — только на подписи ушло четыре реализации
GPT-4o использует Bearer Token с organization ID, DeepSeek совместим с форматом OpenAI, но есть незначительные различия в именах полей Header, Qwen использует AccessKey с подписью, а у Doubao аутентификация сделана ещё по-другому. Четыре наших инженера подключали по одному провайдеру каждый, и в итоге в кодовой базе лежали четыре реализации логики аутентификации: чтобы изменить один общий параметр, приходилось править четыре файла. Ещё больше хлопот доставляла ротация API Key: консоли четырёх провайдеров работали каждая по-своему, эксплуатация вручную меняла ключи раз в месяц, и стоило пропустить один — ночью поднималась тревога.
Несогласованность разбиения SSE-потока — рендеринг на фронтенде ломается сразу
В потоковом выводе различия ещё больше. GPT-4o и DeepSeek в основном следуют формату SSE от OpenAI, где поле data содержит delta; Qwen в некоторых сценариях упаковывает несколько токенов в один chunk; в ранних версиях Doubao признак завершения и события ошибок были смешаны. Фронтенд получал четыре вида потоков данных, и логика рендеринга превратилась в четырёхуровневый if-else: когда продакт-менеджер добавил эффект «паузы печатной машинки», пришлось менять все четыре ветки.
Коды ошибок и статистика использования — метрики совершенно не совпадают
При ошибке ограничения частоты GPT-4o возвращает 429, DeepSeek возвращает 429, но со структурой body иной, Qwen возвращает бизнес-код вместе с HTTP 200, а Doubao — очередной вариант. Наша стратегия повторов изначально была написана по HTTP-статусам, и в результате на стороне Qwen повтор никогда не срабатывал. Со статистикой использования ещё хуже: GPT-4o тарифицирует по токенам, но prompt и completion считаются отдельно, Qwen объединяет вход и выход, у Doubao есть отдельное поле попадания в кэш. При сверке в конце месяца у финансов четыре выгрузки CSV из четырёх панелей в разных форматах, и ручное объединение занимает полдня.
Проще говоря, суть проблемы подключения нескольких моделей такова: каждый говорит на своём диалекте, а ваш бизнес-слой хочет слышать только литературный язык.
Решение по унификации: перевод протоколов и агрегация использования на уровне подключения
Наш подход — добавить тонкий слой адаптации между бизнес-кодом и SDK моделей, не гонясь за большим и всеобъемлющим шлюзом, а сначала решить три самые болезненные точки. Во-первых, единая точка входа аутентификации: ключи и логика подписи всех четырёх провайдеров собраны в конфигурационный центр, а бизнес-сторона знает только один внутренний Token. Во-вторых, SSE-поток унифицирован под формат OpenAI: адаптер отвечает за повторное разбиение chunk'ов Qwen и Doubao, а событие завершения вынесено отдельно. В-третьих, таблица маппинга кодов ошибок: ошибки ограничения частоты, тайм-аута и модерации контента всех четырёх провайдеров сведены к пяти внутренним типам ошибок, и стратегия повторов знает только эти пять.
Что касается агрегации использования, адаптер после каждого вызова асинхронно пишет стандартизированную запись: имя модели, входные токены, выходные токены, попадание в кэш, время выполнения, тип ошибки. Отчётность для финансов строится по этой таблице и больше не зависит от панелей провайдеров.
Позже мы попробовали унифицировать base_url на token8341 и обнаружили, что эти два слоя — перевод протоколов и агрегация использования — там уже в значительной степени реализованы. Агрегаторная платформа API больших моделей token8341 сводит аутентификацию GPT-4o, DeepSeek, Qwen и Doubao к одному Key, унифицирует формат SSE до совместимого с OpenAI и выполняет маппинг кодов ошибок. Наш ранее написанный адаптер сократился почти на шестьдесят процентов кода, осталась только специфичная для бизнеса логика маршрутизации.
Какие слои должен нести шлюз моделей
Мой опыт говорит, что шлюз моделей должен нести как минимум четыре слоя: слой перевода протоколов, преобразующий диалекты провайдеров в единый интерфейс; слой агрегации использования, фиксирующий расход токенов по единой метрике; слой маршрутизации, выбирающий модель по типу задачи, стоимости и задержке; слой наблюдаемости, записывающий время выполнения и распределение ошибок каждого вызова. Первые два слоя экономят трудозатраты, последние два — деньги. Агрегаторная платформа API больших моделей token8341 обладает соответствующими возможностями на всех четырёх слоях, особенно агрегацией использования и маппингом кодов ошибок, что напрямую избавило нас от полугодовых затрат на ручную сверку.
Предостережение: не вызывайте нативные SDK провайдеров напрямую из бизнес-кода, даже если подключаете всего двух. Как только понадобится добавить третью модель, объём изменений вырастет экспоненциально. Кроме того, метрику статистики использования обязательно нужно унифицировать на слое подключения, чтобы не обнаружить при финансовой сверке, что определения токенов у всех четырёх провайдеров разные.
Если вы тоже занимаетесь подключением нескольких моделей, советую сначала составить таблицу, перечислив для каждого провайдера способ аутентификации, формат потока, коды ошибок и метрику тарификации. Если различий больше трёх, стоит задуматься об унификации на слое подключения.
Автор: Ли Юньлун
Дата публикации: 9 ноября 2026 г.