Миграция с OpenAI на DeepSeek выглядит страшнее, чем проходит на деле. Продукт не переписывается: DeepSeek отдаёт доступ через интерфейс, совместимый с OpenAI API. Меняются адрес запроса, ключ и имя модели. Всё остальное — код продукта, обработка ответов, стриминг — остаётся прежним.
Ниже — что трогать в коде, что ломается на живых проектах и как откатиться, если что-то пошло не так.
Что именно меняется
Совместимость здесь не маркетинговая: те же пути запросов, тот же формат ответа, та же авторизация по ключу. Поэтому переход сводится к трём значениям уровня окружения.
- base_url — адрес эндпоинта. У DeepSeek он один, у российского шлюза другой. Клиент умеет отправлять запросы на любой адрес.
- api_key — ключ доступа. Держите его в переменных окружения, чтобы смена поставщика не требовала сборки и релиза.
- model — имя модели из каталога, например deepseek-chat. Названия храните в конфиге, а не в каждом вызове.
Если эти три вещи уже вынесены в конфиг, миграция превращается в правку одного файла. Если нет — начните с выноса: он окупается на первом же эксперименте с другой моделью.
Что переписать в коде, а что оставить
В 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. Интеграция, написанная один раз, живёт на любой совместимой модели.
Про сам механизм переключения мы писали в разборе «OpenAI SDK и китайские модели». Там про то, почему код не приходится переписывать. Здесь — про то, что стоит проверить после переключения.
Что ломается на живых проектах
Совместимость означает одинаковый протокол, но не одинаковое поведение. Разница всплывает в мелочах, и почти все они проверяются заранее.
- Промпты. Инструкции, заточенные под одну модель, на другой дают другой результат. Прогоните свои формулировки на новой модели, а не ждите, что ответы совпадут.
- Вызов функций и JSON. Поддержка строгих форматов и вызова функций у моделей различается. Проверьте обе стороны на своих схемах, а не на демо из документации.
- Длинный контекст. Сверьте лимиты с самыми большими запросами приложения. Разница в лимитах вылезает уже в проде.
- Тексты ошибок. Ваша обвязка с повторами не должна зависеть от формулировок прежнего провайдера.
- Журнал. Пишите в логи модель и адрес, куда ушёл запрос. Без этого эксперименты превращаются в гадание.
- Лимиты расходов. Скрипт, ушедший в цикл, портит бюджет на любом провайдере. Ставьте лимиты до подключения продакшена.
Почти всё из списка лечится настройкой. Но проверять лучше до переключения: после переключения за вечер уже не отделаться.
Быстрая проверка до продакшена
Полноценный тест занимает вечер. Хватит реальных запросов и одной новой конфигурации.
- Соберите набор из пятнадцати-двадцати своих запросов, включая неудобные формулировки. Это важнее любого чужого бенчмарка.
- Пропустите набор через новую модель и сравните ответы с текущими: где приходится править результат, сколько ждёт пользователь.
- Проверьте вызов функций и строгие форматы, если они у вас есть.
- Переведите сначала один сервис, потом остальные. Ошибка в конфигурации не заденет весь продукт.
Такой прогон говорит о модели больше, чем любое демо: видны свои данные, свой язык, своя нагрузка.
Откат за одну строку
Главный аргумент в пользу конфигурации вместо кода — скорость отката. Вернуть прежний base_url и имя модели можно правкой переменных окружения, без сборки и релиза.
Держите старый и новый ключи в разных переменных. Тогда переключение и откат — это выбор, какая переменная подставлена, а не отзыв доступа и выпуск новой версии.
Продукт переживает смену модели спокойно, если провайдер вынесен в конфиг. И тяжело — если имя модели зашито в код вызовов.
Сколько это занимает на практике
На проекте, где провайдер уже в конфиге, переход — это часы: правка, тестовый прогон, наблюдение за логами. Основное время уходит не на код, а на проверку промптов на своих данных.
На проекте с ключами и именами моделей в коде сначала придётся сделать вынос. Это скучно, но это разовая работа, и она открывает дорогу к любой модели дальше — не только к DeepSeek.
Как это устроено в Китай-API
Мы делаем Китай-API — российский шлюз к моделям DeepSeek, Qwen, GLM и Kimi. Для кода это тот же приём: один OpenAI-совместимый base_url, один ключ, привычный SDK. Вокруг — то, чего нет в чужом API: оплата в рублях и закрывающие документы для бухгалтерии. Лимиты и журнал расходов ждут в кабинете.
Платформа готовится, запуск — скоро. Заявку на ранний доступ можно оставить в Telegram-боте: сообщим, когда откроем доступ первым. Устройство шлюза описано на главной странице.
Про доступ и документы читайте в статье «API китайских моделей в России», про выбор модели — в разборе «DeepSeek или Qwen».