Modelo local em 2026: o que cabe no seu laptop

A pergunta "quantos bilhões de parâmetros cabem na minha memória?" tem uma resposta fácil e errada.

Errada porque três coisas disputam essa memória, não uma. Os pesos do modelo são só a primeira. O cache de atenção é a segunda, e cresce com o tamanho do contexto. A terceira é o resto: runtime, sistema operacional, ativações.

Quase todo guia calcula a primeira parcela e para. É por isso que tanta gente baixa um modelo que "cabe", abre um arquivo grande e vê a máquina travar.

Este post faz as três contas. Com a fórmula à mostra, validada contra um exemplo publicado, e aplicada a modelos reais de 2026. É o último post do cluster sobre engenharia de harness, e o único em que a restrição não é dinheiro. É memória.

O erro começa na conta de uma parcela só: multiplicar parâmetros por bytes e declarar que cabe.

Essa conta ignora o cache de atenção, que em contextos de 2026 pode passar do tamanho do modelo. E ignora que o sistema também precisa de memória.

Há um segundo problema, mais grosseiro, e vale nomear porque afeta quem está pesquisando agora. Boa parte dos guias de "melhores modelos locais" publicados neste ano lista modelos que não existem. Aparecem combinações como "Llama 3.3 8B" (a família 3.3 saiu apenas em 70B), "Mistral Small 3 7B" (o Mistral Small 3 tem 24B) e "Qwen 3 7B" (a família tem 8B, não 7B).

São textos montados sem conferir nenhuma ficha técnica. Quem segue essas listas escolhe hardware para um modelo imaginário.

A defesa é simples e vale para todo este post: confira no model card. Parâmetros, número de camadas e cabeças de atenção são públicos. É com esses números que a conta fecha.

O orçamento tem três linhas, e só a primeira é fixa.

Os pesos são o produto dos parâmetros totais pelos bytes por parâmetro da quantização escolhida. Essa parcela não muda durante o uso.

O cache de atenção guarda as chaves e valores já calculados, para não recalcular tudo a cada token novo. Ele cresce de forma linear com o contexto. É a parcela que surpreende.

O overhead é o que sobra: o runtime, o sistema, os buffers de ativação. Reservar 2 GB é um piso razoável em máquina de uso geral.

Quem gerencia bem o que entra no contexto paga menos nas duas últimas linhas. É o mesmo problema tratado em por que seu agente esquece, visto agora pelo lado da RAM.

Em 2026, o número que decide se o modelo cabe deixou de ser o número que decide quão rápido ele roda.

Modelos com mistura de especialistas ativam só uma fração dos pesos por token. O Qwen3.6-35B-A3B tem 35 bilhões de parâmetros e ativa 3 bilhões. Ele calcula na velocidade de um modelo de 3B. Mas os 35B inteiros precisam estar na memória, porque qualquer especialista pode ser chamado no token seguinte.

Rápido e gordo. Essa é a combinação que confunde.

O nome dos modelos piorou a confusão. O Gemma 4, lançado pela Google em 2 de abril de 2026 sob licença Apache 2.0, tem quatro tamanhos: E2B, E4B, 26B MoE e 31B denso. O "E" significa effective — parâmetros ativados na inferência, e não o tamanho do modelo (blog do Google, lido em 28/08/2026). O 26B MoE ativa 3,8B dos seus 26B.

O nome anuncia a velocidade e omite o que precisa caber na RAM.

Vale registrar a consequência prática para agentes: um modelo pequeno com muitas ferramentas declaradas gasta boa parte da janela antes de fazer qualquer trabalho. O tema está em design de ferramentas para agentes, e ele pesa mais em modelo local, onde a janela é apertada.

O cache depende da arquitetura, não do tamanho do modelo. A fórmula:

cache = 2 × camadas_com_atenção_plena × cabeças_KV × dim_cabeça × tokens × bytes

O 2 inicial existe porque se guarda chave e valor. Os bytes são 2 em precisão de 16 bits.

