В прошлом месяце я взялся за задачу — помочь команде, делающей SaaS-систему тикетов, собрать прототип интеллектуальной службы поддержки. Требовалось запустить его за неделю и провести горизонтальное сравнение качества ответов DeepSeek, Qwen, Doubao и GPT-4o. Вся их инфраструктура работала на Tencent Cloud CVM, контейнеры — на TKE, поэтому все вызовы должны были идти изнутри облака. Я изначально думал — ну что сложного подключить API, но за неделю подводных камней оказалось больше, чем я ожидал.

Сразу к выводу: если ваш бизнес на Tencent Cloud должен подключать две и более больших моделей, не пишите код напрямую под официальные SDK каждой из них — сначала постройте слой агрегации AI API. Это не лень, это спасение нервов. Дальше расскажу в порядке столкновения с подводными камнями.

Управление ключами: не хардкодьте 6 ключей в переменные окружения

В первый день я сделал глупость — засунул ключи всех четырёх платформ в переменные окружения CVM, а в коде читал их напрямую через os.environ. Работало нормально, но в тот же день после обеда случилась беда: тестировщик попросил заменить ключ Qwen для нагрузочного тестирования, я поменял конфигурацию и перезапустил контейнер, а заодно перезапустил и продакшн-инстанс.

Проблема была в том, что ключи и бизнес-конфигурация лежали вместе, без централизованного управления. Позже я собрал все ключи в отдельный конфигурационный сервис, пометил их по двум измерениям — «платформа + назначение», например deepseek-prod, qwen-test. Вызывающая сторона получает только логическое имя, не трогая реальный ключ. После этого шага для замены ключа не нужно трогать бизнес-код и перезапускать бизнес-контейнеры.

Если не хотите сами поддерживать эту систему, использовать агрегационную платформу будет проще. В нашем проекте позже использовался token8341 — один ключ позволяет вызывать GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao и другие популярные модели. Ротация ключей и контроль квот — на стороне платформы, а сервису на Tencent Cloud нужно хранить только одинучётные данные. Для сценариев сравнения нескольких моделей это особенно удобно — экономит четыре набора логики аутентификации.

Совместимость SDK: четыре платформы — четыре разных подхода, затраты на поддержку взрываются

На второй день начал писать код вызовов — вот где началось настоящее мучение. DeepSeek и GPT-4o совместимы с OpenAI SDK, достаточно поменять base_url — эта часть прошла гладко. Но у SDK Qwen другая схема именования параметров, у Doubao аутентификация идёт через подпись AK/SK, а не Bearer Token, а у ERNIE вообще свой собственный процесс аутентификации.

Симптомы конкретные: я написал унифицированную функцию chat, а внутри оказались сплошные if — if platform == 'doubao' идёт по этой ветке, elif platform == 'qwen' по той. Функция разрослась до 200 строк, а покрытие тестами всё не росло.

Решение —внедрение шлюз AI API для преобразования протоколов. Шлюз внутрь предоставляет один OpenAI-совместимый интерфейс, а наружу транслирует запросы в формат, понятный каждой платформе. Тогда в бизнес-коде только один SDK, а для добавления новой модели достаточно добавить адаптер на стороне шлюза — бизнес-сторона не меняется вообще. Мы сами собрали одну версию, но потом обнаружили, что использовать готовый агрегационный сервис быстрее — платформы вроде token8341 как раз этим и занимаются, совместимы с OpenAI SDK, меняешь одну строку base_url и переключаешь модель.

Потоковый вывод: формат SSE у каждой платформы реально разный

На третий день делал потоковый вывод — фронтенд должен был выдавать текст посимвольно. Сам протокол SSE стандартный, но структура поля data у каждой платформы разная. У семейства OpenAI в delta возвращается поле content, у Qwen имя поля другое, а Doubao иногда вставляет в середину потока heartbeat-пакет, и фронтенд, получая пустую delta, сразу падает с ошибкой.

