Quantização no Ollama: q4_K_M, q8_0 ou fp16?

Alterações causadas pela quantização do Ollama

A quantização do Ollama armazena cada peso de um modelo com menos bits do que o ficheiro usado no treino. Uma tag terminada em q4_K_M mantém cerca de quatro bits por peso, enquanto fp16 mantém dezasseis. Por isso, o download tem aproximadamente um quarto do tamanho e a máquina lê um quarto dos bytes para produzir cada token. Os pesos são arredondados para uma grelha mais grosseira, não são eliminados. Com quatro bits, a maioria dos modelos responde de forma semelhante à versão com precisão total.

Essa é toda a troca: uma utilização de memória muito menor e mais tokens por segundo, em troca de uma pequena perda de precisão. O que se segue explica como prever os dois efeitos para um modelo específico num servidor específico, antes de passar vinte minutos a transferir um ficheiro que não vai caber.

Se o Ollama ainda não estiver em execução, comece por instalar o Ollama num VPS. Esta página assume que ollama ls já funciona.

Como ler uma tag de quantização do Ollama, como q4_K_M

Os modelos locais são distribuídos como ficheiros GGUF, o formato que o llama.cpp utiliza para armazenar os pesos no disco. O Ollama é baseado no llama.cpp, por isso as tags do Ollama mantêm os nomes de quantização do llama.cpp sem alterações.

O número indica a largura pretendida. q4 significa que a maioria dos tensores de pesos é compactada com quatro bits por peso. q8 significa oito. fp16 não é quantizado: é o modelo em ponto flutuante de 16 bits, a precisão em que a maioria dos modelos é publicada.

K identifica uma quantização K. Os pesos são agrupados em blocos pequenos, e cada bloco armazena a sua própria escala junto dos valores compactados. Um bloco cujos pesos estejam todos próximos de 0.01 recebe uma escala precisa. Um bloco que contenha um valor atípico elevado recebe uma escala mais grosseira. São estas escalas por bloco que tornam utilizável um ficheiro de quatro bits. Também são a razão pela qual um ficheiro de quatro bits nunca tem exatamente quatro bits por peso.

A última letra identifica a mistura. S, M e L determinam quantos tensores são promovidos acima da largura pretendida. Em q4_K_M, os tensores que mais perdem quando são arredondados são armazenados com maior largura, enquanto a maioria permanece com quatro bits. É por isso que q4_K_M produz melhores resultados do que o q4_0 mais antigo, com praticamente o mesmo tamanho de ficheiro.

Peça ao Ollama que mostre o que está armazenado no disco, em vez de tentar deduzir isso a partir do nome que introduziu:

ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_M

ollama show mostra architecture, parameters, quantization, context length e embedding length. A linha quantization é a fonte de verdade para um modelo que transferiu há meses e cuja variante já não se lembra de ter escolhido.

Bits por peso determinam o tamanho do ficheiro

Qualquer estimativa de tamanho começa por um número: quantos bits o formato usa por peso, em média para todo o ficheiro. O llama.cpp publica valores medidos para o Llama 3.1 8B na documentação do quantize, e estes valores aplicam-se bem a qualquer modelo denso com uma estrutura semelhante.

[
  {
    "label": "F16",
    "bits_per_weight": 16,
    "file_gib": 14.96
  },
  {
    "label": "Q8_0",
    "bits_per_weight": 8.5,
    "file_gib": 7.95
  },
  {
    "label": "Q6_K",
    "bits_per_weight": 6.56,
    "file_gib": 6.14
  },
  {
    "label": "Q5_K_M",
    "bits_per_weight": 5.7,
    "file_gib": 5.33
  },
  {
    "label": "Q4_K_M",
    "bits_per_weight": 4.89,
    "file_gib": 4.58
  },
  {
    "label": "Q3_K_M",
    "bits_per_weight": 3.99,
    "file_gib": 3.74
  }
]

A surpresa nessa tabela está na segunda coluna. Q4_K_M não usa quatro bits por peso. Mede 4.89 bits, porque as escalas dos blocos e os tensores promovidos também ocupam espaço real. Q8_0 mede 8.5 bits em vez de oito, pelo mesmo motivo. Use o valor medido e o cálculo ficará a poucos por cento do ficheiro real:

weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB

Esse é o ficheiro Q4_K_M de 4.58 GiB, obtido a partir de dois números. Também corresponde, com boa aproximação, à memória ocupada pelos pesos depois de carregados. O Ollama não descompacta nada ao carregar: os pesos quantizados permanecem na memória no mesmo formato empacotado e cada bloco é convertido à medida que é utilizado.

O que o Ollama realmente fornece para cada tamanho de modelo

A biblioteca publica uma tag q4_K_M, uma q8_0 e uma fp16 para a maioria das famílias. Algumas famílias mais recentes quebram esse padrão e aparecem na biblioteca apenas com tags cloud, sem nada para descarregar em qualquer tamanho. Esse é o limite que encontra ao tentar executar o GLM 5.2 numa VPS. Estes são os tamanhos do Qwen3 em agosto de 2026, lidos da lista de tags na página do modelo. Todos os valores abaixo correspondem ao espaço em disco antes de serem carregados na RAM. Juntos, dois ou três modelos podem ocupar o volume root de uma VPS pequena. Por isso, é útil saber onde o Ollama armazena os modelos que descarrega antes de começar a acumular tags.

[
  {
    "label": "Qwen3 4B",
    "q4_K_M_gb": 2.6,
    "q8_0_gb": 4.4,
    "fp16_gb": 8.1
  },
  {
    "label": "Qwen3 8B",
    "q4_K_M_gb": 5.2,
    "q8_0_gb": 8.9,
    "fp16_gb": 16
  },
  {
    "label": "Qwen3 14B",
    "q4_K_M_gb": 9.3,
    "q8_0_gb": 16,
    "fp16_gb": 30
  },
  {
    "label": "Qwen3 32B",
    "q4_K_M_gb": 20,
    "q8_0_gb": 35,
    "fp16_gb": 66
  }
]

A tag predefinida é importante neste caso. ollama pull qwen3:8b descarrega exatamente os mesmos 5.2 GB que ollama pull qwen3:8b-q4_K_M, porque a tag sem sufixo é a compilação q4_K_M. Q4_K_M não é um compromisso que a biblioteca oferece sem convicção. É a opção predefinida escolhida pelo projeto upstream. Por isso, usá-la como referência é o primeiro passo sensato para qualquer modelo que ainda não tenha testado. O mesmo raciocínio orienta as escolhas de tags em executar o Qwen 3 numa VPS.

As proporções mantêm-se em todas as linhas. Passar de q4_K_M para q8_0 custa cerca de mais setenta por cento, e não exatamente o dobro, porque os tensores de embedding e de saída não aumentam à mesma escala que os restantes. fp16 ocupa aproximadamente três vezes o espaço de q4_K_M. Um modelo 32B em q4_K_M tem 20 GB de pesos. Isso já ultrapassa a capacidade de uma máquina com 16 GB para manter qualquer janela de contexto. Para uma visão mais ampla dos modelos que cabem em cada máquina, consulte quais modelos pode alojar localmente.

Por que o cache KV é um custo adicional dependente do contexto

Os pesos são o custo fixo. O cache KV (cache de chaves e valores) é o custo variável. Cada token na janela de contexto mantém os seus vetores de chave e valor em todas as camadas, portanto o cache cresce linearmente com o tamanho da janela permitido. Ele é alocado para toda a janela quando o modelo é carregado, e não à medida que a conversa cresce. Por isso, uma janela longa consome memória mesmo com um prompt de uma palavra.

KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16:  2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token

Esses números do modelo vêm da configuração do próprio modelo: 36 camadas, 8 cabeças de chave/valor e uma dimensão de cabeça de 128. ollama show fornece a arquitetura e a contagem de parâmetros, e o config.json do modelo no Hugging Face fornece o restante. Multiplique o custo por token pelo tamanho da janela e o cache deixa de ser um erro de arredondamento.

[
  {
    "label": "4k",
    "kv_cache_gb": 0.6,
    "floor_ram_gb": 5.8
  },
  {
    "label": "8k",
    "kv_cache_gb": 1.21,
    "floor_ram_gb": 6.4
  },
  {
    "label": "16k",
    "kv_cache_gb": 2.42,
    "floor_ram_gb": 7.6
  },
  {
    "label": "32k",
    "kv_cache_gb": 4.83,
    "floor_ram_gb": 10
  }
]