A fórmula confere. Aplicada a um exemplo publicado de forma independente — 80 camadas, 8 cabeças de chave-valor, dimensão 128 e 131.072 tokens — ela devolve 42,9 GB, exatamente o valor que a fonte reporta.

Agora o caso real. O model card do Qwen3.6-35B-A3B publica a arquitetura: 40 camadas, no arranjo 10 × (3 × Gated DeltaNet → 1 × Gated Attention). Os blocos de atenção plena têm 16 cabeças de query, 2 de chave-valor e dimensão 256.

O detalhe que muda tudo: das 40 camadas, só 10 são de atenção plena. As outras 30 usam DeltaNet, uma forma de atenção linear que não acumula cache proporcional ao contexto.

Colocando na fórmula, e comparando com uma arquitetura densa clássica:

Uma ressalva de honestidade: a coluna da direita é uma comparação construída, não um modelo real medido. Ela usa 40 camadas de atenção plena com 8 cabeças de chave-valor e dimensão 128, uma configuração típica de modelos densos anteriores. Serve para isolar o efeito da arquitetura, mantendo a contagem de camadas igual.

O resultado, mesmo assim, é grande: o mesmo contexto custa oito vezes menos memória.

A implicação prática do contexto longo em máquina pequena aparece em o que a medição diz sobre contexto longo. Aqui o ponto é anterior: sem essa arquitetura, o contexto simplesmente não caberia.

E se não couber? Três saídas, em ordem de custo

A primeira saída é a mais barata e a mais ignorada: use menos contexto. O cache cresce de forma linear, então cortar o contexto pela metade corta o cache pela metade. A maioria das tarefas locais não precisa de 262 mil tokens. Configure o limite do runtime para o que a tarefa usa de fato, em vez de deixar o padrão do modelo.

A segunda é quantizar o cache, e não só os pesos. Guardar chaves e valores em 8 bits em vez de 16 corta essa parcela pela metade. Aquele exemplo de 42,9 GB cai para cerca de 21,5 GB em FP8. Formatos de 4 bits levam a algo próximo de 10,7 GB, com hardware que os suporte. É uma opção de runtime, e a maioria não a liga por padrão.

A terceira é trocar de modelo por causa da arquitetura, não do tamanho. Entre dois modelos de porte parecido, o que tiver menos camadas de atenção plena vai custar muito menos memória no contexto que você pretende usar. Esse critério não aparece em nenhuma tabela comparativa, e costuma decidir mais que a contagem de parâmetros.

Repare na ordem. As duas primeiras saídas você aplica hoje, na máquina que já tem. A terceira exige baixar outro modelo.

Esta é a leitura que contraria o senso comum do assunto.

A quantização encolhe os pesos. Ela não faz quase nada pelo cache de atenção, que continua sendo calculado em 16 bits na configuração padrão da maioria dos runtimes.

Quem comprou memória achando que Q4 resolveria contexto longo comprou pela razão errada. Passar de FP16 para Q4 corta os pesos em quatro. O cache continua igual.

O que tornou contexto de 262 mil tokens viável num laptop foi trocar a maior parte das camadas de atenção plena por atenção linear. É decisão de arquitetura, tomada por quem treinou o modelo. Você não pode aplicá-la depois.

Os pesos, para 35 bilhões de parâmetros totais:

Os dois últimos valores são aproximações. Os esquemas k-quant não usam o mesmo número de bits em todas as camadas, e o tamanho do vocabulário influencia — neste modelo ele é grande, com 248.320 entradas. Confira o tamanho do arquivo antes de fechar a conta.

O consenso diz que Q4 custa pouco. As faixas de perplexidade que circulam nos guias de comunidade sustentam isso: algo em torno de 0,1% a 0,3% de aumento em Q8, 0,5% a 1,5% em Q6, e 1,5% a 3% em Q4.

Só que perplexidade é um instrumento cego para o que interessa aqui.

Um trabalho de 2026 mediu isso com método estatístico. The Illusion of Equivalency: Statistical Characterization of Quantization Effects in LLMs, de Baha Rababah, Shahzeb Qamar, Lorenz Sparrenberg, Rafet Sifa, Murat Kantarcioglu, Cuneyt Gurcan Akcora e Carson K. Leung, testou larguras de 8 a 2 bits em vários modelos (arXiv 2607.08734, versão 2 de agosto de 2026).

