Ollama: Q4, Q8 ou fp16, qual quantização escolher?

O que a quantização do Ollama altera

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 terço do tamanho, e a máquina lê cerca de um terço dos bytes para gerar cada token. Os pesos são arredondados para uma grelha menos precisa, não são eliminados. Com quatro bits, a maioria dos modelos responde de forma próxima do comportamento com precisão total.

Esta é toda a compensação: uma utilização de memória muito menor e mais tokens por segundo, em troca de uma pequena perda de precisão. A seguir, explicamos como prever ambos os efeitos para um modelo específico numa máquina específica, 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 numa VPS. Esta página pressupõe 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 usado pelo llama.cpp para armazenar os pesos em disco. O Ollama é baseado no llama.cpp, por isso as tags do Ollama mantêm inalterados os nomes de quantização do llama.cpp.

O número indica a largura alvo. q4 significa que a maioria dos tensores de pesos é empacotada 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 pequenos blocos, e cada bloco armazena a sua própria escala junto dos valores empacotados. Um bloco cujos pesos estejam todos próximos de 0.01 recebe uma escala fina. Um bloco que contenha um valor atípico grande recebe uma escala ampla. Essas escalas por bloco mantêm utilizável um ficheiro de quatro bits e também explicam por que um ficheiro de quatro bits nunca tem exatamente quatro bits por peso.

A última letra indica a combinação. S, M e L determinam quantos tensores são armazenados acima da largura alvo. Em q4_K_M, os tensores que mais perdem qualidade quando são arredondados são armazenados com maior largura, enquanto a maior parte permanece com quatro bits. Por isso, q4_K_M produz uma saída melhor do que o q4_0 mais antigo, com praticamente o mesmo tamanho de ficheiro.

Peça ao Ollama a informação que está em disco, em vez de tentar adivinhar a partir do nome que introduziu:

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

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

Bits por peso determinam o tamanho do ficheiro

Todas as estimativas de tamanho começam pelo mesmo número: quantos bits o formato utiliza por peso, calculados como 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 utiliza quatro bits por peso. O valor medido é de 4.89 bits, porque as escalas dos blocos e os tensores promovidos também ocupam espaço real. Q8_0 utiliza 8.5 bits em vez de oito, pelo mesmo motivo. Utilize o valor medido e o cálculo ficará a poucos por cento do tamanho real do ficheiro:

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, com uma boa aproximação, a memória ocupada pelos pesos depois de carregados. O Ollama não descompacta nada durante o carregamento: os pesos quantizados permanecem na memória no mesmo formato empacotado, e cada bloco é convertido à medida que é utilizado.

O que o Ollama disponibiliza efetivamente para cada tamanho de modelo

A biblioteca publica uma tag q4_K_M, uma tag q8_0 e uma tag fp16 para a maioria das famílias. Algumas famílias mais recentes fogem a esse padrão e aparecem na biblioteca apenas com tags cloud only, sem nada para transferir em qualquer tamanho. É esse o bloqueio que encontra ao tentar executar o GLM 5.2 numa VPS. Estes são os tamanhos do Qwen3 em outubro de 2026, lidos na lista de tags da página do modelo. Todos os valores abaixo referem-se ao espaço em disco antes de o modelo ser carregado para a RAM. Dois ou três modelos podem ocupar o volume root de uma VPS pequena. Por isso, é importante saber onde o Ollama armazena os modelos que transfere 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 transfere 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 disponibiliza a contragosto. É a opção predefinida escolhida pelo projeto upstream. Por isso, corresponde à primeira escolha sensata para qualquer modelo que ainda não tenha testado pessoalmente. 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á excede o que uma máquina com 16 GB consegue armazenar com 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 cada camada, por isso o cache cresce de forma linear 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 quando o prompt tem apenas 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 4096 tokens, a janela padrão que o Ollama escolhe quando há menos de 24 GiB de VRAM (incluindo uma VPS apenas com CPU), o cache adiciona 0.6 GB aos pesos. Aumente a janela para 32k e só o cache chegará a 4.83 GB. Isso é quase a mesma quantidade de memória ocupada pelos pesos quantizados, e o mínimo para o modelo completo passa a ser 10 GB. É um mínimo porque os buffers de computação e o sistema operativo ocupam memória adicional. Leia o valor real na coluna SIZE de ollama ps depois de o modelo ser carregado. Numa GPU com 24 a 48 GiB de VRAM, a janela padrão é 32k. A partir de 48 GiB, é 256k. Por isso, numa placa com muita memória, não assuma o valor de 4k.

