Как мигрировать после снятия модели: сохраните prompt и базу приёмки задач

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

Материал относится к общим API-шлюзам и клиентам. Он не оценивает надёжность какого-либо relay-сервиса и не превращает бренды, модели или слово «рекомендация» из поискового отчёта в факты. Каталоги моделей и страницы deprecation со временем меняются; здесь проверена структура официальных источников, а конкретный переход нужно сверять с объявлением поставщика, вашим аккаунтом и выбранной версией. Примеры используют локальные имитированные ответы и не вызывают платный API.

1. Определите: это удаление, переименование, права или замена маршрута

Сообщение «модель нельзя вызвать» может быть следствием четырёх разных событий. Сначала сохраните время ошибки, точный ID модели, путь запроса, HTTP-статус, тело ответа, группу канала и версию клиента. Затем сравните одинаковый запрос до и после изменения. Не заменяйте ID на приблизительное имя из поисковой выдачи только потому, что получили 404.

Наблюдение	Более вероятная причина	Первое доказательство	Чего нельзя сразу заключать
ID сообщает, что модель не существует или устарела	Upstream удалил модель, завершил версию или шлюз хранит старый ID	Официальная информация о жизненном цикле, исходная ошибка шлюза	Новый ID полностью эквивалентен старому
В списке модели нет, но существующий запрос ещё проходит	Кеш списка, псевдоним или различия прав канала	Список и реальный запрос одного ключа с временными метками	Отсутствие в списке означает немедленное удаление
В одной группе ID работает, в другой запрещён	Изменились группа, аккаунт или региональные права	Связка группы, ключа и ответа upstream в журнале	Поставщик удалил модель вообще
Запрос успешен, но изменились ответ, инструмент или JSON	Перешли на замену, изменились значения по умолчанию или адаптер переписал запрос	Поле модели в ответе, маршрут шлюза и структурные проверки	Виноваты только температура или prompt

Сначала изучите официальную страницу моделей upstream, уведомления об удалении и журнал изменений собственно шлюза. В официальных источниках OpenAI это Models, а у Anthropic — Models overview и план прекращения поддержки Model deprecations. Они могут подтвердить публичный ID, жизненный цикл или рекомендацию по миграции, но не доказывают, что ваш relay-аккаунт, псевдоним или квота уже синхронизированы.

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

2. Зафиксируйте воспроизводимую базовую линию старой версии

До миграции сохраните входные данные старой задачи, ключевые параметры и приемлемый результат. Одного ответа на «привет» недостаточно: он не обнаружит потерю параметров инструмента, обрезание длинного контекста, дрейф структурированного вывода или изменение границ безопасности.

Для каждой реальной задачи создайте запись базовой линии:

1. Запишите версии клиента, SDK, шлюза, канала и ID модели; для образа сохраните digest, чтобы latest не изменился между проверками.
2. Храните обезличенный шаблон prompt, системные инструкции, примеры переменных и условия остановки. Секреты, персональные данные и полный рабочий текст нельзя класть в репозиторий.
3. Определите проверки для текста, JSON, инструментов и ошибок. Фиксируйте имена и типы полей, допустимые значения, причину завершения и обязательные аргументы инструмента, а не только сходство строк.
4. Опишите меру стоимости и задержки: время до первого фрагмента, общую длительность, входной и выходной расход, число повторов и отдельную проверку, списывается ли ошибка. Без счёта нельзя выводить списание из HTTP-статуса.
5. Оставьте небольшой разрешённый набор репрезентативных примеров с ожидаемым поведением, недопустимым поведением и точками ручной проверки. Набор нужен для сравнения до и после, а не для рейтинга моделей.

Сохраните результаты как версионированный JSON, например baseline-2026-10-23.json, вместе с хэшем и временем сбора. Если изменились prompt или схема инструмента, создайте новую базовую линию, а не приписывайте разницу модели. В контрольном списке автоматического отката модели описаны признаки скрытого перехода на запасной маршрут; при миграции такой маршрут нужно исключить или явно записывать.

3. Выберите замену и задайте явное сопоставление

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

Удобно вести таблицу сопоставления:

