Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
JetSpec++ ускоряет генерацию LLM, почти убирая время черновой модели из пути ответа. В нерецензированном препринте команда UC San Diego, UIUC, Nanjing University, Meta и StepFun сама получила ускорение до 1,54 раза относительно DSpark. Метод имеет смысл для собственного контура вывода, где можно распределить целевую и черновую модели по разным GPU.
Почему быстрый черновик всё равно задерживает ответ
При обычной авторегрессионной генерации модель добавляет по одному токену за проход. Спекулятивное декодирование (speculative decoding) поручает небольшой модели подготовить сразу блок токенов, а основная модель проверяет их одним проходом.
Проверка идёт слева направо. Основная модель принимает совпавшее начало блока, а после первого отклонения отбрасывает остаток и сама выбирает следующий токен. Такой порядок сохраняет распределение ответов целевой модели: черновик влияет на скорость, но не меняет правила генерации.
Ускорение зависит от двух величин. Черновая модель должна предлагать токены, которые основная модель примет, но не должна тратить на это столько времени, что подготовка блока съест выигрыш от совместной проверки.
Обычно стадии выполняются последовательно: сначала черновик, затем проверка. JetSpec++ переносит подготовку следующего блока на время текущей проверки. Критический путь — последовательность операций, которая определяет задержку ответа, — теперь включает более долгую из двух параллельных стадий, а не их сумму.
Проблема в том, что следующий черновик приходится начинать до результата проверки. Ещё неизвестно, сколько токенов примет основная модель, какой токен станет началом следующего блока и какими будут её внутренние представления для нового контекста.
Как прогноз и самокоррекция заполняют паузу
JetSpec++ заранее рассматривает несколько возможных исходов проверки. Каждый исход задаёт длину принятого фрагмента и следующий токен, от которого нужно продолжить генерацию.
Адаптер прогнозирует внутренние представления целевой модели для блока, который она ещё проверяет. Затем небольшой декодер оценивает возможные исходы и выбирает наиболее вероятные. Для каждого выбранного исхода система заранее готовит следующий блок и кладёт его в кэш.
Когда проверка заканчивается, система ищет фактический исход в кэше. При совпадении готовый блок сразу уходит на следующую проверку. Если подходящего варианта нет, черновая модель выполняет обычный запасной проход, поэтому ошибка прогноза снижает скорость, но не меняет результат генерации.
Оставшееся время внутри окна проверки JetSpec++ тратит на самокоррекцию. Черновая модель получает весь блок параллельно и несколько раз пересматривает токены с учётом уже предложенного начала. Для этого её обучают на примерах, где начало блока правильное, а продолжение частично зашумлено.
Между проходами адаптер заново прогнозирует внутренние представления. Декодер находит первое место, где его лучший токен расходится с черновиком, заменяет этот токен и запускает следующий проход. Именно замена первой ошибки дала большую часть прибавки от такой коррекции: простого обновления внутренних представлений оказалось недостаточно.
Эти вычисления не добавляют задержку, пока помещаются во время проверки на другом GPU. Если черновая стадия становится длиннее, она снова выходит на критический путь, поэтому число прогнозируемых исходов и проходов коррекции приходится подбирать под конкретное оборудование.
Когда JetSpec++ меняет архитектурный план
Относительно последовательной генерации пиковое ускорение достигло 7,45 раза, а скорость одного запроса — 1361 токена в секунду. За один раунд система принимала в среднем 8,94 токена против 6,89 у DSpark: выигрыш связан не только с перекрытием стадий, но и с более точным черновиком.
Метод проверяли на Qwen3-8B в задачах по математике, программированию и диалогу, при жадной генерации и выборке. Системные замеры относятся к одному запросу на GB200, причём черновая модель работала на втором GPU. Поэтому результаты отвечают на вопрос о задержке отдельного ответа, но не показывают поведение под пакетной нагрузкой или на другой конфигурации ускорителей.
JetSpec++ меняет планы команд, которые разворачивают модели сами и готовы выделить отдельный ускоритель под черновую стадию. Архитектуре нужен доступ к внутренним представлениям целевой модели, обученные адаптер и черновая модель, общий кэш исходов и согласованное выполнение на двух устройствах.
Для внешнего API без доступа к слоям модели этот подход не подходит напрямую. Для собственного сервера он предлагает другой компромисс: не уменьшать черновую модель любой ценой, а оставить её достаточно точной и спрятать работу за проверкой. Практический критерий внедрения прост — весь прогноз и самокоррекция должны завершаться раньше целевой модели.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
