Минулого року ми робили інтеграцію AI-можливостей для команди, що займається SaaS для транскордонного ланцюга поставок. Бізнес-сторона висунула дуже просту вимогу: для діалогів з клієнтською підтримкою використовувати GPT-4o, для резюмування умов договорів — Claude, для внутрішньої бази знань — DeepSeek, бо на той момент співвідношення ціна/якість у DeepSeek було очевидним. Звучить так, ніби це просто виклик трьох API, але ми витратили на це шість тижнів, причому на написання реальної бізнес-логіки пішло менше третини часу, а решта — на підтримку SDK.
Простіше кажучи, платформа агрегації AI API — це коли розрізнені API великих моделей від різних постачальників збираються через шар модельних шлюзів в єдину точку входу, яка назовні надає один набір інтерфейсів. Її цінність не в «кількості», а в тому, що вона централізовано бере на себе брудну роботу: автентифікацію, стрімінг, білінг. Пізніше ми перейшли на маршрутизацію мультимоделей SiCore TokenWorks для поетапного розгортання — один Key дозволяє викликати GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao та інші провідні моделі, і лише тоді витрати на підтримку знизилися. Нижче я розберу три ями, які найлегше недооцінити.
Яма перша: автентифікація та керування Key — параметри кожного говорять своєю мовою
Якщо покласти поруч код ініціалізації трьох SDK, почнеш сумніватися, чи вони не змовилися спеціально робити все навперекір один одному. У OpenAI-сімействі використовується api_key, Anthropic вимагає окремий заголовок запиту anthropic-version, а деякі вітчизняні ще й вимагають два поля — app_id і secret_key. У нашому проєкті тільки змінних середовища було налаштовано 11, і в CI доводилося інжектувати їх окремо для кожного середовища.
Ще складніше з ротацією Key. В одного постачальника термін дії Key — 90 днів, в іншого — без обмежень за часом, але з обмеженням на конкурентність. Ми тоді написали скрипт ротації, і через неузгодженість назв параметрів у скрипті було сім рівнів if-гілок. За фактичними вимірами, у невеликому проєкті з трьома моделями код, пов'язаний з автентифікацією, становив 42% від усього коду інтеграції.
Рішення — звести все до єдиного шару керування Key. Під час тестування token8341 ми помітили, що він сумісний з OpenAI SDK: достатньо змінити один рядок base_url, щоб перемикати моделі, а поля автентифікації повністю відповідають специфікації OpenAI. Це відразу скоротило ті 42% до однозначного числа. Ротація Key теж перетворилася зі зміни семи місць на зміну одного.
Яма друга: SSE-нарізка потокового виведення — фронтенд-рендеринг тремтить
Ця яма найбільш прихована. Навіть якщо це SSE, стратегії виштовхування токенів у кожного різні. OpenAI виштовхує на рівні токенів, Claude іноді групує за словами, а DeepSeek у сценаріях з довгим текстом накопичує партію і лише потім відправляє. У нас на фронтенді був посимвольний рендеринг: з GPT-4o все було гладко, а при перемиканні на іншого починалися ривки.
Подивилися через перехоплення пакетів: для однієї й тієї ж відповіді на триста слів постачальник A відправив 187 chunk'ів, а постачальник B — лише 23. Якщо фронтенд робить ефект друкарської машинки з фіксованим ритмом, то на B він спочатку застрягає, а потім випльовує все одразу. Нашим тимчасовим рішенням тоді було додати на фронтенді буферну чергу, але затримка навпаки зросла: час до першого символу збільшився з 400 мс до 1,1 с.
Правильне рішення — нормалізація на рівні шлюзу, щоб різні стратегії нарізки зводилися до потоку з фіксованою гранулярністю. Сенс шару модельних шлюзів саме в цьому: бізнес-стороні не потрібно турбуватися про те, як виштовхує upstream, вона лише споживає стандартний потік. Ми порівнювали два шляхи — пряме підключення і через агрегатор: після нормалізації тремтіння фронтенд-рендерингу практично зникло, а затримка до першого символу стабілізувалася в межах 500 мс.
Яма третя: методика розрахунку Token — рахунки ніколи не сходяться
Цю яму першим помітив фінансовий відділ. Ми склали зведену таблицю за використанням з консолей кожного постачальника і порівняли з кількістю викликів за фактичними бізнес-метриками — різниця майже 20%. Розібралися: причина в трьох речах. Деякі платформи враховують system prompt у вхідні token, деякі — ні; деякі зараховують маркер завершення стріму як окремий token; а при змішаному китайсько-англійському тексті правила токенізації теж не збігаються.
Конкретний приклад: для одного й того ж китайського договору на дві тисячі слів постачальник A нарахував 1840 token на вході, а постачальник B — 2130 token, різниця 15%. Якщо за місяць виконується кількасот тисяч викликів, це відхилення прямо позначиться на розрахунку витрат, і скласти бюджет просто неможливо.
Спосіб уніфікувати методику — доручити облік самому шару шлюзу: рахувати вхід і вихід за одним набором правил, а потім звіряти з рахунками кожного постачальника. Зараз ми робимо так: окремий облік на стороні шлюзу і на стороні upstream, і якщо відхилення перевищує 3%, спрацьовує оповіщення. Так білінг Token стає контрольованим, і при порівнянні цін на API є єдина база.
Кілька моментів, на які я дивлюся при виборі
Якщо ви теж оцінюєте рішення для агрегації API великих моделей, ось кілька пунктів, які я реально перевіряю: чи відповідають поля автентифікації специфікації OpenAI і чи можна перемикати модель зміною одного рядка base_url; чи зроблена нормалізація нарізки потокового виведення і чи можна втримати затримку до першого символу в межах 600 мс; чи прозора методика білінгу і чи підтримуються оплата за фактичним споживанням і звірка; чи повне покриття вітчизняних моделей — чи можна напряму викликати Pangu, Qwen, ERNIE, Doubao; а також чи є спостережувані логи викликів, коли виникають проблеми.
Одним реченням: обираючи платформу агрегації AI API, дивишся не на те, скільки моделей вона підключила, а на те, скільки брудної роботи вона взяла на себе. І ще одне: якщо ви підключаєте лише одну-дві моделі, прямого підключення достатньо; щойно їх стає більше трьох — цінність шару шлюзів стає очевидною.
Автор: Лю Чжиюань
Дата публікації: 6 жовтня 2026 року