A.T.L.A.S - GPU de US$ 500 supera Claude Sonnet em benchmark de programação

• A.T.L.A.S (Adaptive Test-time Learning and Autonomous Specialization) é um sistema de IA auto-hospedado que entrega desempenho de geração de código em nível de grandes modelos usando uma única GPU de consumo
• No LiveCodeBench v5, registrou 74.6% pass@1-v(k=3), superando o Claude 4.5 Sonnet (71.4%) e alcançando uma melhoria de desempenho quase duas vezes maior em relação à versão anterior
• Mantendo congelado um modelo de 14B de parâmetros (Qwen3-14B-Q4_K_M), obtém alto desempenho com geração baseada em restrições, loop de autoverificação e correção e seleção de candidatos com Geometric Lens
• Executa de forma totalmente autônoma em ambiente local, sem nuvem nem chamadas de API, e o custo se resume ao consumo de energia, oferecendo alta eficiência de custo em comparação com modelos baseados em API
• Em um ambiente com RTX 5060 Ti 16GB GPU, processa 599 tarefas em cerca de 2 horas, mostrando que é possível reproduzir em hardware pessoal a capacidade de geração de código de grandes modelos

Resultados do benchmark

• LiveCodeBench v5: 74.6% pass@1-v(k=3), 599 tarefas executadas
  • Pipeline V3: PlanSearch + self-verified PR-CoT repair
• GPQA Diamond: 47.0%, 198 tarefas
• SciCode: 14.7%, 341 tarefas
• pass@k-v(k=3) não é o resultado de uma única tentativa, mas um método que inclui geração de 3 candidatos, seleção com Lens e correções iterativas em caso de falha

• Contribuição por etapa da V3 (Ablation Study)

  • A: base (sem V3) → 54.9%
  • B: Phase 1 (PlanSearch + BudgetForcing + DivSampling) → 67.3% (+12.4pp)
  • C: Phase 1+2 (Lens routing) → 67.3% (+0.0pp)
  • D: Phase 1+3 (self-verified refinement) → 74.6% (+7.3pp)
  • A Phase 3 realiza verificação interna com casos de teste gerados pelo próprio modelo, sem usar as respostas reais
  • O PR-CoT recuperou 36 de 42 problemas (85.7%) na Phase 3

Comparação de custo e desempenho

Sistema	LCB pass@1	Custo por tarefa	Observações
DeepSeek V3.2 Reasoning	86.2%	~$0.002	API, tentativa única
GPT-5 (high)	84.6%	~$0.043	API, tentativa única
ATLAS V3	74.6%	~$0.004	Apenas energia local, best-of-3 + repair
Claude 4.5 Sonnet	71.4%	~$0.066	API, tentativa única
Claude 4 Sonnet	65.5%	~$0.066	API, tentativa única

• O ATLAS gera apenas custo de energia, sem custo de API
• Com uma GPU de 165W, as 599 tarefas levam cerca de 1 hora e 55 minutos
• A latência é maior, mas a eficiência de custo é muito alta

Como funciona

• Pipeline completo

  • Phase 1: Generate
    • PlanSearch: extração de restrições e geração de planos variados
    • Budget Forcing: controle do uso de tokens
  • Etapa de Verify
    • Geometric Lens (C(x)): energy scoring com embeddings próprios de 5120 dimensões
    • Sandbox: execução e verificação do código
  • Phase 3: Repair
    • Self-Test Generation: o modelo gera seus próprios pares de entrada e saída
    • PR-CoT Repair: correção de código baseada em chain-of-thought de múltiplas perspectivas
  • Uma única instância do llama-server roda sobre K3s e realiza ao mesmo tempo speculative decoding e geração dos próprios embeddings
  • O Geometric Lens seleciona o melhor código entre os candidatos (87.8% de precisão em tarefas com resultados mistos)
  • As tarefas que falham seguem para a Phase 3, onde passam por geração de testes próprios e correções iterativas

Instalação e execução

• Clone o repositório no GitHub, copie o arquivo de configuração e execute o script de instalação
• Execute o benchmark V3 com benchmark/v3_runner.py
• Consulte docs/SETUP.md para o procedimento detalhado de instalação

Hardware e reprodução

Recurso	Mínimo	Ambiente de teste
GPU VRAM	16 GB	RTX 5060 Ti 16 GB
RAM do sistema	14 GB	16 GB
Python	3.10+	3.11
OS	RHEL 9 / Ubuntu 24	RHEL 9 (Proxmox VM)

