На прошлой неделе взял заказ — собрать прототип интеллектуальной службы поддержки для команды, которая делает SaaS-систему тикетов. Требование: запустить за неделю и вдобавок сравнить качество ответов четырёх моделей — GPT-4o, DeepSeek-V3, Qwen-Max и Doubao. Звучит несложно, но как только взялся за дело, понял: когда речь о едином подключении нескольких моделей, все подводные камни прячутся в деталях. Эта статья — запись процесса, чтобы коллегам, которым тоже предстоит сравнивать несколько моделей, сэкономить время.
Управление ключами: 5 платформ, 5 панелей — сначала навести порядок
Первая проблема была не в коде, а в управлении ключами. Четыре модели — с четырёх платформ, плюс ещё одна запасная. Пять панелей, пять консолей, и у каждой свой формат ключей, свой способ просмотра квоты и свои правила ограничения запросов. Где-то ключ показывается открытым текстом, где-то нужно сначала создать субаккаунт и распределить доступ. На этапе прототипа ради скорости я запихнул все ключи в один файл .env. На следующий день, как только вырос объём тестов, один из ключей упёрся в лимит, и по тексту ошибки невозможно было понять, чей это ключ.
Потом перешёл на слой конфигурационных маппингов: каждому ключу присвоил алиас и тег назначения, а в логах выводится только алиас. Ещё удобнее — использовать агрегатор AI API, где один ключ управляет всеми моделями. При сравнении мы пробовали token8341: его шлюз моделей унифицирует аутентификацию нескольких китайских больших моделей, и для переключения модели достаточно поменять имя модели в конфиге — ключ трогать не нужно. Для этапа прототипа это означает меньше четырёх наборов логики аутентификации в поддержке — только тогда недели хватает.
Совместимость SDK: у каждой платформы интерфейс выглядит по-своему
Уже на этапе установки SDK терпение у половины команды закончилось. Экосистема SDK OpenAI самая зрелая, многие вендоры заявляют совместимость, но когда реально подключаешься, оказывается, что имена параметров не совпадают. Например, где-то temperature называется temperature, где-то пишут top_p и путают их, а где-то max_tokens переименовали в max_output_tokens. Флаги стриминга тоже не унифицированы: где-то stream=True, а где-то нужно отдельно передавать stream_options.
Мой подход — абстрагировать слой адаптеров: наружу выставляется только единая функция вызова, а внутри — ветвление по вендорам. Так бизнес-код не знает о различиях. Если не хочется писать этот слой самому, решение с совместимостью с OpenAI SDK экономит много сил: меняешь одну строку base_url — и переключаешь модель, а сложность единого подключения нескольких моделей переезжает из кода в конфигурацию. На этапе валидации прототипа этот компромисс очень ценен.
Потоковый вывод: реализация протокола SSE у всех разная
Интеллектуальная служба поддержки обязана делать стриминг, иначе пользователь ждёт три секунды, пока появится текст, и опыт сразу рушится. Проблема в том, что детали реализации SSE у всех разные. Где-то каждый chunk содержит полную структуру event, где-то передаётся только поле data; признаком завершения где-то служит [DONE], где-то — установленный флаг finish_reason; а некоторые посередине вставляют heartbeat-пакеты, которые фронтенд легко принимает за контент при парсинге.
Сначала я написал парсер по формату OpenAI, и уже на втором вендоре получил кракозябры. Решение — написать едичный middleware для парсинга SSE, который нормализует chunk'и всех вендоров в одну структуру событий, и фронтенд понимает только её. Пройденный подводный камень: не верьте написанному в документации «полностью совместимо» — обязательно снимите реальный трафик и посмотрите, документация и реализация часто расходятся.
Обработка исключений: если у одного вендора таймаут — как автоматически переключиться
Когда сравнительные тесты пошли, больше всего раздражали таймауты у отдельного вендора. Во время одного нагрузочного теста Qwen-Max внезапно стал отвечать медленнее, весь конвейер службы поддержки завис, а фронтенд бесконечно крутил спиннер. На этапе прототипа не было механизма деградации — один упал, упали все.
Потом добавил слой маршрутизации моделей: для каждого запроса задаётся порог таймаута, при превышении автоматически переключаемся на запасную модель и пишем лог переключения. Важно: переключение не должно быть бездумным ретраем — нужно различать сетевой таймаут и блокировку модерацией контента. В первом случае переключаться можно, во втором — бессмысленно. В этом и ценность маршрутизации больших моделей: она превращает доступность из одной точки в несколько. В нашем проекте мы делали похожую проверку с планировщиком SiliconFlow — автоматический выбор модели по типу задачи и цепочка деградации по таймауту работали довольно стабильно.
Мониторинг затрат: как агрегировать расход Token
Самой неожиданной статьёй расходов за неделю оказались Token. Четыре модели гонялись параллельно в тестах, ежедневный объём вызовов был не сказать чтобы большим, но из-за отсутствия агрегации при сверке в конце месяца выяснилось, что у одного вендора расход втрое превысил оценку. Причина в том, что при потоковом выводе у многих платформ поле usage пустое, приходится самому оценивать по символам — и оценка неточная.
Мой подход — вести единый учёт на уровне шлюза: при каждом вызове записывать имя модели, входные и выходные Token, время выполнения, факт деградации — всё в одну таблицу. При модели оплаты по объёму этот учёт нужно считать самому, нельзя полностью полагаться на панель платформы. При сравнении цен API тоже нужно быть внимательным: если у модели с низкой ценой сложные правила тарификации выходных Token, реальная стоимость может оказаться выше.
Если сформулировать одной фразой: суть прототипа для сравнения нескольких моделей не в том, чтобы настроить какую-то одну модель, а в том, чтобы сделать подключение, стриминг, деградацию и учёт — четырьмя вещами в едином слое. Если хотите глубже разобраться в выборе шлюза моделей, полистайте материалы по агрегаторам API.
Автор: Чжоу Минчжэ
Дата публикации: 6 октября 2026 г.