Dimensionamento guia · 10 min de leitura

# Qual formato de quantização realmente usar.

Uma pilha de serving pede um formato numérico antes de pedir qualquer outra coisa, e a resposta altera a sua fatura mensal por um fator de oito. O formato com os pesos menores nem sempre é o que resulta no menor modelo.

A resposta curta

- **A regra prática:** Os pesos encolhem exatamente na proporção do nome — BF16 / FP16 **2 B/param** · FP8 **1 B/param** · 4-bit (AWQ, GPTQ) **0.5 B/param**. Mais nada encolhe.
- **O que isso vale:** Qwen 3 32B precisa de [NVIDIA A100 PCIe](https://gpuserver.io/pt/gpu/a100-80gb) a **$1,091** por mês em precisão total, e de [NVIDIA L4](https://gpuserver.io/pt/gpu/nvidia-l4) a **$125** em 4 bits. Mesmo modelo, mesmo contexto.
- **A armadilha:** O cache de chave/valor não acompanha a queda dos pesos. Em 128k de contexto, um Llama 3.3 70B de 4 bits é **53 %** cache e apenas 47 % pesos.
- **Onde o 4 bits perde de vez:** Llama 3.1 8B em 128k precisa de **23.0 GB** em 4 bits contra **18.4 GB** em FP8 — mais memória, para uma qualidade pior

## Comece aqui

A maior parte desta página é aritmética, então aqui está a conclusão primeiro. Quatro perguntas definem o formato, e elas são feitas nesta ordem porque cada uma pode encerrar a discussão sozinha.

**O modelo já cabe na precisão total, com espaço para o seu contexto?** Rode-o em BF16 e pare de ler. Quantização é uma forma de comprar uma máquina menor, e você já comprou uma que funciona. Não há prêmio por comprimir um modelo que já cabe.

**O seu contexto é curto e o seu modelo é grande?** É aqui que os 4 bits fazem jus à sua reputação. Os pesos dominam a memória, e reduzi-los a um quarto é quase o mesmo que reduzir a máquina a um quarto.

**O seu contexto é longo e o seu modelo é pequeno?** Use FP8, em uma placa que o suporte. O FP8 reduz à metade tanto o cache quanto os pesos, e a partir de certo comprimento é essa segunda redução que importa — a tabela abaixo mostra o ponto exato em que ele ultrapassa os 4 bits.

**Você está atendendo uma pessoa em uma máquina?** O GGUF via Ollama é, de longe, o que dá menos trabalho, e o throughput que você abre mão é throughput que um único usuário jamais usaria.

Tudo depois disso explica por que essas quatro respostas são o que são, e fornece os números para conferi-las com o seu próprio modelo, e não com o nosso. Se você ainda não calculou quanta memória o seu modelo precisa, essa aritmética é [um guia separado](https://gpuserver.io/pt/guides/vram-sizing) e vem primeiro.

## Três formatos, quatro nomes

Existem apenas três formatos numéricos em uso comum para serving, e eles diferem em uma coisa: quantos bytes cada parâmetro custa. Todo o resto — AWQ, GPTQ, GGUF, bitsandbytes — é um método para produzir um desses três, não um quarto formato.

**Os três formatos numéricos, e a que cada valor em bytes se aplica**

| Formato | Bytes por peso | Bytes por elemento de cache | Para que serve |
|---|---|---|---|
| BF16 / FP16 Os pesos como publicados | 2 | 2 | Qualidade de referência |
| FP8 Produzido pela própria pilha de serving | 1 | 1 | Quase referência, Hopper e Blackwell |
| 4-bit (AWQ, GPTQ) Um checkpoint preparado com antecedência | 0.5 | 2 | Pesos menores, cache permanece em FP16 |

Leia as duas colunas numéricas como um par. Elas são iguais nas duas primeiras linhas e *não* são iguais na terceira, e essa única assimetria é responsável pela maioria das surpresas mais adiante nesta página.

Os quatro nomes que você realmente vai encontrar em um repositório de modelos correspondem a essa tabela da seguinte forma.

### AWQ e GPTQ

Dois caminhos para o mesmo destino de 4 bits. O AWQ decide quais pesos importam observando as ativações e os protege; o GPTQ comprime camada por camada e corrige o erro à medida que avança. Os dois produzem um checkpoint que o vLLM e o SGLang carregam diretamente, e, em qualquer modelo, a diferença entre eles é menor que a diferença entre qualquer um dos dois e 16 bits.

### GGUF

A família llama.cpp, e o que o Ollama usa por baixo dos panos. É mais um contêiner do que um único método: um arquivo guarda os pesos em qualquer uma de uma dezena de precisões, e ele transborda camadas para a RAM do sistema quando a placa é pequena demais. Imbatível para um único usuário em uma única máquina, e o mais fraco dos três sob concorrência real.

### FP8

Não é bem um formato de checkpoint, e sim um modo. Dê a uma pilha de serving pesos de 16 bits e ela vai convertê-los para FP8 ao carregar, sem download separado e sem passagem de calibração. É o único dos quatro que também consegue comprimir o cache, por isso ele aparece onde você não esperaria, mais abaixo.

### BF16 e FP16

Os pesos como os autores os lançaram, e a referência contra a qual todas as outras linhas são medidas. Dois bytes por parâmetro, sem conjunto de calibração, sem suporte de kernel a verificar, sem argumento de qualidade a discutir. Quando cabe, é a resposta correta, e o resto desta página é uma distração.

Pedir cada um deles é uma única flag. São as mesmas opções que o [guia do vLLM](https://gpuserver.io/pt/guides/serve-llama-70b) usa em detalhe; o ponto aqui é só o quão pequena é a diferença entre eles.

O mesmo servidor, de quatro formas

```
# 1. Reference. The weights as published, nothing to prepare.
$ vllm serve meta-llama/Llama-3.3-70B-Instruct --dtype bfloat16

# 2. FP8, quantised while it loads. No second download, no calibration.
#    --kv-cache-dtype is the half everyone forgets: it is what
#    halves the CACHE as well as the weights.
$ vllm serve meta-llama/Llama-3.3-70B-Instruct \
    --quantization fp8 --kv-cache-dtype fp8

# 3. Four-bit AWQ. A DIFFERENT checkpoint, prepared by someone else.
$ vllm serve casperhansen/llama-3.3-70b-instruct-awq \
    --quantization awq_marlin

# 4. Four-bit GPTQ. Same idea, different repository and flag.
$ vllm serve TechxGenus/Llama-3.3-70B-Instruct-GPTQ \
    --quantization gptq_marlin
```

## A metade que não diminui

Quantizar os pesos para 4 bits não quantiza o cache de chave/valor. O AWQ e o GPTQ comprimem os pesos, e só os pesos; o cache permanece em 16 bits, a menos que você peça separadamente um cache FP8, e em um checkpoint de 4 bits quase ninguém faz isso. Essa é a terceira coluna da tabela acima, e é o motivo pelo qual a aritmética abaixo não segue o que todo mundo espera.

A consequência é mais fácil de ver em um único modelo. Abaixo está o Llama 3.3 70B, em 4 bits, em cada comprimento de contexto que o [configurador](https://gpuserver.io/pt/configure) oferece — pesos contra cache.

**Pesos e cache de um modelo de 70B em 4 bits, por comprimento do contexto**

| Contexto | Pesos | Cache KV | Parcela do cache |
|---|---|---|---|
| 4k tokens | 35.0 GB | 1.3 GB | 3 % |
| 8k tokens | 35.0 GB | 2.5 GB | 7 % |
| 32k tokens | 35.0 GB | 10.0 GB | 22 % |
| 128k tokens | 35.0 GB | 40.0 GB | 53 % |

A coluna de pesos nunca muda — esse é todo o sentido de quantizá-los. A coluna de cache cresce linearmente com o contexto até que, na última linha, ela fica maior do que o próprio modelo a que pertence.

**Em 128k, um Llama 3.3 70B de 4 bits é 53 % cache.** Você quantizou os pesos para um quarto do tamanho original e a máquina necessária quase não mudou, porque você comprimiu a parte que já não era o problema. Quem dimensiona uma implantação de contexto longo só pelo número de pesos vai pedir menos da metade do necessário.

Leve isso longe o suficiente e os 4 bits param de vencer por completo. O FP8 reduz à metade as duas metades; os 4 bits reduzem a um quarto apenas uma metade e deixam a outra intacta. Então, para cada modelo existe um comprimento de contexto em que os dois se cruzam, e ele chega mais cedo quanto menor for o modelo — porque um modelo pequeno tem pouco peso a economizar e o mesmo crescimento de cache por token.

**Memória total em FP8 contra 4 bits, por modelo e comprimento de contexto**

| Modelo | 4k | 8k | 32k | 128k |
|---|---|---|---|---|
| Llama 3.1 8B 8 B de parâmetros · 32 camadas · 8 cabeças KV | 5.24 bits, por 4.3 GB | 5.84 bits, por 4.0 GB | 9.24 bits, por 2.3 GB | 23.0FP8 vence — 18.4 GB |
| Qwen 3 32B 32 B de parâmetros · 64 camadas · 8 cabeças KV | 19.54 bits, por 17.8 GB | 20.74 bits, por 17.2 GB | 27.64 bits, por 13.8 GB | 55.2um empate técnico |
| Llama 3.3 70B 70 B de parâmetros · 80 camadas · 8 cabeças KV | 41.74 bits, por 39.5 GB | 43.14 bits, por 38.8 GB | 51.74 bits, por 34.5 GB | 86.34 bits, por 17.2 GB |

Valores em gigabytes, para o menor dos dois formatos, com o perdedor indicado embaixo. Leia da esquerda para a direita e observe a vantagem da coluna de 4 bits diminuir conforme o contexto cresce.

A última linha mantém a liderança em toda parte, porque 70 bilhões de parâmetros representam uma quantidade enorme de peso a economizar. A linha do meio termina empatada: em 128k, Qwen 3 32B custa exatamente o mesmo nos dois formatos, e você optaria pelo FP8 pela qualidade. E a primeira linha se inverte por completo at 128k, onde os 4 bits exigem *mais* memória do que o FP8 e ainda são o menos fiel dos dois. Essa combinação — mais memória e pior saída — é o erro de quantização mais comum que vemos, e ele é invisível se você só olhar para o tamanho do arquivo de pesos.

## O que sua placa realmente pode fazer

O FP8 é antes um recurso de hardware do que de software. Uma placa cujos tensor cores não o suportam ainda assim carrega um checkpoint FP8 — a pilha desempacota os pesos para 16 bits antes da multiplicação — mas você só mantém a economia no download, e nada da velocidade, e um cache FP8 fica totalmente indisponível para você. Os 4 bits são o oposto: funcionam em qualquer lugar, porque os pesos são desempacotados para 16 bits antes da aritmética de qualquer forma.

**Placas do catálogo por geração, e seu suporte a FP8**

| Geração | Placas que alugamos | FP8 |
|---|---|---|
| Ampere | NVIDIA RTX A6000 48GB, NVIDIA A100 PCIe 40GB, NVIDIA A100 PCIe 80GB, NVIDIA A100 SXM4 80GB | Nenhum no hardware — desempacotado para 16 bits |
| Ada Lovelace | NVIDIA L4 24GB, NVIDIA RTX 4090 24GB, NVIDIA L40S 48GB | Nos tensor cores — pesos e cache |
| Hopper | NVIDIA H100 PCIe 80GB, NVIDIA H100 SXM5 80GB, NVIDIA H200 SXM5 141GB | Nos tensor cores — pesos e cache |
| Blackwell | NVIDIA RTX 5090 32GB, NVIDIA B200 SXM6 180GB | Nos tensor cores — pesos e cache |

Essa coluna descreve o silício, o que não é exatamente a mesma pergunta que saber onde o FP8 é uma boa ideia. A própria observação do catálogo ao lado do formato cita Hopper and Blackwell, e isso é uma afirmação sobre as pilhas de serving, não sobre os tensor cores: essas são as gerações em que os kernels FP8 e os caches FP8 tiveram mais uso e menos surpresas. A Ada Lovelace vai rodar. Hopper e Blackwell são onde colocaríamos uma implantação que depende disso.

**Em uma placa Ampere, o FP8 é uma economia no download e nada mais.** As NVIDIA RTX A6000, NVIDIA A100 PCIe e NVIDIA A100 SXM4 não têm caminho FP8 nos tensor cores. Se o seu plano era reduzir o cache à metade em uma delas, isso não vai acontecer — e os valores de memória na coluna FP8 acima não são valores alcançáveis nesse hardware. Escolha a placa e o formato juntos, nessa ordem.

Mais uma coisa que vale a pena saber antes de escolher uma placa. Llama 3.3 70B em FP8 a 8k precisa de 81.9 GB, e uma placa de 80 GB — a NVIDIA A100 PCIe, entre outras — fica 1.9 GB aquém disso. Não o suficiente para ser óbvio em uma planilha, mas o suficiente para falhar na máquina. A placa que resolve isso sozinha é a categoria seguinte, e o [configurador](https://gpuserver.io/pt/configure) vai informar qual é essa antes de você pagar, e não depois.

## O que isso compra em velocidade

Gerar um token significa ler os pesos ativos na memória uma vez. Menos bytes por peso significa menos bytes para ler, o que significa mais tokens por segundo — e em um único fluxo sem processamento em lotes essa relação é quase perfeitamente linear, porque não há mais nada esperando a placa. Esse é o mesmo teto de largura de banda de memória usado pelo [guia de custo por token](https://gpuserver.io/pt/guides/api-vs-self-hosting) na divisão, e ele é deliberadamente conservador. Abaixo, ele é aplicado a um modelo pequeno o bastante para rodar em qualquer máquina de placa única que alugamos, para que o formato e a placa possam ser lidos na mesma tabela.

**Taxa de geração em fluxo único para um modelo de 8B, por placa e formato**

| Placa | Largura de banda | BF16 / FP16 | FP8 | 4-bit (AWQ, GPTQ) |
|---|---|---|---|---|
| NVIDIA L4 24 GB · $125 por mês | 300 GB/s | ~ 8 tok/s | ~ 17 tok/s | ~ 34 tok/s |
| NVIDIA RTX A6000 48 GB · $286 por mês | 768 GB/s | ~ 22 tok/s | ~ 43 tok/s | ~ 86 tok/s |
| NVIDIA L40S 48 GB · $714 por mês | 864 GB/s | ~ 24 tok/s | ~ 49 tok/s | ~ 97 tok/s |
| NVIDIA RTX 4090 24 GB · $193 por mês | 1008 GB/s | ~ 28 tok/s | ~ 57 tok/s | ~ 113 tok/s |
| NVIDIA A100 PCIe 40 GB · $392 por mês | 1555 GB/s | ~ 44 tok/s | ~ 87 tok/s | ~ 175 tok/s |
| NVIDIA RTX 5090 32 GB · $335 por mês | 1792 GB/s | ~ 50 tok/s | ~ 101 tok/s | ~ 202 tok/s |
| NVIDIA A100 PCIe 80 GB · $1,091 por mês | 1935 GB/s | ~ 54 tok/s | ~ 109 tok/s | ~ 218 tok/s |
| NVIDIA H100 PCIe 80 GB · $1,469 por mês | 2000 GB/s | ~ 56 tok/s | ~ 113 tok/s | ~ 225 tok/s |

Llama 3.1 8B em uma placa, um fluxo por vez. Toda máquina listada comporta isso nos três formatos, então as linhas são comparáveis tanto na horizontal quanto na vertical — e a proporção entre as três colunas é a mesma em cada linha, porque é definida pelos bytes por peso e mais nada.

Duas ressalvas na leitura dessa tabela. A primeira é que ela descreve uma requisição de cada vez, e quase ninguém atende uma requisição de cada vez: sob processamento contínuo por lotes, os pesos são lidos uma única vez para o lote inteiro, então o limite passa a ser a aritmética, e não a memória, e a proporção entre as colunas diminui. A segunda é que desquantizar tem um custo. Os pesos de 4 bits precisam ser desempacotados antes de serem multiplicados, e em um modelo pequeno com lote pequeno, esse desempacotamento pode consumir uma parcela visível do que a leitura menor economizou. A direção da tabela é confiável; os múltiplos exatos não são uma promessa.

## O que isso custa para você

Esta é a parte do assunto em que números apresentados com confiança devem ser recebidos com desconfiança, inclusive os nossos. O erro de quantização depende muito mais do modelo do que do método, e as comparações publicadas discordam entre si porque medem modelos diferentes em tarefas diferentes. O que se pode dizer com honestidade é o formato geral do fenômeno.

**O FP8 é próximo o suficiente para ser incontroverso.** Ainda é um formato de ponto flutuante — um expoente e uma mantissa, com menos bits em cada um — e não a grade de inteiros à qual um checkpoint de 4 bits precisa ser mapeado com escalas por grupo. É por isso que ele degrada tão suavemente, e por que não precisa de passagem de calibração. A maioria das equipes o adota sem rodar uma avaliação, e a maioria não sofre consequências por isso.

**4 bits é uma troca real, e os efeitos são desiguais.** A pontuação média nos benchmarks costuma se mover muito pouco. O que se move é a cauda: cadeias longas de raciocínio, aritmética exata, idiomas raros, formatos de saída rígidos. Um modelo que ainda pontua bem em uma suíte de múltipla escolha pode passar a fechar JSON de forma incorreta.

**Modelos maiores absorvem melhor.** 4 bits em um 70B é uma implantação de rotina. 4 bits em um 8B, cujos parâmetros carregam mais peso individual, é onde a degradação se nota — e, conforme a tabela acima, é onde ele menos compensa.

**Os dados de calibração importam mais do que as siglas.** Tanto o AWQ quanto o GPTQ comprimem em relação a um corpus de amostra. Um checkpoint calibrado em prosa em inglês e usado para código vai ter um desempenho pior do que o método merece, e nenhuma tabela de benchmark vai indicar isso.

O que leva à única recomendação desta página que não é aritmética: rode os dois. Você está alugando uma máquina com root e sem nada medido por uso, então servir o mesmo modelo duas vezes em duas portas e rodar cem prompts seus em cada uma custa uma noite e resolve a questão para a sua carga de trabalho, não para a de outra pessoa. Essa é uma resposta muito melhor do que qualquer tabela, esta incluída — e é por isso que preferimos mostrar a fórmula a uma pontuação.

**Teste na ordem que custa menos.** Comece pelo BF16, se ele couber, porque é a referência que as suas outras execuções vão precisar. Passe para o FP8 em seguida — mesmo checkpoint, uma flag, nada para baixar. Só recorra a um checkpoint de 4 bits quando os dois anteriores tiverem sido descartados por falta de memória, e, quando isso acontecer, compare-o com a execução em FP8, não com as suas expectativas.

## Qual máquina isso representa

O motivo pelo qual tudo isso importa é a fatura. Abaixo está a máquina mais barata do [nosso catálogo](https://gpuserver.io/pt/#catalog) que comporta cada modelo *inteiro* em contexto de 8k, em cada um dos três formatos — inteiro no sentido de caber em uma única placa, sem repartição, porque um modelo repartido entre placas traz [a interconexão](https://gpuserver.io/pt/guides/nvlink-vs-pcie) para a discussão, e isso é assunto de outro guia.

**Máquina mais barata que comporta cada modelo inteiro, por formato**

| Modelo | BF16 / FP16 | FP8 | 4-bit (AWQ, GPTQ) |
|---|---|---|---|
| Llama 3.1 8B | [NVIDIA L4](https://gpuserver.io/pt/gpu/nvidia-l4) $125 por mês · precisa de 19.5 GB | [NVIDIA L4](https://gpuserver.io/pt/gpu/nvidia-l4) $125 por mês · precisa de 9.8 GB | [NVIDIA L4](https://gpuserver.io/pt/gpu/nvidia-l4) $125 por mês · precisa de 5.8 GB |
| Qwen 3 32B | [NVIDIA A100 PCIe](https://gpuserver.io/pt/gpu/a100-80gb) $1,091 por mês · precisa de 75.9 GB | [NVIDIA RTX A6000](https://gpuserver.io/pt/gpu/rtx-a6000) $286 por mês · precisa de 37.9 GB | [NVIDIA L4](https://gpuserver.io/pt/gpu/nvidia-l4) $125 por mês · precisa de 20.7 GB |
| Llama 3.3 70B | [4 × NVIDIA B200 SXM6](https://gpuserver.io/pt/gpu/b200) $11,790 por mês · precisa de 163.9 GB | [4 × NVIDIA H200 SXM5](https://gpuserver.io/pt/gpu/h200) $8,405 por mês · precisa de 81.9 GB | [NVIDIA RTX A6000](https://gpuserver.io/pt/gpu/rtx-a6000) $286 por mês · precisa de 43.1 GB |

Em contexto de 8k, nas máquinas que realmente alugamos. Quando uma célula lista várias placas, isso é o menor nó em que a placa vem, e não um modelo repartido: as placas maiores são vendidas em conjuntos de quatro e oito, então a forma mais barata de evitar repartir um 70B na precisão total é comprar quatro delas e usar uma só. É exatamente essa conta que a quantização existe para evitar.

**Leia a linha do meio de ponta a ponta: $1,091 contra $125, cerca de 9×.** O mesmo Qwen 3 32B, o mesmo contexto de 8k, a mesma placa única e o mesmo acesso root — e um formato numérico diferente entre eles. Esse é todo o argumento comercial para a quantização, e também por isso vale mais uma noite medindo do que uma tarde lendo.

Dois hábitos fazem a diferença entre usar bem essa tabela e ser pego de surpresa por ela. Dimensione pelo contexto que você realmente vai usar, não pelo máximo do modelo — a segunda tabela desta página é o que acontece com quem confunde os dois. E confira o formato na placa antes de pedir, não depois: NVIDIA RTX A6000, NVIDIA A100 PCIe e NVIDIA A100 SXM4 não consegue te dar os números em FP8, não importa qual flag você passe. O [configurador](https://gpuserver.io/pt/configure) informa a memória necessária e se ela cabe em uma placa, para cada nó e cada formato, antes de qualquer pagamento. Se o que você está pesando é alugar contra pagar uma API por token, [esse ponto de equilíbrio](https://gpuserver.io/pt/guides/api-vs-self-hosting) é calculado separadamente, e a quantização o desloca bastante a favor do hardware.

## Verifique o formato e a máquina juntos.

O configurador informa o que o seu modelo precisa em cada precisão, e quais nós o comportam em uma única placa, antes de você pagar qualquer coisa.

[Abrir o configurador](https://gpuserver.io/pt/configure) [Ler os guias](https://gpuserver.io/pt/guides)

## Outros guias

- [Dimensionamento · 10 min Rodando um modelo de mistura de especialistas Parâmetros totais decidem a máquina, parâmetros ativos decidem a velocidade. O que o DeepSeek V3 e o Qwen 3 235B precisam em VRAM, e qual nó alugar para eles. Ler o guia](https://gpuserver.io/pt/guides/mixture-of-experts)
- [Custo · 6 min Quando o aluguel mensal supera o por hora O ponto de equilíbrio calculado com números reais, três custos que um preço por hora esconde até a fatura, e a armadilha do tempo ocioso que triplica uma estimativa. Ler o guia](https://gpuserver.io/pt/guides/monthly-vs-hourly)
- [Custo · 9 min Hospedagem própria contra uma API por token O ponto de equilíbrio entre pagar uma API por token e alugar uma GPU, calculado com nossos preços e throughput — e as quatro coisas que a aritmética deixa de fora. Ler o guia](https://gpuserver.io/pt/guides/api-vs-self-hosting)

---

Fonte: https://gpuserver.io/pt/guides/awq-vs-gptq-vs-fp8/. Este arquivo é gerado a partir dos mesmos dados que o site; se um número aqui divergir de uma página, a página prevalece e este arquivo está desatualizado — a fonte canônica é https://gpuserver.io/.