14 января 2027 года OpenAI отключит в API четыре модели семейства GPT-4, включая GPT-4o. На миграцию у разработчиков остаётся около трёх месяцев, хотя компания ранее обещала предупреждать об остановке моделей минимум за шесть. Закрытие GPT-4o API — не просто очередная строка в документации: для российских команд это повод прямо сейчас проверить, какая модель обслуживает продакшен и сколько бизнес-логики завязано на её поведение.
О планах OpenAI сообщает The New Stack. Издание обратило внимание на разрыв между заявленным сроком предупреждения и фактическим графиком: пользователям GPT-4o дали вдвое меньше времени, чем они могли ожидать, ориентируясь на прежние обязательства компании. Речь идёт именно о программном интерфейсе, через который модели встроены в продукты, внутренние сервисы, ботов, инструменты поддержки и пайплайны обработки данных.
Самая неприятная часть таких уведомлений — не сам факт вывода старой модели. Облачные модели регулярно меняются, а поставщик вправе прекращать поддержку устаревших вариантов. Проблема в сроке: три месяца для замены модели в прототипе выглядят терпимо, но для крупного сервиса это цикл из инвентаризации, выбора альтернативы, регрессионного тестирования, пересчёта экономики и согласований с безопасностью. Если модель участвует в принятии решений, разбирает документы или пишет код внутри корпоративного контура, «просто поменять идентификатор модели» обычно не получается.
GPT-4o долго был удобной опорной точкой для команд, которым нужен был универсальный мультимодальный API. При переходе на другую модель придётся проверить не только качество ответов, но и детали, которые редко попадают в красивую презентацию: формат вызова инструментов, устойчивость структурированного вывода, длину ответов, обработку русского языка, скорость и лимиты. Даже небольшое изменение в поведении модели способно сломать парсер JSON, увеличить число эскалаций в поддержку или сделать ассистента слишком разговорчивым там, где продукт ждёт одно короткое поле.
Для бизнеса закрытие GPT-4o API означает ещё и пересмотр затрат. Новая модель может оказаться дороже или дешевле, но сравнивать только цену токена недостаточно. В расчёт входят повторные запросы, доля ошибок, расходы на модерацию, задержка ответа и стоимость работы команды, которая будет исправлять последствия миграции. Особенно уязвимы продукты, где промпты и тестовые наборы исторически подгонялись под одну конкретную модель и не имеют формального набора критериев качества.
Практический минимум на ближайшие недели выглядит прозаично. Нужно составить карту всех вызовов GPT-4o и остальных затронутых моделей, отделить критические пользовательские сценарии от внутренних экспериментов и зафиксировать текущие метрики. Затем — прогнать кандидатуры на одинаковом наборе реальных, обезличенных задач. Полезно заранее включить журналирование версии модели, лимитов и параметров запроса: при разборе инцидента это сэкономит куда больше времени, чем очередная попытка угадать, почему ответы изменились.
Не стоит также путать миграцию с единичным релизом. Надёжнее построить в приложении слой абстракции над провайдером и моделями, добавить возможность переключения через конфигурацию и держать резервный сценарий для ключевых функций. Это не избавляет от тестов, зато уменьшает цену следующего уведомления. У компаний, работающих с несколькими регионами и ограничениями доступа к зарубежным сервисам, появляется дополнительная задача: убедиться, что выбранная замена доступна их инфраструктуре и не создаёт новый риск для непрерывности сервиса.
История с четырьмя моделями GPT-4 показывает, что обещание о сроке предупреждения само по себе не является планом миграции. Рынок генеративного ИИ всё больше напоминает зависимость от быстро меняющейся облачной платформы: модель надо не только выбрать, но и уметь безболезненно заменить. Главный вопрос для команд теперь не в том, успеют ли они перейти до 14 января, а в том, смогут ли они сделать следующий переход без аврального переписывания продукта.