REAP20 acelerou um Qwen local em 42% sem perda de precisão no DS1000

Ao escolher um LLM local para código, é fácil montar um torneio bonito e acabar com um vencedor inútil. Basta pegar o conjunto de prompts de outra pessoa, esquecer o limite de raciocínio ou comparar os modelos em modos diferentes. O autor do material fez quase tudo isso por conta própria e depois gastou centenas de horas de GPU para entender onde o experimento tinha desandado.

O valor prático da história está justamente nos erros. Em uma RTX 4070 Ti Super com 16 GB de memória de vídeo, o autor testou a família Qwen no DS1000, um conjunto de mil tarefas de Pandas, NumPy, SciPy, Scikit-learn, Matplotlib, PyTorch e TensorFlow. O código do modelo era inserido em um modelo de teste, executado, e o resultado era comparado com uma referência. Isso se aproxima mais do trabalho real de um especialista em dados do que mais um teste de criar uma landing page ou um jogo no navegador.

Primeira execução: velocidade sem longas reflexões

No teste inicial, o raciocínio estava desativado. Os melhores em número de tarefas resolvidas foram a REAP20-28B e o Qwen3.6-35B-A3B. A REAP20 se comportou de forma especialmente interessante: com precisão comparável, gerava a resposta 42% mais rápido que o modelo original, embora 20% dos pesos tivessem sido removidos.

Para o trabalho diário, é um resultado de peso. Se a pessoa espera o próximo trecho de código NumPy, a latência importa mais do que a capacidade do modelo de refletir por vários minutos. Por isso, o autor propôs uma divisão prática: um modelo MoE rápido ajuda no modo interativo, e um modelo dense mais lento executa à noite tarefas que não exigem controle constante, como uma revisão preliminar de código.

Mas o resultado não pode virar um ranking universal. O DS1000 foi lançado em 2023, e parte das tarefas pode ter entrado nos dados de treinamento de modelos novos. Uma única execução não mostra a dispersão dos resultados, e diferentes quantizações e configurações de decodificação atrapalham ainda mais uma comparação justa. Por fim, a escolha das bibliotecas deve corresponder ao trabalho real: o autor se importava com NumPy, SciPy, Scikit-learn e PyTorch, então depois reduziu o conjunto de 1000 para 509 tarefas.

O limite de tokens quebrou o segundo experimento

Na segunda execução, o autor ativou o thinking, mas deixou 4096 tokens para o raciocínio. Essa decisão virou a tabela de cabeça para baixo. A precisão da REAP20 caiu para menos da metade, enquanto a versão completa do mesmo modelo quase não mudou o resultado. O motivo foi prosaico: em aproximadamente dois de cada três casos, a REAP20 batia no teto e não conseguia terminar a resposta.

Um exemplo simples: o modelo sabe como escrever a solução com Scikit-learn, monta o plano correto, mas é interrompido antes do código final. O sistema de verificação dá zero, exatamente como para uma resposta totalmente errada. Se olharmos apenas a precisão final, podemos concluir que o modelo piorou. Na prática, o que está quebrado é o circuito de medição.

Essa é uma lição importante para qualquer benchmark interno: guarde o motivo do término da resposta, o número de tokens usados, o tempo de geração e a proporção de interrupções. Resultados com finish_reason=length devem ser analisados separadamente; caso contrário, uma limitação da infraestrutura se disfarça de fraqueza do modelo.

O que aconteceu depois da correção

O autor passou a elevar o limite gradualmente e a continuar os raciocínios interrompidos. O Qwen3.8-27B no modo de esforço máximo acabou resolvendo 252 de 509 tarefas, contra as 173 iniciais. O ganho foi de 79 soluções, mas o preço foi desagradável: a série de iterações levou cerca de 153 horas. Em precisão final, o modelo apenas se aproximou do mais rápido Qwen3.6-MoE sem raciocínio.

Em uma RTX 6000 Pro profissional, o modelo Qwen3.8-Flash-Next-NVFP4 atingiu 58,1% no DS1000 completo em 8,5 minutos. No entanto, esse resultado não pode ser transferido para uma placa de vídeo gamer: outro hardware, outro formato de pesos e outra configuração mudam a economia da execução.

A conclusão prática é chata, mas útil. Primeiro, monte um pequeno conjunto de tarefas próprias, fixe as versões das bibliotecas e use parâmetros de execução idênticos. Depois, meça a precisão, a latência, as interrupções por limite e o custo de uma solução bem-sucedida. Para um assistente diurno, escolha o modelo pela velocidade com qualidade suficiente; para tarefas noturnas, é possível dar mais tempo e tokens. E, acima de tudo, não trate um design de experimento fraco com centenas de horas de GPU adicionais.