A janela é definida no servidor, e não por pedido, quando executa o Ollama 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. Depois, consulte a coluna CONTEXT de ollama ps para confirmar com que janela o modelo em execução foi realmente carregado. OLLAMA_KV_CACHE_TYPE quantiza o próprio cache: f16 é o valor predefinido, q8_0 usa aproximadamente metade da memória de f16 e q4_0 usa aproximadamente um quarto. É uma opção global, por isso todos os modelos nesse servidor recebem o mesmo tratamento. A quantização do cache só tem efeito quando o Flash Attention está ativado. O Ollama ativa-o automaticamente quando o backend o suporta, e OLLAMA_FLASH_ATTENTION=1 força a sua ativação. Numa máquina pequena 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 seu custo explica a janela em detalhe. O cache também é dimensionado uma vez por slot de pedido concorrente, 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. Essa é a base do cálculo para escolher o número de slots paralelos e o limite da fila.

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

Considere o consumo dos pesos, mais a cache KV, mais uma margem para o sistema operativo e tudo o que estiver a ser executado. 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 e muito pouca margem. Não planeie usar 8B com uma janela de 32k neste caso, porque o mínimo de 10 GB já ultrapassa a memória disponível.

16 GB. O 8B em q4_K_M funciona confortavelmente com uma janela de 16k ou 32k. O 14B em q4_K_M ocupa 9.3 GB de pesos e cabe com uma janela moderada. O 8B em q8_0 ocupa 8.9 GB, portanto também cabe. Comparar os dois com os seus próprios prompts é a forma mais útil de investir uma hora neste assunto.

32 GB. O 14B em q8_0 (16 GB) e o 32B em q4_K_M (20 GB) carregam ambos. A compilação 32B com uma janela grande ficará próxima do limite. Por isso, monitorize ollama ps em vez de assumir que há margem suficiente.

O que a quantização degrada primeiro

O erro de quantização não se distribui uniformemente pelas capacidades de um modelo. 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 é a primeira a degradar-se. 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, nas quais um pequeno erro no passo dois produz uma resposta errada no passo oito. Formatos de saída rigorosos, nos quais um parêntese errado 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, em vez de surgirem como texto vagamente pior. Assim, deteta-os no próprio dia. Um agente de programação é a versão mais exigente deste teste, porque conduz o modelo através de chamadas de ferramenta sucessivas. Por isso, apontar um agente para o seu servidor Ollama expõe uma quantização demasiado 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 colocar um modelo grande em hardware limitado. São uma opção real quando a alternativa é não executar o modelo. Não são uma boa predefinição. Entre q4_K_M e q8_0, a diferença é suficientemente pequena para que uma tabela de perplexidade publicada não permita decidir qual é melhor 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 justificam o uso de 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 a sua compilação de quatro bits perdeu. Servir a partir de 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. Num sistema 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, é esta: 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 praticamente a mesma RAM (memória de acesso aleatório), e o modelo maior sabe mais. Teste isso com os seus próprios prompts, em vez de aceitar essa conclusã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, não pela capacidade de cálculo, porque produzir cada token exige ler todos os pesos uma vez. Isto cria 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 de canal duplo. A sua fração é menor, porque uma VPS partilha esse barramento com todos os outros tenants da máquina. Por isso, considere estes valores um limite que ninguém atinge. O padrão é a parte útil: na CPU, reduzir para metade o número de bits por peso aumenta aproximadamente para o dobro a taxa de tokens. A quantização é o maior fator de velocidade disponível numa máquina sem GPU. A tolerância da taxa obtida depende do modelo, e Nemotron 3.5 Lightning numa 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 com seiscentos tokens demora um minuto completo. Por isso, limitar a resposta com num_predict muitas vezes reduz mais o tempo de espera do que diminuir novamente a precisão.

