Tive a mesma ideia, então tenho brincado com isso no nanochat. Por exemplo, aqui estão 8 agentes (4 claude, 4 codex), com 1 GPU cada rodando experimentos nanochat (tentando excluir o softcap logit sem regressão). O resumo é que não funciona e é uma bagunça... Mas ainda assim é muito bonito de se ver :) Tentei algumas configurações: 8 pesquisadores independentes solo, 1 cientista-chefe dando trabalho para 8 pesquisadores juniores, etc. Cada programa de pesquisa é um branch git, cada cientista faz fork em um branch de funcionalidades, árvores de trabalho git para isolamento, arquivos simples para comunicações, pule Docker/VMs para simplificar no momento (acho que instruções são suficientes para evitar interferências). A organização de pesquisa roda em grades de janelas tmux de sessões interativas (como o Teams) para que seja bonito de olhar, ver o trabalho individual deles e "assumir" se necessário, ou seja, sem -p. Mas ok, o motivo de não funcionar até agora é que as ideias dos agentes são bem ruins logo de cara, mesmo com a inteligência mais alta. Eles não pensam cuidadosamente no design dos experimentos, executam variações um pouco sem sentido, não criam linhas de base fortes nem ablatam as coisas corretamente, não controlam cuidadosamente o tempo de execução ou os fracassos. (Só para dar um exemplo, um agente ontem "descobriu" que aumentar o tamanho oculto da rede melhora a perda de validação, o que é um resultado totalmente espúrio dado que uma rede maior terá uma perda de validação menor no regime de dados infinitos, mas também treina por muito mais tempo, não está claro por que precisei vir apontar isso). Eles são muito bons em implementar qualquer ideia bem definida e descrita, mas não a geram de forma criativa. Mas o objetivo é que você esteja programando uma organização (por exemplo, uma "organização de pesquisa") e seus agentes individuais, então o "código-fonte" é a coleção de prompts, habilidades, ferramentas, etc. e processos que o compõem. Por exemplo, uma reunião diária de pé pela manhã agora faz parte do "código de organização". E otimizar o pré-treinamento do nanochat é apenas uma das muitas tarefas (quase como uma avaliação). Então – dado um tarefa arbitrária, quão rápido sua organização de pesquisa gera progresso nela?

Com o tsunami de demanda por tokens que se aproxima, há oportunidades significativas para orquestrar a memória+computação subjacente *exatamente da perfeição* para os LLMs. A restrição fundamental e não óbvia é que, devido ao processo de fabricação do chip, você obtém dois pools de memória completamente distintos (de implementações físicas diferentes também): 1) SRAM no chip, que fica imediatamente ao lado das unidades de computação, que é incrivelmente rápida, mas de capacidade muito baixa, e 2) DRAM off-chip que tem capacidade extremamente alta, mas cujo conteúdo só pode ser sugado por um canudo longo. Além disso, há muitos detalhes da arquitetura (por exemplo, arrays sistólicos), números, etc. O design do substrato físico ótimo e depois a orquestração de memória+computação nos fluxos de trabalho de maior volume dos LLMs (inferência prepreenchimento/decodificação, treinamento/ajuste fino, etc.) com o melhor throughput/latência/$, é provavelmente o quebra-cabeça intelectual mais interessante de hoje, com as maiores recompensas (\cite 4,6T do NVDA). Tudo isso para conseguir muitos tokens, rápido e barato. Pode-se argumentar que o fluxo de trabalho que pode importar mais (decodificação por inferência *e* em contextos longos de tokens em loops agentivos apertados) é o mais difícil de alcançar simultaneamente pelos ~ambos os campos do que existe hoje (adjacente à NVIDIA primeiro HBM e Cerebras adjacente primeiro à SRAM). Enfim, a equipe do MatX tem nota A++, então é um prazer ter um pequeno envolvimento e parabéns pelo aumento!