Исследователи NVIDIA, Наньянского технологического университета (NTU) и Массачусетского технологического института (MIT) представили SoL-Pi — набор из четырёх механизмов для снижения расхода токенов кодинг-агентом Pi. Согласно описанию результатов MarkTechPost, на бенчмарке EdgeBench система уменьшила измеренный трафик токенов на 44,7–49,0%, а расходы на API — примерно на треть.
Оптимизации затрагивают не саму языковую модель, а обвязку агента: слой, управляющий контекстом, вызовами инструментов, результатами команд и делегированием. Механизмы искал исследовательский ИИ в автоматических циклах экспериментов, а не разработчики вручную.
Все показатели пока следует рассматривать как результаты авторов. В доступных материалах нет независимого воспроизведения тестов, а перенос оптимизаций между моделями сама команда называет предварительным.
Автоматический поиск вместо ручной настройки агента
При продолжительной работе кодинг-агент многократно отправляет модели историю изменений, вывод команд, журналы ошибок и результаты тестов. Даже если отдельный запрос относительно недорог, накопленный контекст может заметно увеличить общий расход токенов.
Обычные методы оптимизации — квантизация, ускоренные вычислительные ядра или переход на более дешёвую модель — уменьшают стоимость обработки токена. SoL-Pi действует иначе: его задача состоит в том, чтобы сократить число токенов, необходимых для завершения работы.
По данным авторов, исследовательский ИИ анализировал трассы отдельного агента на базе Pi, предлагал изменения в его обвязке и проверял получившиеся варианты. Поиск прошёл через 535 изолированных сред. Каждый цикл включал реализацию предложенного изменения и независимую проверку кандидата.
Критерии приёма фиксировались до запуска поиска. Оптимизатор не мог менять их в процессе: показатели возможностей агента должны были оставаться в заранее установленном диапазоне, а хотя бы одна метрика эффективности — улучшаться. Такой порядок должен был ограничить риск ситуации, когда сокращение контекста уменьшает расходы, но одновременно лишает агента информации, необходимой для выполнения задачи.
Авторы связывают эту методику с направлением автоматического проектирования агентских обвязок, к которому относится Meta-Harness. При этом они признают известную проблему подобных систем: найденные конфигурации могут хорошо работать на поисковых заданиях, но давать небольшое улучшение или ухудшение на новых данных.
Что показал EdgeBench
Для оценки использовался EdgeBench из 51 публичной задачи. Как утверждается в описании исследования, задания бенчмарка не участвовали в основном поиске механизмов. После заморозки кандидатов 11 задач применили для одноразового отбора, а оставшиеся 40 — для финального тестирования. Результаты финальной части не возвращались оптимизатору.
Полный набор механизмов сначала создавался на траекториях GPT-5.6 Sol, после чего его без повторного поиска перенесли на Opus 5.
| Бэкенд | Сохранённая оценка базового Pi | Сокращение трафика токенов | Снижение стоимости API |
|---|---|---|---|
| GPT-5.6 Sol | 93,7% | 49,0% | 33,2% |
| Opus 5 | 94,3% | 44,7% | 33,5% |
Проценты в столбце оценки показывают отношение результата SoL-Pi к базовому Pi, а не абсолютную успешность выполнения задач. Поэтому из них нельзя сделать вывод, что агент решил около 94% заданий.
Доступное описание называет два из четырёх найденных механизмов. ObservationPack формирует более компактное представление наблюдений, возвращаемых агенту после выполнения действий. Action Fusion объединяет последовательные действия, чтобы сократить число отдельных обращений и сопутствующий служебный контекст. Названия и подробности оставшихся двух механизмов в доступном пересказе не раскрыты, поэтому их функции нельзя надёжно восстановить без препринта и документации проекта.
Для отдельной конфигурации Performance авторы выбрали лучший одиночный механизм под каждый бэкенд: ObservationPack для GPT-5.6 Sol и Action Fusion для Opus 5. В таком режиме оценки превысили показатели базового Pi на 5,3% и 12,8% соответственно. Это отдельный эксперимент, и его не следует смешивать с результатами полного стека, ориентированного прежде всего на экономию токенов.
Общая экономия не означает сокращение каждой метрики
SoL-Pi уменьшил совокупную стоимость тестов, но не все виды трафика снизились. На GPT-5.6 Sol объём записи в кэш вырос с 0,0141 млрд до 0,0316 млрд токенов. Несмотря на это, заявленная общая стоимость прогона сократилась с $1339 до $894.
Этот результат показывает, почему расходы агентской системы нельзя оценивать только по размеру контекста или одной категории токенов. Итог зависит от числа запросов, повторного использования кэша, цен конкретного API и того, какие операции выполняет обвязка.
Авторы также оценивают потенциальную почасовую экономию в $8,75–$13,50 относительно штатных обвязок Codex и Claude Code и в $4,36–$5,71 относительно базового Pi. Это расчёт для исследовательской конфигурации, а не гарантированный тарифный эффект. Реальная экономия для команды будет зависеть от модели, продолжительности сессий, структуры репозитория и доли задач, где механизмы SoL-Pi действительно срабатывают.
В частности, из этих цифр нельзя автоматически заключить, что любой пользователь сократит ежемесячный счёт ровно на треть. Для коротких заданий, небольших контекстов или другого профиля кэширования эффект может отличаться.
Перенос на Opus 5 остаётся предварительным
По наблюдению исследователей, на Opus 5 механизмы запускались реже, чем на GPT-5.6 Sol. Возможное объяснение — весь поисковый этап основывался только на траекториях GPT-5.6 Sol. Это ограничивает вывод о том, что одна и та же обвязка будет одинаково эффективна с разными моделями.
Показатели EdgeBench также не заменяют тестирование на реальном рабочем процессе. Публичный бенчмарк не обязательно отражает крупные монорепозитории, длительные миграции, нестабильные тесты или задачи, требующие многократного взаимодействия с внешними инструментами.
Код SoL-Pi, по сообщению авторов, опубликован как расширение с лицензией MIT в организации NVlabs на GitHub. Заявлена работа с немодифицированным Pi версии 0.85.1 и Node.js 22.19 или новее. Базовый проект и его актуальную структуру можно проверить в репозитории Pi, а сведения об исследовательских публикациях команды — на портале NVIDIA Research.
Перед внедрением разработчикам стоит проверить точный адрес и историю изменений репозитория SoL-Pi, совместимость версий и условия лицензии непосредственно в файлах проекта. Практический тест лучше проводить на собственном наборе типовых задач: сравнить успешность выполнения, входные и выходные токены, операции с кэшем, число вызовов инструментов и полную стоимость одного завершённого задания. Только такой парный прогон покажет, переносится ли заявленная экономия EdgeBench на конкретный рабочий процесс.