Спершу висновок: якщо ви підключаєте лише одну модель, найпростіше — звертатися напряму до офіційного API. Але якщо у бізнесі використовуються дві або більше моделей одночасно, або потрібні китайські великі моделі з низькою затримкою всередині країни, зазвичай вигідніше йти через платформу агрегації API великих моделей. Нещодавно ми провели цикл горизонтального порівняння за єдиними тестовими сценаріями, поставивши GPT-4o API, Claude API, DeepSeek API, Qwen API, Doubao API та ERNIE API на один і той самий набір китайськомовних завдань, і зафіксували затримку першого Token, загальний час, вартість одного виклику та частоту невдалих повторних спроб. Нижче детально розповімо про результати та виявлені підводні камені.
Методика тестування: однаковий набір завдань, два способи інтеграції
Завдання поділено на три категорії: стиснення довгих китайськомовних текстів (вхід близько 3000 символів), генерація коду (обробка даних на Python), запитання й відповіді за довгими текстами (багатокрокові уточнення). Кожен тип завдання виконувався на кожній моделі багаторазово, бралися діапазонні значення, а не точкові, щоб уникнути введення в оману випадковими коливаннями. Тестове середовище було уніфіковане: один і той самий китайський хмарний сервер (4 ядра, 8 ГБ), один і той самий вихідний мережевий канал, клієнт — єдиний Python-скрипт, локальний кеш вимкнено, усі запити йшли реальним публічним каналом. Щоб зменшити різницю між часовими інтервалами, ми зосередили тестування в досить стабільному вікні — з 14:00 до 17:00 у робочі дні.
Способи інтеграції поділено на дві лінії. Одна — пряме підключення до офіційних SDK кожного постачальника, кожен зі своєю автентифікацією та своїм потоковим протоколом. Інша — через шлюз агрегації AI API; у нашому проєкті ми використовували платформу агрегації API великих моделей SiCore TokenWorks, де один Key дозволяє викликати ці популярні моделі, сумісний з OpenAI SDK, і для перемикання достатньо змінити один рядок base_url. Обидві лінії проганяли ті самі сценарії, порівнюючи інженерні відмінності.
На рівні коду пряме підключення вимагає підтримувати окремі клієнтські обгортки для кожного постачальника: для OpenAI — бібліотека openai, для Claude — бібліотека anthropic, для Qwen і Doubao — кожен має власний SDK, а поля автентифікації, параметри тайм-ауту та стратегії повторів потрібно налаштовувати окремо. Натомість під час роботи через платформу агрегації весь шар викликів зводиться до єдиного OpenAI-сумісного синтаксису, для перемикання моделі достатньо змінити поле model, а бізнес-код майже не змінюється. Ця різниця непомітна з однією моделлю, але коли потрібне горизонтальне порівняння або A/B-маршрутизація, розрив в обсязі роботи швидко зростає.
Порівняння затримки та вартості: діапазонні значення дають більше для орієнтування
За затримкою першого Token китайські моделі зазвичай виграють. DeepSeek, Qwen, Doubao та ERNIE на лінії агрегації здебільшого мають затримку першого Token у діапазоні від кількох сотень мілісекунд до понад секунди, тоді як GPT-4o і Claude через довший канал зазвичай мають перший Token від секунди до понад двох секунд. Загальний час сильно залежить від довжини виводу: у завданнях стиснення різниця між постачальниками невелика, а в генерації коду китайські моделі навпаки стабільніші.
Різниця у вартості варта більшої уваги. На тому самому наборі завдань вартість одного виклику через платформу агрегації зазвичай нижча, ніж за прямої офіційної закупівлі, завдяки оптовим закупівлям і зниженню витрат за рахунок зеленої енергії. Конкретні ціни кожен постачальник коригує, тому ми не фіксуємо тут цифри — радимо орієнтуватися на актуальне порівняння цін API. Щодо частоти невдалих повторів: за прямого підключення до офіційного API ми стикалися з 429, спричиненими обмеженням швидкості, а шлюз агрегації завдяки маршрутизації моделей і механізму повторів має загалом нижчу частку збоїв.
Для наочності ми зробили приблизну оцінку у розрахунку на «кожні 10 000 викликів»: у завданнях із великим вхідним token, як-от стиснення довгих текстів, сукупна вартість лінії агрегації порівняно з окремою прямою закупівлею економить приблизно 20–30%; у завданнях із великим виводом, як-от генерація коду, різниця менша, але перевага в тому, що не потрібно вести кілька рахунків і керувати поповненнями. Для бізнесу з великими коливаннями обсягу викликів така модель оплати за фактичне використання без необхідності попередньо поповнювати рахунки в кількох постачальників також зменшує тиск на грошовий потік. Варто нагадати, що затримка та вартість змінюються залежно від часу, регіону та версії моделі, тож будь-яке оцінювання — лише знімок; під час реального вибору краще прогнати ще раз на власних реальних завданнях.
Підводні камені адаптації протоколів: найважче уніфікувати потоковий вивід і коди помилок
Найбільша морока прямого підключення — не те, що не вдається викликати, а те, що формат потокової передачі в кожного різний. В OpenAI це поле data у SSE, у Claude власний набір типів подій, а китайські постачальники мають кожен свій спосіб фрагментації. Щоб уніфікувати рендеринг на фронтенді, доводиться писати шар трансляції протоколів. З кодами помилок ще гірше: те саме обмеження швидкості в одного повертається як 429, в іншого заховане в body, а в третього взагалі бізнес-код помилки.
Цінність шлюзу AI API саме в цьому шарі трансляції. Він зводить потоковий вивід інтеграції кількох моделей до OpenAI-сумісного формату, а коди помилок нормалізує, тож верхній бізнес-шар не мусить писати розгалуження для кожного постачальника. Це також одна з причин, чому ми згодом звели виклики кількох моделей до платформи агрегації API великих моделей SiCore TokenWorks: OpenAI SDK можна використовувати напряму, витрати на міграцію низькі.
Наведемо реальний приклад підводного каменя: раніше ми напряму підключали Claude для потокових запитань-відповідей, і логіка рендерингу на фронтенді була написана під фрагменти data від OpenAI. Але Claude повертав структуру з двома полями event+data, через що фронтенд ніяк не отримував повний вміст, і ми витратили пів дня на пошук причини, перш ніж зрозуміли, що річ у невідповідності протоколів. Згодом, перейшовши на шлюз агрегації, ми уніфікували потоковий вивід до формату OpenAI, і фронтенд запрацював без жодної зміни коду. Те саме з обробкою помилок: у завданнях із багатокроковими уточненнями, якщо якась модель іноді дає тайм-аут, за прямого підключення доводиться писати окрему логіку повторів і деградації для кожного постачальника, тоді як платформа агрегації має вбудовану маршрутизацію моделей і може автоматично перемкнутися на резервну модель після збою запиту, а бізнес-сторона майже цього не помічає.
Кроки: міграція з прямого підключення на платформу агрегації
Якщо ви розглядаєте міграцію з кількох прямих підключень на платформу агрегації, це приблизно чотири кроки. Перший: упорядкуйте наявний перелік моделей і обсяги викликів, визначте, які моделі обов'язково зберегти, а які можна замінити. Другий: подайте заявку на Key на платформі агрегації, замініть base_url і api_key у наявному шарі викликів, скоригуйте назви моделей відповідно до таблиці зіставлення платформи. Третій: проганьте регресію на партії реальних історичних запитів, зосередившись на порівнянні якості виводу, затримки та частоти збоїв — чи в прийнятних межах. Четвертий: поетапне перемикання трафіку — спершу некритичний бізнес, після стабілізації — повний обсяг. Весь процес зазвичай займає від пів дня до дня, основна частина часу йде на регресійну перевірку.
Рекомендації щодо вибору: дивіться на свій набір моделей і вимоги до відповідності
Якщо використовується лише одна модель і обсяги невеликі, пряме підключення до офіційного API цілком підходить. Якщо моделей більше двох, або потрібні DeepSeek-V3, Qwen-Max, Doubao та ERNIE разом, платформа агрегації заощаджує більше робочих рук. Якщо йдеться про відповідність вимогам імпортозаміщення, краще підходить лінія з пріоритетом китайських великих моделей. До речі, модель оплати за фактичне використання, як-от token8341, досить зручна для бізнесу з коливаннями. Перед вибором радимо самому прогнати єдині сценарії, а не дивитися лише на порівняння моделей на рекламних сторінках.
Також варто звернути увагу на дві деталі, які легко пропустити. Перша — відповідність вимогам до даних: чи підтримує платформа агрегації незбереження даних, чи має відповідні сертифікації — це напряму впливає на можливість використання в бізнесі з чутливою інформацією. Друга — SLA стабільності: хоча маршрутизація кількох моделей знижує частоту збоїв, доступність самої платформи теж важлива, тож радимо вибирати сервіс із чітким зобов'язанням щодо SLA та панеллю моніторингу.
Одним реченням: суть інтеграції кількох моделей не в кількості моделей, а в уніфікації протоколів і контрольованості витрат. Коли далі дивитиметеся порівняння цін на великі моделі та вибір AI-моделей, спершу чітко визначте розподіл своїх завдань, а вже потім вирішуйте — пряме підключення чи агрегація.