FOSHI Pesquisa independente · Brasil · 2026

Modelos de linguagem carregam mais parâmetros do que precisam.

Este é um projeto independente que mede quanto dá pra tirar antes da qualidade cair — e quanto custa cada corte. Sem laboratório, sem financiamento, numa placa de vídeo doméstica.

38% dos parâmetros de um transformer equivalente
96% da qualidade de linguagem desse mesmo modelo
95% da velocidade de geração, no mesmo hardware

Medido em quatro escalas de modelo, com três sementes aleatórias em cada ponto e uma linha de base treinada na mesma receita.

100+modelos treinados do zero
62execuções controladas
41scripts de experimento
152Mtokens de treino, dois corpora
1GPU de consumo

O QUE FOI MEDIDO

Um transformer guarda blocos de processamento repetidos, camada após camada. Boa parte do que cada bloco aprende é estruturalmente parecida com o que o bloco vizinho aprende — e essa repetição ocupa espaço sem acrescentar informação nova.

A pesquisa mede quanta dessa repetição dá pra remover, componente por componente, e o preço exato de cada remoção. Cada número vem de modelos treinados do zero e comparados contra uma linha de base de mesmo tamanho, treinada na mesma máquina com a mesma receita.

A descoberta central é que os componentes de um transformer não são igualmente redundantes. Alguns toleram compartilhamento agressivo; outros perdem qualidade rápido. Tratar os dois do mesmo jeito é o que fazia as tentativas anteriores falharem.

O custo de cada corte foi quantificado por parâmetro removido. Isso transforma a compressão numa escolha — onde economizar — em vez de um ajuste cego aplicado ao modelo inteiro.

AS TÉCNICAS FORAM ISOLADAS ANTES DE COMBINADAS

Antes de empilhar qualquer coisa, cada técnica de compressão foi treinada sozinha e medida contra a mesma linha de base. Isso revelou que a combinação não se comporta como a soma das partes: uma técnica que funciona isolada pode desaparecer quando combinada, e o único jeito de saber é medir as duas situações.

O erro mais comum em compressão é multiplicar os fatores de cada técnica e anunciar o produto. Este projeto cometeu esse erro, chegou internamente a um número inflado em duas ordens de grandeza, e o corrigiu quando as técnicas foram medidas juntas de verdade.

OS DADOS

Nem todo parâmetro custa o mesmo pra remover

Os dois componentes principais de um transformer foram comprimidos separadamente e o custo foi normalizado pela quantidade de parâmetros que cada corte remove. A diferença entre eles é de quase nove vezes — e é isso que torna a compressão uma escolha em vez de um ajuste cego.

Componente A Componente B 3,0 26,8 PONTOS DE QUALIDADE PERDIDOS POR MILHÃO DE PARÂMETROS REMOVIDOS

A fronteira entre comprimir e perder qualidade

Quatro configurações medidas, três sementes cada. Comprimir mais custa mais, mas não de forma uniforme: entre os dois primeiros pontos a compressão sobe um terço e o custo praticamente não se move. O último ponto ultrapassa o critério e foi descartado.

critério: 5% 0 2 4 6 8 1,5× 2,0× 3,0× 6,0× reprova FATOR DE COMPRESSÃO → CUSTO %

O custo não some com a escala — ele trava

A mesma configuração medida em três tamanhos de modelo. O custo cai e depois estaciona. A linha tracejada é o valor que havia sido registrado como previsão antes do terceiro experimento; ele não se confirmou, e a previsão está registrada como falha.

0 1 2 3 3,34 2,15 2,14 0,96 previsto pequeno médio grande ESCALA DO MODELO → CUSTO %
medido, três sementes por ponto previsto antes do experimento — não se confirmou

O QUE ISSO DARIA EM ESCALA

PROJEÇÃO — ARITMÉTICA, NÃO MEDIÇÃO
~3 bi parâmetros guardados, no lugar de um modelo de 8 bilhões
~1,5 GB de memória, com pesos em quatro bits
~5 bi equivalentes dentro de um orçamento de 1 GB

Estes três números não vêm de nenhum modelo treinado. São a proporção medida nas escalas pequenas aplicada a tamanhos que esta pesquisa não alcançou — o maior modelo verificado até aqui tem menos de duzentos milhões de parâmetros.

A proporção pode não se manter. Já aconteceu antes neste projeto: uma tendência aparentemente estável em duas escalas parou de valer na terceira, e a previsão registrada antes do experimento falhou. Por isso a projeção aparece separada dos resultados, e sem a cor usada para o que foi medido.

