Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Новый декодер ускоряет генерацию LLM, подстраивая объём предварительной работы под конкретный запрос и текущую нагрузку. На Qwen3-4B он работал до 14% быстрее прежней цепочки, хотя препринт не прошёл рецензирование и все числа получили сами авторы. Для систем с дешёвым черновиком это превращает размер дерева из постоянной настройки в параметр среды исполнения.
Почему широкое дерево тратит вычисления не на те ветви
При черновом декодировании (speculative decoding) небольшая модель заранее предлагает несколько токенов, а основная LLM проверяет их за один проход. Обычный черновик строит цепочку: если один токен отклонён, весь остаток становится бесполезным. Дерево снижает этот риск, потому что заранее покрывает несколько возможных продолжений.
Полублочные черновики вроде DSpark получают все позиции блока за один проход. Однако базовая часть модели выдаёт для каждой позиции общее распределение и не учитывает, какой токен стоит перед ней. Если напрямую строить из этих оценок дерево, разные родители получают одинаково ранжированных детей, даже когда такие продолжения неправдоподобны.
В контрольном опыте такое дерево уступило исходной цепочке даже при восьмикратном бюджете проверки. Проблема была не в недостаточной ширине, а в том, что дополнительные узлы попадали не на те ветви.
TreeSpark использует уже существующую в DSpark марковскую голову: она корректирует оценку следующего токена с учётом непосредственного родителя. Для новой ветви нужны поиск в таблице и небольшое матричное умножение, но не ещё один проход черновой модели. Поэтому один набор базовых оценок поддерживает разные продолжения внутри дерева.
Вероятность токена ещё не показывает, примет ли его основная модель. TreeSpark калибрует эту оценку по результатам прошлых проверок, причём берёт только рёбра, до которых дошёл бы успешно принятый путь. Затем перемножает оценки вдоль ветви: чем ниже вероятность выживания всего пути, тем меньше пользы принесёт следующий узел.
Дерево растёт сначала по наиболее перспективной ветви и останавливается, когда ценность лучшего оставшегося кандидата падает ниже порога. Так система выбирает бюджет заново в каждом раунде, а не проверяет постоянное число токенов независимо от уверенности черновика.
Случайная генерация требует не только правильных оценок
При жадной генерации достаточно проверить, совпадает ли предложенный токен с выбором основной модели. При случайной выборке токенов детерминированные верхние кандидаты и обычная проверка искажают итоговое распределение: в тесте с высокой неопределённостью расстояние полной вариации достигло 0,46. Эта метрика равна нулю для совпадающих распределений и растёт по мере расхождения.
TreeSpark выбирает соседние ветви без возвращения уже взятых токенов. После отклонения система пересчитывает остаточное распределение и продолжает проверку со следующим кандидатом. Такой рекурсивный отказ сохраняет распределение основной модели при любой температуре, если решение добавить место в дерево принято до того, как система увидела значение нового токена.
Порог роста одновременно служит регулятором нагрузки. При свободном GPU система допускает больше ветвей, потому что один проход основной модели может проверить их параллельно. Когда пакет запросов растёт и проверка становится дороже, порог повышается, дерево сжимается и в пределе превращается в исходную цепочку.
Это различие важно для эксплуатации: больше принятых токенов за раунд не всегда означает выше пропускную способность. Широкое дерево сокращает число проходов основной модели, но увеличивает объём вычислений внутри каждого прохода. TreeSpark принимает решение по измеренной стоимости конкретного режима, а не только по качеству черновика.
Меняет ли TreeSpark планы разработки
На Qwen3-4B адаптивное дерево принимало на 15–25% больше черновых токенов за раунд, чем настроенная цепочка DSpark. Метод проверяли на трёх размерах Qwen3, шести задачах, при жадной и случайной генерации. Во всех этих режимах адаптивная остановка давала лучшее соотношение между принятыми токенами и стоимостью проверки, чем фиксированный бюджет.
Команды с DSpark или похожим черновиком могут проверить подход без переобучения основной LLM и базовой части черновой модели. Понадобятся дешёвая условная голова, калибровка на результатах проверки и таблица порогов, построенная по замерам своего оборудования. Последний пункт нельзя заменить значениями из статьи: выгодный размер дерева зависит от пакетирования и стоимости прохода основной модели.
Для черновика, который выдаёт только независимые распределения по позициям, TreeSpark не станет готовой надстройкой. Сначала потребуется способ недорого пересчитывать продолжение для конкретного родителя. Работа показывает, что одно лишь расширение дерева без такой зависимости способно ухудшить результат.
Границы замеров пока оставляют решение на уровне прототипа. Использованные черновики ограничивали путь блоком из семи токенов, а фактическое ускорение измеряли в Python-стенде для одиночного запроса. Поведение под параллельной нагрузкой изучали отдельно, не в производственном сервисе с непрерывным пакетированием.
Практический вывод касается прежде всего архитектуры среды исполнения. Если команда уже внедряет черновое декодирование, стоит заложить динамический бюджет проверки и собирать метки принятия для калибровки. Менять основную модель ради TreeSpark не требуется, но фиксировать одно дерево для всех запросов теперь выглядит слабым базовым решением.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
