Повторяющаяся стоимость ИИ в продакшене — не инференс. Это переквалификация: перезапуск оценок, перенастройка промптов и регрессионное тестирование, которые вы должны каждый раз, когда модель меняется под вами. Письмо пришло во вторник. Модель, которую мы запускали в продакшене почти год, намеренно закреплённую на конкретной версии, объявляли устаревшей. У нас было окно для миграции. После этого эндпоинт начал бы возвращать ошибки. Мы сделали всё, что говорит делать свод правил осторожной инженерии. Мы не плавали на последнем алиасе, который мог измениться под нами за ночь. Мы закрепили точную версию модели, записали её в конфиг и обращались с ней как с любой другой зависимостью, которую мы не хотели бы двигать без проверки. Закрепление должно было быть безопасным выбором. Уведомление об устаревании сделало ясным то, что закрепление тихо скрывало: закрепление версии модели не покупает вам иммунитет к изменениям. Оно покупает вам отсрочку. Земля всё равно движется. Вы просто выбираете вторник. Это различие — самая недофинансированная стоимость в продакшен-ИИ. Команды моделируют свои расходы на ИИ как инференс: токены на входе, токены на выходе, умноженные на цену. Они оптимизируют выбор модели, оптимизируют длину промпта, спорят, достаточно ли хороша более дешёвая модель. Почти ни у кого нет строки в бюджете на тот день, когда модель меняется и всю систему приходится заново доказывать корректной. Я назову эту строку налогом на переквалификацию, и к концу этой статьи я хочу, чтобы у вас было и название для него, и способ планировать вокруг него. От чего закрепление действительно защищает, а от чего нет Закрепление версии модели — действительно хорошая практика. Оно останавливает тихий дрейф поведения, когда провайдер обновляет веса за алиасом, и ваши выходные данные меняются без единой изменённой строки вашего кода. Если вы когда-нибудь видели, как оценка сдвигается без причины, которую вы могли бы найти в своих собственных коммитах, вы уже знаете, почему команды закрепляют. Но закрепление — это замок на вашей стороне двери, которую контролирует и провайдер. Провайдеры объявляют устаревание. В 2026 году темп, если что, ускорился: новые фронтирные модели выходят каждые несколько месяцев, старые уходят на закат, и несколько провайдеров вывели модели из эксплуатации с коротким уведомлением. Большинство команд всё равно не запускают одну модель. Текущая реальность, подтверждённая инженерными опросами в течение года, такова, что продакшен-стеки держат несколько моделей в полёте одновременно: фронтирную модель для сложных рассуждений, более дешёвую модель для рутинных вызовов, иногда самостоятельно размещённую модель для данных, которые не могут покинуть здание. Каждая из них на своих собственных часах устаревания. Так что закрепление не устраняет изменение. Оно превращает непредсказуемое изменение в запланированное. Это реальное улучшение, потому что запланированное изменение — это то, на что можно выделить персонал и бюджет. Это катастрофа только тогда, когда вы относились к закреплению как к постоянству и не заложили ничего в план на день его истечения. То, что все забывают оценить: модель — не единственное, что меняется Вот часть, которая делает переквалификацию дорогой, а не тривиальной. Когда вы переходите с одной версии модели на следующую, модель — не взаимозаменяемая деталь. Почти всё, что вы построили поверх старой модели, было, хотели вы того или нет, настроено на конкретное поведение этой модели. Ваши промпты были настроены на неё. Формулировка, которая надёжно давала структурированный вывод на старой модели, может дать нечто тонко иное на новой. Ваши примеры с несколькими выстрелами были откалиброваны под её причуды. Ваши ограждения были настроены против её режимов отказа. Ваши парсеры вывода были укреплены против конкретных форм, которые она склонна была возвращать. Ваша температура и y...