Anthropic показала: конфигурация инфраструктуры сдвигает баллы Terminal-Bench на 6 п.п.

Инфраструктура может сдвинуть результат агентного кодинг-бенчмарка на несколько процентных пунктов, а иногда сильнее, чем разделяет лидеров таблицы. К такому выводу пришли инженеры Anthropic, прогнав Terminal-Bench 2.0 в шести конфигурациях ресурсов. Между самой строгой и самой щедрой настройкой разница составила 6 п.п. при p < 0,01. При этом модель, обвязка и набор задач оставались неизменными.

Как нашли проблему

Anthropic запускает Terminal-Bench 2.0 на кластере Google Kubernetes Engine. При калибровке команда заметила, что баллы не совпадают с официальным лидербордом, а доля инфраструктурных ошибок неожиданно высока: до 6% задач падали из-за сбоев подов, никак не связанных со способностями модели.

Причина оказалась в способе применения лимитов. Реализация на Kubernetes трактовала рекомендованные ресурсы задачи одновременно как гарантированный минимум и как жёсткий потолок. Контейнер получал ровно столько памяти, сколько указано, и умирал при малейшем превышении. Кратковременный скачок потребления приводил к OOM-kill, хотя задача могла бы завершиться успешно. Провайдер песочниц, который использует лидерборд Terminal-Bench, более лоялен: он допускает временное превышение и не убивает контейнер.

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

Авторы прогнали бенчмарк от строгого соблюдения спецификаций (1x) до полного отсутствия лимитов. Ключевые цифры:

• доля инфраструктурных ошибок падает монотонно: с 5,8% при 1x до 0,5% без ограничений;
• переход от 1x к 3x снижает ошибки с 5,8% до 2,1% (p < 0,001);
• в диапазоне 1x–3x успешность колеблется в пределах шума (p = 0,40);
• выше 3x успешность растёт быстрее, чем убывают ошибки: ещё −1,6 п.п. ошибок дают почти +4 п.п. успеха;
• итоговый прирост без лимитов относительно 1x — +6 п.п. (p < 0,01);
• на SWE-bench (227 задач, по 10 семплов, RAM до 5x) прирост всего 1,54 п.п.

До отметки 3x дополнительные ресурсы лечат нестабильность: бенчмарк становится надёжнее, но не легче. Выше агент начинает решать то, что раньше не мог: тянет тяжёлые зависимости, запускает дорогие подпроцессы, гоняет ресурсоёмкие тесты. Заметнее всего выросли задачи rstan-to-pystan и compile-compcert.

Что именно измеряет бенчмарк

Тесные лимиты вознаграждают экономные стратегии, щедрые — подходы с грубой силой. Пример — задача bn-fit-modify на подгонку байесовской сети. Часть моделей сразу ставит pandas, networkx и scikit-learn. При щедрых лимитах это работает, при жёстких под падает от нехватки памяти ещё на установке. Есть и лёгкий путь: реализовать математику на стандартной библиотеке, и некоторые модели выбирают именно его. Конфигурация ресурсов решает, какая привычка окажется выигрышной.

Эффект воспроизвёлся на разных моделях Anthropic, хотя величина различалась. На других семействах тенденция, по-видимому, сохраняется, но строго это не проверяли. Есть и менее изученные факторы: Anthropic анекдотически наблюдала колебания проходимости в зависимости от времени суток, вероятно из-за задержек API.

Практические выводы

Авторы рекомендуют задавать для каждой задачи два параметра, гарантированный объём и порог убийства контейнера, а не одно значение. Зазор нужно калибровать так, чтобы баллы на нижней и верхней границе различались в пределах шума. Для Terminal-Bench 2.0 потолок 3x срезал инфраструктурные ошибки примерно на две трети и почти не завысил результат. Множитель нужно публиковать вместе с результатами.

Для тех, кто читает лидерборды, вывод прямой: отрыв меньше 3 п.п. без документированной конфигурации стоит воспринимать скептически. Разброс в умеренном диапазоне ресурсов чуть меньше 2 п.п., и он накладывается на обычные биномиальные доверительные интервалы в 1–2 п.п., а на краях диапазона достигает 6. Лабораториям стоит относиться к ресурсам как к полноценной экспериментальной переменной, наравне с форматом промпта и температурой. Мейнтейнерам бенчмарков — публиковать не только рекомендованные спецификации, но и методику их применения. Иначе лидерство в пару пунктов может означать просто более мощную виртуальную машину.