Команда ARC-AGI-3 ускорила агента с 500 до 3400 токенов в секунду

В соревновании ARC-AGI-3 участник занял шестое место и вынес оттуда урок, который полезен далеко за пределами игровых агентов. Когда вычислительный бюджет фиксирован девятью часами, выигрывает не обязательно самый хитрый промпт. Иногда решающим становится то, сколько полноценных попыток агент успеет сделать и сколько качества вы потеряете ради этой скорости.

Автор начинал примерно с десяти параллельных игровых линий и скорости около 500 токенов в секунду. После месяца работы сервер выдавал около 3400 токенов в секунду и одновременно обслуживал 110 линий на GPU с 96 ГБ памяти. Однако простое ускорение не гарантировало роста результата: некоторые оптимизации незаметно портили ответы модели, а после нескольких часов игры появлялось плато.

Почему промпты почти не помогли

Сначала участник перебрал привычный набор идей: двух агентов с судьёй, разные способы представления поля, отдельного «фотографа» игровых механик, программную модель мира, рой советчиков и агента со свежим взглядом. Почти все варианты давали результат на уровне шума либо ухудшали его.

Базовый агент уже умел получать изображение и ASCII-представление поля, запускать Python для анализа и выбирать действие. Дополнительные роли увеличивали расход токенов, но не устраняли главное ограничение: агенту требовалось больше независимых попыток пройти 110 игр. В условиях конкурса очередной красивый слой рассуждений оказывался менее полезным, чем ещё несколько завершённых траекторий.

Это хороший тест для любой агентной системы. Если новая схема выглядит умнее, но не повышает долю успешно выполненных задач на повторяемом наборе, перед вами пока не улучшение, а дорогая гипотеза.

Как уместить 110 линий на одной карте

Основную память GPU занимали веса модели и её 512 экспертов. Поэтому состояние игровых линий вынесли в оперативную память, KV-кэш сжали до четырёхбитного формата, а число доступных экспертов сначала сократили до 400. Это позволило резко увеличить параллелизм.

Отдельный выигрыш дала пакетная обработка входящих сообщений. Когда несколько игр одновременно возвращают модели новые наблюдения, их выгоднее обработать вместе: чтение входного контекста хорошо распараллеливается, тогда как генерация ответа всё равно идёт токен за токеном. Планировщик собирал несколько запросов на такую обработку, уменьшая число дорогих запусков.

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

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

Скорость нужна до точки насыщения

Самая практичная находка — горячая смена режима. Первые шесть часов агент работал быстро с 400 экспертами и запускал максимум линий. Когда простые игры завершались и оставалось около 70 сложных, система подключала все 512 экспертов и переходила к более качественной генерации. Такой режим поднял результат примерно с 50 до 54 очков.

Больше токенов после определённого момента почти не помогало. Агент быстро забирал простые уровни, а затем застревал на трудных: разница между 600 тысячами и 900 тысячами токенов на игру становилась небольшой. Это и есть практический предел масштабирования попыток без улучшения самого решателя.

Для разработчиков вывод простой: измеряйте не только токены в секунду. Нужны как минимум три графика — пропускная способность, качество решения и результат в зависимости от времени. Оптимизируйте сначала число полезных попыток, затем найдите точку насыщения и верните качество на финальном участке. И обязательно проверяйте каждое ускорение на длинных траекториях: микроскопическая ошибка, незаметная в одном ответе, может стоить всей задачи.