Главная/Блог/Аналитика/vLLM Semantic Router: Эра микро-агентов…
Аналитика11 мин чтения · 2 июля 2026 г.

vLLM Semantic Router: Эра микро-агентов в слое инференса

Как vLLM Semantic Router превращает роутер из простого переключателя моделей в активный слой оркестрации, объединяя микро-агентов для создания «супер-модели» поверх API.

vLLM Semantic Router: Эра микро-агентов в слое инференса

В индустрии искусственного интеллекта мы привыкли смотреть на горизонт, ожидая появления следующей «frontier» модели. Каждый новый чекпоинт от OpenAI, Google или Anthropic встречает волну хайпа, обещающую прорыв в рассуждениях и креативности. Однако, пока все глаза прикованы к самим моделям, более интересный и трансформирующий слой находится прямо перед ними. Это слой роутинга. Роутеры эволюционируют из простых диспетчеров запросов в центральную нервную систему (control plane) для инференса ИИ. Их роль больше не ограничивается тем, чтобы просто направить запрос в нужное место. В эпоху, когда производство ИИ перестало быть миром одной модели, роутер становится архитектором интеллекта.

Исторически первая задача роутера была сугубо практической: маршрутизировать правильный запрос к правильной модели. Это уже имеет огромное значение. Роутер может существенно сократить затраты, решая, когда запрос заслуживает использования дорогой frontier-модели, а когда достаточно открытой или локальной модели. Он может сделать политику безопасности исполняемой, отправляя чувствительные домены к более строгим моделям или фильтрам. Он может координировать облако и edge-устройства, сохраняя приватные или требующие низкой задержки данные локально, и эскалировать сложные задачи в облако. Но это лишь начало. Следующая, более захватывающая роль роутера — делать саму модель лучше. Не за счет изменения весов, а за счет превращения одного вызова API в ограниченную, но эффективную коллаборацию внутри слоя обслуживания.

01От выбора модели к конструированию способностей

Идея о том, что «модель» может быть лишь поверхностью, за которой скрывается команда, стала популярной благодаря продукту Sakana Fugu. Они коммерциализировали простую, но мощную концепцию: пользователь взаимодействует с единым интерфейсом, а внутри работает слаженная группа специалистов. Исследования в этой области, включая технические отчеты по Fugu и координационные работы, такие как Conductor и Trinity, дают нам полезный язык для размышлений об оркестрации. Однако видение vLLM Semantic Router отличается тем, где оно помещает эту абстракцию. Коллаборация не должна жить только внутри одного коммерческого эндпоинта или специфического для приложения графа агентов. Она должна стать открытым примитивом слоя обслуживания (serving layer).

vLLM Semantic Router внедряет эту идею в открытый слой обслуживания. Для пользователя вызов остается неизменным и привычным — это стандартный вызов chat completion к модели vllm-sr/auto. Но за этим стабильным именем модели роутер выбирает рецепт (recipe), рассылает запросы рабочим узлам, собирает кворум, проверяет расхождения, синтезирует окончательный ответ, восстанавливает контракт вывода и возвращает нормальный ответ, совместимый с OpenAI. Точка не в том, чтобы обнажить сложность. Точка в том, чтобы сделать коллаборацию ощущающейся как одна модель.

02Looper: среда выполнения для микро-агентов

В архитектуре vLLM Semantic Router ключевую роль играет компонент под названием Looper. Это среда выполнения (runtime) для ограниченных микро-агентов. Запрос входит в роутер как обычное завершение чата. Роутер извлекает сигналы, проецирует их в форму задачи или диапазоны риска, сопоставляет решение и выбирает алгоритм. Этот алгоритм может быть обычным одно-модельным маршрутом, а может быть маршрутом Looper.

Алгоритмы Looper работают внутри роутера, сохраняя единый интерфейс модели для пользователя.
Алгоритмы Looper работают внутри роутера, сохраняя единый интерфейс модели для пользователя.

