INSANO: este modelo de IA de 46 MB roda 5 vezes mais rápido no meu laptop (embeddings congelados testados)

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: INSANE: This 46 MB AI Model Runs 5x FASTER on My Laptop (Frozen Embeddings TESTED) · Canal: Prompt Engineer 48 · 05:42 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Dados, bancos de dados e embeddings, Inferência e otimização de modelos, Modelos locais e open source

Resumo

O vídeo analisa um estudo que substitui a tabela de embedding treinada de modelos pequenos por códigos binários congelados de apenas 16,8 MB. Nos testes apresentados, essa abordagem iguala ou supera a tabela aprendida em vários benchmarks, e um modelo ternário de 46 MB roda cerca de cinco vezes mais rápido que uma versão quantizada de 8 bits no laptop do apresentador. O vídeo também aborda os limites do método, incluindo resultados desfavoráveis em tokens de controle e emojis, além de ressalvas sobre o tamanho do estudo e a licença. A conclusão é que, para modelos pequenos executados em CPU, uma parte considerável da tabela de embedding pode ser dispensável.

Pontos-chave

Na Gemma 3 de 270 milhões de parâmetros, cerca de 168 milhões são dedicados à tabela de embedding.
O método reduz cada embedding a um código de 512 bits, totalizando 16,8 MB para o vocabulário, e mantém essa tabela congelada.
Em WordSim, os códigos congelados obtêm 0,617, contra 0,614 das embeddings originais em ponto flutuante.
Nos testes relatados, a tabela congelada vence no Lambada, empata em HellaSwag e PIQA, e perde para a tabela aprendida no ARC-E.
O modelo ternário de 46 MB alcança 517 tokens por segundo e usa 63 MB de memória no laptop do apresentador.
A comparação com um modelo de 8 bits executado em llama.cpp registra 103 tokens por segundo e 471 MB de memória.
Ao adicionar 10 mil palavras biomédicas como novos tokens sem retreinamento, a tabela aprendida piora 43%, enquanto a congelada piora 3%.
O estudo reconhece limitações: tokens de controle e previsão de emojis não favorecem a tabela congelada, e o treinamento pode ser insuficiente para a tabela grande.
A licença é apenas para pesquisa não comercial, e também se aplicam os termos da Gemma, do Google.

Capítulos

Início	Capítulo	Resumo
00:00	O custo da tabela de embedding	O vídeo apresenta a proporção de parâmetros dedicada ao vocabulário e explica a proposta de substituí-lo por códigos congelados.
01:34	Treinamento e resultados nos benchmarks	São comparados três modelos e apresentados os resultados de perda, benchmarks e desempenho em palavras raras.
03:07	Teste de velocidade e memória no laptop	O apresentador compila o kernel, mede a execução do modelo ternário e compara velocidade e memória com llama.cpp.
04:09	Limitações, licença e conclusão	O vídeo testa a inclusão de palavras novas, discute limitações e termos da licença e conclui que embeddings congelados podem ser úteis em modelos pequenos para CPU.

Citações

63% de um modelo de linguagem pequeno não é o cérebro; é o dicionário. — 00:00

O modelo ternário empata com o aprendido em Lambada e PIQA em um arquivo de 46 MB. — 02:37

O kernel ternário é cinco vezes mais rápido. — 03:38

Para modelos pequenos em CPU, as evidências indicam que boa parte disso é dispensável. — 05:11

Conceitos e entidades

