В прошлом году мы занимались подключением 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 стратегии выталкивания token наружу у всех разные. OpenAI отправляет на уровне token, Claude иногда блоками по словам, DeepSeek в сценариях с длинным текстом накапливает партию и только потом отправляет. У нас на фронтенде был посимвольный рендеринг: с GPT-4o всё шло гладко, а при переключении на другого — начинало прыгать рывками.
Посмотрели через перехват пакетов: на один и тот же ответ в триста знаков вендор A отправил 187 чанков, а вендор B — всего 23. Если фронтенд делает эффект печатной машинки с фиксированным ритмом, то на вендоре B сначала будет затык, а потом поток. Нашим временным решением была буферная очередь на фронтенде, но задержка только выросла: время до первого символа поднялось с 400 мс до 1,1 с.
Правильное решение — нормализация на уровне шлюза, сведение разных стратегий чанкинга к потоку с фиксированной гранулярностью. В этом и смысл слоя модельного шлюза: бизнес-стороне не нужно думать, как отправляет upstream, — она просто потребляет стандартный поток. Мы сравнили два пути — прямое подключение и через агрегатор: после нормализации дрожание фронтенд-рендеринга практически исчезло, а задержка до первого символа стабильно держится в пределах 500 мс.
Яма третья: методика подсчёта Token — счета никогда не сходятся
Эту яму первой обнаружила финансовая служба. Мы составили сводную таблицу пообъём использования из консолей каждого вендора и сравнили с количеством вызовов, посчитанным по бизнес-метрикам, — расхождение почти в двадцать процентов. Разобрались — дело в трёх вещах: одни платформы включают system prompt в input 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 г.