O processamento do prompt comporta-se de forma diferente. Ler um prompt longo é uma tarefa limitada pela capacidade de cálculo, não pela largura de banda. Por isso, mais cores ajudam nessa fase, mas quase não aumentam a velocidade da 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 em cada quantização e deixe que os seus valores prevaleçam.

Como quantizar um modelo manualmente

Isto é importante quando fez um fine-tuning e não existe uma tag de biblioteca. O procedimento depende do formato final pretendido, porque o Ollama já não produz os K-quants GGUF medidos nesta página.

Para um K-quant, como q4_K_M, faça a quantização antes de o Ollama receber o ficheiro. O Ollama não quantiza modelos GGUF durante a importação e recusa --quantize numa origem GGUF. Quantize o GGUF não quantizado com llama-quantize do llama.cpp e, em seguida, importe o ficheiro concluído. Esta rota de importação tem uma limitação própria: uma incompatibilidade no template de chat pode fazer o modelo responder com texto sem sentido. O guia importar um ficheiro GGUF para o Ollama explica como resolver esse problema. A linha quantization de ollama show permite confirmar se o ficheiro importado corresponde à build pretendida.

O --quantize próprio do Ollama funciona apenas com importações de safetensors. Aponte um Modelfile para o diretório que contém os pesos safetensors não quantizados:

FROM /path/to/safetensors/directory

Depois, faça o build:

ollama create --quantize int4 mymodel

No Ollama v0.40.2 (verificado em 2026-10-11), --quantize aceita int4, int8, nvfp4, mxfp4 e mxfp8. q4 e q8, assim como fp4 e fp8, são aceites como aliases de int4 e int8. Nomes GGUF como q4_K_M, q4_K_S, q8_0, q6_K e q5_K_M são rejeitados com um erro unsupported quantize type. Estes tipos não são os K-quants GGUF apresentados nas tabelas acima. Por isso, não use os valores de bits por peso e de tamanho do ficheiro desta página para prever os valores desses tipos.

O que verá quando algo falhar

Tudo é executado na CPU quando esperava a GPU. Leia a coluna PROCESSOR:

ollama ps

É apresentada a indicação 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 (memória 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 obtida apenas com a CPU, porque cada token fica à espera da metade mais lenta. Reduza a janela de contexto, quantize a cache ou descarregue uma compilação mais pequena. Adicionar núcleos não ajudará.

O modelo é terminado durante o carregamento. Verifique 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 no sistema. Numa VPS sem swap configurada, 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 compilações do mesmo modelo podem coexistir em ollama ls com tags diferentes, e um script que descarrega o nome sem sufixo seguirá o destino atualmente definido pela biblioteca. Execute ollama show com a tag exata solicitada pelo cliente e leia a linha quantization, em vez de confiar no nome do ficheiro de configuração.

FAQ

Qual é a quantização do Ollama que devo descarregar?

Comece com q4_K_M. Esta é a tag predefinida da biblioteca Ollama para a maioria dos modelos, por isso ollama pull qwen3:8b e ollama pull qwen3:8b-q4_K_M descarregam o mesmo ficheiro. Mude 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 orçamento de memória é fixo, um modelo maior em q4_K_M normalmente supera um modelo menor em q8_0. 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. Pelo mesmo motivo, Q8_0 mede 8.5 bits, em vez de oito. Use o valor medido para 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 apenas numa VPS 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. Isto dá um mínimo próximo de 5.8 GB, antes dos buffers de computação e do sistema operativo. Numa janela de 32k, a cache ocupa sozinha 4.83 GB. Reserve 8 GB para uma janela curta e 16 GB se precisar de uma janela longa.

Por que motivo o meu modelo usa 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. Por isso, 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 reduzir a cache para metade ou descarregue uma quantização menor.