Gemma 3 (modelo): Modelo de linguagem da Google usado como base para o estudo de embeddings congelados.
embedding (conceito): Representação vetorial associada a tokens, cuja tabela ocupa grande parte dos parâmetros dos modelos pequenos analisados.
BitNet (conceito): Abordagem de quantização mencionada como exemplo de técnica que reduz os pesos do modelo, mas mantém a tabela de embedding em 16 bits.
GPTQ (conceito): Técnica de quantização citada na transcrição como GBTQ, que não reduz a tabela de embedding a menos de 16 bits.
AWQ (conceito): Método de quantização citado como incapaz de reduzir a tabela de embedding mantida em 16 bits.
WordSim (benchmark): Avaliação usada para comparar a qualidade semântica dos códigos congelados com as embeddings originais.
Lambada (benchmark): Benchmark no qual o modelo com tabela congelada supera o modelo com tabela aprendida nos resultados apresentados.
HellaSwag (benchmark): Benchmark em que os modelos com tabela congelada e aprendida empatam nos testes relatados.
PIQA (benchmark): Benchmark em que os modelos com tabela congelada e aprendida empatam nos resultados apresentados.
ARC-E (benchmark): Benchmark em que a tabela de embedding aprendida supera a congelada nos testes relatados.
llama.cpp (ferramenta): Ferramenta usada para executar o modelo de referência com tabela aprendida e quantização de 8 bits.
Zig (ferramenta): Linguagem usada para compilar o kernel em C disponibilizado pelos autores do estudo.
Shadow 250M (modelo): Modelo anterior do mesmo autor, mencionado como parte da linhagem do trabalho.
Shadow 50M (modelo): Modelo anterior do mesmo autor, citado junto ao Shadow 250M.

Tradução completa (pt-BR)

00:00 63% de um modelo de linguagem pequeno não é o cérebro, é o dicionário. No modelo Gemma 3 de 270 milhões, 168 milhões de parâmetros têm uma única função: consultar palavras. Então, um pesquisador fez uma pergunta provocadora: e se esse dicionário nunca fosse treinado? Este é “Embeddings são caros demais: um vocabulário congelado de 16 megabytes para modelos pequenos”. Sou engenheiro de prompt, li o artigo, baixei o repo e executei tudo no meu próprio laptop. Os números reais vêm

00:31 a seguir. Primeiro, onde ficam os pesos. A tabela de embeddings representa 62,6% do modelo. As camadas feed-forward, onde acontece o raciocínio, representam 26%. E a compressão não resolve isso. BitNet, GBTQ e AWQ mantêm os embeddings em 16 bits. Comprima o corpo do modelo para ternário e, ainda assim, você carrega cerca de 335 megabytes de vocabulário junto de um cérebro de 20 megabytes. A aposta do artigo é que um token não precisa de 640 números de ponto flutuante aprendidos; precisa de um código. Eis a receita: pegue os próprios embeddings do Gemma, centralize-os e mantenha as 512 principais

01:04 direções principais; depois, descarte tudo, exceto o sinal: mais um ou menos um, 512 bits por token. 262.000 tokens × 512 bits: 16,8 megabytes, e isso nunca mais é treinado. Duas pequenas transformações lineares conectam os códigos ao corpo do modelo, somando 650.000 parâmetros. É só isso que aprende do vocabulário. Na saída, os mesmos códigos pontuam a resposta. A entrada e a saída compartilham uma tabela e um prior de frequência fixo chamado

01:34 seal, que acrescenta 1 megabyte. Uma tabela congelada ainda sabe o significado das palavras? No WordSim, os códigos pontuam 0,617; os embeddings originais de ponto flutuante pontuam 0,614. Agora, o experimento. Três modelos, mesmos dados, mesmas etapas, mesma seed; só o vocabulário muda. Braço A: a tabela aprendida normal, com 268 milhões de parâmetros treináveis. Braço B: a tabela congelada com um corpo de ponto flutuante, apenas 101 milhões de parâmetros treináveis. Braço C: a tabela congelada com um corpo de BitNet ternário. Cada peso é menos um,

02:06 zero ou mais um. Cada braço foi treinado com dois bilhões de tokens de dados da web e educacionais de boa qualidade, em uma RTX 5090, por cerca de US$ 18 por braço. O estudo inteiro custou menos de US$ 75. Então, o que a tabela aprendida realmente oferece? 0,2 nats de perda de validação a um custo de 2,6 vezes mais parâmetros treináveis. Mas a perda não é o teste. No Lambada, a tabela congelada vence por 1,6. No HellaSwag e no PIQA, empata. Só no ARC-E a tabela aprendida leva vantagem, por 3,4 pontos.

02:37 Esse é todo o retorno de 168 milhões de parâmetros: um benchmark. O modelo ternário empata com o modelo aprendido no Lambada e no PIQA, em um arquivo de 46 megabytes. Onde a tabela aprendida vence? No meio: em palavras que viu centenas ou milhares de vezes. Em palavras raras, vistas de 10 a 19 vezes, a tabela congelada vence por até 2,3 nats. Os códigos já chegaram sabendo o significado da palavra. Mais de 52.000 tokens do Gemma nunca aparecem no treinamento. Na tabela aprendida, essas linhas continuam aleatórias. Na