Com a janela padrão de 4096 tokens do Ollama, o cache acrescenta 0.6 GB aos pesos. Aumente a janela para 32k e apenas o cache chega a 4.83 GB. Isso corresponde a quase a mesma quantidade de memória que os pesos quantizados, e o requisito mínimo de memória para o modelo completo passa a ser 10 GB. É um valor mínimo porque os buffers de computação e o sistema operativo também ocupam memória. Leia o valor real na coluna SIZE de ollama ps depois de o modelo ser carregado.

A janela é definida no servidor, e não por pedido, quando o Ollama é executado como um serviço:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Numa instalação com systemd, coloque-a antes num drop-in:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

Reinicie com sudo systemctl restart ollama. Em seguida, consulte a coluna CONTEXT de ollama ps para confirmar com que janela o modelo em execução foi realmente carregado. OLLAMA_KV_CACHE_TYPE permite quantizar o próprio cache: f16 é o padrão, q8_0 usa aproximadamente metade da memória de f16 e q4_0 usa cerca de um quarto. É uma opção global, portanto todos os modelos nesse servidor recebem o mesmo tratamento. Num sistema pequeno com uma janela longa, reduzir o cache para metade liberta mais memória do que qualquer outra alteração isolada. Definir num_ctx e o respetivo custo explica a janela em detalhe. O cache também é dimensionado uma vez por slot de pedidos simultâneos, e não uma vez por servidor. Assim, permitir que o Ollama responda a dois prompts em simultâneo duplica o valor que acabou de calcular. Esse é o cálculo por trás de escolher a quantidade de slots paralelos e o limite da fila.

O que cabe num VPS de 8, 16 ou 32 GB

Considere os pesos do modelo, mais a cache KV, mais uma margem para o sistema operativo e tudo o que estiver a correr. Uma margem de 2 GB é confortável num VPS pequeno.

8 GB. Um modelo 4B em q4_K_M ocupa 2.6 GB e deixa espaço para uma janela longa. Um modelo 8B em q4_K_M cabe com a janela predefinida de 4k, mas com muito pouca margem. Não planeie usar 8B com uma janela de 32k neste caso, porque o limite inferior de 10 GB já ultrapassa a memória disponível.

16 GB. 8B em q4_K_M com uma janela de 16k ou 32k funciona com margem confortável. 14B em q4_K_M tem 9.3 GB de pesos e cabe com uma janela moderada. 8B em q8_0 ocupa 8.9 GB, por isso também cabe. Comparar estes dois modelos com os seus próprios prompts é a forma mais útil de passar uma hora a estudar este assunto.

32 GB. 14B em q8_0 (16 GB) e 32B em q4_K_M (20 GB) carregam sem problemas. A build 32B com uma janela grande ficará perto do limite, por isso monitorize ollama ps em vez de assumir que haverá margem suficiente.

O que a quantização degrada primeiro

O erro de quantização não afeta de forma uniforme aquilo que um modelo faz. A fluência é a última a desaparecer, precisamente por isso é fácil não detetar os danos: um modelo mal quantizado continua a escrever frases corretas. A precisão desaparece primeiro. A recuperação exata de um número de versão, de uma assinatura de API ou de uma data. Cadeias longas de raciocínio, em que um pequeno erro no passo dois se transforma numa resposta errada no passo oito. Formatos de saída estritos, em que um parêntese incorreto faz uma chamada de ferramenta falhar.

Este último caso é o teste prático. Quando um modelo tem de devolver JSON que o seu código analisa, os danos da quantização surgem como um erro de análise, e não como prosa vagamente pior. Assim, deteta o problema no próprio dia. Um agente de programação é a versão mais exigente desse teste, porque conduz o modelo através de chamadas de ferramentas sucessivas. Por isso, apontar um agente para o seu servidor Ollama expõe uma quantização excessivamente agressiva no espaço de uma tarde.