На данный момент основными паттернами Looper являются:

  • Confidence (Уверенность): последовательная петля эскалации. Сначала пробует более дешевый кандидат, измеряет уверенность и эскалирует только при низком балле.
  • Ratings (Оценки): ограниченная петля fan-out. Запускает несколько кандидатов параллельно с жестким лимитом параллелизма и агрегирует их с учетом весов оценок.
  • ReMoM (Repeated Mixture-of-Model Reasoning): повторное смешивание рассуждений моделей. Рассылает образцы по ширине, ждет достаточного количества успешных ответов и запускает финальный раунд синтеза.
  • Fusion (Слияние): паттерн «панель судей — финализатор». Независимые ответы моделей становятся доказательствами для судьи, который выносит вердикт.
  • Workflows (Рабочие процессы): среда выполнения микро-агентных рабочих процессов. Поддерживает статические роли или динамического планировщика, выполняет ограниченные шаги рабочих и синтезирует финальный ответ.

Важно понимать детали реализации. Looper — это не просто лозунг «спроси больше моделей». Это небольшая среда выполнения с бюджетом, топологией, трассировкой и политикой обработки ошибок. Это инфраструктурный уровень, а не прикладная логика.

03Разбор алгоритмов Looper

Confidence: эскалация только для сложных случаев

Confidence — это цикл, чувствительный к затратам. Он начинается с более маленькой или дешевой кандидатуры, а затем оценивает, достаточно ли уверен ответ, чтобы остановиться. Сигнал уверенности может поступать из логарифмических вероятностей токенов (logprob), маржи logprob, гибридного балла, самопроверки или верификатора Entailment в стиле AutoMix. Если балл проходит порог, роутер немедленно возвращает ответ. Если балл слишком низок, маршрут эскалирует к следующему кандидату. Важная часть здесь не в том, что эскалация существует, а в том, что эскалация становится явной политикой роутера: пороги, поведение при сбое и условия остановки видны и настраиваемы.

Confidence превращает эскалацию в измеренную политику остановки на основе уверенности.
Confidence превращает эскалацию в измеренную политику остановки на основе уверенности.

Ratings: параллельное качество под жестким лимитом

Ratings — это контролируемый цикл ансамбля. Он запускает несколько кандидатов параллельно, но только до настроенного предела max_concurrent. Это делает его полезным, когда маршрут должен извлекать выгоду из нескольких точек зрения моделей, не превращая каждый запрос в неконтролируемый fan-out. Роутер собирает успешные ответы, применяет агрегацию, учитывающую рейтинги, и обрабатывает сбои в соответствии с политикой маршрута. На практике Ratings отлично подходит для A/B-тестирования, стратегий ансамбля и маршрутов, где оператор уже имеет значимые сигналы качества для каждого кандидата.

Ratings обеспечивает выполнение нескольких кандидатов в пределах жестких ограничений и с учетом рейтингов.
Ratings обеспечивает выполнение нескольких кандидатов в пределах жестких ограничений и с учетом рейтингов.

ReMoM: широта с контрактом

ReMoM полезен, когда задача имеет высокую вариативность рассуждений, а формат ответа должен выжить в процессе коллаборации. Он рассылает несколько попыток рассуждения, ждет минимального кворума успешных ответов, а затем просит модель синтеза объединить доказательства в требуемый контракт вывода. Если синтез терпит неудачу, но предыдущие рабочие узлы произвели действительные доказательства, маршрут не обязан завершаться ошибкой API. Он может откатиться к лучшему действительному доказательству и все равно вернуть нормальный ответ.

ReMoM управляет широтой, кворумом, синтезом и откатом как элементами обслуживания.
ReMoM управляет широтой, кворумом, синтезом и откатом как элементами обслуживания.

Fusion: несогласие как сигнал

Fusion исходит из другой гипотезы. Иногда полезным объектом является не средний ответ, а структура несогласия. Независимые ответы панели становятся доказательствами. Судья видит согласие, противоречия и уникальные идеи, а финализатор возвращает один ответ, сворачивая трассу за пределами API. Это делает Fusion особенно полезным, когда есть правдоподобные конкурирующие пути: сложные задачи с множественным выбором, экспертные сужения длинного формата или задачи с точным ответом, где один уверенный ответ может быть хрупким.

Fusion не скрывает несогласие, а превращает его в доказательство для финального решения.
Fusion не скрывает несогласие, а превращает его в доказательство для финального решения.