COMO FOI TESTADO

  1. Previsão registrada antes do experimento. Cada teste de escala teve o resultado esperado e os desfechos possíveis escritos em log antes de qualquer peso ser inicializado. Duas previsões falharam e estão registradas como falha, com o valor previsto ao lado do medido.
  2. Parâmetros pareados. Toda comparação é contra uma linha de base do mesmo tamanho, treinada na mesma receita, na mesma máquina. Compressão é sempre medida sobre o corpo do modelo, com a tabela de vocabulário excluída — foi justamente ela que mascarou o erro anterior.
  3. Três sementes por ponto. Nenhum número publicado vem de uma execução só. Quando um resultado depende de cruzar um limiar, o critério é a pior semente, não a média.
  4. Auditoria antes de rodar. Cada script é revisado antes da execução. Quatro erros de implementação foram encontrados dessa forma, e três deles teriam produzido um resultado falso positivo — fariam acreditar em algo bom que não existia.
  5. Vereditos automáticos exigem significância. Depois de um script interpretar ruído como tendência, todo veredito passou a calcular o erro padrão e comparar com a dispersão entre sementes antes de concluir qualquer coisa.
  6. Reprodutível bit a bit. Sementes fixas, checkpoint por época com escrita atômica, e todos os números publicados conferidos contra os arquivos em disco.

O QUE FOI RETRATADO

Compressão de 28×

O número vinha de multiplicar dois fatores que não se multiplicam. Um teste com parâmetros pareados derrubou a alegação inteira.

Sessenta e dois experimentos comprovando compressão

Nenhum deles comprimia. A contabilidade incluía a tabela de vocabulário, que mascarava o corpo do modelo estar maior que a linha de base. Nove de nove escalas verificadas estavam infladas entre 0,3% e 41%.

O custo do compartilhamento some conforme o modelo cresce

Ele diminui e depois trava num piso positivo. A leitura anterior vinha de dois pontos de medição; o terceiro ponto, registrado como previsão antes do experimento, mostrou a saturação — e a previsão falhou.

Uma lei geral prevendo a compressão a partir da arquitetura

Oitocentas e quarenta e quatro fórmulas testadas sobre quarenta e dois pontos. A melhor explicava 13% da variância. A análise de teto de ruído mostra por quê: nessa escala a aleatoriedade do treino domina o efeito arquitetural, e configurações idênticas produziam resultados de sinal oposto.

O QUE NÃO FUNCIONOU

Remover os pesos menores

Cortar metade dos pesos de menor magnitude degradou a qualidade em mais de 50%. A hipótese de que o modelo estava subtreinado nunca foi confirmada, então a técnica está fora do conjunto.

Fatorar as matrizes em posto menor

Funciona isolada e some quando combinada com o resto. Foi medida em quatro escalas e não melhorou o resultado em nenhuma.

Fundir pesos por média

Combinar blocos treinados separadamente tirando a média dos pesos falhou completamente em modelos já treinados.

Escalar dois eixos ao mesmo tempo

A regra usada nos experimentos antigos crescia dois componentes juntos e destruía a compressão por construção. Foi a causa raiz do erro nos sessenta e dois experimentos.

Medir capacidade nesta escala

O teste de tarefa foi executado e deu resultado nulo: todos os modelos ficaram no acaso. Não é problema de amostra — é o modelo ser pequeno demais para a métrica funcionar.

Empurrar o compartilhamento ao extremo

Com parâmetros pareados, levar esse eixo ao limite piorou a qualidade de forma monotônica. O ganho aparente era parâmetro comprado, não compressão.

COMO O PROJETO CHEGOU AQUI

LIMITES DO QUE ISSO MOSTRA

  • A qualidade é medida por perplexidade em texto, não por desempenho em tarefas. O teste de tarefa foi executado e deu nulo, com a estatística registrada.
  • O maior modelo treinado até aqui é pequeno para os padrões da área. Nada aqui foi verificado em escala industrial, e a extrapolação para modelos grandes é aritmética, não evidência.
  • Um único par de corpora, em inglês, com contexto curto. Generalização para código, outros idiomas ou seguimento de instruções não foi testada.
  • Os números valem para um orçamento de treino fixo. Há indício medido de que treino mais longo melhora o resultado, e a extensão disso é desconhecida.
  • Uma única GPU, um único tipo de precisão, geração de um token por vez. Outros regimes de execução não foram medidos.

SITUAÇÃO

A pesquisa continua. As próximas etapas são validar o resultado em uma escala maior do que a placa doméstica alcança, fechar a lacuna do teste de tarefa — que exige um modelo grande o bastante para sair do acaso — e rodar o modelo comprimido em um telefone comum.

O método completo, as configurações e os dados brutos não estão publicados. Contato aberto para colaboração, revisão independente ou acesso sob acordo.