• Reproduzido em ambiente com Proxmox VM + passthrough de GPU via VFIO
• Também pode rodar em outras GPUs NVIDIA com VRAM de 16GB ou mais, mas requer ajustes de driver e configuração de VRAM
• Principais parâmetros de ajuste:
  • número de slots --parallel (padrão 2, reduzir para 1 em caso de VRAM insuficiente)
  • quantização do KV cache (Q4_0)
  • comprimento de contexto por slot (padrão de 20480 tokens)
  • testes concluídos com CUDA 12.8
• V3.1 deve melhorar a portabilidade

Roadmap

• V3.0 (concluído, 2026-03-05)

  • Baseado em Qwen3-14B-Q4_K_M, com desempenho de 74.6% no LCB
  • Pipeline PlanSearch + BudgetForcing + Geometric Lens + PR-CoT concluído

• Limitações conhecidas

  1. Otimização focada em LCB: pouca otimização para outros benchmarks, como GPQA e SciCode
  2. Phase 2 (Lens routing): efeito mínimo devido à falta de dataset (+0.0pp)
  3. G(x) metric tensor desativado: C(x) não treinado, sem estrutura geométrica significativa
  4. Processamento single-thread: sem suporte a paralelização de tarefas
  5. Bug de stdio no SandboxAdapter: função de separação de entrada desativada (correção prevista para V3.1)

• V3.1 (em andamento)

  • Troca de modelo: Qwen3-14B → Qwen3.5-9B (DeltaNet linear attention, 3~4x mais rápido)
  • Retreinamento do Lens: recalibração de C(x) com base em feedback em tempo real
  • Redesenho da Phase 2: reimplementação ou remoção de G(x), correção do bug no SandboxAdapter
  • Introdução de paralelização: aumento da velocidade de processamento com execução paralela de tarefas
  • Suite de benchmarks expandida: inclusão de avaliação de raciocínio e conhecimento além de programação

• Benchmarks planejados para V3.1

  • Programação: LiveCodeBench v5, SciCode e datasets adicionais resistentes a contaminação
  • Raciocínio/Conhecimento: GPQA Diamond, AA-LCR, AA-Omniscience, Humanity’s Last Exam, CritPt etc.
  • O Confidence Router seleciona o caminho conforme a dificuldade da tarefa:
    • consulta simples → inferência rápida baseada em RAG (~30 segundos)
    • problema complexo de programação → pipeline completo (~20 minutos)
  • Meta: 80~90% LCB pass@1-v(k=3) e maior velocidade de processamento

Licença

• A.T.L.A.S Source Available License v1.0

[GN⁺]

Comentários no Hacker News

• Eu não espero que um agente gere grandes blocos de código
  Em vez disso, ele é muito mais útil para vasculhar logs ou analisar vários arquivos-fonte e explicar a causa de falhas em testes
  Acho que precisamos de benchmarks de depuração para avaliar essa capacidade. Seria bom ter testes que medissem familiaridade com sistemas de build ou CLI

  • Também concordo. É especialmente útil ao aplicar pequenas mudanças consistentes em toda a codebase
    Por exemplo, refatorei o app inteiro de hard delete para soft delete, e precisei alterar tanto a lógica de exclusão quanto as queries
    Fazer isso manualmente é tedioso e sujeito a erros, então fiquei realmente grato por o agente ter resolvido rápido
  • Para esse tipo de trabalho de longo prazo, SWE Bench Pro ou Terminal Bench 2 são mais adequados
    O SWE Bench Pro ainda não foi otimizado em excesso, então é confiável
    Já o SWE comum ou o LCB perderam muita utilidade por causa da competição de inflar números
  • Testes relacionados a sistema de build são cobertos pelo CompileBench (benchmark da Quesma)
    Só para contextualizar, sou fundador da Quesma
  • Eu passo o dia inteiro fazendo geração de código em larga escala
    Hoje em dia quase não escrevo código diretamente, seja na empresa ou em projetos paralelos
    Trabalho principalmente criando ferramentas para desenvolvedores em Rust e TypeScript
  • Eu também deixo a configuração de ambiente com o agente
    Faço deploy com kubectl / helm e, quando surge um problema, o agente depura por conta própria
    É surpreendente como algo que levava horas termina num instante