Abaixo de quatro bits, a perda aumenta rapidamente. Os tipos q3 e de dois bits existem para quem tenta executar um modelo grande em hardware limitado. São uma opção real quando a alternativa é não executar o modelo de todo. São uma escolha predefinida fraca. Entre q4_K_M e q8_0, a diferença é suficientemente pequena para que uma tabela de perplexidade publicada não resolva a questão para a sua carga de trabalho. Por isso, não tente decidir dessa forma. Execute ambos com trinta dos seus próprios prompts e leia a saída.

Quando q8_0 ou fp16 compensam a RAM

Use q8_0 quando houver memória realmente disponível e a tarefa não tolerar erros pequenos: extração estruturada, chamadas de ferramentas e código que precisa de compilar. Nesse caso, está a comprar uma margem de segurança, não um modelo visivelmente mais inteligente.

Use fp16 apenas por dois motivos. Ou está a quantizar o modelo por conta própria e precisa do ficheiro de origem, ou está a medir uma linha de base para saber quanto perdeu com a sua compilação de quatro bits. Servir o modelo em fp16 consome três vezes mais memória do que q4_K_M, por uma diferença que a maioria das pessoas não consegue identificar num teste cego. Numa máquina apenas com CPU, também reduz a taxa de tokens para um terço.

A regra mais importante, com um orçamento de memória fixo, é a seguinte: um modelo maior em q4_K_M normalmente supera um modelo menor em q8_0. 9.3 GB de pesos 14B contra 8.9 GB de pesos 8B representam quase a mesma RAM (random access memory), e o modelo maior tem mais conhecimento. Teste isto com os seus próprios prompts em vez de aceitar a afirmação sem verificar.

A inferência apenas com CPU é limitada pela largura de banda da memória

A maioria dos planos VPS não inclui GPU, por isso o modelo é executado na memória do sistema, usando a CPU do host. A geração fica limitada pela largura de banda da memória, e não pela capacidade de cálculo, porque produzir um token exige ler cada peso uma vez. Isso estabelece um limite que não depende do número de cores que contratou.

tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB  =  9.6 tokens/s    qwen3 8B q4_K_M
50 GB/s / 8.9 GB  =  5.6 tokens/s    qwen3 8B q8_0
50 GB/s / 16 GB   =  3.1 tokens/s    qwen3 8B fp16

Cinquenta GB/s é aproximadamente o valor teórico para um host com DDR4-3200 em canal duplo. A sua parcela é menor, porque um VPS partilha esse barramento com todos os outros tenants da máquina. Considere estes valores um limite que ninguém atinge. O padrão é a parte útil: na CPU, reduzir para metade os bits por peso duplica aproximadamente a taxa de tokens. A quantização é o maior fator de velocidade disponível numa máquina sem GPU. A tolerância à taxa obtida depende do modelo, e Nemotron 3.5 Lightning num VPS aplica esse cálculo a uma compilação específica, com a tag e a quantidade de RAM incluídas. A outra parte da espera é a quantidade de texto que o modelo decide escrever. A dez tokens por segundo, uma resposta de seiscentos tokens demora um minuto inteiro. Por isso, limitar a resposta com num_predict muitas vezes reduz mais o tempo de espera do que diminuir mais um nível de precisão.

O processamento do prompt comporta-se de forma diferente. Ler um prompt longo é limitado pela capacidade de cálculo, e não pela largura de banda. Por isso, mais cores ajudam nessa fase, mas quase não alteram a velocidade de geração. Uma máquina que processa rapidamente um prompt de 4k e depois gera texto lentamente está a funcionar normalmente.

Não aceite estes cálculos sem os verificar. Meça os tokens por segundo na sua própria máquina usando o mesmo prompt para cada quantização e deixe que os seus valores prevaleçam.

Quantizar um modelo por conta própria

Ollama pode criar um modelo quantizado a partir de uma fonte fp16 ou fp32. Isso é útil quando você fez fine-tuning e não existe uma tag de biblioteca correspondente. Aponte um Modelfile para os pesos não quantizados:

FROM /path/to/my/model/f16