03:07 congelada, elas mantêm seu significado. Agora, a parte que me interessa: isso realmente roda em um laptop comum? Os autores disponibilizaram um único arquivo C feito exatamente para isso. Então, testei. Não havia compilador C nesta máquina. Por isso, instalei Zig e compilei o kernel deles com as flags exatas do artigo. O arquivo de pesos de 46 megabytes foi carregado, e executei o benchmark deles: prefill de 128 tokens e, depois, geração de 64. Resultado na minha máquina: 517 tokens por segundo, usando 63 megabytes de memória.

03:38 O artigo relata 62 megabytes e de 615 a 740 tokens por segundo no Xeon usado pelos autores. O uso de memória coincide quase exatamente. Aqui, a velocidade é um pouco menor. Depois, comparei com a baseline: o mesmo modelo, com a tabela aprendida, em GGUF de 8 bits no llama.cpp, usando as mesmas oito threads. Deu 103 tokens por segundo. O kernel ternário é cinco vezes mais rápido. A memória conta a mesma história: 471 MB em 8 bits, contra 63 para o modelo ternário congelado.

04:09 Por que o modelo normal não pode ser reduzido? Todo quantizador mantém aquela tabela grande em 16 bits. Dos 4 bits do arquivo, 250 MB são só vocabulário. O kernel é confiável? Passei a ele “there are 64 validation tokens”. O artigo relata uma perda do próximo token de 4,495. Obtive 4,495. Agora, o truque que eu não esperava: adicionar palavras novas depois do treinamento. Os autores pegaram 10.000 palavras biomédicas e adicionaram cada uma como um único token novo. Sem retreinar. A tabela aprendida teve um resultado 43% pior. A tabela congelada perdeu apenas

04:41 3%. Por quê? Um código congelado vem de uma regra: faça a média das partes, pegue o sinal e pronto. Uma tabela aprendida não tem regra. Suas novas linhas começam aleatórias. E o artigo é transparente sobre o que não funcionou. Tokens de controle totalmente novos e a previsão de emojis não favoreceram a tabela congelada. Uma seed por braço, dois bilhões de tokens, o que significa que a tabela grande foi subtreinada. A vantagem da tabela aprendida provavelmente cresce com mais dados. A alegação de velocidade vem de um laptop e de duas bases de código diferentes. Agora, incluí

05:11 meu próprio laptop. A proporção se manteve. Além disso, leia a licença: apenas para pesquisa não comercial; os termos do Gemma, do Google, também se aplicam à tabela. A linhagem importa. O mesmo autor lançou primeiro Shadow 250M e Shadow 50M. Nenhum dos dois era um teste controlado. Este artigo é… Então, os embeddings são caros demais? Para modelos pequenos em uma CPU, as evidências dizem que muitos deles são, sim. 16 MB de código fixo igualaram ou superaram o desempenho de 168 milhões de parâmetros treináveis em três de quatro benchmarks. E, em seguida, o autor

05:42 dá pistas sobre uma única tabela congelada para texto, imagens, áudio e vídeo, ainda rodando em uma CPU. Tudo foi disponibilizado: pesos, dados, logs e todas as respostas das avaliações. Links na descrição. Lembra do dicionário do começo? Acontece que talvez você não precise ensiná-lo uma única palavra.

Transcrição original

[00:00] 63% of a small language model is not the brain, it is the dictionary. In Gemma 3’s 270 million model, 168 million parameters do one job, they look up words. So, one researcher asked a rude question, what if that dictionary was never trained at all? This is embeddings are overpriced, a frozen 16 megabyte vocabulary for tiny models. I’m prompt engineer, I read the paper, pulled the repo, and ran the whole thing on my own laptop. Real numbers coming

