Маршрутизация запросов к ИИ превращается из технической мелочи в ключевой слой инфраструктуры. Раньше роутер просто решал, какой модели отдать запрос: дешёвой локальной или дорогой frontier. Теперь этого мало. Новая идея в том, что роутер сам может улучшать ответ модели, не меняя её веса. Он превращает один вызов API в ограниченную коллаборацию внутри serving-слоя.
Проект vLLM Semantic Router выводит эту логику в открытый слой. Пользователь по-прежнему дёргает одну модель, например vllm-sr/auto. Но внутри роутер сам выбирает «рецепт», запускает воркеров, собирает кворум, проверяет разногласия, синтезирует ответ и возвращает обычный OpenAI-совместимый результат. Сложность спрятана. Коллаборация должна ощущаться как работа одной модели.
Ядро этой системы — looper. Это рантайм для bounded-микроагентов. У него есть несколько основных алгоритмов. Confidence — последовательная эскалация: сначала пробует дешёвую модель, проверяет уверенность (по logprob, self-verification) и, если низко, отправляет запрос дальше. Ratings — параллельный запуск нескольких кандидатов с жёстким лимитом на concurrency и weighted-агрегацией. ReMoM — веерный запуск попыток, ожидание кворума, а затем синтез финального ответа с запасным fallback-планом. Fusion — превращает разногласия между независимыми моделями-панелистами в структурированные доказательства для судьи и финализатора. Workflows — самый агентный паттерн: планировщик выбирает разрешённые worker-модели, шаги ограничены бюджетом, таймаутами и политикой ошибок.
Главный вывод из тестов: нет одного лучшего цикла. Для каждого бенчмарка (GPQA-Diamond, LiveCodeBench, Humanity's Last Exam) нужен свой рецепт. Роутер определяет тип задачи, риск, контракт на ответ и подбирает алгоритм.
Результаты впечатляют. Закрытая конфигурация VSR набирает 92.6% на LiveCodeBench (против 90.3 у Opus 4.8) и 96.0% на GPQA-Diamond (против 95.5 у Fugu Ultra). Это не значит, что нужно гонять все модели на каждый запрос. Это значит, что коллаборация на уровне роутера создаёт более сильный «образ модели», чем любой отдельный вызов под капотом.
Старый serving-слой был пассивен. Новый активен. Он задаёт вопросы: достаточно ли одной модели, какой паттерн коллаборации запустить, по какому контракту собирать ответ. Это не склейка приложений. Это инфраструктура. Следующая гонка будет не только за лучшей моделью, но и за лучшим роутером, который знает, когда экономить, когда включать safety и когда собирать команду из нескольких моделей.