A conclusão é direta: variantes quantizadas não são equivalentes ao modelo base. Segundo os autores, base e variante quantizada costumam apresentar mudança de comportamento mesmo quando acurácia e perplexidade são preservadas.

Isso reposiciona o conselho padrão. Escolher quantização por tabela de perplexidade é escolher por uma métrica que, por construção, não captura a diferença que vai te afetar.

O que resta é testar na sua tarefa. Se o modelo local vai revisar código, escrever em português técnico ou operar ferramentas, é nisso que ele precisa ser comparado — antes e depois de quantizar. O método está em avaliar agente na tarefa real, e vale igual para modelo local.

Trocar de runtime muda a velocidade mais do que trocar de quantização.

Em Apple Silicon há duas opções principais: o MLX, framework da própria Apple, e o llama.cpp, que o Ollama usava como base. O Ollama migrou para MLX em 30 de março de 2026.

Os números medidos, e a razão de eles parecerem contraditórios:

Fontes diferentes citam "3× mais rápido" e "5% a 15% mais rápido" para a mesma comparação. As duas estão certas, e medem coisas diferentes: a vantagem do MLX chega a 3× em modelos MoE e fica em 1,4× a 1,6× em modelos densos. A última linha da tabela mostra que em hardware mais antigo a vantagem pode desaparecer por completo.

Uma limitação a declarar: com exceção da data de migração do Ollama, esses números vêm de material técnico que não publica versões de software nem datas de medição. Trate-os como ordem de grandeza, não como referência. A conclusão que sobrevive é a de método: meça o seu caso, no seu hardware, com os dois runtimes.

O ano concentrou lançamentos, e quase todos sob licença permissiva.

Datas e licenças conferidas nos anúncios oficiais e na linha do tempo de lançamentos open weight, em 28/08/2026. Essa tabela é um retrato e envelhece rápido. A fórmula das seções anteriores não envelhece.

Repare na linha do DeepSeek. O V4-Pro tem 1,6 trilhão de parâmetros totais, é aberto sob licença MIT e não roda no seu laptop em nenhuma quantização. Aberto não quer dizer local. São duas propriedades independentes, e confundir as duas é a origem de boa parte da frustração com modelo aberto.

A própria Google registra o limite superior de forma útil: o Gemma 4 de 31B, em bf16 e sem quantizar, cabe num único H100 de 80 GB. Esse é o tamanho de máquina em questão quando ninguém quantiza nada.

Somando as três parcelas, com o contexto que você realmente usa e uma reserva para o sistema:

A vantagem estrutural do Apple Silicon aqui não é velocidade, é capacidade: a memória unificada é compartilhada entre CPU e GPU, então o teto de modelo é o teto de RAM da máquina. Numa placa dedicada, o teto é a VRAM da placa.

Três argumentos costumam ser usados. Só dois se sustentam.

Custo por token igual a zero. Verdadeiro, mas incompleto: você troca custo variável por custo fixo de hardware, mais o seu tempo de operação. O ponto de equilíbrio depende do volume, e o método para calcular isso está em onde o dinheiro vaza em produção. Para uso individual com plano de assinatura, a conta muda de novo, e está em quanto custa cada padrão de uso.

Dado que não sai da máquina. É o argumento mais sólido, e o único que nenhuma redução de preço de API neutraliza. Código proprietário, dado de cliente e material sob sigilo têm um custo de vazamento que não aparece em nenhuma tabela de tokens. Vale lembrar que rodar local reduz a exposição do dado, mas não elimina os riscos de manipulação do próprio modelo, tratados em injeção de prompt.

Qualidade equivalente. Este é o argumento fraco. Os melhores modelos abertos de 2026 são bons, e os melhores deles não cabem no seu laptop. O que cabe é uma camada abaixo, e para trabalho agêntico longo a diferença aparece.

<!-- [PERSONAL EXPERIENCE] -->