• Eu gostaria de recomendar a desenvolvedores que experimentassem modelos como MiniMax e Kimi no trabalho real
  Mas as desvantagens também aparecem rápido — maior consumo de tokens de raciocínio, saída lenta, queda de qualidade etc.
  Ainda assim, dá para economizar bastante se você gerenciar bem o roteamento de modelos e o reasoning budget
  Também é importante otimizar o app e os prompts para reduzir os tokens de saída

  • Também estou tendo resultados razoáveis com o Kimi
    Mas, em tarefas difíceis, a eficiência importa mais do que o simples preço por token
    A abordagem do link também funciona com Sonnet e Opus
    Só que MiniMax e Qwen ainda não chegam nesse nível
    No fim, o principal é projetar um harness que diferencie qual modelo é mais custo-efetivo para cada tarefa
  • Eu não uso modelos abaixo do estado da arte
    Testei o Opus 4.6 medium e me arrependi na hora. A diferença de qualidade é grande demais
  • Como mostra este link, o MiniMax tem desempenho fraco em tarefas que não são de programação
    resultado comparativo do aibenchy
  • Eu uso MiniMax todos os dias para programar
    Não ligo para consumo de tokens; no plano de 10 euros por mês dá para fazer 1500 requisições a cada 5 horas
    Na prática, ele não é mais lento que Opus ou Sonnet
    Nos benchmarks, os modelos da Anthropic parecem melhores, mas em trabalho real a diferença quase não existe
    Quando o MiniMax trava, eu mudo para o Opus, e depois volto para o MiniMax
    O Opus consome o orçamento rapidamente, mas o MiniMax é praticamente ilimitado
  • O Kimi tem sido recentemente meu modelo principal para depuração
    Ele encontra problemas mais rápido que Claude ou GPT
    Mas o problema de consistência de contexto é sério — ao reescrever código, pequenos desvios podem estragar tudo

• Neste momento, é uma corrida interminável por preço
  O DeepSeek vence todos os modelos em execução única, e o custo também fica na faixa de metade da energia elétrica local

  DeepSeek V3.2 Reasoning 86.2% ~$0.002 API, single-shot
  ATLAS V3 (pass@1-v(k=3)) 74.6% ~$0.004 apenas eletricidade local, best-of-3 + pipeline de reparo

  • Se eu puder rodar localmente, aceito pagar algo como US$ 0,004 de eletricidade
  • Mas ele ainda não responde perguntas sobre o Massacre da Praça da Paz Celestial de 1989…
  • Testei vários modelos abertos, mas só o DeepSeek 3.2 está realmente em nível SOTA
  • Também dá para aplicar essa abordagem ao DeepSeek
    A ideia é gerar várias respostas, selecionar candidatos promissores com um modelo pequeno, testá-los e repetir com feedback
    Ele converge gradualmente, como uma espécie de algoritmo genético
  • Alguém pode explicar o que significa “mais barato que a conta de luz”?

• Modelos pequenos foram ajustados demais para os testes, e no ambiente real o desempenho é péssimo

• Eu sempre sou cético
  Benchmarks são aprovados, mas na prática muitas vezes falta generalidade
  Ainda assim, a tentativa de enxugar os modelos em si é interessante

  • Isso varia bastante conforme a linguagem e a área
    Em programação de sistemas (C++, Rust), ainda existe uma grande distância em relação ao nível do Sonnet 4.5
    Modelos abertos passam tempo demais resolvendo erros de sintaxe e frequentemente perdem consistência lógica
    Tenho GPUs locais suficientes, mas também me preocupo com os problemas de licença dos modelos em nuvem
  • A abordagem do ATLAS é bem inteligente
    Ele gera várias soluções e calcula uma impressão digital de embeddings (fingerprint) de cada código para prever a exatidão
    Uma pequena rede neural chamada Cost Field dá uma pontuação a isso e escolhe o código mais provável de estar correto
    Assim, reduz o tempo de teste e ainda seleciona a resposta certa com 88% de precisão
  • Ao reduzir o modelo, cada neurônio acaba assumindo vários papéis, então a capacidade de generalização cai
    Paradoxalmente, um modelo grande pode ser estruturalmente mais simples

• Enquanto eu lia, o preço da GPU já virou US$ 1000

• Este projeto feito por IA roda seu próprio benchmark de uma forma completamente diferente do LiveCodeBench
  No README, está explícito que a pontuação do ATLAS vem do resultado do pipeline V3 (best-of-3 + Lens + reparo iterativo) com base em 599 tarefas do LCB
  Já as pontuações dos modelos concorrentes usam execução única (pass@1), então a comparação é injusta
  Sonnet ou GPT5.4 também poderiam ter pontuações maiores se fossem testados do mesmo jeito
  O README tem muitas estruturas que nem são realmente usadas, o que mostra a fragilidade de código gerado automaticamente por IA

• Fico curioso se esse tipo de benchmark só funciona para otimização específica do problema
  No fim, vamos acabar aprendendo os limites de não conseguir comprimir a generalidade

• A expressão “Geometric Lens routing” soa estranha demais
  Parece só um termo inventado pelo GPT

• Apesar do ceticismo, fico muito feliz de ver esse tipo de experimento com modelos abertos
  Se der para rodar modelos localmente até em PCs intermediários para avançados, já é um grande progresso