Qwen local numa RTX 5080 sobe de 33% para 88,5% em teste de caderno de laboratório

Quando uma rede neural local perde para uma em nuvem, a culpa costuma cair no hardware: falta memória de vídeo, dizem. O autor de uma série de artigos no Habr foi verificar se é isso mesmo. A estação de trabalho dele, com uma única RTX 5080 (16 GB de VRAM e 62 GB de RAM), teve um resultado modesto nos testes anteriores.

Em perguntas sobre um caderno de laboratório eletrônico, a Qwen 3.8 IQ2_XS, numa versão anterior, acertou apenas 8 de 24, ou seja, 33%. Após os ajustes, no mesmo computador, a Qwen 3.

8 IQ3_XXS marcou 23,0 pontos de 26 possíveis (88,5%) no conjunto atualizado de 26 tarefas e dividiu o primeiro lugar com o Claude Opus 5.5. Imagine que você rodou um modelo local para analisar código ou dados e ele «se comporta como um burro».

A causa pode ser que o servidor desligou o cache de conversas sem avisar e que o limite de tokens corta o raciocínio no meio da frase. Abaixo, o que exatamente precisou ser corrigido.

Versão completa em vez da reduzida

A versão Qwen 3.8 Coder IQ1_M foi reduzida a 23,4 GB de duas formas. Os pesos foram comprimidos para cerca de 1,6 bit, e metade dos especialistas roteados de cada camada foi removida: sobraram 256 de 512. Aqui, os «especialistas» são blocos separados do modelo, entre os quais ele distribui o trabalho. Em edições simples de código, quase não se notam perdas. Elas aparecem quando é preciso manter vários subsistemas em mente ao mesmo tempo: transações aninhadas do FireDAC, recálculo da interface, reempacotamento de arquivos do projeto e verificação de atualizações em segundo plano com conferência de SHA-256. Nesses casos, o modelo reduzido errava repetidamente.

O autor adotou a versão completa, com 512 especialistas, Qwen3.8-Flash-Next-GSQ-RCO-IQ3_XXS, do laboratório ISTA-DASLab (2,84 bits por peso, 40 GiB de especialistas). Pelas tabelas de retenção de precisão, ela é apenas 2,3 pontos percentuais melhor que a IQ2_XS: 87,3% contra 85,0% em relação ao modelo sem compressão. Mas, num agente de vários passos com contexto de cerca de cem mil tokens, pequenas imprecisões se acumulam de um passo para o outro, e a diferença passa a ser perceptível.

Duas armadilhas na configuração do servidor

No início, o agente ainda esbarrava no timeout de 45 minutos. Nos logs do engine Strata, apareceram duas causas.

Primeira: reserva dupla de memória. O servidor carregava na memória de vídeo os slots de especialistas mais usados (7,0 GiB) e, ao mesmo tempo, tentava fixar na RAM todos os 40 GiB de especialistas. Sobravam apenas 0,7 GiB de RAM livre, e por isso o servidor desligava o cache de conversas em silêncio. Sem ele, a cada passo de uma sessão longa o agente relia de 60 a 100 mil tokens de histórico e perdia cerca de um minuto. A flag --resident-experts fixa na RAM somente o complemento da memória de vídeo, ou seja, 33,5 GiB. Os 5,4 GiB liberados foram para o cache de sessões.

Segunda: raciocínio interrompido. Antes de editar o código, o modelo escreve dentro da tag think um plano de 6 a 9 mil tokens. O agente tinha um teto de maxTokens 8192, e o servidor estava com o modo answer_room ativado. Quando o raciocínio chegava a 6144 tokens, o servidor fechava a tag à força e deixava 2048 tokens para a resposta. O pensamento era cortado no meio da frase, o modelo devolvia um comentário sem chamar nenhuma ferramenta, e tudo recomeçava. O autor aumentou o limite para maxTokens 16384 e configurou answer_room: false. Os ciclos em vão desapareceram, e o modelo passou a manter de 70 a 81 tokens por segundo com contexto de 131 072 tokens.

No Windows, há um detalhe: fixar 33,5 GiB de memória na inicialização leva cerca de 30 segundos. Por isso, é melhor manter o servidor como um único processo permanente durante toda a série de tarefas.

Os resultados

Nas 20 tarefas de Delphi, uma tarefa era considerada resolvida se o projeto compilasse no RAD Studio sem novos avisos do compilador e passasse nos testes ocultos do DUnitX. A Qwen completa, sem skill adicional, resolveu 19 de 20 (95%), como o Claude Sonnet 5.5, e passou em todos os testes ocultos. Ela resolveu as três tarefas em que a versão reduzida tropeçava. Com a skill delphi-development ativada, o resultado caiu para 17 de 20. O autor atribui a queda à variação estatística de execuções isoladas: um modelo forte lê os módulos vizinhos e adota o estilo do projeto mesmo sem dicas.

No teste ELN Suite 1.1 (26 tarefas, servidor MCP ativo), o modelo local marcou 23,0 pontos (88,5%) e terminou em 46 minutos. O Claude Sonnet 5.5 e o Gemini 4 fizeram 21,0 cada, e o DeepSeek V4.1 Flash, 19,0. A primeira execução deu 22,0: o único zero veio de uma pergunta de aquecimento, em que o modelo passou um parâmetro booleano como a string "True" em vez de true. O wrapper agêntico OMP tolera isso, mas o validador estrito do próprio autor e um dos cinco parsers de parâmetros duplicados no servidor Delphi não toleram.

Conclusões práticas e ressalvas

• Não use versões com especialistas removidos em tarefas agênticas complexas.
• Fique de olho no equilíbrio entre RAM e cache de conversas: o desligamento silencioso do cache transforma a sessão numa releitura infinita do contexto.
• Deixe uma margem de maxTokens para o modelo de raciocínio e não ative o fechamento forçado do think.
• Faça as ferramentas tolerarem "True" e null em campos opcionais.

As ressalvas importam. Os testes são do próprio autor, feitos em projetos fechados, e parte das configurações foi executada uma única vez. Os antigos 33% vieram de um conjunto de 24 perguntas, e os novos 88,5%, de um conjunto atualizado de 26 tarefas. O modelo local é visivelmente mais lento: 46 minutos contra 17 do Opus 5.5 e 11 do Sonnet 5.5. Em compensação, a execução custa $0 contra $5,37 do Opus. Se as tarefas não são urgentes e os dados não podem sair do laboratório, esse é um argumento sério a favor de ter hardware próprio.