Старый ID	Новый ID	Область действия	Что обязательно повторить	Условие отката
legacy-model	replacement-model	Только тестовая группа	Формат, инструменты, длинный контекст, расходы	Провал любого жёсткого требования
Старый псевдоним	Зафиксированный ID версии	Новые production-запросы	Разбор псевдонима, права и реальный ID в журнале	Невозможно подтвердить реальный ID
Старый ID канала A	Новый ID канала B	Один tenant или application	Авторизацию, регион, единицы учёта и ошибки	Нет полей для счёта или аудита

Храните сопоставление в конфигурации, а не в нескольких клиентах. В журнале каждого запроса оставляйте обезличенные ID клиента и шлюза, фактически отправленный ID, канал и номер попытки. Если шлюз делает автоматический fallback, вызывающая сторона должна знать о переходе; успешный статус не должен скрывать замену. Потерянные адаптером параметры проверяйте по методике диагностики проигнорированных параметров API, а не компенсируйте случайными изменениями prompt.

Не переносите автоматически старые ключи, баланс или историю в новый сервис. Активы аккаунта и конфигурация — отдельная задача; см. чеклист миграции между поставщиками. Он не подтверждает совместимость ID, единиц тарификации или прав нового канала.

4. Проведите изолированную приёмку на уровне задачи

Создайте отдельную тестовую группу, тестовый ключ и локальный upstream-имитатор. Имитатор должен возвращать фиксированные обычные, потоковые, инструментальные, структурированные ошибки и тайм-ауты. Так проверяется конечный автомат клиента и шлюза, но не качество реальной модели, квота upstream или счёт поставщика. Для этой статьи не устанавливаются production-зависимости и не выполняются платные API-вызовы.

Матрица приёмки должна включать минимум следующее:

Задача	Проверка локально	Условие успеха
Обычный текст	Фиксированный вход и сравнение обязательных полей и причины завершения	Структура, кодировка и классификация ошибок остаются обрабатываемыми
Поток	Имитировать фрагменты, задержку, обрыв и повтор	Половинный ответ не считается успехом и не склеивается дважды
Инструмент	Имитировать выбор, проверку аргументов и результат	Имя, типы аргументов и порядок вызовов разбираются
Структурированный вывод	Вернуть корректный и намеренно сломанный JSON	Ошибка проверки попадает в явную ветку, без тихого исправления
Длинная задача	Обезличенный пример на границе контекста и тайм-аута	Обрезание, тайм-аут и повтор наблюдаемы и обратимы
Права и счёт	Ограниченный тестовый ключ и фиксированный имитированный расход	Запрещённая модель отклоняется, попытки связываются в журнале

Для каждой строки сохраните результат старой и новой модели, хэш запроса, фактический ID, время и ошибку. Сходство полного текста — только вспомогательный сигнал. Типы JSON, аргументы инструментов, обязательные источники и корректное защитное отклонение проверяйте отдельными утверждениями. При различии сначала отделите prompt, преобразование шлюза, псевдоним, параметры генерации и саму модель; не объясняйте всё финальным текстом.

5. Выполните постепенный переход, откат и наблюдение после релиза

После изолированной проверки включите сопоставление на небольшом объёме. Делите поток по application, tenant или заранее определённой доле и записывайте поля наблюдения из базовой линии. Не копируйте один оплачиваемый production-запрос в две линии без явного разрешения. Следите за долей ошибок, провалом структурных проверок, успешностью инструментов, повторами, P95 задержки, входным и выходным расходом и списаниями по фактическому ID модели.

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

После выпуска сверяйте счёт и журнал: связывайте число попыток с request ID, проверяйте повторные и ошибочные запросы, кеш и единицы учёта. Убедитесь, что серый трафик не попал в чужой аккаунт. После окончания окна наблюдения запишите конечный ID, версию prompt, результат приёмки, известные различия и дату следующей проверки. Тогда следующее удаление модели начнётся с воспроизводимой базы задач, а не с догадки по одному успешному приветствию.

Источники

• OpenAI Models: вход в официальный каталог моделей; фактическая доступность зависит от аккаунта и ответа API.
• Anthropic Models overview: официальный обзор возможностей и версий.
• Anthropic Model deprecations: официальные уведомления о прекращении и миграции.