Workflows: роли под бюджетом

Workflows — это самый «агентный» паттерн, и тот, который требует самых строгих границ. Планировщик может выбирать только разрешенные модели-работники. План валидируется. Шаги ограничены максимальным количеством шагов, максимальным параллелизмом, таймаутами и политикой ошибок. Финальный ответ все еще должен удовлетворять контракту вывода. Для задач в стиле SWE (Software Engineering) это означает, что роутер может выразить планировщика, патчера, верификатора и финализатора, не заставляя приложение владеть собственным стеком агентов. Для производства это критическое различие: цикл мощен, но он все еще управляется инфраструктурой.

Workflows предоставляет роутеру ограниченную систему ролей, а не неконтролируемого автономного агента.
Workflows предоставляет роутеру ограниченную систему ролей, а не неконтролируемого автономного агента.

04Auto Recipes: одна модель, много циклов

Публичная поверхность остается единым именем модели: vllm-sr/auto. Внутренне роутер может использовать сигналы и проекции для выбора правильного цикла для запроса. Сложность, риск, давление контракта, задержка и стоимость — это не комментарии в промпте. Это факты маршрутизации, которые могут выбрать Confidence, Ratings, ReMoM, Fusion, Workflows или путь отката. Это разница между «агент как логика приложения» и «микро-агент как среда выполнения обслуживания». Роутер контролирует бюджет, политику, топологию, трассу и режим отказа.

Auto Recipes позволяют сигналам выбирать шаблон коллаборации, сохраняя одно имя модели.
Auto Recipes позволяют сигналам выбирать шаблон коллаборации, сохраняя одно имя модели.

05Рецепты побеждают один универсальный цикл

Самый важный урок из нашей работы по оценке (evals) заключается не в том, что один алгоритм всегда выигрывает. Наоборот: лучший цикл зависит от формы задачи. GPQA-Diamond требует строгого сохранения ответов с множественным выбором. LiveCodeBench хочет исполняемый код и устойчивость к скрытым тестам. Humanity's Last Exam требует разрешения несогласий и точного форматирования ответов. Задачи в стиле SWE требуют планировщика, патчера, верификатора и финализатора.

Именно поэтому vllm-sr/auto не должен означать «всегда запускать самый большой цикл». Он должен означать: выбрать рецепт, который подходит этой задаче. В наших рецептах эта форма явна: GPQA-Diamond маршрутизирует сложные научные промпты с множественным выбором в рецепт ReMoM со строгим сохранением формата ANSWER: X. LiveCodeBench ищет ограничения, стартовый код, стандартный ввод, риск таймаута и риск скрытых тестов перед выбором цикла, ориентированного на код. HLE обнаруживает формальное рассуждение, риск несогласия, длинный контекст и давление точного ответа перед выбором между более глубоким ReMoM, меньшим Fusion или путем отката.

Сигналы и проекции позволяют роутеру выбирать шаблон коллаборации, соответствующий бенчмарку.
Сигналы и проекции позволяют роутеру выбирать шаблон коллаборации, соответствующий бенчмарку.

Это то, почему коллаборация на стороне роутера — это больше, чем промпт-инжиниринг. Промпт — лишь часть. Рецепт также определяет пул моделей, роли моделей, усилия рассуждения, параллелизм, кворум, таймаут, модель синтеза, политику отката, контракт вывода и метки наблюдаемости.

06Карточка оценок: доказательство, а не вся история

Мы оценили текущий рецепт с закрытыми моделями на трех сложных бенчмарках. Цифры полезны, потому что они показывают, что идея не только эстетична. В нашей карточке оценок VSR Closed означает, что рецепт использует только бэкенды закрытых моделей. VSR Hybrid означает, что рецепт смешивает открытые и закрытые модели, используя более сильные закрытые модели там, где рецепт требует более высокого риска для суждения, ремонта, синтеза или отката.

Карточка оценок VSR демонстрирует превосходство или соответствие frontier-моделям на сложных тестах.
Карточка оценок VSR демонстрирует превосходство или соответствие frontier-моделям на сложных тестах.

