Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Немедленная отправка каждого готового шага в LLM замедляет завершение агентных процессов, когда общий движок перегружен. В нерецензированном препринте, где все числа получили сами авторы, управление моментом отправки сократило P95 — порог, быстрее которого завершаются 95% процессов, — до 3,5 раза. Для архитектуры это добавляет отдельный слой планирования перед движком, а не требует ускорять саму модель.
Почему готовый шаг полезно придержать
Агентный процесс чередует обращения к модели и работу инструментов. Следующий шаг становится доступен только после предыдущего ответа и связанного с ним действия: например, запуска тестов или чтения файла. Полное время такого процесса считают от его поступления до завершения последнего обращения к LLM.
Большинство сред исполнения отправляет шаг в движок сразу после того, как выполнены зависимости. При небольшой нагрузке это разумно: очередь короткая, а запрос быстро получает вычислительные ресурсы.
При перегрузке готовые шаги продолжают поступать быстрее, чем движок успевает их завершать. Они образуют уже принятую, но не выполненную работу. Планировщик уровня процесса больше не может отозвать такие запросы и пропустить вперёд шаг процесса, который позже оказался срочнее.
Проблема возникает до внутренней очереди LLM-движка. Готовность означает, что шаг уже можно выполнить, но не требует отправлять его немедленно. Разделив эти события, среда исполнения сохраняет возможность менять порядок по мере старения процессов и появления новых готовых шагов.
Как планировщик выбирает момент отправки
Алгоритм решает две связанные задачи: какой готовый шаг отправить следующим и стоит ли сейчас добавлять работу в движок. Одной сортировки недостаточно, если среда исполнения всё равно немедленно отправляет всю очередь. Ограничение очереди без осмысленного порядка тоже не определяет, какой процесс продвигать первым.
Приоритет шага зависит от риска задержать весь процесс и от ожидаемого объёма вычислений. Каждый незавершённый процесс получает базовый вес. Когда его возраст переходит в медленный хвост, вес растёт. Границу хвоста планировщик обновляет по времени уже завершённых процессов.
Полученный вес делят на оценку работы текущего шага. В неё входят размер запроса и ожидаемая длина ответа; последнюю оценивают только по ранее завершённым обращениям. Так короткий шаг, который заметно приблизит старый процесс к завершению, может обойти более дорогой запрос.
Вторая часть метода ограничивает объём принятой, но незаконченной работы. Планировщик наблюдает за очередью, задержкой и количеством ожидающих запросов. Когда давление растёт, допустимый объём уменьшается; при свободном движке — увеличивается. Если подходящий шаг не помещается в текущий бюджет, он остаётся снаружи и может участвовать в следующем выборе.
От бесконечного ожидания защищает отдельное правило: слишком долго отложенный шаг получает право пройти независимо от обычного приоритета. Метод не меняет обработку запроса внутри движка и не требует прерывать уже начатую генерацию.
Планы меняются там, где движок работает под нагрузкой
Метод проверяли повторным воспроизведением реальных трасс агентов для задач разработки из SWE-bench и SWE-Gym — по сотне процессов в каждой. Эксперименты охватили Qwen3-8B, Qwen3-32B и Llama-3.3-70B при нескольких скоростях поступления задач. В парных запусках сохранялись процессы, моменты поступления, работа модели и задержки инструментов; менялся только порядок отправки шагов.
Самый заметный результат получен для SWE-bench с Llama-3.3-70B под высокой нагрузкой: P95 полного времени снизился с 1986,3 до 568,0 секунды, то есть на 71,4%. При лёгкой нагрузке разница между новым методом и немедленной отправкой укладывалась в 1%, поэтому запас вычислительной мощности он почти не превращает в дополнительную задержку.
Разбор компонентов показал, что основную часть выигрыша дал порядок шагов с учётом хвоста. Подстройка допустимого объёма работы под состояние очереди добавила меньший, но устойчивый эффект. Значит, фиксированного ограничения числа запросов недостаточно: планировщику нужна информация о возрасте всего процесса и ожидаемой цене следующего шага.
Работа меняет планы команд, которые управляют собственным или общим LLM-движком и ожидают периоды насыщения. В такой системе момент готовности шага стоит хранить отдельно от момента его отправки. Для внедрения понадобятся очередь перед движком, учёт незавершённой работы, оценки размера шага и показатели перегрузки.
Проверять эффект следует по полному времени агентного процесса под возрастающей нагрузкой, а не только по задержке отдельного обращения к модели. На постоянно свободном движке новый слой почти ничего не даёт. Эксперименты охватывают процессы разработки с последовательными зависимостями, поэтому вывод напрямую относится именно к такой структуре нагрузки.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
