TAO ускорил ИИ-агентов: первый токен быстрее до 36%, задачи до 27%

Когда ИИ-агент чинит баг в репозитории, он не только думает. Модель выдаёт команду, компилятор, тесты или поисковик на отдельных процессорах её выполняют, результат возвращается в модель, и так десятки раз. Исследователи из Шанхайского университета Цзяо Тун назвали такую схему CGDC: кластер GPU для инференса плюс разбросанные по сети CPU для инструментов. Они предложили планировщик TAO, который решает, каких агентов пускать на GPU и на какой именно узел, с учётом того, когда у каждого агента вернётся ответ инструмента. По сравнению с лучшим из конкурентов по каждой метрике TAO снижает задержку выполнения задачи до 26,8%, среднее время до первого токена после возобновления сессии (TTFT) до 36,3%, а скорость генерации (токенов в секунду) повышает до 29,5%.

Почему GPU и кэш страдают, пока агент ждёт инструмент

Пока инструмент работает, агенту GPU не нужен. Сессию можно приостановить и отдать место другим. Но у паузы есть цена. Модель хранит в памяти KV-кэш: уже посчитанное представление истории диалога. Если вернуться на тот же узел быстро, префикс переиспользуется и не надо заново прогонять весь контекст. Если задержаться, кэш вытесняется, и пересчёт съедает ёмкость.

Авторы показали это на трассах DeepSeek-V4 Flash с двух узлов H100: доля сохранившегося кэша заметно падает с возрастом наблюдения, кривая построена на интервале до 1 800 секунд.

По мнению авторов, существующие системы допускают две ошибки:

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

Три числа в строгом порядке и задача про рюкзаки

Для каждой пары «ждущая сессия — узел» TAO считает тройку чисел, которые сравниваются по порядку, как слова в словаре:

• Кредит кэша. Сколько токенов этой сессии, по наблюдениям, лежит на данном узле. Старые наблюдения затухают по экспоненте с заданным периодом полураспада. Нет данных об узле — кредит нулевой.
• Готовность к возврату. Двоичный признак: вернётся ли инструмент в ближайшее окно планирования. Предсказание строится из подсказок самих инструментов (у Claude Code есть Monitor, у OpenCode — сообщение о таймауте Bash), разобранных команд sleep и истории длительностей. Если ничего нет, берётся пять секунд по умолчанию. Просроченным прогнозам дают временные пробные шансы, чтобы сессия не оставалась «готовой» вечно.
• Число токенов. При равенстве первых двух предпочтение отдаётся длинным контекстам.

Порядок зафиксирован, а значения меняются со временем. Поэтому не нужны ручные веса в сумме.

Дальше работает точный алгоритм динамического программирования. Задача похожа на классические «несколько рюкзаков»: у каждого узла есть остаточная ёмкость, у каждой сессии стоимость допуска, надо набрать максимум суммарной ценности. Решение точное для замороженного снимка состояния, хотя округление ёмкости может исключить планы, допустимые до округления. Планировщик работает в отдельном асинхронном процессе и перед применением проверяет план по живому состоянию. По данным авторов, подготовка и расчёт занимают менее 0,12% времени работы в тесте с четырьмя репликами.

Что показали замеры на H100

Тестировали три модели: DeepSeek-V4 Flash на двух узлах H100, Qwen3-32B на четырёх и GLM-4.7 на одном. Нагрузки такие: SWE-bench Lite (исправление реальных багов) через mini-SWE-agent, Terminal-Bench 2.0 с Claude Code для сложных терминальных задач и SWE-verified для Qwen при высокой конкуренции. Каждый узел держит одну реплику модели.

Сравнивали с четырьмя названными подходами: планировщик vLLM с круговым распределением, он же с учётом кэша, Dynamo от NVIDIA (учитывает KV) и ThunderAgent (по числу токенов и упаковке «по убыванию»).

На SWE-bench Lite относительно лучшего конкурента в каждой колонке:

• задержка задачи ниже на 2,4–26,8%;
• TTFT ниже на 7,4–36,3%;
• скорость генерации выше на 5,1–29,5%.

На Terminal-Bench TAO впереди по задержке и TTFT на всех трёх уровнях конкуренции. На Qwen3-32B у него минимальный TTFT при всех трёх числах параллельных сессий. Максимумы взяты по 12 конфигурациям «модель — нагрузка — конкуренция», так что на каждой конкретной связке выигрыш скромнее.

Что с этим делать инженерам

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

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