Журнал · Rit.work

AgSpec перестраивает спекулятивное декодирование под кодовых агентов

AgSpec сохраняет код, логи и прошлые попытки между вызовами, а затем подбирает длину черновика по роли агента и результатам проверки.

Rit.work
Студия разработки
2 октября 2026 г.3 мин чтения

Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.

Кодовых агентов удалось ускорить без переобучения модели и без изменения распределения её ответов. В нерецензированном препринте KAIST, где все числа получены самими авторами, AgSpec увеличил скорость генерации до 4,76 раза относительно обычной поочерёдной генерации при пачке из 16 запросов. Работа переносит основной резерв ускорения из самой модели в устройство сессии: какие тексты хранит система и сколько токенов предлагает модели за один шаг.

Повторяемый текст должен пережить один вызов модели

При спекулятивном декодировании система сначала предлагает модели черновое продолжение, а затем целевая модель проверяет его токены параллельно. Принятые токены экономят последовательные шаги генерации, отклонённые создают лишнюю вычислительную нагрузку. AgSpec получает черновик поиском по уже доступному тексту, поэтому отдельная малая модель ему не нужна.

Обычный поисковый механизм часто видит только текущий запрос или заранее собранную базу кода. Для кодового агента этого мало: после следующего вызова из контекста может исчезнуть открытый файл, а новая попытка решения не найдёт код и журналы из предыдущей.

AgSpec разделяет текст на три корпуса. Корпус сессии хранит запросы, ответы модели и результаты инструментов между всеми вызовами и ролями. Корпус рабочей области получает файлы, которые агент открыл в репозитории. Глобальный корпус содержит заранее подготовленные справочные тексты и не зависит от конкретной задачи.

Файлы индексируются не только в исходном виде, но и так, как агент записывает их в ответ. Например, при выдаче унифицированной заплатки каждая строка получает служебный префикс. Без такого преобразования содержимое строки совпадает по смыслу, но образует другую последовательность токенов, и поиск её пропускает.

Главный вклад дал корпус сессии: сохранение текста между вызовами увеличило среднее число принятых черновых токенов в 1,6–2,1 раза. Рабочая область поверх него добавила ещё 2,2–7,0%. Это показывает порядок внедрения: сначала стоит сохранить траекторию сессии, затем подключать файлы репозитория и их формы вывода.

Длина черновика зависит от роли и текущего этапа

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

AgSpec сочетает предварительный профиль с обратной связью во время работы. Профиль задаёт отдельный верхний предел для каждой роли и целевой модели: черновик обрывается там, где вероятность принять следующий токен уже не покрывает стоимость его проверки. Затем система сокращает или расширяет продолжение по результатам предыдущих проверок.

Это особенно влияет на серверы, которые одновременно обслуживают много запросов. При малой загрузке проверка лишних токенов сравнительно дешева, но в большой пачке она отнимает вычисления у всех запросов. Длинный фиксированный черновик в таком режиме оказался на 30% медленнее короткого.

Одна только онлайн-коррекция длины повысила скорость на 66%: доля отклонённых токенов снизилась с 78% до 50%. Система укорачивала черновик, пока редактор создавал новый код, и увеличивала его, когда тот начинал копировать уже известные фрагменты. Поэтому средняя длина принятого продолжения сама по себе не определяет скорость: важно, сколько лишних токенов модель проверила ради этого результата.

Менять модель не требуется, но слой выполнения придётся сделать сессионным

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

Практический план начинается со сбора доли принятых токенов отдельно по ролям и этапам задачи. После этого можно сохранить корпус сессии, добавить открытые файлы в форматах вывода конкретного агента и только затем включить адаптивную длину. Единый предел для всех ролей оставляет часть ускорения неиспользованной и при высокой параллельности может замедлить систему.

Проверка охватила SWE-bench Verified и TeamBench, несколько целевых моделей, пять поисковых способов подготовки черновика и EAGLE-3. Авторы использовали жадную генерацию, отделяли задачи глобального корпуса от оцениваемых и очищали сессионные данные между запусками. Результаты относятся прежде всего к агентам, которые многократно обращаются к одному репозиторию, повторяют заплатки и возвращаются к прежним журналам.

Сессионный корпус также меняет требования к изоляции данных. В нём оказываются запросы, закрытый код и вывод инструментов, поэтому доступ следует ограничивать одной сессией, а сам корпус удалять после её завершения. Если инфраструктура обслуживает независимых клиентов, это становится частью архитектуры безопасности, а не только оптимизацией скорости.

Источники

Пауза в чтении

Похоже на вашу задачу?

Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.

Rit.work

Студия разработки

Собираем мобильные приложения и помогаем командам получать от AI реальную пользу. Основатель и команда, работаем удалённо — с клиентами в России и за рубежом.

← Ко всем материалам
Понравилось? Обсудим вашу задачу