Ollama: Q4, Q8 ou fp16, qual 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 etiqueta terminada em q4_K_M mantém cerca de quatro bits por peso, enquanto fp16 mantém dezasseis. Assim, 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 próxima da 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. 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 que o llama.cpp usa 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 é empacotada com quatro bits por peso. q8 significa oito. fp16 não é quantizado: é o modelo em ponto flutuante de dezasseis 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 mais ampla. Estas escalas por bloco permitem utilizar um ficheiro de quatro bits e também explicam por que razão 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 promovidos para uma largura superior à pretendida. Em q4_K_M, os tensores que mais perdem qualidade quando arredondados são armazenados com uma largura maior, 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 quase o mesmo tamanho de ficheiro.

Peça ao Ollama que mostre o que está armazenado no disco, em vez de tentar adivinhar com base no nome que indicou:

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 descarregou há meses e cuja escolha já não recorda.

Bits por peso determinam o tamanho do ficheiro

Todas as estimativas de tamanho partem de um número: quantos bits o formato utiliza por peso, calculados como média em todo o ficheiro. O llama.cpp publica valores medidos para o Llama 3.1 8B na documentação de quantização, 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. 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á dentro de alguns pontos percentuais 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 ao carregar: os pesos quantizados permanecem na memória no mesmo formato compactado, e cada bloco é convertido quando é utilizado.

O que o Ollama realmente disponibiliza 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. Estes são os tamanhos do Qwen3 em agosto de 2026, obtidos da lista de tags na página do modelo.

[
  {
    "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 disponibiliza sem convicção. É a opção predefinida escolhida pelo upstream, pelo que reproduzi-la é 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 embeddings e de saída não aumentam à mesma escala que os restantes. fp16 corresponde aproximadamente a três vezes q4_K_M. Um modelo 32B em q4_K_M ocupa 20 GB de pesos, o que já excede a capacidade de uma máquina com 16 GB, mesmo sem uma janela de contexto. Para uma visão mais abrangente 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, por isso o cache cresce linearmente com o tamanho da janela permitida. 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 só 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 valores do modelo vêm da própria configuração: 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 representa quase a mesma quantidade de memória que os 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.

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 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 efetivamente carregado. OLLAMA_KV_CACHE_TYPE também permite quantificar o 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, por isso todos os modelos nesse servidor recebem a mesma configuraçã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 respetivo custo explica a janela em detalhe.

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

Pesos do modelo, mais a cache KV, mais 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. 8B em q4_K_M com uma janela de 16k ou 32k funciona com margem confortável. 14B em q4_K_M ocupa 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 os dois com os seus próprios prompts é a forma mais útil de passar uma hora a avaliar este assunto.

32 GB. 14B em q8_0 (16 GB) e 32B em q4_K_M (20 GB) carregam normalmente. A build 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 é o que sobrevive durante mais tempo, precisamente por isso é fácil não perceber os danos: um modelo mal quantizado continua a escrever frases claras. 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, em que um pequeno erro no passo dois se transforma numa resposta errada no passo oito. Formatos de saída rigorosos, em que um único parêntese errado faz uma chamada de ferramenta falhar.

Esse ú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 apenas vagamente pior. Assim, deteta-os no mesmo 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 revela uma quantização agressiva em poucas horas.

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. 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 resolvê-la dessa forma. Execute ambos com trinta dos seus próprios prompts e leia a saída.

Quando q8_0 ou fp16 justificam a RAM

Use q8_0 quando a memória estiver realmente disponível e a tarefa penalizar erros pequenos: extração estruturada, chamadas de ferramentas e código que tem de compilar. 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 sua conta e precisa do ficheiro de origem, ou está a medir uma linha de base para saber quanto perdeu a sua compilação de quatro bits. 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 costuma superar um modelo menor em q8_0. 9.3 GB de pesos 14B contra 8.9 GB de pesos 8B usam praticamente a mesma RAM (random access memory), e o modelo maior sabe mais. Teste isso com os seus próprios prompts em vez de aceitar esta 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, 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 núcleos contratados.

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 dois canais. A sua parcela é menor, porque uma VPS partilha esse barramento com todos os outros clientes da máquina. Portanto, considere esses 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 recurso disponível para aumentar a velocidade numa máquina sem GPU.

O processamento do prompt comporta-se de forma diferente. Ler um prompt longo é uma operação limitada pelo processamento, e não pela largura de banda. Por isso, mais núcleos ajudam nessa etapa, 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 comportar-se normalmente.

Não aceite nenhum destes cálculos sem os verificar. Meça os tokens por segundo na sua própria máquina com o mesmo prompt em cada nível de 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. Isto é útil quando ajustou um modelo e não existe uma tag de biblioteca correspondente. Aponte um Modelfile para os pesos não quantizados:

FROM /path/to/my/model/f16

Depois, 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 nem q5_K_M aqui. Para esses formatos, faça a quantização com a ferramenta própria do llama.cpp e importe o ficheiro GGUF concluído. A linha quantization de ollama show permite confirmar se a compilação fez o que foi solicitado.

O que verá quando algo falhar

Tudo é executado na CPU quando esperava usar 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 (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 diminui para perto da taxa obtida apenas com a CPU, porque cada token fica à espera da parte mais lenta. Reduza a janela de contexto, quantize a cache ou utilize uma build mais pequena. Adicionar mais núcleos não resolve o problema.

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 no servidor. 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 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

Qualização do Ollama que devo obter?

Comece por q4_K_M. Esta é a tag predefinida que a biblioteca Ollama disponibiliza para a maioria dos modelos, portanto ollama pull qwen3:8b e ollama pull qwen3:8b-q4_K_M obtêm o mesmo ficheiro. Use q8_0 apenas quando houver memória disponível e a tarefa for sensível a pequenos erros, 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, portanto teste essa combinação antes de gastar RAM com maior precisão.

q4_K_M significa realmente quatro bits por peso?

Não. Medido no Llama 3.1 8B, são 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, em vez de oito, pelo mesmo motivo. Use o valor medido nas 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 a 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 próximo de 5.8 GB antes dos buffers de computação e do sistema operativo. Com uma janela de 32k, a cache sozinha ocupa 4.83 GB. Planeie 8 GB para uma janela curta e 16 GB se pretender 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 obtenha uma quantização menor.