Результаты впечатляют:

  • LiveCodeBench (Jan-Apr 2025): VSR Closed набрал 92.6, превзойдя Fugu Ultra (92.0), GPT-5.5 (90.7) и Opus 4.8 (90.3).
  • GPQA-Diamond: VSR Closed набрал 96.0, превзойдя Fugu Ultra (95.5), Gemini 3.1 Pro (94.3) и GPT-5.5 (93.6).
  • Humanity's Last Exam: VSR Closed набрал 50.0, сравнявшись с Fugu Ultra (50.0) и превзойдя Gemini 3.1 Pro (45.0). VSR Hybrid набрал 47.1, что также выше многих открытых моделей, таких как GLM-5.2 (40.5) и Qwen3.7 Max (41.4).

Карточку оценок следует читать внимательно. Это не утверждение, что каждый запрос всегда должен использовать каждую закрытую модель. Это было бы неправильным продуктом. Утверждение в том, что коллаборация, управляемая роутером, может создать более сильную идентичность модели, чем отдельные вызовы под ней. Она может превосходить или соответствовать базовым линиям frontier-моделей, сохраняя одну поверхность API.

💡
Совет для практиков. Не пытайтесь заменить все вызовы одной сложной цепочкой. Используйте vllm-sr/auto как точку входа, но настраивайте рецепты под конкретные задачи. Для простых вопросов используйте Confidence, для кода — Ratings или специализированные циклы, для сложных рассуждений — ReMoM или Fusion.

07Что это значит на практике

Старый стек обслуживания был пассивным. Он принимал имя модели и отправлял запрос на бэкенд. Следующий стек обслуживания активен. Он задает вопросы: какие доказательства у нас есть об этом запросе? В какой диапазон качества, стоимости, задержки и безопасности он попадает? Достаточно ли одной модели? Если нет, какой паттерн коллаборации должен запуститься? Какой контракт ответа должен быть сохранен? Что произойдет, если один провайдер медленный или ошибается? Как мы можем предоставить один чистый ответ, сохраняя полную трассу?

Это не прикладной клей. Это инфраструктура. Микро-агенты принадлежат роутеру, потому что роутер уже владеет тем, что нужно микро-агентам: псевдонимами моделей, политикой провайдеров, учетными данными, метаданными стоимости, сигналами, решениями, повторными попытками, таймаутами, трассами и семантикой ответов, совместимых с OpenAI.

Фраза «frontier model» начинает означать две вещи. Одна — это чекпоинт. Другая — это граница системы. Волна оркестрации сделала направление видимым. vLLM Semantic Router — это ставка на то, что эта способность должна быть программируемой, наблюдаемой и открытой на уровне обслуживания. Гонка за лучшие модели все еще будет включать лучшие модели. Но она также будет включать лучшие роутеры: роутеры, которые знают, когда сэкономить деньги, когда обеспечить безопасность, когда остаться на edge, когда пойти в облако и когда превратить один запрос в маленькую, дисциплинированную команду. Это и есть обещание микро-агентов внутри Model API.

⚠️
Важно. При внедрении в российских реалиях обратите внимание на доступность закрытых моделей. Гибридные рецепты (VSR Hybrid) позволяют использовать локальные открытые модели для черновой работы и эскалировать только критические этапы (например, финальное суждение) к доступным облачным API, если они доступны, или к более мощным локальным моделям, если облако недоступно. Это снижает зависимость от внешних сервисов.
📌
Факт. Архитектура vLLM Semantic Router позволяет запускать микро-агентов локально на GPU, если вы используете открытые модели в качестве рабочих узлов. Это обеспечивает полную конфиденциальность данных на этапе обработки, так как трассировка и промежуточные данные не покидают ваш сервер, если это не требуется политикой маршрута.

08Заключение

Будущее ИИ-инференса лежит не только в увеличении параметров моделей, но и в интеллектуальном управлении ими. vLLM Semantic Router предлагает путь к созданию «супер-моделей» из набора обычных моделей, делая процесс прозрачным, управляемым и экономически эффективным. Для разработчиков и операторов это означает переход от управления отдельными вызовами к управлению стратегиями коллаборации, что в конечном итоге приводит к более надежным и качественным результатам при оптимизированных затратах.

Источник: оригинал ↗