Tempo de leitura: 5 minutos
Olá, é um prazer inenarrável estar mais uma vez escrevendo este post. Um agente de código pode alterar centenas de linhas, executar os testes locais e parecer pronto para uso. Mas o que acontece quando o sistema precisa carregar um modelo real, receber uma solicitação pela API e entregar a resposta correta? É justamente essa diferença entre passar por verificações isoladas e funcionar no caminho completo de inferência que o novo benchmark SWE-Serve tenta medir.
Apresentado pela NVIDIA em 23 de setembro de 2026, o SWE-Serve avalia agentes de programação em tarefas relacionadas ao SGLang, sistema de código aberto para servir grandes modelos de linguagem. Os resultados indicam que os testes locais, sozinhos, podem transmitir uma confiança maior do que a realidade permite.
O que o SWE-Serve avalia
O SWE-Serve foi criado para testar mudanças em escala de repositório dentro da pilha de serving de modelos. Em vez de limitar a avaliação à geração de kernels ou à otimização de desempenho, o benchmark cobre problemas que vão do carregamento de modelos ao atendimento de solicitações por uma interface de serviço.
A primeira versão transforma 83 pull requests incorporados ao SGLang em 53 tarefas executáveis, distribuídas por seis áreas de engenharia: decodificação avançada, suporte a modelos e backends, kernels e quantização, APIs de serving, cache e estado de execução, além de execução distribuída e agendamento.
Doze tarefas são executadas em CPU e 41 usam uma única GPU NVIDIA H100. As mudanças avaliadas são substanciais: a solução de referência mediana altera 553 linhas distribuídas por sete arquivos, enquanto os verificadores normalmente combinam testes para o novo comportamento com testes de regressão.
Como o SWE-Serve expõe a diferença entre teste local e serving real
A principal descoberta aparece quando o servidor é realmente iniciado. Das 53 tarefas, 19 carregam um modelo e verificam o patch por meio de uma interface de serving ao vivo. Nessas tarefas, 627 patches foram avaliados: a taxa de aprovação foi de 45,9% com o verificador completo, mas subiu para 69,4% quando os testes de serving foram retirados.
Na prática, 147 patches mudaram de reprovados para aprovados quando a etapa de serving ao vivo foi excluída. Isso significa que aproximadamente um em cada três patches que passavam pelas outras verificações falhava quando precisava funcionar no caminho completo entre a solicitação e a resposta.
O exemplo citado pela NVIDIA envolve uma tarefa de suporte aos modelos Qwen3.5, incluindo uma versão densa de 0,8 bilhão de parâmetros e uma versão Mixture-of-Experts de 35 bilhões de parâmetros, com 3 bilhões de parâmetros ativos. O agente precisa fazer os modelos carregarem e responderem por interfaces normais do SGLang, além de lidar com entradas de imagem e vídeo, solicitações compatíveis com a API da OpenAI, geração em lote e log probabilities.
Esse tipo de avaliação é diferente de verificar apenas se uma função retorna o valor esperado. É como testar cada peça de um carro sobre a bancada e concluir que o veículo está pronto sem jamais ligá-lo. O serving ao vivo verifica se as peças continuam funcionando quando precisam operar juntas.
SWE-Serve mostra que tarefas atravessam vários domínios
O benchmark também separa o caminho de uma solicitação em quatro domínios de execução: entrada e saída, agendamento e ciclo de vida da solicitação, execução do modelo e gerenciamento do cache KV e dos recursos de execução.
As 26 tarefas restritas a um único domínio tiveram taxa de aprovação de 69%. Já as 27 tarefas que atravessavam mais de um domínio alcançaram 47,7%, uma diferença de 21,3 pontos percentuais. O resultado sugere que a dificuldade não está apenas na quantidade de código alterado, mas nas conexões entre partes diferentes do sistema.
Esse ponto é especialmente importante para quem acompanha a evolução dos agentes de IA e suas avaliações. Um agente pode ser competente em modificar um componente isolado e ainda assim falhar ao lidar com efeitos colaterais em cache, agendamento, execução e comunicação com a API.
Os resultados variam bastante entre os modelos
A NVIDIA avaliou 11 modelos e 31 configurações de esforço usando o mini-swe-agent, um agente de engenharia de software que opera apenas com Bash e em condições de acesso restrito à informação externa. Cada configuração executou o benchmark completo de 53 tarefas três vezes.
Considerando a melhor configuração testada para cada modelo, a média de aprovação na primeira tentativa variou de 34,6% a 75,5%. Entre os resultados divulgados, Claude Opus 5 e GPT-5.6 Sol alcançaram 75% com desvios padrão de 3% e 6%, respectivamente. O custo médio por tarefa, porém, foi diferente: US$ 17,40 para o primeiro e US$ 12,26 para o segundo.
A relação entre preço e desempenho também não foi direta. Entre quatro modelos com média de 64%, o custo médio por tarefa variou de US$ 0,95 a US$ 7,24, enquanto o tempo médio ficou entre 25,5 e 99,9 minutos. Portanto, escolher um agente para tarefas de engenharia não depende apenas da maior pontuação geral: custo, velocidade e especialidade também entram na conta.
O que o SWE-Serve não prova
Uma aprovação no SWE-Serve tem um significado específico: o patch satisfez o verificador do benchmark nas condições de hardware declaradas. Isso não significa que a alteração esteja pronta para produção, que deva ser incorporada ao SGLang ou que tenha sido aprovada pelos mantenedores do projeto.
A primeira versão também possui limites. Ela não avalia outros mecanismos de inferência, execução com várias GPUs ou serving em múltiplos nós. Além disso, o benchmark usa tarefas baseadas no SGLang, portanto seus resultados não devem ser tratados como uma medida universal da capacidade de qualquer agente em todo tipo de projeto.
A equipe afirma ter analisado 786 possíveis fontes de tarefas, criado 156 candidatas executáveis e selecionado 53. Os testes foram realizados no hardware declarado, e os experimentos impediram o acesso à web pública e aos repositórios upstream. O acesso ao Hugging Face foi mantido para permitir o download dos pesos dos modelos.
Por que o SWE-Serve importa para agentes de código
O SWE-Serve reforça uma ideia simples, mas frequentemente esquecida: um teste que passa não é necessariamente uma funcionalidade que funciona. Em sistemas de inferência, o comportamento final depende de várias camadas conectadas, e um erro pode aparecer somente quando o modelo é carregado, uma solicitação chega pela API ou várias requisições são processadas ao mesmo tempo.
Para os agentes de código, isso muda o que significa resolver uma tarefa. Não basta editar arquivos até os testes existentes ficarem verdes. O agente precisa entender o fluxo de execução, prever como a mudança interage com o runtime e validar o resultado por uma interface próxima daquela usada na prática.
É essa a principal contribuição do benchmark: transformar em números a distância entre um patch que parece correto no ambiente local e um patch que realmente atravessa todo o caminho de serving. No SWE-Serve, essa distância aparece claramente nos 45,9% de aprovação com testes completos contra 69,4% sem as verificações de serving ao vivo.
O projeto pode ser explorado no leaderboard do SWE-Serve, e seus ambientes, verificadores e configurações de referência estão disponíveis no repositório do SWE-Serve no GitHub. Para quem desenvolve ou avalia agentes de programação, a mensagem é direta: testes unitários são essenciais, mas o servidor também precisa ser colocado para trabalhar.
