LLM API и интеграция
Как перейти на другую модель без переписывания кода
Смена модели почти никогда не ломает код — она ломает поведение, и это выясняется не на деплое, а через неделю по жалобам. Через совместимый интерфейс переезд выглядит как правка одной строки: другой идентификатор, тот же запрос, тот же ответ по форме. А дальше оказывается, что новая модель пишет длиннее, иначе понимает ту же инструкцию, не поддерживает нужный формат ответа или молча обслуживается вообще другой позицией. Разбираем, что проверить до переезда, что поедет тихо и как сделать переход обратимым за минуту, а не за релиз.
Почему переезжать приходится
Четыре причины, и три из них от вас не зависят.
Модель отключают. У вендоров есть расписания вывода версий. Мы ведём календарь отключений, и он пополняется регулярно.
Слаг остаётся, а модель меняется. Худший вариант: запросы продолжают проходить, ошибки нет, форма ответа та же — но отвечает другая модель. Заметить можно только по полю model в ответе.
Цена изменилась. У вендоров и у посредников.
Вышла модель лучше или дешевле. Единственная причина, которую вы контролируете.
Отсюда практический вывод: переезд — не разовое событие, а регулярная операция. Проектировать её надо соответственно.
Что готовится заранее
Три вещи, которые превращают переезд из проекта в правку конфига.
Идентификатор модели в конфигурации, а не в коде. Тогда смена — правка строки и перезапуск, а не релиз. Это самое дешёвое вложение из всех и его почему-то делают в последнюю очередь.
Выборка запросов с известными правильными ответами. Без неё вы не сможете сравнить до и после — как её собрать.
Логирование поля model из ответа. Чтобы видеть, кто на самом деле отвечал.
Если этих трёх вещей нет, любой переезд превращается в неделю работы вместо часа.
Что проверить до переключения
Шесть пунктов, читаются в выдаче каталога за пять минут.
Статус протокола. protocols.chat_completions должен быть available. Позиция может числиться в каталоге и не принимать запросы.
Ставка. Вход и выход отдельно. Разница может быть кратной: в каталоге на 5 сентября 2026 года платные текстовые позиции идут от 1 до 180 ₽ за миллион.
Условия доступа. access.policy: достаточно ли баланса или нужно платное пополнение.
Проверенные возможности. Вызов функций, строгий вывод JSON, параллельные вызовы. У большинства позиций эти поля помечены unknown — это «не проверяли», а не «работает» — как читать поля.
Размер контекста. Если у новой модели окно меньше, длинные запросы начнут отклоняться.
Служебный контекст маршрута. Он входит в ваш prompt_tokens и различается между семействами в разы — почему prompt_tokens больше, чем вы отправили.
Последние два пункта пропускают чаще всего, а они и создают сюрпризы в счёте.
Что поедет тихо
Пять вещей, которые не выдадут себя ошибкой.
Длина ответов. Новая модель может писать в полтора раза длиннее при той же инструкции. Счёт вырастет, интерфейс поедет, ошибки не будет.
Следование формату. Если вы разбираете ответ регулярным выражением или ожидаете определённую структуру, другая модель может оформлять иначе. Отсюда правило: при переезде включайте строгий формат, если он поддержан — как получить строгий JSON.
Реакция на системный промпт. Правила, накопленные за полгода под одну модель, на другой работают иначе: часть станет лишней, часть перестанет действовать — как устроен системный промпт.
Строгость отказов. Запросы, проходившие раньше, могут начать отклоняться — и придёт это как успешный ответ, а не как ошибка — как различать.
Скорость. Задержка меняется, и на интерактивных сценариях это заметит пользователь раньше вас — как это мерить.
Порядок переезда
Семь шагов. Занимает вечер, если подготовка сделана.
- Прочитайте поля новой позиции по списку выше.
- Прогоните выборку на старой модели. Зафиксируйте базовое значение — вам нужно с чем сравнивать.
- Прогоните ту же выборку на новой. Ничего не меняя в промпте.
- Сравните три величины: долю правильных ответов, среднюю длину ответа, стоимость прогона. Не только первую.
- Разберите расхождения. Часто выясняется, что часть правил промпта была нужна только старой модели.
- Переключите часть трафика, а не весь. Даже десять процентов на сутки показывают то, чего не видно на выборке.
- Держите откат наготове. Одна строка в конфигурации.
Пятый шаг регулярно оказывается самым полезным: переезд — хороший повод почистить промпт от правил, которые компенсировали слабости конкретной модели.
Про запасную модель
Отдельно, потому что это тот же механизм, но в другой роли.
Раз переезд — регулярная операция, логично держать вторую позицию готовой всегда. Не обязательно другого провайдера: достаточно другой модели, на которой ваша выборка проверена и результат известен.
Тогда отключение модели или отказ маршрута становится переключением, а не инцидентом — как строить повторы и запасные варианты.
Проверять запасной вариант надо реально, а не на бумаге: непроверенный запасной маршрут — это иллюзия, а не защита. Раз в квартал прогнать выборку достаточно.
Что не переносится
Три вещи, которые придётся делать заново.
Отлаженные промпты. Переносятся, но требуют перепроверки — часть правил окажется лишней, часть недостающей.
Замеры качества. Старые цифры к новой модели не относятся.
Ожидания по цене. Ставка, служебный контекст и длина ответов меняются одновременно, и итог может отличаться сильнее, чем разница в прайсе.
Что переносится без изменений: код, если вы работаете через совместимый интерфейс. Именно поэтому совместимость — не формальность, а то, что отличает правку конфига от проекта.
Что делать при экстренном переезде
Отдельный сценарий: модель отключили или маршрут перестал отвечать прямо сейчас, а выборку прогонять некогда.
Порядок на пятнадцать минут.
- Возьмите позицию того же класса. Не самую дешёвую и не самую дорогую, а сопоставимую по назначению с той, что отвалилась.
- Проверьте статус протокола и размер контекста. Два поля, которые чаще всего ломают запросы сразу.
- Переключите и включите повышенное внимание к логам. Особенно к длине ответов и доле отказов.
- Прогоните выборку в фоне, не дожидаясь тишины. Результат понадобится, чтобы решить, оставаться или искать дальше.
- Сообщите своей команде, что маршрут временный. Иначе временное решение останется навсегда и без проверки.
И вывод на будущее из любого экстренного переезда: если он занял больше часа, значит подготовка не была сделана. Идентификатор в конфигурации, готовая выборка и проверенный запасной вариант превращают такую ситуацию из аврала в переключение — и стоят они дёшево ровно до того момента, когда понадобятся.
Чего мы не утверждаем
Не сравниваем модели по качеству. Своих замеров мы не делали; проверять надо на своей выборке.
Не обещаем, что переезд пройдёт без правок промпта. Обычно правки нужны.
Не обещаем доступности конкретной позиции. Статус читается перед запросом.
Цифры каталога — на дату. Состояние на 5 сентября 2026 года.
Что нужно, чтобы переезд был дешёвым
Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Главное для этой задачи: один ключ на весь каталог, 54 позиции в шестнадцати семействах. Переход между Claude, GPT, Gemini, Grok и открытыми весами — смена идентификатора в конфигурации, без нового договора, новой интеграции и новой карты.
Платные текстовые модели доступны сразу на приветственном бонусе, так что прогнать выборку на кандидате можно до всякого пополнения. Ставки, статусы протоколов и условия доступа видны в GET /v1/models без регистрации.
Что держать в голове
Ломается не код, а поведение: длина ответов, формат, следование промпту, строгость отказов. Всё это не даёт ошибок и обнаруживается по жалобам через неделю.
Три вещи делают переезд часовой операцией: идентификатор модели в конфигурации, выборка с известными ответами и логирование поля model из ответа. Сделать их стоит до того, как переезд понадобится, — а понадобится он обязательно.
Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Проверить кандидата на своей выборке: keydealer.ru/login.
Частые вопросы
Что нужно, чтобы перейти на другую модель?
Если вы работаете через совместимый интерфейс — сменить идентификатор модели в конфигурации. Код при этом обычно не меняется, а меняется поведение, и вот его надо проверять.
Что ломается при смене модели?
Не запросы, а результаты: другой формат ответа, другая длина, другое следование инструкциям, другой набор проверенных возможностей. Плюс меняется цена и служебный контекст.
Как понять, что переход прошёл успешно?
Прогнать выборку реальных запросов до и после и сравнить долю правильных ответов. Без выборки вывод «работает» ничем не обоснован.
Можно ли откатиться назад?
Да, если идентификатор модели лежит в конфигурации, а не в коде. Тогда откат — правка одной строки без релиза.
Как узнать заранее, что модель отключают?
Смотреть расписания вывода версий у вендора и следить за полями каталога. Некоторые слаги после отключения продолжают отвечать, но обслуживаются другой моделью.