Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
TreeSpark позволяет основной LLM принимать более длинные фрагменты ответа за одну проверку, сохраняя результат жадной генерации. Работа Renmin University of China, Nanjing University и Huawei показала преимущество над DSpark по скорости выдачи токенов, хотя препринт не рецензирован и числа получили сами авторы. Для команд с собственным контуром генерации это повод оценивать черновую модель не только по точности следующего токена, но и по тому, какие ветви реально доходят до проверки.
Почему одной последовательности недостаточно
Генерация с черновиком (speculative decoding) разделяет работу между дешёвой черновой моделью и основной LLM. Первая заранее предлагает продолжение, вторая параллельно проверяет его и принимает совпавший префикс. Чем длиннее принятый фрагмент относительно затрат на подготовку и проверку, тем быстрее появляется ответ.
У линейного черновика есть структурная проблема: первое несовпадение отбрасывает весь остаток, даже если более поздние позиции предсказаны удачно. Параллельная модель уже потратила вычисления на весь блок, но использовать их не может, потому что нужный префикс исчез.
TreeSpark вместо одной цепочки сохраняет несколько продолжений с общими началами. Основная часть черновой модели вычисляет представления один раз, а лёгкий модуль корректирует прогноз отдельно для каждого родительского токена. На каждом уровне система развивает наиболее вероятные варианты, затем обрезает дерево под фиксированный бюджет проверки.
Такой подход сам по себе ещё не решает задачу. Обычное обучение показывает модели правильный токен после эталонного префикса, тогда как при работе она видит собственные промежуточные варианты. Кроме того, полезная ветвь может проиграть локальный отбор и не попасть в дерево, хотя основная LLM выбрала бы её.
Как обучение учитывает отбор ветвей
TreeSpark во время обучения повторяет ту же процедуру, что будет использовать при выдаче ответа: расширяет дерево, обрезает фронт и упаковывает кандидатов в доступный бюджет. Поэтому модуль коррекции учится на родительских токенах, которые выбрала сама черновая модель, а не только на эталонной последовательности.
Первая дополнительная функция потерь поддерживает выживание целых путей. Она усиливает рёбра, которые сохранились после упаковки дерева, и назначает больший вес продолжениям с высокой вероятностью по оценке основной модели. Это важно, потому что поздний правильный токен бесполезен без всех подходящих предков.
Вторая функция следит за покрытием около границы отбора. Если важный для основной модели токен почти попал в список кандидатов, обучение поднимает его относительно последнего прошедшего варианта. Ограничение штрафа не даёт далёким от границы ошибкам забрать большую часть градиента.
Обе функции повторно используют распределения основной модели, рассчитанные для эталонной цепочки. Дополнительные проходы основной LLM по каждой ветви не нужны, и при эксплуатации не появляется отдельная модель-оценщик. Для альтернативных продолжений эти распределения служат приближёнными метками, поскольку получены в другом контексте.
Принятые фрагменты выросли, но переносить результат нужно поэтапно
По сравнению с DSpark средняя длина принятого фрагмента выросла на 23,4–31,6%, а скорость одного запроса — на 15,1–25,0%. Контрольный опыт с одинаковой архитектурой, бюджетом дерева и правилами проверки дал ещё 6,4% к принятой длине именно за счёт нового обучения, а не только за счёт ветвления.
Проверка охватывала Qwen3-4B и Qwen3-8B, жадную генерацию, девять общих бенчмарков и шесть областей письменных текстов. TreeSpark сравнивали прежде всего с DSpark; отдельно измеряли одиночные запросы и совместную обработку нескольких запросов. Такой масштаб показывает эффект для двух близких моделей и заданной схемы выдачи, но не устанавливает его для генерации с выборкой или других семейств LLM.
Работа меняет планы команд, которые размещают модель самостоятельно и могут вмешиваться в связку черновика с проверяющей LLM. В таком контуре стоит добавить дерево кандидатов в прототип и измерить не только долю совпавших токенов, но также стоимость построения ветвей, длину принятого пути и итоговую скорость на реальной смеси запросов.
Для продукта поверх внешнего API непосредственного изменения нет: метод требует доступа к внутреннему процессу генерации и собственной инфраструктуре выдачи. Даже при самостоятельном размещении TreeSpark пока разумнее рассматривать как вариант оптимизации после выбора основной модели, а не как основание менять архитектуру продукта. Главный практический вывод уже применим шире: черновик следует обучать с учётом тех кандидатов и ограничений бюджета, которые он встретит при эксплуатации.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
