Две модели медленнее одной

Исследователи из Цзиньхуа выложили TokenRouter, систему для связок моделей, которые пишут один ответ вдвоем. Идея связки простая: большая часть текста предсказуема, и ее может писать маленькая дешевая модель, а большую стоит звать только на трудных местах. Сейчас в продакшене модель выбирают на уровне запроса, так делают ChatGPT и Cursor: одна модель получает вопрос и пишет ответ целиком. Здесь выбор делается на каждом токене. В R2R, прошлой работе той же группы, большая модель на 32B писала всего 5% токенов, а качество, по замерам авторов, не проседало.

На бумаге это экономия, на практике запускать такие связки было не на чем. Серверы вроде SGLang и vLLM обслуживают одну модель и ведут все запросы строем, шаг в шаг. Когда запросы постоянно перебегают между быстрой и медленной моделью, строй рассыпается: быстрая ждет медленную, запросы стоят в очередях. Каждый алгоритм приходил с собственным кодом, и у R2R с CITER он даже не умел принимать новые запросы, пока не закончит текущие.

TokenRouter дает каждой модели свой сервер и отпускает их работать в своем темпе, а большую модель заставляет немного подождать, пока не наберется несколько трудных токенов, чтобы посчитать их разом. Код открыт. Итог в аннотации: от 2 до 64 раз быстрее существующих решений.

Существующие решения тут это как раз тот самый код авторов алгоритмов. Сравнение, которое интересует любого, кто платит за GPU, спрятано в таблице внутри: что будет, если не роутить вообще и просто запустить большую модель. В тестах на четыре одновременных запроса официальный код R2R работал в полтора раза медленнее нее. С TokenRouter R2R стал в 1,7 раза быстрее одной большой модели, CITER на 20%, так что экономия наконец появилась не только на бумаге. R-Stitch и с новой системой немного уступил.

До этого CITER, у которого эффективность вынесена прямо в название статьи, в официальном коде работал в семь раз медленнее, чем одна большая модель без всякого роутинга.

@anti_agi