SWE-bench: classificação 2026 dos LLM open-source para programação

Avaliar um LLM localmente com o SWE-bench permite medir a capacidade real de um modelo de pesos abertos de resolver bugs reais do GitHub, muito além das pontuações do HumanEval. O SWE-bench para LLM se destaca porque exige que o modelo navegue por um repositório completo, compreenda uma issue, modifique vários arquivos e passe na suíte de testes. Este artigo detalha a mecânica do benchmark, a variante SWE-bench Verified, os requisitos de hardware, os modelos candidatos do catálogo, o procedimento de execução local e, em seguida, responde às perguntas frequentes de quem trabalha com auto-hospedagem.

Entender a mecânica do SWE-bench

SWE-bench é um benchmark publicado em 2023 pela Universidade de Princeton que coleta 2.294 problemas reais do GitHub provenientes de 12 projetos populares em Python (Django, scikit-learn, sympy, matplotlib, etc.). Cada tarefa fornece ao modelo um repositório com um commit específico e a descrição de uma issue. O LLM deve produzir um patch (diff) que, uma vez aplicado, faz os testes que antes falhavam passarem sem quebrar os testes existentes. Para detalhes sobre a construção do dataset, veja o artigo original do SWE-bench e o repositório oficial no GitHub.

Diferente de HumanEval, que avalia funções curtas isoladas, o SWE-bench mede:

Compreensão contextual : ler um repositório com dezenas de milhares de linhas
Localização de bug : identificar os arquivos corretos para modificar sem orientação explícita
Edição de vários arquivos : produzir um patch coerente que não quebre nada
Raciocínio em cadeias longas : alternar entre exploração, hipótese e verificação

Uma pontuação bruta de 20 % no SWE-bench geralmente corresponde a uma pontuação acima de 80 % no HumanEval, o que explica por que muitos modelos apresentam excelente desempenho no HumanEval, mas sofrem uma queda acentuada no SWE-bench.

SWE-bench Verified: a versão filtrada

SWE-bench Verified é um subconjunto de 500 instâncias anotadas manualmente pela OpenAI em colaboração com os autores de Princeton. O objetivo: remover tarefas cujo enunciado é ambíguo, cujos testes ocultos são específicos demais ou cujo patch de referência depende de um contexto não fornecido. Detalhes completos no blog da OpenAI dedicado ao Verified.

Para um teste local, SWE-bench Verified é a escolha certa :

500 instâncias ao invés de 2.294: execução realizável em alguns dias em uma estação
Avaliação mais confiável do raciocínio real do modelo
Comparação direta com as pontuações publicadas pelos fornecedores

O agente mais usado como referência é SWE-agent, um sistema que disponibiliza um terminal interativo ao LLM, permitindo que ele edite arquivos, execute comandos e realize testes. Uma alternativa popular é OpenHands, que suporta nativamente backends compatíveis com OpenAI (vLLM, llama.cpp server, SGLang).

Modelos do catálogo adequados ao benchmark

O LLM de um agente de programação deve combinar um contexto amplo (o ambiente de execução do agente, ou harness, injeta stack traces, código-fonte e o histórico de ações) e um bom desempenho em raciocínio. Aqui estão os candidatos do catálogo ordenados por perfil de hardware.

Estações de trabalho com capacidade de VRAM muito alta (≥ 400 GB)

DeepSeek V3.2 (685B, MIT) — VRAM Q4 ~410 GB, contexto 128k. Referência atual entre os modelos de pesos abertos no SWE-bench Verified, segundo avaliações independentes.
DeepSeek R1 671B (671B, MIT) — VRAM Q4 ~400 GB, contexto 128k. Modelo de raciocínio de longa cadeia, especialmente adequado para localização de bugs.
Mistral Large 3 675B (675B, Apache 2.0) — VRAM Q4 ~405 GB, ctx 256k. Licença permissiva, interessante para uso comercial.
Kimi K2.6 (1000B, Modified MIT) — VRAM Q4 ~600 GB, ctx 256k. Otimizado para workflows agênticos segundo Moonshot.

