Dá para rodar um LLM num Mac mini de 16 GB? O que medi com quantização

O que é quantização, em uma frase?

Um modelo de linguagem é, em grande parte, uma lista enorme de números: os pesos. Depois de treinados, eles costumam ser guardados em 16 bits cada. Quantizar é guardar cada peso com menos bits, trocando um pouco de precisão por muito menos memória.

A conta é direta. 16 bits são 2 bytes, então um modelo de 9,7 bilhões de parâmetros em 16 bits ocupa uns 19,4 GB só de pesos. O formato Q4_K_M usa cerca de 4,9 bits por peso (4,8944, segundo a documentação do llama.cpp), e o mesmo modelo cai para perto de 6 GB. Na tabela do próprio llama.cpp, o Llama 3.1 de 8 bilhões de parâmetros vai de 14,96 GiB em 16 bits para 4,58 GiB em Q4_K_M: pouco mais de três vezes menor.

Os quatro modelos que medi estão em GGUF, o formato do llama.cpp, que é o que o Ollama roda por baixo.

Quanto de memória e de velocidade cada modelo usou?

Como medi: Mac mini M4 com 16 GB de memória unificada, macOS 15.5, Ollama 0.40.9, em 25 de outubro de 2026. O mesmo pedido em português para todos, até 300 tokens de resposta, temperatura 0. Rodei cada modelo duas vezes e contei a segunda, para o tempo de carregar o modelo não entrar na velocidade. A memória é a que o ollama ps informa com o modelo carregado, e os quatro rodaram 100% na GPU. O contexto foi o padrão de 4.096 tokens, menos na terceira linha.

A velocidade cai mais ou menos na proporção do tamanho: o de 12 bilhões gerou pouco mais de um terço da velocidade do de 4 bilhões. Carregar o modelo do zero levou de 10 a 16 segundos, o que só pesa na primeira chamada.

Por que o contexto também ocupa memória?

O mesmo Qwen, com os mesmos pesos e a mesma quantização, ocupou 5,5 GB com contexto de 4.096 tokens e 7,8 GB com contexto de 65.536 tokens. Os 2,3 GB a mais são a memória que o modelo reserva para guardar o que já leu da conversa, o chamado KV cache.

No Mac de 16 GB, então, a pergunta não é só se o modelo cabe. É se cabem o modelo, o contexto e o resto do sistema ao mesmo tempo. Eu uso a versão de 64 mil tokens porque o agente lê material longo antes de escrever, e mesmo assim sobra memória para a máquina continuar servindo o resto.

Quantizar estraga o modelo?

Um pouco, e quanto menos bits, mais. A documentação da Unsloth explica que a quantização feita depois do treino (PTQ) muitas vezes piora a precisão, principalmente em 4 bits ou menos. Ela aponta dois caminhos: quantizações dinâmicas, que usam um conjunto de calibração para dar mais bits aos pesos que importam mais, e o treino ciente da quantização (QAT), em que o modelo aprende já sabendo que vai ser arredondado.

"QAT has no extra overhead during inference, and uses the same disk and memory usage as normal naive quantization!"
— Unsloth, documentação de Quantization-Aware Training

Em português: o QAT não deixa a inferência mais lenta e usa o mesmo disco e a mesma memória da quantização comum. Segundo a mesma página, ele recuperou 66,9% da precisão perdida pelo Gemma 3 4B no teste GPQA. Eu ainda não testei QAT. É o próximo passo, e conto aqui quando fizer.

Qual tamanho escolher num Mac de 16 GB?

Pelo que medi, e para o que eu faço:

• 9 bilhões em Q4_K_M é o meu equilíbrio para um agente que roda sozinho: cabe com folga mesmo com 64 mil tokens de contexto e gera 18,5 tokens por segundo.
• 12 bilhões cabe, mas sobra menos memória para contexto e para o resto da máquina.
• 4 bilhões é para quando a resposta precisa ser rápida e a tarefa é simples.

Não é uma regra geral. Outra tarefa, outro modelo ou outra versão do Ollama dão outros números, e por isso deixei o método acima: dá para repetir a medição na sua máquina.