[00:31] up. First, where the weight lives. The embedding table is 62.6% of the model. The feed forward layers, where the thinking happens, are 26. And compression doesn’t fix it. BitNet, GBTQ, and AWQ all leave the embedding in 16-bit. Squeeze the body to ternary, and you still carry about 335 megabytes of vocabulary next to a 20 megabyte brain. The paper’s bet, a token doesn’t need 640 learned floats, it needs a code. Here’s the recipe. Take Gemma’s own embedding, center it, keep the top 512

[01:04] principal directions, then throw away everything except the sign, plus one or minus one, 512 bits per token. 262,000 tokens * 512 bits, 16.8 megabytes, and it never trains again. Two tiny linear maps connect the codes to the body, together 650,000 parameters. That is all the vocabulary that learns. On the way out, the same codes score the answer. Input and output share one table and a fixed frequency prior called the

[01:34] seal adds 1 megabyte. Does a frozen table still know what words mean? On WordSim, the codes score 0.617, the original float embeddings score 0.614. Now, the experiment. Three models, same data, same steps, same seed, only the vocabulary changes. Arm A, the normal learned table, 268 million trainable parameters. Arm B, the frozen table with a float body just 101 million tradable. Arm C, the frozen table with a ternary bit net body. Every weight is minus one

[02:06] zero or plus one. Each arm trained on two billion tokens of fine web edu on one RTX 5090, about $18 an arm. The whole study under 75. So, what does the learn table actually buy? 0.2 nats of validation loss for 2.6 times the trainable parameters. But loss is not the test. On Lambada, the frozen table wins by 1.6. On HellaSwag and PIQA, it ties. Only ARC-E favors the learned table by 3.4 points.

[02:37] That is the whole return on 168 million parameters one benchmark. The ternary model ties the learned one on Lambada and PIQA in a 46 megabyte file. Where does the learned table win? In the middle on words it has seen hundreds to thousands of times. On rare words seen 10 to 19 nine times, the frozen table wins by up to 2.3 nats. The codes arrived already knowing the word. Over 52,000 of Gemma’s tokens never appear in training. In the learned table, those rows stay random. In the

[03:07] frozen one, they keep their meaning. Now, the part I care about, does it actually run on a normal laptop? The authors released a single C file for exactly that. So, I tested it. No C compiler on this machine. So, I installed Zig and built their kernel with the exact flags from the paper. The 46 megabyte weights file loaded and I ran their benchmark prefill 128 tokens, then generate 64. Result on my machine, 517 tokens per second in 63 megabytes of memory.

[03:38] The paper reports 62 megabytes and 615 to 740 tokens per second on its Xeon. Memory matches almost exactly. Speed is a bit lower here. Then the baseline same model learned table 8-bit GGUF in llama.cpp, same eight threads. 103 tokens per second. The ternary kernel is five times faster. Memory tells the same story. 471 MB at 8-bit, 63 for the frozen ternary model.

[04:09] Why can’t the normal model shrink? Every quantizer keeps that big table at 16-bit. 250 MB of the 4-bit file is just vocabulary. Is the kernel honest? I fed it there are 64 validation tokens. The paper reports a next token loss of 4.495. I got 4.495. Now, the trick I did not expect adding new words after training. The authors took 10,000 biomedical words and added each as a single new token. No retraining. The learned table collapsed 43% worse. The frozen table lost only

[04:41] 3%. Why? A frozen code comes from a rule. Average the pieces, take the sign, done. A learned table has no rule. It’s new rows start out random. And the paper is honest about what failed. Brand new control tokens and emoji prediction did not favor the frozen table. One seat per arm, 2 billion tokens which under trains the big table. The learned table’s edge probably grows with more data. The speed claim comes from one laptop and two different code bases. I have now

[05:11] added my own laptop. The ratio held up. Also, read the license, non-commercial research only, and Google’s Gemma terms apply to the table. The lineage matters. The same author shipped Shadow 250M and Shadow 50M first. Neither was a control test. This paper is So, is the embedding overpriced? For tiny models on a CPU, the evidence says a lot of it, yes. 16 MB of fixed code matched or beat 168 million train parameters on three of four benchmarks. And next, the author

[05:42] teases one frozen table on a text, images, audio, and video, still running on a CPU. Everything is released, weights, data, logs, and every evaluation answer. Links in the description. Remember the dictionary at the start? It turns out you may not need to teach it a single word.