Snorkel гоняет миллионы агентных симуляций в месяц и экономит 20% на песочницах

Оценка агентов — не то же самое, что оценка чат-бота. Модель не просто отвечает на вопрос: она открывает терминал, ставит пакеты, запускает обучение, ломает и чинит сервисы. Чтобы понять, насколько она хороша, ей нужно дать настоящее рабочее место. Об этом кейс Snorkel — data-лаборатории, которая делает датасеты и бенчмарки для фронтирных лабораторий и корпораций. Среди прочего, она участвует в Terminal-Bench.

Зачем агенту реалистичная среда

Проблема знакомая всем, кто гонял агентные эвалы. Агент провалил задачу, но почему? Модель не справилась или у неё просто не оказалось нужного инструмента? Если среда урезана, бенчмарк измеряет не способности модели, а ограничения вашей инфраструктуры.

Задачи у Snorkel разные: кодинг, инфраструктура, ML-инжиниринг. ML-агенту для обучения модели нужен GPU. Инфраструктурному агенту может понадобиться целое ядро Linux и несколько контейнеров. Поэтому команда запускает симуляции в песочницах Modal, включая VM-песочницы с мультисервисными системами и GPU-нагрузкой. Один провайдер для GPU и CPU упрощает и инфраструктуру, и учёт расходов. По словам Snorkel, GPU-песочницы нужного масштаба они получили только у Modal.

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

Почему ресурсы под агента так сложно оценить

Раньше команда прикидывала CPU и память для каждой песочницы заранее. Выходило плохо в обе стороны. Если дать мало, агент падает из-за нехватки ресурсов, и прогон невалиден: это не ошибка модели, а шум в метрике. Если перестраховаться, вы платите за простаивающее железо.

Угадать сложно по двум причинам. Во-первых, нагрузка рваная. Агент ждёт ответа LLM, потребление почти нулевое, потом запускается, скажем, grep по большому репозиторию — и случается пик. Во-вторых, весь код в песочнице пишет сама модель, а бенчмарков много, поэтому профиль нагрузки заранее неизвестен.

Выход — bursting в Modal. Песочница на лету расширяет память или CPU, когда это нужно. Платить приходится за фактическое потребление или за заявленный минимум, смотря что больше. Это позволило запрашивать меньше ресурсов и не получать падений. Snorkel говорит об экономии около 20% на общем счёте за песочницы, а число прогонов, упавших из-за лимитов, сократилось.

Оговорка: пока bursting используют лишь 10–15% песочниц Snorkel. Цифра в 20% — оценка самой компании, да ещё в кейсе, который публикует вендор. Воспринимайте её как ориентир, а не как гарантию для вашей нагрузки.

Инференс под бенчмарк

Вторая половина задачи — сами модели. Для первичных проверок новых open-weight моделей Snorkel берёт готовый общий эндпоинт. Если нужна модель, которую заказчик дообучил, команда поднимает её с кастомными весами на выделенном эндпоинте. Важная деталь: всё это делается без участия инфраструктурной команды. Подняли модель, прогнали бенчмарк, свернули.

В планах — оценить Modal ещё и для обучения, чтобы замкнуть цикл «данные → обучение → оценка» на одной платформе.

Что взять себе

• Если строите эвалы агентов, разделяйте «агент не смог» и «среда не позволила». Логируйте причины падений и отдельно считайте отказы по ресурсам.
• Не закладывайте ресурсы наугад ни по среднему, ни по максимуму. Снимите пиковые CPU и память на выборке прогонов (Snorkel строил такой график по 5 000 песочниц) и рассмотрите эластичные лимиты.
• Если агентам нужен GPU внутри песочницы, проверьте, что провайдер тянет его в нужном масштабе, до того как проектировать бенчмарк.
• Если заказчик ждёт ответа за сутки, важна не средняя скорость, а пиковая параллельность.

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