Cluster multi-GPU (140 a 250 GB)

Qwen 3 235B-A22B (235B, Apache 2.0) — VRAM Q4 ~142 GB, ctx 131k. MoE com 22B de parâmetros ativos, boa relação custo/qualidade.
Llama 4 Maverick 400B (400B, Llama 4 Community) — VRAM Q4 ~240 GB, contexto 1M. Contexto excepcional para grandes repositórios.
GLM-5.1 (744B, MIT) — VRAM Q4 ~445 GB, contexto 200k.

Estação única (≤ 80 GB)

Qwen3-Coder-Next 80B-A3B (80B, Apache 2.0) — VRAM Q4 ~48 GB, contexto 262k. Especializado em código, executável em uma A100 80GB ou duas 3090.
gpt-oss 120B (117B, Apache 2.0) — VRAM Q4 ~70 GB, ctx 128k. Modelo de OpenAI publicado com pesos abertos.
Mistral Small 4 (119B, Apache 2.0) — VRAM Q4 ~72 GB, ctx 256k.

Para um comparativo detalhado no campo do código, veja Qwen3-Coder vs DeepSeek V3.2 e a página Melhor LLM para código.

Tokens/s e impacto na duração da execução

Uma execução completa do SWE-bench Verified consome entre 500 milhões e 2 bilhões de tokens, dependendo da estrutura de execução e do número de tentativas permitidas. A taxa de tokens por segundo determina, portanto, diretamente a duração do benchmark.

Estimativas indicativas (a confirmar no seu setup) :

DeepSeek V3.2 em 8×H100 80GB em Q4: ~25 tokens/sec na geração, execução do Verified estimada entre 5 e 8 dias
Qwen 3 235B-A22B em 4×H100: ~40 tokens/s em Q4 (ter 22B de parâmetros ativos no MoE ajuda), execução estimada em 3 a 5 dias
Qwen3-Coder-Next 80B-A3B em 2×A100 80GB: ~60 tokens/seg em Q4, tempo estimado de 2 a 3 dias
gpt-oss 120B em 1×H200 141GB em Q4: ~35 tokens/sec, tempo estimado de execução de 3 a 4 dias

O contexto efetivo importa tanto quanto a velocidade bruta: o SWE-agent injeta regularmente de 30k a 60k tokens no prompt para reconstruir o estado do repositório. Um modelo limitado a 32k de contexto é pouco adequado; busque pelo menos 128k. Ver também o guia de VRAM por quantização para ajustar seu orçamento de memória.

Procedimento de execução local

Aqui está um procedimento simplificado para uma configuração estritamente auto-hospedada.

Preparar o ambiente Docker : SWE-bench Verified exige imagens Docker por projeto (Django, sympy, etc.) para isolar a execução dos testes. Reserve 80 GB de espaço em disco para as imagens oficiais publicadas pelos mantenedores.
Iniciar um servidor de inferência compatível com OpenAI : com vLLM ou llama.cpp em modo servidor, disponibilize seu modelo em localhost:8000/v1. Para Qwen3-Coder-Next em Q4 em 2×A100, um comando típico do vLLM configura --tensor-parallel-size 2 --max-model-len 131072 --quantization awq.
Clonar SWE-agent e configurar o harness de avaliação para apontar para o endpoint local. O arquivo de configuração aceita api_base: http://localhost:8000/v1 et model_name: <votre-modèle>.
Iniciar uma execução de calibração em 10 a 20 instâncias para verificar se a formatação das ações é respeitada. Muitos modelos com pesos abertos falham aqui porque inventam tags XML que o sistema de avaliação não reconhece.
Execução completa : 500 instâncias, vários dias, registrar sistematicamente os patches gerados para análise pós-mortem.
Envio opcional ao leaderboard oficial para comparação pública.

Dica prática: limite o número de ações por instância (50-75) para evitar que um modelo entre em um loop infinito que consuma seu orçamento de tokens.

Interpretação dos resultados

Uma pontuação bruta no SWE-bench Verified deve ser interpretada em termos relativos, não absolutos.

