Snorkel executa milhões de simulações de agentes por mês e economiza 20% em sandboxes

Avaliar agentes não é o mesmo que avaliar um chatbot. O modelo não apenas responde a uma pergunta: ele abre um terminal, instala pacotes, inicia treinamentos, quebra e conserta serviços. Para entender quão bom ele é, é preciso dar a ele um verdadeiro local de trabalho. É disso que trata o caso da Snorkel — um laboratório de dados que cria datasets e benchmarks para laboratórios de fronteira e corporações. Entre outras coisas, ela participa do Terminal-Bench.

Por que o agente precisa de um ambiente realista

O problema é familiar a todos que já rodaram avaliações de agentes. O agente falhou na tarefa, mas por quê? O modelo não deu conta ou simplesmente não tinha a ferramenta necessária? Se o ambiente é reduzido, o benchmark mede não a capacidade do modelo, mas as limitações da sua infraestrutura.

As tarefas da Snorkel são variadas: programação, infraestrutura, engenharia de ML. Um agente de ML precisa de GPU para treinar um modelo. Um agente de infraestrutura pode precisar de um kernel Linux inteiro e de vários contêineres. Por isso a equipe executa as simulações em sandboxes da Modal, incluindo sandboxes de VM com sistemas multisserviço e carga de GPU. Um único provedor para GPU e CPU simplifica tanto a infraestrutura quanto o controle de custos. Segundo a Snorkel, sandboxes com GPU na escala necessária ela só encontrou na Modal.

A escala é esta: milhões de sandboxes por mês, com picos de dezenas de milhares por hora. O motivo não é capricho. Quando sai um novo modelo ou um antigo é ajustado, o cliente quer saber em até um dia se ele serve para o seu caso. Isso significa que é preciso lançar rapidamente muitas execuções paralelas em uma mistura de benchmarks públicos e fechados.

Por que é tão difícil estimar os recursos de um agente

Antes, a equipe estimava CPU e memória de cada sandbox com antecedência. O resultado era ruim nos dois sentidos. Se der pouco, o agente cai por falta de recursos e a execução se torna inválida: não é erro do modelo, é ruído na métrica. Se exagerar na cautela, você paga por hardware ocioso.

Adivinhar é difícil por dois motivos. Primeiro, a carga é irregular. O agente espera a resposta do LLM, e o consumo é quase zero; depois ele executa, digamos, um grep em um repositório grande — e ocorre um pico. Segundo, todo o código na sandbox é escrito pelo próprio modelo, e há muitos benchmarks, então o perfil de carga é desconhecido de antemão.

A saída é o bursting na Modal. A sandbox expande memória ou CPU em tempo real quando necessário. Paga-se pelo consumo real ou pelo mínimo declarado, o que for maior. Isso permitiu solicitar menos recursos sem sofrer quedas. A Snorkel fala em uma economia de cerca de 20% na fatura total de sandboxes, e o número de execuções que falharam por limites diminuiu.

Ressalva: por enquanto, apenas 10–15% das sandboxes da Snorkel usam bursting. O número de 20% é uma estimativa da própria empresa, em um caso publicado por um fornecedor. Encare-o como referência, não como garantia para a sua carga.

Inferência para o benchmark

A segunda metade do problema são os próprios modelos. Para as verificações iniciais de novos modelos open-weight, a Snorkel usa um endpoint compartilhado pronto. Se é preciso um modelo que o cliente refinou, a equipe o sobe com pesos customizados em um endpoint dedicado. Um detalhe importante: tudo isso é feito sem a participação da equipe de infraestrutura. Sobe-se o modelo, roda-se o benchmark, desliga-se.

Os planos incluem avaliar a Modal também para treinamento, a fim de fechar o ciclo «dados → treinamento → avaliação» em uma única plataforma.

O que levar para si

• Se você constrói avaliações de agentes, separe «o agente não conseguiu» de «o ambiente não permitiu». Registre as causas das falhas e conte separadamente os fracassos por recursos.
• Não defina recursos no chute, nem pela média nem pelo máximo. Meça os picos de CPU e memória em uma amostra de execuções (a Snorkel construiu esse gráfico com 5 000 sandboxes) e considere limites elásticos.
• Se os agentes precisam de GPU dentro da sandbox, verifique se o provedor a entrega na escala necessária antes de projetar o benchmark.
• Se o cliente espera a resposta em um dia, importa não a velocidade média, mas a paralelização de pico.

No geral, isto não é um avanço tecnológico, mas uma análise de engenharia cuidadosa de como é a infraestrutura aplicada para avaliar agentes. A principal conclusão: uma métrica honesta de um agente depende não só do modelo, mas também de quão corretamente você lhe forneceu os recursos.