Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Zeyu Liu, Souvik Kundu и Peter A. Beerel предложили механизм Speculative Macro Commit для ускорения LLM-агентов с инструментами, а их работа — препринт, не прошедший рецензирования. По замерам авторов, SMC выполнял задачи быстрее как последовательного агента, так и Speculative Actions, который предвычисляет только отдельные действия. Подход важен командам, у которых задержку создают последовательные вызовы модели, API и внешних систем, а в сценариях повторяются одни и те же цепочки операций.
Что сделали
Обычный агент работает последовательно: модель выбирает действие, исполнитель вызывает инструмент, получает результат и только после этого формирует следующий запрос к модели. Даже если сама модель отвечает быстро, каждый вызов API или переход среды остаётся на критическом пути задачи.
SMC добавляет к основной модели более компактную модель-черновик. В экспериментах эту роль выполняли соответственно Qwen3.5-27B INT4 и Qwen3.5-4B. Пока основная модель выбирает следующее официальное действие, модель-черновик предсказывает несколько будущих вызовов и выполняет их в изолированной копии среды. Эти изменения не попадают в рабочее состояние, пока исполнитель их не примет.
Дополнительно система извлекает из успешных обучающих трасс повторяющиеся последовательности действий. Конкретные идентификаторы пользователей, документов и даты заменяются параметрами, поэтому одна последовательность может соответствовать нескольким задачам. Отобранные шаблоны хранятся во внутренней библиотеке и не показываются основной модели как новые инструменты.
Если следующий вызов основной модели совпадает с первым действием подготовленной цепочки, исполнитель использует его как подтверждённую опорную точку. После проверок он может сразу добавить в официальную историю оставшиеся вызовы и уже полученные результаты. Основная модель не подтверждает каждый пропущенный шаг отдельно, поэтому SMC является приближённой оптимизацией, а не эквивалентом последовательного выполнения.
Проверки учитывают глубину полезного пропуска, актуальность подготовленной ветки и допустимость операций. Для AppWorld авторы также задали правила по именам API, отклоняли неизвестные или необратимые действия и повторно применяли изменяющие состояние операции к рабочей среде.
Что показали
Авторы проверили SMC на τ2 Telecom и AppWorld. В первом случае среднее время задачи уменьшилось на 18,59% относительно последовательного выполнения и на 10,23% относительно Speculative Actions. Итоговые результаты задач совпали с последовательным режимом.
На AppWorld сокращение времени составило 44,93% относительно последовательного режима и 7,64% относительно Speculative Actions. При этом SMC завершил на две задачи меньше. Работа тем самым показывает не только возможный выигрыш, но и цену приближённой фиксации цепочек: подтверждение первого действия не гарантирует правильность всего продолжения.
Отдельные эксперименты объясняют, почему недостаточно просто находить больше повторяющихся последовательностей. Более агрессивный вариант фиксировал больше шагов, но оказался медленнее Speculative Actions из-за накладных расходов. Пользу давали достаточно длинные цепочки, которые уже были выполнены моделью-черновиком и действительно убирали обращения к основной модели с критического пути.
Ограничения
Работа охватывает два набора задач: телекоммуникационный раздел τ2-Bench и AppWorld. Авторы использовали одну пару моделей, жадный выбор следующего токена и собственную реализацию исполнителя. Поэтому замеры не показывают, сохранится ли результат с другими моделями, инструментами, длительностью операций и структурой рабочих процессов.
Сравнение режимов не равно сравнению при одинаковых вычислительных ресурсах. Последовательный вариант работал на одном GPU, а Speculative Actions и SMC — на трёх: для основной модели, её дополнительного экземпляра и модели-черновика. Из статьи поэтому нельзя сделать вывод о снижении стоимости, энергопотребления или потребности в инфраструктуре.
SMC зависит от успешных исторических трасс, повторяемых цепочек и возможности изолировать состояние среды. Правила безопасности для AppWorld частично заданы вручную, что ограничивает переносимость механизма. На одном из тестов также снизилась доля завершённых задач, а сравнения со сторонними реализациями систем спекулятивного выполнения в одинаковой среде авторы не провели.
Что это значит
Работа не меняет планы команд, которые только выбирают основную LLM или ускоряют отдельный вызов модели. SMC решает другой класс задержек: ожидание между последовательными действиями агента. Такой механизм имеет смысл рассматривать после того, как трассировка показывает заметную долю повторяемых цепочек и задержку инструментов на критическом пути.
Для внедрения потребуется исполнитель, который полностью контролирует историю агента, умеет создавать изолированную копию состояния и безопасно переносить подготовленные результаты в рабочую среду. Системам с необратимыми платежами, отправкой сообщений или плохо воспроизводимыми внешними эффектами понадобятся более строгие проверки, чем подтверждение первого вызова.
Практический вывод — проверять SMC как инфраструктурную оптимизацию на собственных трассах, а не закладывать его в архитектуру по результатам двух тестов. Сравнивать следует последовательный режим, предвычисление одного действия и фиксацию цепочек, одновременно измеряя время выполнения, завершение задач и расход GPU. Если повторяемых путей мало или среду нельзя безопасно клонировать, дополнительная модель и синхронизация могут не окупиться.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
