Хотел. Приложение, которое разбирает мои банковские выписки, обязано ходить только в локальную модель на узле. Правило записано в его собственных инструкциях и выполнено его кодом. Я считал вопрос закрытым.
Споткнулся. Шлюз моделей не знает класса входа и знать не может: у него есть только имя роли. А у роли, которой ходило приложение, в настройках стоял безусловный переход — занят локальный рантайм, уходим в облако. Я пошёл в журнал шлюза за 72 часа: 12 строк «Trying to fallback» и 6 попыток дойти до облачной модели. Ни одна не дошла до провайдера. Каждая упала внутри библиотеки на UnsupportedParamsError: frontier-модель не принимает temperature 0.2, а параметры проверяются до HTTP-запроса. Выписки удержала на узле несовместимость параметра, а не политика. Уберут temperature из запроса — и тот же путь уедет в облако без единой правки настроек.
Ключ клиента запрет тоже не выражал. Список моделей ключа шлюз сверяет в аутентификации, а запасную модель роутер выбирает после неё: запрос, пришедший на роль с переходом, уедет в облако и с ключом, которому облако не выписано.
Решил. Отдельная роль — та же модель, тот же рантайм, и ни одной записи в таблице переходов. Нет записи — роутеру нечего выбрать, и отказ рантайма остаётся отказом. Ограничение выражено тем же механизмом, которым выражена вся маршрутизация шлюза, и видно в diff'е настройки. Ключ остаётся вторым рубежом: ключ отвечает за «чего этому клиенту не выписано», роль — за «куда этот запрос не уйдёт».
Чем плачу. Доступностью. Локальный рантайм лёг — приложение получает 5xx и повторяет позже, а не отвечает хуже. Две роли теперь показывают одну и ту же модель на одном рантайме, и это дублирование придётся держать согласованным руками: расходятся они ровно одним свойством. И мастер-ключ шлюза пришлось перевыпустить — он был скопирован в чужой репозиторий и печатался в вывод инструментов, то есть считается скомпрометированным.
#отказ