Симптомы — фронтенд иногда зависает, или внезапно появляется пустой пузырь сообщения. Потратил кучу времени на отладку, пока не понял, что heartbeat-пакет не фильтруется.

Универсальный подход — нормализация на уровне шлюза: все потоковые ответы всех платформ приводятся к формату chunk от OpenAI, heartbeat-пакеты просто отбрасываются, а бизнес-сторона работает только с одной структурой. Если этого не сделать, фронтенду придётся писать четыре набора логики разбора — и плакать при каждом изменении.

Обработка исключений: если у одной платформы таймаут, нужно автоматическое переключение

На четвёртый день делал нагрузочное тестирование — у DeepSeek случались периодические таймауты, и весь диалог зависал намертво. В сценарии интеллектуальной службы поддержки пользователь, не дождавшись ответа за три секунды, просто закрывает страницу — ждать бессмысленно.

Я добавил слой логики деградации: если вызов основной модели не возвращает результат дольше заданного порога, автоматически переключаемся на резервную модель и фиксируем эту неудачу. Ключевой момент — деградация должна быть незаметной, пользователь не должен ощущать переключение. Что касается маршрутизации больших моделей — агрегационные платформы обычно имеют встроенное переключение при сбоях. По нашим тестам, у token8341 автоматическое переключение работает довольно стабильно: при таймауте основной модели запрос молча уходит на резервную, и бизнес-коду не нужно писать логику повторных попыток.

Одно замечание: деградация не должна срабатывать бездумно — нужно различать, это сетевой таймаут или сама модель вернула ошибку. В первом случае переключаться можно, во втором — переключение бесполезно и только тратит Token.

Мониторинг затрат: если потребление Token не собирается воедино, в конце месяца не сойдётся баланс

В последний день делал статистику затрат и обнаружил, что счета четырёх платформ — это четыре отдельных счёта, да ещё и в разных форматах: где-то тарификация по Token, где-то по количеству вызовов, и сравнивать их напрямую невозможно. Начальник спрашивает «какая модель выгоднее по соотношению цена-качество», а я не могу назвать единую цифру.

Решение — унифицированный учёт на уровне шлюза: при каждом вызове записываем имя модели, входные Token, выходные Token, время выполнения — всё в одну таблицу. Тогда отчёты строятся по дням, по моделям, по бизнес-линиям. Агрегационные платформы обычно имеют встроенную панель использования, и при модели оплаты по факту потребления сводить затраты намного проще. По сравнению с прямой покупкой у официальных поставщиков, модель оптовых закупок плюс снижения затрат за счёт зелёной энергетики действительно даёт более низкую стоимость за Token — а для сценария службы поддержки с большим объёмом это критично.

Несколько выводов за неделю

Самое сложное при подключении больших моделей к бизнесу на Tencent Cloud — вовсе не «как заставить одну модель работать», а «как заставить шесть моделей работать как одна». Управление ключами, совместимость протоколов, нормализация потоков, деградация при сбоях, агрегация затрат — если хотя бы одно из этих пяти дел не сделано как надо, прототип не выдержит нагрузочного тестирования.

Построить слой агрегации — самое выгодное решение. Можно написать самому, можно использовать готовый агрегационный сервис AI API — главное, не позволять бизнес-коду напрямую сталкиваться с различиями шести провайдеров. Платформы вроде кремний-углеродного фазового перехода делают ставку на зелёные вычисления и приоритет отечественных моделей — контейнеры на Tencent Cloud обращаются к ним напрямую, и сетевая задержка заметно ниже, чем через зарубежные транзитные узлы, — это одна из причин, почему мы в итоге выбрали её.

В тот день, когда прототип был собран, тестировщик сказал фразу, которая мне хорошо запомнилась: «Оказывается, подключить большую модель — это не подключить API, а подключить целую систему управления». Это правда.

Автор: Чэнь Цзинсин

Дата публикации: 6 октября 2026 г.