Não escrevo estes posts com modelo local, e vale explicar por quê, porque a razão não é a que eu esperava.

Testei a hipótese de usar modelo local para a etapa de pesquisa do cluster. A ideia parecia boa: é a etapa que mais consome contexto, e cortar esse custo teria efeito real. O que me fez desistir não foi qualidade de escrita — foi a etapa de verificação.

O trabalho deste cluster depende de ler uma fonte primária e decidir se um número confere. Isso significa contexto longo com material recém-publicado, muitas vezes posterior ao treino de qualquer modelo, mais uso disciplinado de ferramentas para buscar e conferir. É exatamente a combinação em que a diferença entre o modelo de topo e o que cabe no laptop mais aparece.

O julgamento explícito, então: para rascunho, reescrita e transformação de texto que você mesmo vai revisar, modelo local em 2026 está bom o bastante e a economia é real. Para trabalho de verificação, onde um erro sutil passa despercebido e vai para o ar, eu não uso.

E há uma ironia útil na conta deste post. O modelo que eu rodaria localmente cabe na memória com folga. O contexto de que a tarefa precisa é que não cabia junto.

Quanto de RAM preciso para rodar um LLM local?

Depende de três parcelas, não de uma. Pesos (parâmetros totais × bytes da quantização), cache de atenção (que cresce com o contexto) e cerca de 2 GB de sistema e runtime. Com 8 GB você roda modelos de 2B a 4B em Q4 com contexto curto. Com 16 GB, um 9B em Q4 roda com folga.

Qual modelo cabe em 16 GB?

Um modelo de 9B em Q4 ocupa perto de 5 GB de pesos e deixa espaço confortável para contexto. Um 27B denso em Q4 fica em torno de 15 GB e só cabe com quantização agressiva e contexto curto, o que traz perda de qualidade. A faixa de 16 GB é confortável até 9B.

Q4 perde qualidade de verdade?

Perde mais do que a perplexidade indica. As faixas usuais apontam de 1,5% a 3% de aumento de perplexidade em Q4, mas o artigo The Illusion of Equivalency (arXiv 2607.08734, agosto de 2026) mostra que modelos quantizados apresentam mudança de comportamento mesmo quando acurácia e perplexidade são preservadas. Teste na sua tarefa.

Modelo MoE roda mais rápido?

Sim, e ocupa o mesmo espaço de antes. Um 35B-A3B ativa 3 bilhões de parâmetros por token, então calcula na velocidade de um modelo de 3B. Mas os 35 bilhões precisam estar na memória, porque qualquer especialista pode ser acionado no token seguinte.

Vale mais Mac com memória unificada ou PC com GPU dedicada?

Para caber modelo grande, o Mac leva vantagem: a memória unificada é compartilhada entre CPU e GPU, então o teto é a RAM da máquina, que chega a 128 GB. Numa GPU dedicada de consumo, o teto é a VRAM da placa. Para velocidade pura em modelos que cabem nas duas, a GPU dedicada costuma ganhar.

Modelo aberto quer dizer que roda no meu computador?

Não. São propriedades independentes. O DeepSeek V4-Pro é aberto sob licença MIT e tem 1,6 trilhão de parâmetros totais: não roda em laptop nenhum, em nenhuma quantização. Aberto significa que os pesos estão disponíveis, não que o seu hardware dá conta deles.

• A memória tem três parcelas. Calcular só os pesos é a origem do erro mais comum.
• Parâmetros totais decidem se cabe. Parâmetros ativos decidem a velocidade. Em MoE, os dois números são muito diferentes.
• O cache de atenção depende da arquitetura, não do tamanho. Só as camadas de atenção plena contam.
• Contexto longo em laptop é mérito da arquitetura híbrida, não da quantização.
• Quantizar muda o comportamento mesmo com métrica preservada. Valide na sua tarefa.
• Aberto não é local. Existem modelos abertos que nenhum laptop roda.

O catálogo deste post é um retrato de 28 de agosto de 2026 e vai envelhecer em semanas. A fórmula do cache de atenção, não. Guarde a fórmula, e recalcule quando o próximo modelo sair.