Igor Nascimento A frustração que motiva a conversa
"Comprei uma GPU usada cheia de VRAM, mas ela não roda os formatos mais novos de IA na velocidade esperada." Ouço isso com frequência, e a causa é quase sempre a mesma: a pessoa olhou para a quantidade de gigabytes e esqueceu que VRAM é o estacionamento. O motor que move os dados são os Tensor Cores, e quando o assunto é quantização moderna, a idade da arquitetura dita as regras do jogo.
O que é quantização e por que ela existe
Modelos nascem em precisão de 16 bits, FP16 ou BF16, e isso significa dois bytes por parâmetro: um modelo de 8 bilhões ocupa 16 GB antes de qualquer cache. Quantização é comprimir esses pesos para representações menores, INT8, INT4, ou os formatos de ponto flutuante curtos, FP8 e FP4. O ganho mais óbvio é memória: o mesmo modelo em INT4 cabe em 4 a 5 GB. O ganho menos óbvio, e mais importante para quem serve, é banda: como o decode é limitado por leitura de memória, ler metade dos bytes por token é, em primeira aproximação, gerar o dobro de tokens por segundo.
Há uma distinção que muda tudo o que vem depois e que raramente aparece nos posts sobre o tema. Existem dois tipos de quantização:
Só os pesos (weight-only)
- GPTQ, AWQ, GGUF e similares, em INT4 ou INT8
- Os pesos ficam comprimidos na VRAM e são descomprimidos para FP16 na hora de multiplicar
- O cálculo continua sendo em FP16; o ganho é de memória e de banda
- Funciona em qualquer GPU com Tensor Cores FP16
Pesos e ativações (W8A8, FP8)
- Pesos e ativações em 8 bits
- A multiplicação acontece no formato reduzido, sem descompressão
- O ganho é de memória, de banda e de computação, de uma vez
- Exige que o Tensor Core entenda aquele formato em silício
Essa distinção é a chave para entender por que uma placa antiga pode rodar INT4 bem e FP8 mal.
O segredo: suporte nativo no silício
Para uma quantização ser rápida de verdade, a GPU precisa entender aquele formato em nível de hardware. É aqui que entram as gerações de Tensor Cores:
| Geração | Placas | O que o Tensor Core entende |
|---|---|---|
| Pascal e anteriores | GTX 10xx, Tesla P40/P100 | Não há Tensor Cores. Tudo roda em núcleos CUDA gerais, e a multiplicação de matrizes é lenta por natureza |
| Volta / Turing | V100, RTX 20xx, T4 | Volta estreou os Tensor Cores em datacenter, com FP16. Turing foi a primeira geração de consumo e somou INT8 e INT4 |
| Ampere | RTX 30xx, A100, A10 | Adiciona BF16, essencial para a estabilidade de LLMs modernas, TF32, e aceleração de matrizes esparsas |
| Ada Lovelace / Hopper | RTX 40xx, L40, H100 | Transformer Engine com FP8 nativo, dobrando a vazão em relação a FP16 |
| Blackwell | RTX 50xx, B200 | FP4 nativo e formatos sub-8-bit, quadruplicando a vazão de Ampere nos melhores casos |
O nosso cluster roda em RTX 3060, que é Ampere. Isso significa FP16, BF16, INT8 e INT4 nativos, e nenhum FP8 em silício. Saber disso antes de escolher o formato do modelo evita uma semana de "por que está lento".
O que acontece quando o formato não é suportado
Se você tenta rodar um modelo em FP8 numa arquitetura sem instruções para isso, acontece um de dois cenários:
- Emulação via software. A GPU converte os dados de FP8 para FP16 antes de calcular, e converte de volta. Você paga ciclos extras de computação e perde a vantagem de velocidade. Sobra o ganho de memória, que às vezes é o que você queria, mas é preciso saber que foi só isso que se comprou.
- Incompatibilidade de kernel. Motores de inferência modernos, como o vLLM, selecionam kernels otimizados pela compute capability do chip. Se a placa não atinge o requisito, o kernel não carrega, e o motor cai para um caminho genérico ou se recusa a iniciar com aquele formato.
Para quem serve com poucos usuários simultâneos, o gargalo é o decode, e o decode é limitado por banda, não por computação. Nesse regime, quantização só de pesos em INT4 numa placa Ampere entrega quase todo o ganho possível: lê um quarto dos bytes e calcula em FP16, que a placa faz bem. A descompressão na hora custa computação que a placa tinha sobrando. Ter FP8 nativo passa a importar quando o prefill domina (prompts longos, muitos usuários, lote grande), porque aí a conta vira computação e o formato reduzido na multiplicação faz diferença real.
Então: custo por GB ou geração?
É a pergunta de quem monta cluster, e a resposta depende de qual regime você vai viver. Uma placa de datacenter antiga com 24 GB custa hoje uma fração de uma placa de consumo recente com 16 GB. Os trade-offs:
| Critério | Placa antiga, muita VRAM | Placa recente, menos VRAM |
|---|---|---|
| Carregar modelo grande | Cabe mais modelo por real gasto | Pode exigir duas placas ou quantização mais agressiva |
| Decode com poucos usuários | Bom, se tiver Tensor Core FP16 e banda decente | Bom |
| Prefill pesado e lote grande | Sofre: sem FP8, sem esparsidade, menos TFLOPs | Brilha: é onde a geração nova paga a diferença |
| Formatos FP8 e FP4 | Emulado ou indisponível | Nativo |
| Suporte de software | Kernels novos param de dar suporte a compute capability antiga | Primeiro a receber otimizações |
| Consumo e calor | Geralmente pior por token gerado | Melhor eficiência energética |
A regra que uso: se o produto é conversa com poucas pessoas e modelo grande, VRAM barata ganha, desde que a placa tenha Tensor Cores FP16 (o que exclui Pascal, por mais que os 24 GB da P40 sejam tentadores). Se o produto é vazão, lote e prompts longos, a geração ganha, e a VRAM que falta se resolve com duas placas ou com quantização mais agressiva.
E há uma terceira variável que pesa mais do que parece: o ciclo de vida do software. Bibliotecas de inferência abandonam arquiteturas antigas. Comprar barato hoje pode significar ficar preso numa versão de motor daqui a dezoito meses. Isso não aparece no preço, mas aparece no calendário.
Muita VRAM numa arquitetura legada resolve o problema de carregar o modelo. Não resolve o de computar matrizes compactas na velocidade que aplicações em tempo real exigem. São dois problemas, e a ficha técnica só mostra o primeiro.
Resumo da conversa
- Quantização reduz bytes por parâmetro; em decode isso é diretamente mais tokens por segundo, porque o gargalo é banda.
- Quantização só de pesos descomprime para FP16 na hora e roda bem em qualquer placa com Tensor Core FP16. Quantização de pesos e ativações, como FP8, precisa de suporte em silício.
- Pascal não tem Tensor Cores; Turing trouxe FP16 e INT8; Ampere trouxe BF16; Ada e Hopper trouxeram FP8; Blackwell trouxe FP4.
- Sem suporte nativo, o formato é emulado (ganha memória, perde velocidade) ou o kernel não carrega.
- Poucos usuários e modelo grande: VRAM barata com FP16. Vazão, lote e prompt longo: geração nova. E conte o ciclo de vida do software no preço.