SABSUS

OPENAI · СРОК ОТКЛЮЧЕНИЯ API · ДООБУЧЕННЫЕ МОДЕЛИ

Какие GPT-4o и GPT-4.1 отключат в API 14 января 2027 года

У части действующих интеграций появился срок замены. Самый важный вопрос для владельца дообученной автоматизации: где будут храниться и как будут проверяться её бизнес-правила после перехода на другую модель?

Редакция SABSUS · · Источники проверены 14 октября 2026 года UTC

Что объявлено 14 октября

OpenAI уведомила разработчиков о выводе следующих снимков моделей из эксплуатации и назначила прекращение доступа к ним через API на 14 января 2027 года:

  • GPT-4o: gpt-4o-2024-08-06 и gpt-4o-2024-11-20;
  • GPT-4o mini: gpt-4o-mini-2024-07-18;
  • GPT-4.1: gpt-4.1-2025-04-14;
  • GPT-4.1 mini: gpt-4.1-mini-2025-04-14.

Та же дата относится к дообученным версиям перечисленных моделей. Рекомендованная замена для них — gpt-6-luna. Уведомление датировано 14 октября; точные часы публикации и отключения не указаны. Официальный график OpenAI.

Проверяйте полный идентификатор. Например, у gpt-4o-2024-05-13 и GPT-4.1 nano в том же графике стоит другая дата: 23 октября 2026 года. Нельзя переносить январский срок на всё семейство GPT-4. Этот разбор относится к API-интеграциям.

Попросите разработчика найти модель в действующем запросе, настройках фоновых задач и резервных маршрутах. Если используется короткое имя без даты, установите, к какой версии оно ведёт. Название в интерфейсе подрядчика и старый договор сами по себе этого не подтверждают. В реестр внесите рабочий процесс, идентификатор, ответственного и доказательство из текущей конфигурации.

Дообученную модель нельзя считать перенесённой после замены имени

В карточке GPT-6 Luna дообучение, или fine-tuning, отмечено как неподдерживаемое. Следовательно, рекомендация перейти на Luna не предлагает прямого переноса прежней дообученной конфигурации. Возможности GPT-6 Luna.

Редакционная рекомендация: перед выбором замены восстановите описание того, какие задачи решало дообучение. Ответ «модель знает наш бизнес» слишком расплывчат для приёмки. Попросите разделить три вида требований:

Формат результата

Имена полей, разрешённые категории, обязательные значения и способ обозначить неизвестное. Это договор между моделью и программой, которая читает ответ.

Правила решения

Почему обращение получает конкретную категорию, когда нужно уточнение и в каких случаях сотрудник обязан проверить результат.

Изменяемые сведения

Текущие товары, условия обслуживания, сроки и внутренние инструкции. У каждого факта должен быть проверяемый источник и владелец обновления.

Затем решите, где каждое требование будет обеспечиваться: в инструкции, примерах, подключённой базе знаний, проверках приложения или ручном решении. Это варианты проектирования, которые требуют испытания. Наличие большего контекстного окна не доказывает воспроизведение прежнего поведения.

Соберите доступные компании обучающие примеры, разметку, контрольные ответы и историю исправлений с учётом разрешений на данные. Зафиксируйте, какие материалы сохранились, какие устарели и что придётся восстановить с владельцем процесса. Если исходного набора нет, обозначьте это отдельным риском и объёмом работы. Сохранение старого идентификатора модели не заменяет эти материалы.

Прежние ответы используйте для сравнения, но не объявляйте их правильными автоматически. Владелец процесса должен подтвердить действующие правила. Иначе переход законсервирует ошибку, которая давно стала привычной.

Пример: распознавание условий сервисного договора

Условный сервис оборудования дообучил GPT-4.1 mini на внутренних категориях обращений. Модель предлагает диспетчеру тип заявки и основание: платный выезд, проверка договора обслуживания или уточнение. Вымышленная компания хочет заменить её до январского отключения. Это учебный сценарий, а не описание клиентского внедрения.

В проверочном сообщении клиент пишет: «После последнего обслуживания снова появился шум». В старых примерах подобные сообщения часто относились к договорному обслуживанию. Но текст сам по себе не подтверждает действующий договор и состав покрытия. Если новая модель угадывает ту же категорию, совпадение с прежним ответом ещё не решает задачу.

  1. Зафиксируйте основания. Для тестовой заявки укажите подтверждённый договор, его версию и применимый пункт. Если договора в разрешённых данных нет, ожидаемый результат — запрос проверки, а не обещание бесплатного визита.
  2. Разделите извлечение и решение. Модель выделяет симптом и отмечает, что номер оборудования в сообщении не указан. Приложение получает допустимые сведения о договоре; сотрудник проверяет спорное покрытие. Выбор новой модели не меняет полномочия на назначение бесплатных работ.
  3. Проверьте пары случаев. Два одинаковых сообщения сопровождаются разными подтверждёнными условиями: в одном договор действует, в другом истёк. Отдельная пара имеет одинаковый договор, но разные неисправности. Так становится видно, учитывает ли кандидат основание решения.
  4. Разберите расхождение. Для каждого отличия от старого ответа отметьте: ошибка новой конфигурации, прежняя ошибка, изменившееся правило или недостаточные данные. Сотрудник подтверждает итоговую оценку.

