Почему выбор из 10 000 значений тормозит LLM — и как это исправить

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

Trie automaton решает задачу уже не как универсальную грамматику, а как специальный автомат для конечного набора строк. Общие префиксы образуют trie, а допустимые токены для каждой вершины заранее превращаются в маски. Благодаря этому проверка следующего шага занимает 0,65 мкс против 5,8 мкс у XGrammar — примерно в семь раз быстрее.

Но самый интересный результат находится не в этой цифре. Предварительно рассчитанные маски позволяют обойти guided decoding pipeline и использовать stateless serving path. Поэтому в пакетной обработке ускоряется не только вычисление допустимых токенов: итоговая пропускная способность vLLM при batch size 256 достигает 219 req/s против 7,5 req/s у XGrammar, то есть заявленные 29× складываются из алгоритмического выигрыша и экономии на интеграционном пути.

Для практического применения это означает простую вещь: если ответы выбираются из большого, но фиксированного справочника, универсальный механизм ограниченного декодирования может быть избыточным. Авторы сообщают о компиляции менее чем за 100 мс для наборов до 10 000 значений и о неизменной стоимости шага при росте набора; корректность вывода при этом гарантируется на 100%.

Ограничение тоже принципиальное: это специализированное решение именно для конечных наборов с известной структурой — общими префиксами, ограниченной глубиной и заранее известным размером. Результаты приведены в сравнении с XGrammar и зависят от сценария пакетной подачи: 29× нельзя автоматически переносить на любую генерацию, любую грамматику или любой размер batch. Тестирование охватывает семь семейств токенизаторов с размером словаря от 32K до 262K, но сам источник — только описание работы, без деталей о других сценариях нагрузки.

Если ваши модели выбирают из больших справочников, что сегодня сильнее ограничивает систему: скорость проверки допустимых токенов или архитектура, через которую эта проверка встроена в serving? Источник: cs.AI updates on arXiv.org