Modelos locais perdem para Opus e Codex: 0,21 ponto no MacBook contra 1,00 do Codex

É possível manter um "sistema de agentes do apocalipse", que funciona sem assinatura e sem as regras dos outros? O autor de um estudo no Habr, desenvolvedor do projeto open-daimon, testou isso na prática. Ele deu a mesma tarefa a modelos de nuvem, a um MacBook Pro com Apple M5, a um notebook gamer com RTX 5080 e a um NVIDIA DGX Spark. A nuvem ficou bem à frente: o Codex fez 1,00, o Opus 5.5 fez 0,96, e o melhor resultado no MacBook foi 0,21. Uma ressalva importante: na parte publicada do material, o texto é interrompido na descrição da última rodada do modelo denso no Spark, então não temos as conclusões finais do autor.

Por que ele precisou de modelos locais e como a tarefa foi montada

O autor apresenta os motivos de forma direta. Nos termos para consumidores, a Anthropic proíbe o uso comercial do Claude.ai, Pro e Max por residentes do EEE e da Suíça, de modo que trabalhar no Claude Code com a assinatura Max viola formalmente as regras. Ele também cita casos em que o Claude se recusou a ajudar com root na própria TV LG e em que um pesquisador teve a conta bloqueada depois de analisar um firmware com o ChatGPT (este último caso é só relato dele; a OpenAI não comentou). Somam-se a isso o desaparecimento de pesos "sem censura" no Hugging Face e a verificação de passaporte via Persona desde abril.

O teste foi construído sobre o repositório minibank: cerca de 700 linhas de Python, um ledger multimoeda e um arquivo DECISIONS.md com as decisões da equipe. O pedido soava como o de um gerente: o extrato não bate com o saldo, descubra o motivo, corrija, verifique e confira se o mesmo problema não acontece em outro lugar. São sete armadilhas: um conversor isca, com docstring "use em todo lugar", uma cotação corrigida retroativamente, o limite do mês em UTC, a comissão em uma linha separada, a exportação CSV com horário em formato ISO, um conversor antigo em que é proibido mexer e um teste que consolida números errados.

A avaliação foi feita sem que o agente soubesse: 20 testes ocultos valem metade da nota, sete condições "sutis" valem 15%, nove correções comprovadamente erradas, que os próprios testes do agente deveriam pegar, valem um quarto, e as regras valem 10%. A escala foi recalculada de modo que 0 significa "nada mudou" e valor negativo significa "quebrou mais do que consertou". O limite era de 20 minutos.

O que mostraram a nuvem, os notebooks e o DGX Spark

Referência na nuvem: o Codex (GPT-6.1 Sol, medium) terminou em 101 segundos e ≈$0,14 por rodada, o Opus 5.5 em 91 segundos e $0,30, e o Claude Fable 5.1 em 288 segundos e $1,79. Os três leram o DECISIONS.md, desviaram da isca e atualizaram o teste traidor. A diferença está só nos testes próprios: o Codex pegou 9 correções erradas de 9, e o Opus e o Fable pegaram 8 cada. As rodadas repetidas mostraram que isso é ruído: o Opus e o Fable também chegaram a 0,92.

MacBook Pro M5 com 32 GB: o Qwen3 Coder 30B A3B (MoE, 4 bits) gera 52 tokens/s com prefill de 743 tokens/s, mas substituiu o conversor e continuou recalculando a conversão, e a nota foi 0. O Qwen3.8 27B (5,4 tokens/s) leu o DECISIONS.md, mas em 20 minutos não fez nenhuma edição. O melhor foi o Gemma 4 12B: 0,21 em 575 segundos. Ele usou o valor já lançado em vez de recalcular, mas deixou passar o UTC, o horário ISO e a comissão. Esse resultado apareceu em apenas três de dez rodadas; em outra, a nota foi −0,17. Os ajustes de sampling não reduziram a variação.

Notebook gamer com RTX 5080 (16 GB de VRAM) e Qwen3.6-35B-A3B: a velocidade em um contexto de 42 mil tokens subiu de 9,5 para 94 tokens/s depois de uma distribuição manual das camadas no LM Studio. Todas as 40 camadas ficam na placa de vídeo, com os pesos dos experts na CPU em 40% das camadas e o KV-cache em q8_0.

O autor atribui a queda anterior ao fato de o LM Studio enviar para o processador camadas inteiras, junto com a atenção. Mesmo assim, a velocidade não trouxe qualidade: o harness leve pi fez 0,31 em 285 segundos, e o OpenCode fez 0,14 e estourou o limite. O OpenCode envia cerca de 15 mil tokens no primeiro passo, contra 2 200 do pi, e seu modelo gerou 55 mil tokens de raciocínio, contra 11 mil.

No DGX Spark (chip GB10, 128 GB de memória compartilhada, vLLM, NVFP4, formato de 4 bits com suporte de hardware no chip), o Qwen3.6-35B-A3B destilado com base no Opus fez 0,25: 12 dos 20 testes ocultos e 3 das 7 condições sutis. Esse modelo deixou passar os meses em UTC, o horário ISO e a comissão em todas as cinco rodadas, feitas em duas máquinas, dois servidores e dois harnesses. O modelo denso ThinkingCap-Qwen3.8-27B, com limite de 10 minutos, deixou o diff vazio, embora tenha apontado corretamente o erro principal em seu raciocínio; sem limite, gastou 987 segundos e fez 0,92.

Conclusão prática

O autor ressalva que a tarefa é uma só, em Python, e que em geral houve uma ou duas rodadas, então esse teste não distingue entre si modelos locais parecidos. Mas a distância entre a nuvem e os modelos locais rápidos não se explica por ruído. Na prática, duas coisas ficam claras. Um harness leve e o ajuste manual de offload aceleram o agente local em várias vezes, mas a qualidade é definida pelo tamanho do modelo. E o único resultado local no nível da nuvem, o modelo denso de 27B no Spark, exigiu quase 16,5 minutos em vez de um minuto e meio.