Результат замены здесь измеряется сохранением нужного делового решения и его основания. Процент совпадений со старой моделью можно оставить вспомогательным показателем. Не смешивайте его с правильностью по текущим договорам.

До допуска в рабочую очередь сохраняйте ответы кандидата отдельно. В журнале сопоставьте пример, версию правила, ожидаемое основание, результат и решение проверяющего. Общий порядок сравнения и выпуска описан в проверке изменения правила AI. Здесь ключевое условие — независимо подтвердить правила, которые раньше связывали с дообученной моделью.

Две технические развилки перед испытанием

Для GPT-6 Luna вызов функций в Chat Completions поддерживается только при reasoning_effort: none. Для рассуждения вместе с инструментами OpenAI рекомендует Responses API. Если рассуждение включено, при миграции также нужно убрать неподдерживаемые параметры temperature, top_p и top_logprobs; у Chat Completions — logprobs. Руководство перехода на GPT-6.

Попросите исполнителя показать выбранный путь и фактически отправленный запрос без секретов и клиентских данных. Если старый процесс получал из CRM договор через функцию, успешный текстовый ответ без этого вызова не подтверждает работоспособность замены. В тесте должно быть видно, откуда взялось основание классификации.

Luna принимает текст и изображения и выдаёт текст; нативные аудио и видео не поддерживаются. Окно составляет 1 050 000 токенов, максимум выхода — 128 000. Это ограничения модели, а не обещание скорости или качества вашей задачи. Карточка модели.

Оставьте проверку структуры, допустимых категорий и обязательных оснований на стороне приложения. Ошибка разбора, отказ или отсутствие ответа должны сохранять заявку для сотрудника. Не превращайте технически корректный JSON в автоматическое разрешение на действие.

Цена Luna и условия доступа на дату проверки

Для Standard и короткого контекста OpenAI указывает следующие цены за миллион текстовых токенов в USD: обычный вход — 0,10, чтение из кэша — 0,01, запись в кэш — 0,125, выход — 0,50. Для региональной обработки предусмотрена надбавка 10%. Таблица цен API.

При входе свыше 272 000 токенов ко всему запросу применяются удвоенные ставки входа и кэша, а ставка выхода увеличивается в 1,5 раза. Batch и Flex стоят половину Standard, Fast — вдвое дороже Standard. Порог контекста и режимы обработки. Токены рассуждения оплачиваются как выходные, даже когда их нет в видимом ответе. Учёт reasoning-токенов.

Главный дополнительный расход в этом переходе может оказаться в восстановлении правил дообученной системы. Запросите отдельную оценку подготовки контрольного набора, переноса правил, доработки обработчика и проверки диспетчером. Расход API считайте по новой конфигурации: если правила теперь передаются во входе, прежний журнал токенов уже не описывает тот же запрос. Общую методику даёт учёт стоимости принятой AI-задачи.

Luna уже представлена в API; бесплатный уровень в карточке не поддерживается, лимиты различаются по платным уровням. Проверьте фактический доступ и квоту своего проекта до назначения срока испытания. Уровни доступа и ограничения.

В опубликованном списке поддерживаемых стран OpenAI API России на дату проверки нет. Русский язык статьи не означает доступность сервиса из любой страны. До работы с данными проверьте допустимость доступа организации, передачу сведений и условия хранения; обход региональных ограничений не входит в план. Поддерживаемые страны и территории.

Что должно быть готово до переключения

Назначьте внутренний срок раньше отключения с запасом на выявленные проблемы. Разделите готовность по процессам: одна обычная текстовая интеграция может перейти быстрее системы, поведение которой опиралось на дообучение.

  • Зависимость установлена. Известны действующие и резервные модели, а также задачи по расписанию, которые их вызывают.
  • Правила восстановлены. У каждого существенного решения есть источник, ожидаемый результат и ответственный за изменения.
  • Замена принята. Проверены спорные случаи, объяснены расхождения и согласован новый расход.
  • Есть рабочий путь при сбое. После 14 января нельзя рассчитывать на отключённую модель как на резерв. Подготовьте другой проверенный маршрут или очередь ручной обработки.

В общем реестре AI-агентов отметьте завершённую замену и оставшиеся зависимости. Для проекта с SABSUS согласуйте модель, данные и разрешённые действия через раздел AI-решений и API и интеграций. Готовый перенос дообученных GPT-4-моделей или включённая в тариф интеграция с Luna здесь не заявляются.

Практический вывод

Сначала найдите точную модель и восстановите проверяемые бизнес-правила, затем выбирайте способ их исполнения после отключения. Для дообученной автоматизации главным документом приёмки станет описание решений и оснований, которые новая конфигурация должна сохранять.

Разобрать зависимость интеграции

Автор: редакция SABSUS. Первоисточники проверены 14 октября 2026 года UTC. Сценарий, классификация требований и критерии приёмки являются редакционным анализом. Клиентские fine-tuning-модели, API-вызовы и перенос интеграции при подготовке материала не тестировались.