Проект на OpenAI SDK переключается на китайскую модель правкой конфигурации: меняются адрес, ключ и имя модели. Разбираем, что трогать в коде, где спотыкаются на переходе и как проверить всё до первой оплаты.
Почему не придётся переписывать код
Китайские вендоры DeepSeek, Qwen, GLM или Kimi дают доступ к моделям через интерфейс, совместимый с OpenAI API. На практике это значит: те же методы, тот же формат ответа, тот же стриминг.
Интерфейс повторяет привычный OpenAI: те же пути запросов, авторизация по ключу, структура ответа. Поэтому существующие тесты и обработчики обычно проходят без переделок.
Для проекта на OpenAI SDK переход сводится к смене адреса. Клиент уже умеет отправлять запросы на произвольный base_url — вы подставляете новый. Обработка ответов, логика продукта и обвязка не трогаются.
Дальше начинаются детали. Их немного, и каждая проверяется на своих данных.
Три правки в конфигурации
В типичном проекте меняются три значения. Все они уровня окружения, а не бизнес-логики.
- base_url — адрес, по которому клиент отправляет запросы. Здесь появляется адрес китайского вендора или российского шлюза.
- api_key — ключ доступа. Держите его в переменных окружения, чтобы смена поставщика не требовала сборки и релиза.
- model — имя модели из каталога. Названия у китайских вендоров свои, поэтому храните их в конфиге, а не в коде вызовов.
Если эти три вещи вынесены в конфиг, переход превращается в правку одного файла. Если нет — начните с выноса: он окупится на первом же эксперименте.
Живой пример: было и стало
Вот как выглядит правка в Python. Клиент создаётся один раз, меняются только параметры подключения.
Было: client = OpenAI()
Стало: client = OpenAI(base_url="https://ваш-шлюз/v1", api_key=os.environ["LLM_KEY"])
Вызов не меняется: client.chat.completions.create(model="deepseek-chat", messages=[...])
Стриминг, обработка ошибок и разбор ответа работают как раньше.
Тот же принцип в других SDK: у каждого есть параметр base_url. Интеграция, написанная один раз, живёт на любой совместимой модели.
Отдельно держите под контролем имя модели. Каталоги обновляются, названия различаются, и список моделей в одном месте экономит время при каждом переключении.
Что проверить до продакшена
Перед переключением продакшена прогоните короткий чек-лист. Он закрывает почти все сюрпризы перехода.
- Стриминг. Отправьте тестовый запрос: синтаксис тот же, но убедитесь, что обработчик принимает чанки как раньше.
- Формат ответа. JSON и роли сообщений не меняются. А поддержку строгих форматов и вызова функций проверьте у конкретной модели: набор возможностей у вендоров разный.
- Длинный контекст. Сверьте лимиты с самыми большими запросами приложения. У моделей они отличаются, и ошибка легко вылезает уже в проде.
- Ошибки и таймауты. Ваша обвязка с повторами должна переживать отказы. Проверьте, что она не завязана на тексты ошибок прежнего провайдера.
- Журнал. Пишите в логи модель и адрес, куда ушёл запрос. Без этого эксперименты быстро превращаются в гадание.
- Постепенность. Переведите сначала один сервис, потом остальные: ошибка в конфигурации не заденет весь продукт.
Что можно проверить до оплаты
Переход проверяется без договора и предоплаты. Хватит тестового ключа и одного вечера.
- Соберите тестовый набор: пятнадцать-двадцать реальных запросов из своей задачи, включая неудобные формулировки.
- Получите тестовый ключ у вендора или через шлюз. Для прогона достаточно минимального лимита.
- Пропустите набор через новую конфигурацию и сравните ответы с текущими: где приходится править результат и сколько ждёт пользователь.
- Подготовьте откат. Вернуть прежний base_url в конфиге — дело одной строки.
Такой прогон говорит больше любого чужого демо: видны свои данные, свой язык, своя нагрузка.
Где обычно спотыкаются
- Ключ зашит в коде. Попадёт в репозиторий — придётся отзывать. Выносите в переменные окружения до первого коммита.
- Модель выбрана по чужому демо. Тестовый набор из предыдущего раздела показывает, как модель отвечает на ваших данных.
- Нет лимитов на расход. Скрипт, ушедший в цикл, портит бюджет. Ставьте лимиты до подключения продакшена.
- Тесты и продакшен в одном аккаунте. Расходы не разнести, инциденты не разделить. Заведите разные ключи.
Почти всё из этого списка лечится конфигурацией. Но проверять лучше до запуска: после запуска за вечер уже не отделаться.
Как это устроено в Китай-API
Мы делаем Китай-API — российский шлюз к китайским моделям DeepSeek, Qwen, GLM и Kimi. Для кода это тот же приём: один OpenAI-совместимый base_url, один ключ, привычный SDK. А вокруг — то, что не видно в коде: оплата в рублях и документы для бухгалтерии. Лимиты и журнал расходов ждут в кабинете.
Платформа готовится, запуск — скоро. Заявку на ранний доступ можно оставить в Telegram-боте: сообщим, когда откроем доступ первым. Как устроен шлюз — на главной странице.
Про доступ и документы читайте в статье «API китайских моделей в России», про выбор модели — в разборе «DeepSeek или Qwen». Про оплату — в материале «Как оплатить DeepSeek из России».