Executando verificação de segurança...
1

@bugzoid, você NÃO está falando besteira. Essa dor é real e é exatamente o problema que estou atacando em 4 repositórios satélites do Crompressor. O comentário que você fez me motivou a publicar essa pesquisa que estava no laboratório.(crompressor-semantico)

A tese que defendo é: quantizar pesos para 4 bits é o começo, não o fim. Como você mesmo disse, reduz armazenamento mas não muda o padrão de acesso à memória. O que eu fiz foi levar os conceitos do Crompressor (Codebook, LSH, XOR Delta) direto pra dentro da inferência neural. Alguns resultados reais:

  • Codebook como substituto de tensores: No MNIST, treinar APENAS o codebook do Crompressor (em vez dos pesos individuais) atingiu 97.56% de accuracy com 40.8x menos parâmetros. Com K=256 chegou a 98.08% — superando o baseline de pesos Float32.
  • KV Cache via Codebook: No GPT-2 rodando numa Tesla T4, comprimir o KV Cache com ponteiros CROM deu 94.2% de redução real de memória.
  • CROM-Chat (Pesquisa 9): Uma LLM generativa experimental rodando inferência inteira em Go puro, CPU only, zero dependência de GPU. Usa uma arquitetura inspirada no LLaDA (difusão bidirecional) com RAG via LSH. Está crua ainda, mas roda e gera texto em milissegundos.

A ideia central: em vez de quantizar e torcer para caber na RAM, usar o Codebook do Crompressor como espaço de aprendizado — os pesos não são floats, são ponteiros O(1) para padrões num dicionário. Isso muda o paradigma de acesso à memória, que é exatamente o gargalo que você identificou.

Os repos onde essa pesquisa vive:

Essa pesquisa não está pronta — está viva. Mas os números não mentem. Valeu por levantar esse ponto! 🔬

Carregando publicação patrocinada...