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