Резервная модель (fallback model)

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