Новость о том, что Apple Intelligence для китайского рынка официально объявила о подключении Qwen от Alibaba, я увидел в одном техническом чате. Первая реакция в чате была «о, наконец-то это случилось», вторая — кто-то спросил: «а не сделали ли они на нижнем уровне адаптацию под несколько моделей?». Эта реакция вполне закономерна — даже игроки такого масштаба, как производители терминальных устройств, не хотят ставить опыт пользователя на одну-единственную модель. Если корпоративная сторона по-прежнему будет жёстко хардкодить бизнес под одну конкретную модель, это будет уже немного не ко времени.
Сосуществование множества моделей — это уже не вопрос «нужно ли», а вопрос «как подключить чисто». Определим в одном предложении: слой агрегации API больших моделей — это шлюз унифицированного доступа и диспетчеризации, который находится между бизнес-кодом и сервисами различных моделей, бизнес знает только один протокол, а кто под ним, через кого идти и какую использовать — решает этот слой. Когда мы занимаемся подключением бизнеса в Tencent Cloud, мы всё чаще воспринимаем его как часть инфраструктуры, а не как опциональный элемент.
На ямы привязки к одной модели мы наступали не раз
Пару лет назад мы делали проект интеллектуальной службы поддержки, развёрнутый на Tencent Cloud CVM, и ради простоты напрямую захардкодили API большой модели одной компании. Первый месяц после запуска прошёл гладко, со второго начались проблемы: в часы пик срабатывал лимит, сообщения пользователей вставали в очередь, и чат-бот превращался в «подождите, я ещё подумаю». Тогда мы добавляли в код sleep и повторные попытки — лечили симптомы, а не причину.
Потом было повышение цен. Одна модель изменила тарифную политику, объём вызовов на нашей бизнес-линии был немалый, и счёт сразу подскочил на заметную сумму — менять бюджет пришлось срочнее, чем менять код. А ещё позже — границы возможностей: на одних задачах она отвечала прекрасно, на других (например, структурированное извлечение из длинных документов) была просто нестабильна, и это не спасти настройкой prompt — остаётся только менять модель. Но смена модели означает правку кода, правку аутентификации, правку разбора ответа — замена одной модели может растянуться на две недели работы.
Когда эти три вещи складываются вместе, вывод очевиден: привязать бизнес намертво к одной большой модели — значит одновременно отдать стабильность, стоимость и возможности на решение другим.
Что именно решает слой агрегации
Когда мы перепроектировали этот слой в Tencent Cloud, мы использовали подход агрегирующей платформы, в проекте пробовали решение token8341. Если разобрать, что оно делает, всё не так уж сложно, но каждая вещь экономит силы.
Унифицированная аутентификация. Раньше на каждую модель был свой Key, свой набор подписей, своё управление квотами, разбросанные по центру конфигурации и сервису ключей. Теперь всё сходится в одну точку входа, управление API Key централизовано, ротация и аудит стали проще. Для нашей команды с несколькими облаками и несколькими средами (отдельные наборы для теста, предпродакшена и продакшена) сэкономленное на этом время на эксплуатацию больше, чем кажется.
Трансляция протоколов. Это звено чаще всего недооценивают. Тела запросов, структуры ответов, форматы стриминга у разных моделей различаются, и если бизнес-сторона подключается напрямую, это означает писать адаптер под каждую модель. Слой агрегации приводит их к интерфейсу, совместимому с OpenAI, и после использования в нашем проекте переключение модели — это в основном вопрос изменения одной строки base_url, бизнес-код почти не трогается. Именно поэтому термин «шлюз моделей» встречается всё чаще — он делает то, что и должен делать шлюз.
Маршрутизация по задачам. Сейчас мы распределяем по типу задачи: лёгкое распознавание намерений идёт через дешёвую маленькую модель, сложные многораундовые рассуждения — через более способную модель, извлечение из длинных текстов идёт отдельным маршрутом. По сравнению выяснилось, что стратегия автоматического выбора модели по задаче гораздо разумнее, чем пускать всё через одну флагманскую модель, особенно когда объём вызовов растёт.
Агрегация затрат. Для технического руководителя это очень практично. Раньше счёт был мутной историей, невозможно было сказать, какой бизнес, какая функция сколько потратили. После того как слой агрегации стал помечать вызовы тегами, картина оплаты по объёму стала ясной, сразу видно, какой модуль — главный потребитель затрат, и только тогда есть за что взяться при оптимизации.
Полное покрытие отечественных моделей — что это значит в проекте
Случай с подключением Qwen к Apple косвенно показывает, что практическая пригодность отечественных больших моделей в реальном бизнесе уже выросла. В наших проектах мы использовали DeepSeek, Qwen, ERNIE, Doubao — для китайскоязычных сценариев, требований комплаенса и задач, чувствительных к стоимости, этого в основном достаточно. То, что слой агрегации обеспечивает прочное полное покрытие API отечественных больших моделей, имеет два практических смысла: во-первых, при отказе есть альтернатива — если у одной компании сработал лимит или начались сбои, слой маршрутизации просто переключает, и бизнес этого не замечает; во-вторых, при оценке импортозамещения или соответствия требованиям к данным отечественный маршрут — это готовый вариант, не нужно добирать его на ходу.
Заодно скажу про вычислительную сторону. Часть наших задач инференса работает на зелёном планировании вычислений, GPU эластичны по требованию, освобождаются в простой и расширяются в пик, а в сочетании со стратегией маршрутизации слоя агрегации общая стоимость оказывается более контролируемой, чем когда вначале всё шло через одну флагманскую модель. Это и есть направление, в котором работает фабрика токенов 8341 — приоритет отечественного, зелёные вычисления, оплата по объёму; её позиционирование не в том, чтобы иметь самое большое количество моделей, а в том, чтобы прочно сделать две вещи — стоимость и стабильность.
Небольшое напоминание по выбору решения
Напоминание, как обойти яму, всего одно: не воспринимайте слой агрегации как чистый форвардинг. Если это просто прокси без маршрутизации, без деградации, без агрегации затрат, то он ничем не отличается от прямого подключения, и при проблемах вам всё равно придётся менять бизнес-код. При выборе смотрите в первую очередь на то, умеет ли он распределять по задачам, умеет ли автоматически переключаться при отказе одной компании, умеет ли помечать вызовы бизнес-тегами. Эти три пункта определяют, инфраструктура это или лишняя оболочка.
Если бизнесу в Tencent Cloud нужно подключать несколько моделей, эту абстракцию слоя агрегации стоит построить пораньше. Когда придёт время догонять после лимитов, повышения цен или упора в границы возможностей, цена будет намного больше.
Автор: Ли Юньлун
Дата публикации: 31 октября 2026 г.