Сдвиг
Большую часть последних двух лет архитектура агентов определялась одним жёстким ограничением: каждый токен стоил денег, а счётчик крутился на чужой инфраструктуре. Команды реагировали рационально. Они сокращали промпты, агрессивно кэшировали и приберегали самые большие модели для шагов, которые действительно в них нуждались. Модель была дефицитным ресурсом; оркестрация была тем, что вокруг неё помещалось.
Это ограничение ослабевает. Модели с открытыми весами сократили большую часть разрыва в следовании инструкциям, использовании инструментов и структурированном выводе, а стеки для обслуживания стали достаточно эффективными, чтобы запускать их в значительных объёмах на собственном или зарезервированном оборудовании. Практическое следствие не в том, что большие хостируемые модели исчезают. Оно в том, что маржинальная стоимость токена становится параметром дизайна, который вы контролируете, а не счётом, который вы получаете.
Когда маржинальный инференс дёшев и предсказуем, интересный вопрос перестаёт быть «какая модель?» и становится «сколько раз, в каком порядке и как проверено?» Узкое место мигрирует с выбора модели на качество оркестрации и утилизацию оборудования.
Маршрутизация становится архитектурой
Первое заметное изменение в том, что маршрутизация моделей перестаёт быть решением о закупке и становится структурным. Нагрузка агента с высоким объёмом редко бывает равномерно сложной. Это длинный хвост лёгких шагов — классификация, извлечение, нормализация, переписывание запросов для поиска, валидация схемы — punctuated небольшим числом действительно сложных: многошаговое планирование, разрешение неоднозначности, синтез из противоречивых источников.
Как только вы можете запускать лёгкие шаги на небольшой самостоятельно размещённой модели, профиль затрат всей системы меняет форму. Сложные шаги по-прежнему направляются к фронтирной модели, но теперь они составляют меньшинство вызовов. Архитектура читается как политика маршрутизации: дешёвый классификатор решает, какой уровень обрабатывает каждый шаг, а дорогой уровень зарезервирован. Эта политика — код, которым вы владеете, который версионируете и тестируете, а не конечная точка вендора.
Это механизм, о котором стоит говорить конкретно. Типичный слой маршрутизации состоит из трёх частей:
- Сигнал сложности. Небольшая модель (или эвристика по длине ввода, количеству инструментов и сложности схемы) оценивает входящий шаг. Этот сигнал дёшев и несовершенен; его задача — быть консервативным в отношении эскалации.
- Карта уровней. Каждый уровень указывает на конкретное развёртывание: квантованная модель с открытыми весами на локальных GPU, хостируемая небольшая модель, хостируемая фронтирная модель. Уровни взаимозаменяемы за стабильным интерфейсом.
- Путь отката и эскалации. Когда дешёвый уровень не проходит валидацию — некорректный JSON, отсутствующая цитата, неудачный вызов инструмента — шаг повторяется на следующем уровне вверх. Эскалация — это страховка, позволяющая быть агрессивным с дешёвым уровнем.
Экономика работает только если эскалация редка и измеряется. Если треть вызовов дешёвого уровня эскалируется, вы заплатили дважды и не получили ничего. Это измерение — забота оркестрации, и именно туда теперь уходит большая часть инженерных усилий.
Что это позволяет
Дешёвый, контролируемый маржинальный инференс меняет то, какие дизайны агентов становятся доступными, а значит, какие дизайны создаются.
Более широкое ветвление. Шаг планирования, который раньше давал один план-кандидат, может дать несколько, каждый оценивается и получает балл до выбора. Сэмплирование нескольких путей рассуждения и выбор лучшего — хорошо понятный способ повысить надёжность, но он умножает инференс. Когда множитель — это контролируемая локальная стоимость, а не счёт за вызов, ветвление становится значением по умолчанию, а не роскошью.
Больше проходов верификации. Верификация — это часть дизайна агента, которая окупается и которую легче всего сократить под давлением затрат. Дешёвая модель-верификатор, которая перечитывает каждый вызов инструмента, проверяет каждое извлечённое поле по его исходному фрагменту и отклоняет неподтверждённые утверждения, может работать на каждом шаге, а не на выборке. Верификатору не нужно быть блестящим; ему нужно быть последовательным и достаточно дешёвым, чтобы работать всегда.
Непрерывная оценка. Возможно, самое значимое изменение — в стенде оценки. Когда инференс — это статья расходов, которой вы владеете, набор eval — не ночная пакетная задача, конкурирующая за бюджет. Это сервис, который работает непрерывно при каждом изменении промпта, политики маршрутизации и версии модели. Обнаружение регрессий переходит с «следующего утра» на «следующий коммит». Поведенческий дрейф в квантованной модели или перенастроенном маршрутизаторе всплывает, пока изменение ещё на ревью.
Ничто из этого не новые техники. Все они были известны и все нормировались. Сдвиг в том, что ограничение нормирования переместилось.
Чего это стоит
Владение инференсом обменивает переменный счёт на фиксированное операционное бремя, и бремя немаленькое.
Планирование мощностей. Хостируемая конечная точка поглощает всплески. Самостоятельное развёртывание — нет. Вам нужно знать пиковое число одновременных шагов, токенов в секунду на реплику и сколько запаса оставить для прогонов оценки, которые теперь конкурируют с продакшн-трафиком. Недооцените — и задержка деградирует именно тогда, когда агент наиболее загружен; переоцените — и преимущество в стоимости испарится в простаивающих GPU. Это задача прогнозирования с реальными последствиями, и она не исчезает.
Выбор квантования. Запуск модели с открытыми весами при пониженной точности обычно необходим, чтобы уместить полезную пропускную способность на доступном оборудовании. Каждый уровень квантования — это другая модель с другим поведением: структурированный вывод может деградировать раньше свободного текста, а召回 на длинном контексте часто деградирует первым. Выбор — не деталь развёртывания; это поведенческое изменение, которое нужно оценивать как любое другое.
Фиксация версий. Хостируемые фронтирные модели меняются под вами, что само по себе проблема, но по крайней мере изменение единообразно. Самостоятельный флот фиксирует точные веса, точные версии стека обслуживания и точные артефакты квантования. Это даёт воспроизводимость и даёт обязательство по обслуживанию: патчи безопасности, обновления драйверов и дисциплину относиться к обновлению весов как к релизу с собственным прогоном оценки.
Гетерогенные флоты усложняют оценку. Это честный компромисс в центре тезиса. Когда поведение различается по маршруту, единый агрегированный балл оценки вводит в заблуждение. Изменение промпта, улучшающее фронтирный уровень, может незаметно ухудшить дешёвый уровень, а агрегат может не сдвинуться. Оценка должна быть нарезана по маршрутам, а метрики уровня маршрута должны отслеживаться во времени. Стенд усложняется именно потому, что архитектура стала более способной.
Есть ещё одна стоимость, которую легко недооценить: сама политика маршрутизации становится компонентом с режимами отказа. Неправильно настроенный сигнал сложности отправляет сложные шаги на дешёвый уровень, где они не проходят валидацию и эскалируются — или, что хуже, не проходят валидацию и принимаются. Маршрутизатору нужны собственные тесты, собственные метрики (частота эскалации, частота принятия на дешёвом уровне, стоимость на завершённую задачу) и собственный процесс ревью.
Ограничение перемещается
Сдвиг открытых весов часто подают как историю о затратах, и это так. Но устойчивое изменение — архитектурное. Когда инференс был дорогим и внешним, модель была ограничением, а оркестрация — сантехникой. Когда инференс дёшев и принадлежит вам, модель — компонент, а оркестрация — ограничение.
Это переопределяет, куда должны идти инженерные усилия. Они идут в политики маршрутизации, которые измеряются, а не предполагаются. Они идут в верификацию, которая работает на каждом шаге, потому что может. Они идут в стенды оценки, достаточно быстрые для непрерывного запуска и достаточно гранулярные, чтобы ловить регрессии конкретных маршрутов. Они идут в модели мощностей, которые поддерживают высокую утилизацию, не истощая продакшн.
Ничто из этого не бесплатно. Это другой счёт, оплачиваемый операционным вниманием, а не расходом за токен, и его стоит платить только когда объём достаточно высок, чтобы маржинальная стоимость действительно имела значение. Для агентов с низким объёмом хостируемая конечная точка остаётся правильным ответом. Ошибка — предполагать, что хостируемый ответ остаётся правильным по мере роста объёма, и обнаружить проблему маршрутизации только после того, как архитектура затвердела вокруг одного уровня.
Команды, которые больше всего выигрывают от экономики открытых весов, — не те, у кого самые большие GPU. Это те, чья оркестрация уже была достаточно хороша, чтобы использовать дешёвый инференс, и кто относился к маршрутизации, верификации и оценке как к первоклассной инженерии, а не как к конфигурации.