Em seguida, crie o modelo e confirme o resultado:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize aceita q8_0, q4_K_S e q4_K_M. Não existe uma opção q6_K ou q5_K_M aqui. Para esses formatos, faça a quantização com a própria ferramenta do llama.cpp e importe o ficheiro GGUF final. Esse método de importação tem uma limitação própria: uma incompatibilidade no template de chat pode fazer o modelo responder com texto corrompido. O guia importar um ficheiro GGUF para o Ollama explica esse procedimento. A linha quantization de ollama show permite verificar se a compilação fez o que você solicitou.

O que verá quando algo correr mal

Tudo corre na CPU quando esperava a GPU. Consulte a coluna PROCESSOR:

ollama ps

É apresentado 100% GPU, 100% CPU ou uma divisão como 48%/52% CPU/GPU. Uma divisão significa que os pesos e a cache KV não couberam na VRAM (RAM de vídeo, a memória da placa gráfica), pelo que parte do modelo foi colocada na memória do sistema. A velocidade aproxima-se então da taxa apenas da CPU, porque cada token espera pela parte mais lenta. Reduza a janela de contexto, quantize a cache ou utilize uma build mais pequena. Adicionar cores não ajudará.

O modelo é terminado durante o carregamento. Consulte o kernel e o log do serviço:

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50

Uma linha que contenha Out of memory: Killed process significa que o total dos pesos, da cache KV e dos buffers ultrapassou a memória disponível na máquina. Numa VPS sem swap configurado, toda a máquina pode ficar bloqueada durante vários segundos antes de essa linha aparecer.

As respostas pioraram e não alterou nada. Duas builds do mesmo modelo podem coexistir em ollama ls com tags diferentes, e um script que obtém o nome sem sufixo seguirá o destino para o qual a biblioteca aponta nesse momento. Execute ollama show com a tag exata solicitada pelo cliente e leia a linha quantization, em vez de confiar no nome no ficheiro de configuração.

FAQ

Qual quantização do Ollama devo obter?

Comece por q4_K_M. Esta é a tag predefinida que a biblioteca do Ollama disponibiliza para a maioria dos modelos, pelo que ollama pull qwen3:8b e ollama pull qwen3:8b-q4_K_M obtêm o mesmo ficheiro. Passe para q8_0 apenas quando houver memória disponível e a tarefa penalizar erros pequenos, como chamadas de ferramentas ou saída JSON estruturada. Quando o limite de memória é fixo, um modelo maior em q4_K_M normalmente supera um modelo menor em q8_0, por isso teste essa combinação antes de reservar RAM para maior precisão.

q4_K_M significa realmente quatro bits por peso?

Não. Medido no Llama 3.1 8B, o valor é 4.89 bits por peso, porque cada bloco de pesos armazena a sua própria escala e os tensores mais sensíveis são promovidos para um tipo mais largo. Q8_0 mede 8.5 bits, e não oito, pelo mesmo motivo. Use o valor medido ao fazer estimativas: o número de parâmetros multiplicado pelos bits por peso, dividido por oito, dá o tamanho do ficheiro em bytes.

De quanta RAM precisa um modelo 8B numa VPS apenas com CPU?

Some os pesos, a cache KV e uma margem de segurança. O Qwen3 8B em q4_K_M tem 5.2 GB de pesos. Com a janela predefinida de 4096 tokens, a cache acrescenta 0.6 GB, resultando num mínimo de cerca de 5.8 GB antes dos buffers de cálculo e do sistema operativo. Com uma janela de 32k, só a cache ocupa 4.83 GB. Planeie 8 GB para uma janela curta e 16 GB se quiser uma janela longa.

Por que motivo o meu modelo está a usar 100% da CPU quando o servidor tem uma GPU?

Execute ollama ps e leia a coluna PROCESSOR. 100% CPU, ou uma divisão como 48%/52% CPU/GPU, significa que os pesos e a cache KV não couberam na VRAM, pelo que o Ollama colocou parte ou todo o modelo na memória do sistema. A causa habitual é uma janela de contexto maior do que a capacidade da placa, porque a cache é alocada para toda a janela quando o modelo é carregado. Reduza a janela com OLLAMA_CONTEXT_LENGTH, defina OLLAMA_KV_CACHE_TYPE=q8_0 para dividir a cache por dois ou obtenha uma quantização menor.