Otimizando o AutoResearch no RTX 5090: O que falhou e o que funcionou

Problemas Iniciais e Caminho Funcional
A configuração inicial para executar o AutoResearch em um sistema RTX 5090/Blackwell estava "totalmente quebrada" com desempenho extremamente ruim—apenas alguns milhares de tokens por segundo e MFU (Utilização de FLOPs do Modelo) praticamente inútil, apesar do código estar tecnicamente em execução.
O caminho de configuração funcional envolveu:
- Evitar o caminho de compilação do modelo completo que estava quebrado nesta configuração
- Manter as boas melhorias de compilação do otimizador fundido onde elas realmente ajudavam
- Usar o caminho estável de atenção SDPA/CuDNN
- Ajustar o lote total e o orçamento de tempo empiricamente em vez de adivinhar
- Automatizar o ciclo de benchmark/extração/estratégia/re-execução
O Que Falhou
Vários modos de falha foram enganosos:
- Um caminho que era tecnicamente correto, mas catastróficamente lento
- Interpretação enganosa do MFU até que o denominador foi corrigido para o contexto da 5090
- Configurações de lote por dispositivo maiores que pareciam que deveriam ajudar, mas na verdade pioraram muito as coisas
- Bugs de automação em torno de limpeza de bloqueios/ganchos de conclusão/ordem de despacho
Como o desenvolvedor observou: "Havia várias maneiras de obter uma execução que parecia viva enquanto fazia algo estúpido."
O Que Ajudou
As melhorias reais vieram de:
- Reativar o caminho de compilação do otimizador fundido
- Reduzir o lote total da configuração original maior
- Validar 2**17 como a região de lote total melhor
- Aumentar o orçamento de tempo uma vez que o regime de lote estável foi encontrado
- Tratar a automação como parte do sistema de benchmark, não como uma reflexão tardia
Progressão de Desempenho
A progressão das execuções úteis mostrou melhorias claras:
- Execução saudável de linha de base: val_bpb: 1.165452, mfu: 40.49%
- Melhoria da compilação do otimizador fundido: val_bpb: 1.155400, mfu: 42.88%
- TOTAL_BATCH_SIZE = 2**18: val_bpb: 1.108381, mfu: 43.18%
- Validação TOTAL_BATCH_SIZE = 2**17: val_bpb: 1.089424, mfu: 43.03%
- Melhor resultado atual do loop automático: TOTAL_BATCH_SIZE = 2**17, TIME_BUDGET = 1200, multiplicador LR = 1.0, val_bpb: 0.999445, mfu: 42.56%, total_tokens_M: 387.8, num_steps: 2959
Melhor Configuração Atual
O melhor resultado encontrado até agora:
- TOTAL_BATCH_SIZE = 2**17
- TIME_BUDGET = 1200
- Multiplicador LR = 1.0
Esta combinação superou variantes de lote maiores, a variante menor 2**16, um teste de LR mais baixo e orçamentos de treinamento mais curtos.
Principais Conclusões
A principal lição foi que a configuração vencedora não era uma configuração de "maximizar tudo". O caminho melhor envolveu um regime de lote estável, um horizonte de treinamento mais longo e a eliminação cuidadosa de erros de automação e backend.
O desenvolvedor enfatizou que se você está trabalhando no treinamento Blackwell/5090 e vendo comportamento bizarro, "pode não ser sua imaginação. Alguns caminhos são simplesmente muito piores do que parecem inicialmente." A parte útil deste exercício foi encontrar um caminho que é estável, automatizável, reproduzível e bom o suficiente para construir experimentos reais de acompanhamento sobre ele.
📖 Read the full source: r/LocalLLaMA
👀 See Also

Como a Memória do OpenCLAW Realmente Funciona: Corrigindo o 'Esquecimento' do Agente
Os agentes OpenCLAW não possuem memória persistente entre conversas - eles reconstroem o contexto a partir de arquivos como SOUL.md, USER.md e MEMORY.md a cada vez. Problemas comuns de 'esquecimento' surgem de sessões antigas, arquivos de memória desestruturados e armazenamento de informações importantes no histórico de chat em vez de arquivos permanentes.

Insights Práticos de Configuração do OpenClaw com Experiência em Docker/Windows
Um desenvolvedor compartilha lições específicas de executar o OpenClaw no Docker com Windows 11/WSL2, abordando problemas de persistência, configuração de bot do Discord, abordagens de gerenciamento de memória e soluções alternativas para automação de navegador.

Otimização de Desempenho em Java: Oito Antipadrões que Desaceleram seu Código
Um aplicativo Java de processamento de pedidos melhorou de 1.198ms para 239ms no tempo decorrido, de 85.000 para 419.000 pedidos por segundo e de 1GB para 139MB no uso de heap, corrigindo oito antipadrões comuns identificados por meio de perfilamento com Java Flight Recording.

Construindo uma plataforma de agentes de IA sem servidor na AWS por US$ 0,01/mês com Claude Code
Um desenvolvedor construiu uma plataforma serverless completa na AWS executando agentes de IA por aproximadamente US$ 0,01/mês usando Claude Code ao longo de 29 horas, eliminando componentes caros como NAT Gateway (US$ 32/mês) e ALB (US$ 18/mês). O projeto inclui 233 testes unitários, 35 testes E2E e é implantado com um único comando cdk deploy.