Como os melhores do mundo treinam gastando menos

No Artigo 1 expliquei treino como jogar dardo: tentar, errar, medir o erro, ajustar um pouquinho, repetir bilhões de vezes. Isso é verdade, mas simplificado — porque tem uma pergunta que os melhores laboratórios do mundo levam a sério e a gente também deveria levar: dá pra fazer esse processo gastando muito menos, sem perder qualidade?

Existe um caso real, público, documentado, que prova que sim. Chama-se DeepSeek-V3.

Os números, sem enrolação

DeepSeek-V3 é um modelo com 671 bilhões de números (os "pesos" da receita, lembra do Artigo 1?). Se você fosse usar TODOS eles pra responder cada pergunta, seria um custo gigantesco — cada resposta exigiria ligar todos os 671 bilhões de números ao mesmo tempo.

Só que eles não fazem isso. Pra cada palavra que o modelo gera, só 37 bilhões desses números são realmente usados. O resto fica "desligado" naquele momento.

E o treino inteiro — pegar 14,8 trilhões de pedaços de texto e fazer o processo de "tentar, errar, ajustar" bilhões de vezes — custou 2,79 milhões de horas de GPU. Pareça muito, mas pra um modelo desse tamanho é uma fração do que os concorrentes gastam pra chegar num resultado parecido. E o time relatou que o treino inteiro rodou sem nenhuma instabilidade que exigisse voltar atrás — não é pouca coisa; treinos desse tamanho costumam "explodir" (os números viram lixo no meio do caminho) e precisam ser reiniciados de um ponto anterior.

A ideia central: nem todo "especialista" precisa ser chamado toda vez

Imagina um hospital gigante, com 671 médicos especialistas diferentes — cada um sabe fundo numa coisa específica (cardiologia, pediatria, ortopedia...).

Quando você chega com uma dor no peito, o hospital não chama os 671 médicos pra te examinar. Chama só os 2 ou 3 que fazem sentido pro seu problema. Os outros 668 continuam lá, disponíveis, mas parados — não custam nada nesse atendimento específico.

Isso se chama Mixture of Experts (mistura de especialistas), e é exatamente o "37 bilhões de 671 bilhões" que eu citei acima: o modelo inteiro tem MUITO conhecimento acumulado (os 671B), mas só "chama" a fatia relevante (37B) pra cada situação específica. Você tem o conhecimento gigante disponível, mas paga só pela fatia que usa.

A segunda ideia: comprimir a "memória de curto prazo"

Enquanto o modelo lê um texto (ou escreve uma resposta), ele precisa "lembrar" de tudo que já leu até aquele ponto, pra fazer sentido do que vem depois. Essa lembrança tem um custo real de memória — quanto mais longo o texto, mais caro fica guardar essa lembrança toda.

A técnica que o DeepSeek-V3 usa (chamada Multi-head Latent Attention) é, de novo, uma ideia de compressão: em vez de guardar a lembrança inteira e "crua", ela guarda uma versão resumida e compacta — pequena o bastante pra caber barato na memória, mas rica o bastante pra reconstruir o que importa quando precisar.

Por que isso é literalmente o mesmo princípio do repo `compactação`

Se você olhar as perguntas que a gente já usa pra avaliar qualquer decisão de engenharia no ecossistema (repo compactacao/principios.md):

"Existe uma versão desta solução que usa menos contexto/memória/chamadas pro mesmo resultado, ou isso é o mínimo real necessário?"

É exatamente essa pergunta que o Mixture of Experts e a Multi-head Latent Attention respondem, só que na escala de um modelo de fronteira: fazer mais (671B de conhecimento acumulado) gastando menos (37B ativados, memória comprimida), sem abrir mão do resultado.

Não é coincidência a filosofia bater. É a mesma ideia central do James (compute → descoberta → conhecimento → compressão → automação → menos compute), só que provada por um laboratório real, em produção, num modelo que qualquer um pode baixar e rodar hoje.

O que isso muda pro nosso próprio caminho

A gente não vai treinar um modelo de 671 bilhões de parâmetros numa GPU de notebook — isso é fora de escala pra nós, e tudo bem, já é honesto sobre isso desde o Artigo 1.