OPTIC comprime 100 vezes os per-layer embeddings do Gemma 4 E4B e mantém 97,8% da qualidade

Pesquisadores do VILA-Lab mostraram que as tabelas de per-layer embeddings (PLE) do Gemma 4 E4B podem ser comprimidas em cerca de 100 vezes com perda quase imperceptível de qualidade. O método OPTIC mantém 97,8% do desempenho do modelo BF16 não comprimido, somado em sete benchmarks. O melhor dos seis quantizadores clássicos, a quantização por produto, alcança apenas 66,3% com a mesma taxa de compressão. Ao mesmo tempo, em uma GPU RTX 4090, o consumo de memória cai 29,7%, enquanto o tempo de execução aumenta no máximo 0,40%.

Por que as tabelas de embeddings se tornaram um problema à parte

Uma tendência cada vez mais clara nos modelos de linguagem: a capacidade cresce não só pelo processamento do transformer, mas também pelos embeddings. Os per-layer embeddings do Gemma 4 são um exemplo dessa abordagem. Na versão E4B, eles representam 35,2% de todos os parâmetros. É uma fração enorme, e ela fica na memória, recurso que quase sempre é escasso em dispositivos.

Daí surge o desafio: preservar os ganhos trazidos por embeddings grandes e, ao mesmo tempo, encaixar o modelo em um orçamento de implantação limitado. Com compressão de 100 vezes, os métodos clássicos batem no teto. Eles codificam cada vetor token–camada de forma independente, restando cerca de cinco bytes por vetor. Um código tão pequeno não consegue carregar muita informação. Além disso, a relação entre as camadas fica completamente inexplorada.

Um código por token em vez de um código separado para cada camada

O OPTIC (Output-Path-fitted, Token-shared Indexed Codes) funciona de forma diferente. Para cada token, é armazenada uma única tupla de códigos quantizados, compartilhada entre todas as camadas. Em cada camada, um decodificador afim próprio a decodifica, reconstruindo o vetor específico daquela camada. O orçamento de bytes é gasto uma vez por token e dividido entre as camadas.

A segunda parte da ideia envolve exatamente o que é ajustado. Os códigos e decodificadores não são calibrados a partir dos vetores armazenados em si, mas sim do caminho de saída (output path) do PLE: o vetor passa por um gate e por uma projeção de saída, e a compressão é avaliada pelo resultado após essas etapas. A função objetivo corresponde a como o modelo de fato usa os embeddings, então a precisão não é desperdiçada em detalhes que não afetam o resultado final.

Os números do artigo

• Os PLE representam 35,2% dos parâmetros do Gemma 4 E4B.
• Com compressão de cerca de 100x, cada vetor token–camada fica com aproximadamente cinco bytes.
• BF16 E4B a ~100x: o OPTIC mantém 97,8% da qualidade do modelo não comprimido (agregado em sete benchmarks). A quantização por produto, a mais forte entre seis métodos clássicos de referência, alcança 66,3%.
• A 594x, o OPTIC mantém 90,5%.
• A 1002x, o OPTIC mantém 84,1%.
• O lançamento oficial do E4B com pesos lineares de 4 bits e ativações de 16 bits (W4A16): 96,9% com compressão de PLE de ~100x.
• Inferência do BF16 E4B a partir de códigos compactos a ~100x: 29,7% menos memória de GPU com o mesmo cache KV (1 GiB), com desaceleração não superior a 0,40%. Medição feita em uma RTX 4090.

O trabalho com W4A16 merece atenção especial. A quantização dos pesos do backbone e a compressão dos PLE resolvem partes diferentes do problema, e o resultado de 96,9% mostra que elas se somam: o OPTIC não exige escolher entre uma ou outra.

Para quem isso é útil, e quando

A principal conclusão prática para quem implanta o Gemma 4 E4B em hardware de consumo: os PLE deixam de ser um custo de memória inevitável. A economia de 29,7% de VRAM com o mesmo cache KV significa rodar em uma placa menor ou ter mais espaço para o contexto. A desaceleração, de até 0,40%, é praticamente imperceptível.

Para desenvolvedores que constroem produtos de IA em dispositivos, o princípio em si também é interessante. Se as arquiteturas continuarem aumentando a proporção de embeddings nos parâmetros, serão justamente eles que precisarão ser comprimidos. Um código compartilhado por token, com decodificadores próprios para cada camada e ajuste voltado ao caminho de saída, oferece um modelo funcional para esse tipo de arquitetura.

Os autores (Jiacheng Liu, Yaxin Luo, Xiaohan Zhao, Peng Sun, Xinyi Shang, Jiacheng Cui, Yonina C. Eldar e Zhiqiang Shen) publicaram o código e uma análise do método no GitHub, no repositório VILA-Lab/optic. Um artefato pronto, com compressão de 100x dos PLE, está disponível no Hugging Face sob o nome gemma-4-E4B-it-OPTIC-100x, permitindo verificar o resultado em tarefas próprias. O preprint está disponível como arXiv 2610.31309.