< 10 % : o modelo não domina o formato de ação do agente, ou seu contexto é muito curto
10-25 % : nível satisfatório para um modelo generalista com pesos abertos
25-50 % : nível esperado de um modelo especializado em raciocínio (DeepSeek R1 671B, Kimi K2.6)
> 50 % : nível de fronteira, atingido pelos melhores modelos proprietários

Além do score, veja a distribuição das falhas : testes que excedem o tempo limite, patches que não podem ser aplicados, arquivos modificados fora do escopo. Essa análise frequentemente revela que o modelo é limitado não pelo seu raciocínio, mas pela estrutura de execução (tamanho da janela, análise sintática das ações). Para aprofundar a seleção de modelos para agentes, consulte o guia LLM para agentes.

FAQ

P: SWE-bench ou SWE-bench Verified para o primeiro teste?

Verified, sem hesitação. As 500 instâncias são anotadas manualmente, as ambiguidades são removidas e o tempo de execução permanece razoável em uma única estação de trabalho. O SWE-bench completo (2.294 instâncias) contém tarefas mal especificadas que penalizam injustamente os modelos. O Verified também oferece uma comparação direta com as pontuações publicadas pelos fornecedores de modelos proprietários.

P: Qual quantização escolher para preservar a pontuação em código?

Q4_K_M (GGUF) ou AWQ 4-bit geralmente reduzem em 1 a 3 pontos o desempenho no SWE-bench em comparação com FP16, o que permanece aceitável. Evite Q3 e Q2 em modelos de raciocínio, onde a perda se torna significativa. Se a sua VRAM permitir, Q5_K_M ou Q8 oferecem um melhor equilíbrio. Veja o comparativo de quantização GGUF vs AWQ.

P: É necessário um modelo "coder" especializado ou um generalista?

Os dois perfis funcionam. Modelos especializados em código como Qwen3-Coder-Next 80B-A3B se destacam na geração de patches, mas os modelos de raciocínio generalistas como DeepSeek R1 671B são frequentemente superiores na localização de bugs e no planejamento em múltiplas etapas, que dominam o custo de uma tarefa SWE-bench.

P: É possível rodar o SWE-bench Verified em uma única RTX 4090?

Difícil. 24 GB de VRAM limitam você a modelos ≤ 30B em Q4, e esses modelos geralmente ficam abaixo de 10% no Verified por falta de capacidade de raciocínio suficiente. Você pode usá-lo para validar seu pipeline com um modelo leve como Qwen3-Coder-Next com offload parcial para a CPU, mas procure usar 2×3090 ou 1×A100 80GB para obter um resultado útil.

Q: Quantos tokens um run completo consome?

Estimado entre 500 milhões e 2 bilhões de tokens conforme o ambiente de execução e avaliação (SWE-agent, OpenHands, personalizado) e o número máximo de ações permitidas por instância. Com um orçamento de 50 ações por instância e um contexto médio de 30 mil tokens, conte com aproximadamente 1 bilhão de tokens para 500 instâncias. Quanto mais o modelo “pensa” em cadeia (estilo R1), mais a conta de tokens aumenta.

P: Os resultados locais são comparáveis aos scores do leaderboard?

Sim, desde que você use o harness oficial de avaliação, a mesma versão do conjunto de dados e respeite o protocolo de submissão (um único patch por instância, sem novas tentativas com oráculo). Qualquer modificação no harness ou no prompt de sistema deve ser documentada. O leaderboard SWE-bench aceita submissões de execuções em infraestrutura própria e verifica a reprodutibilidade.

Conclusão

Executar o SWE-bench com um LLM localmente continua sendo o teste mais revelador para distinguir um modelo de código com pesos abertos de um modelo que apenas se sai bem no HumanEval. Com SWE-bench Verified, uma estação com 2×A100 ou 4×H100 e um modelo adequado (Qwen3-Coder-Next, DeepSeek V3.2 ou gpt-oss 120B), uma execução realista é concluída em poucos dias. Para calibrar sua configuração antes de iniciar o benchmark, use o configurador de QualLLM ou navegue pelo catálogo completo.