Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
LEAP научился заранее оценивать длину ответа LLM и уточнять прогнозы по мере работы сервиса. В препринте Kwan Yan, Jialun Zhong и Yanzeng Li, который не прошёл рецензирование и содержит замеры самих авторов, система снизила среднюю задержку на токен на 15,9–40,8% относительно проверенных предсказателей. Для команд со своим контуром инференса это способ добавить планирование по длине без второй нейросети и её периодического переобучения.
Длину ответа извлекают из уже рассчитанного состояния модели
Планировщик по длине ставит короткие запросы раньше длинных, чтобы один большой ответ не задерживал очередь. Ему не обязательно угадывать точное число токенов: достаточно правильно расставить запросы по объёму оставшейся работы.
Обычный предсказатель может повторно обработать промпт отдельным кодировщиком или пропустить скрытые состояния основной модели через многослойную голову. В обоих случаях сервис расходует дополнительные вычисления на решение, которое должно экономить вычисления.
LEAP использует состояние последнего токена промпта из одного позднего слоя обслуживающей LLM. Модель уже получила это представление во время предварительной обработки промпта, поэтому повторно кодировать текст не нужно. Линейная функция на CPU превращает состояние в оценку будущей длины.
При обучении предсказатель работает с квадратным корнем из длины, а затем возводит результат обратно в квадрат. Такое преобразование не позволяет редким длинным ответам полностью определять ошибку обучения, но сохраняет различия между ними лучше логарифма. Для планировщика это полезнее, чем минимальная средняя ошибка на коротких ответах.
После завершения запроса сервис знает фактическую длину и использует её как новый пример. LEAP обновляет коэффициенты методом рекурсивных наименьших квадратов: пересчитывает линейную зависимость без градиентов и без повторного чтения истории запросов. Исходная модель остаётся опорной точкой, поэтому единичные новые ответы не заменяют накопленную зависимость целиком.
Предсказание и обновление идут в отдельных потоках CPU. Пока GPU заканчивает предварительную обработку промпта, CPU переносит выбранное скрытое состояние, рассчитывает длину и готовит порядок очереди. Планировщик продолжает работать с последней опубликованной версией коэффициентов, если очередное обновление ещё не закончено.
Адаптация помогла при смене языка и не съела выигрыш планировщика
Предсказание проверяли на Qwen3-8B, Llama-3.1-8B-Instruct и Mistral-7B-Instruct-v0.3 с наборами Alpaca, ShareGPT и LMSYS. Отдельный перенос на Aya имитировал более заметную смену языка. В качестве конкурентов взяли TIE, TRAIL, LTR, SSJF и EGTP — как отдельные текстовые кодировщики, так и головы над скрытыми состояниями.
После адаптации на завершённых запросах ранговая корреляция Спирмена при крупном сдвиге выросла на 64,7%. Эта метрика показывает, насколько одинаково предсказатель и фактические ответы упорядочивают запросы по длине. Для планирования порядок важнее точного совпадения числа токенов.
В экспериментах с обслуживанием LEAP снизил среднюю задержку на токен на 15,9–40,8%, но пропускная способность выросла на 1,9%. Разница между показателями ожидаема: более удачная очередь быстрее обслуживает средний запрос, однако почти не меняет объём вычислений, который GPU выполняет для всех токенов.
Линейная голова использует в 30 569 раз меньше параметров, чем LTR — лучший из проверенных базовых вариантов в экспериментах с обслуживанием. Её веса занимают 16,39 КБ, поэтому расчёт помещается в кэш процессорного ядра и не требует запуска модели-предсказателя.
Экспериментальный контур охватывает vLLM на одной GPU в режиме немедленного выполнения. Проверка не распространяется на распределённый инференс, кэширование общих префиксов и обработку промпта частями; эти режимы меняют момент, когда скрытое состояние становится доступно планировщику.
Когда LEAP меняет архитектурный план
Работа меняет планы команды, если она управляет собственным инференсом и видит смешанную очередь коротких и длинных запросов. Вместо отдельного предсказателя можно добавить линейное чтение скрытого состояния, хранить признаки активных запросов на CPU и обновлять коэффициенты по фактическим завершениям. Основную LLM при этом переобучать не требуется.
Подход особенно уместен там, где состав трафика меняется после запуска: появляются другие языки, задачи или шаблоны промптов. Завершённые запросы дают бесплатную разметку длины, а рекурсивное обновление позволяет подстроить порядок очереди без отдельного цикла сбора датасета, обучения и развёртывания новой головы.
Если продукт обращается к модели только через внешний API, применить LEAP на своей стороне нельзя: ему нужны скрытые состояния и доступ к планировщику декодирования. Для собственного сервера потребуется вмешательство в путь предварительной обработки, публикацию приоритетов и учёт завершённых запросов, а не простая замена конфигурации.
Планирование по длине также меняет распределение ожидания: средний запрос ускоряется за счёт приоритета коротких ответов, а длинные могут ждать дольше. Перед внедрением нужны правила, которые повышают приоритет долго ожидающих запросов. Сам предсказатель не решает эту задачу справедливости.
LEAP стоит воспринимать не как способ увеличить вычислительную производительность LLM, а как компактный компонент очереди. Главный архитектурный вывод работы: для полезного расписания не нужен максимально точный прогноз, если его стоимость выше выигрыша от перестановки запросов.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
