TokenRouter ускоряет маршрутизацию LLM по токенам в 2–64 раза против обычного сервинга

Одна LLM на все задачи — компромисс. Для расчёта гармоник или разбора спецификации нужна модель, уверенная в формулах и таблицах, а для болтовни хватит универсальной. В проде такое давно решают маршрутизацией: на уровне сессии или запроса система выбирает, какую модель позвать. Исследователи считают, что выигрыш будет заметнее, если маршрутизировать не запросы, а отдельные токены. Проблема в том, что обычные серверы инференса для этого не рассчитаны. Команда TokenRouter предложила систему, которая это исправляет.

Зачем маршрутизировать токены

Представьте, что маленькая модель пишет ответ. Пока всё тривиально, она справляется сама и стоит копейки. На сложном месте ей не хватает уверенности, и к работе подключается большая модель. Так можно сдвинуть границу «стоимость–качество»: платить за большую модель только там, где она нужна.

В статье есть пример роутера R-Stitch. После каждого шага декодирования он считает энтропию распределения следующего токена. Если энтропия выше порога (в экспериментах τ = 0,03), токен считается неуверенным, он отбрасывается, а большая модель перегенерирует его. Остальные токены остаются у малой модели.

На бумаге это красиво. На практике запрос постоянно прыгает между моделями, и сервер начинает буксовать.

Где ломаются обычные серверы

Авторы называют три проблемы.

• Десинхронизация шагов. Модели считают шаг за разное время. В синхронном батче все ждут самую медленную, а быстрые простаивают.
• Задержка допуска в батч. Запрос приходит к целевой модели, когда она занята предыдущим батчем, и ждёт следующего. В расписании появляются дыры, батчи дробятся на мелкие.
• Сложность реализации. В готовых движках нет интерфейса для решения «куда дальше» на каждом шаге. Приходится переписывать много кода и согласовывать его с непрерывным батчингом и кэшем префиксов.

Отдельная беда: в обычном сервере токен, вернувшийся от другой модели, считается новым запросом. Это даёт лишние расходы на сопоставление префиксов и обновление KV-кэша.

Как устроен TokenRouter

Принцип авторов: программируем с точки зрения запроса, исполняем с точки зрения модели. Для клиента система выглядит как обычный сервер с одной LLM. Внутри на каждую модель запускается свой субсервер со своим планировщиком и приватным пулом KV-кэша. Субсерверы работают асинхронно и обмениваются peer-запросами.

Разработчик пишет алгоритм через три функции:

• route(result) вызывается после каждого шага и по логитам, скрытым состояниям и сэмплированным токенам решает, остаться локально или передать запрос другой модели;
• send(req) формирует сообщение для другой модели: ID запроса, суффикс токенов, которых она ещё не видела, статус и поля, специфичные для алгоритма;
• receive(peer_req) превращает сообщение в локальный запрос. По умолчанию он просто принимает все переданные токены, и переопределять его нужно редко.

Для задержки допуска есть планировщик с отложенным батчингом: он ждёт, пока в буфере наберётся B запросов, и только потом запускает шаг. Порог B подбирается аналитически: авторы моделируют маршрутизацию цепью Маркова с учётом конкурентности, вероятности маршрутизации и времени шага каждой модели. Слишком малый B дробит батчи, слишком большой держит запросы в очереди.

Что показали эксперименты

Проверяли пять алгоритмов: CITER, R2R, R-Stitch, Co-LLM и ME. Четыре работают с парой Qwen3-0.6B и Qwen3-32B, ME — с тремя моделями (0.6B, 8B, 32B). Железо — сервер с 8×A100-80G. Нагрузки три: короткое рассуждение (AIME2024, выход до 2048 токенов), длинное рассуждение (выход до 8192) и агентные задачи на траекториях SWE-Smith.

Итог: пропускная способность выше в 2,01–64,15 раза, end-to-end задержка ниже в 2,03–63,64 раза относительно стандартного сервинга. При росте выхода с 2048 до 8192 токенов TokenRouter не просел, а стандартный сервинг потерял 58,1–85,2% пропускной способности.

Что с этим делать

Если вы строите каскад из малой и большой модели, главный вывод такой: проблема часто не в самом алгоритме роутинга, а в том, как его обслуживает движок. Наивная реализация может съесть почти весь выигрыш.

Ограничения тоже есть. Результаты получены на семействе Qwen3 и на конкретных алгоритмах. Качество ответов здесь не главный предмет: статья про скорость обслуживания, а не про то, какой роутер лучше. Порог B зависит от вероятности маршрутизации и скорости моделей, так что на своей связке его нужно считать заново. Для команд с собственным инференсом это повод посмотреть на открытый код.