A quantização em ponto flutuante de 8 bits (FP8) consolidou-se como o padrão de inferência de alta eficiência para modelos de linguagem executados em placas de vídeo profissionais baseadas nas microarquiteturas Ada Lovelace e Hopper da Nvidia. Enquanto a computação em meia precisão tradicional (FP16 ou BF16) exige 2 bytes de memória por parâmetro e a quantização inteira clássica (INT4 ou INT8) pode introduzir degradação perceptível na fluência de raciocínio, o formato FP8 preserva a representação dinâmica com expoente e mantissa dedicados, cortando pela metade a largura de banda de memória necessária para gerar respostas.
Em servidores de produção equipados com aceleradores como Nvidia L4, L40S e H100 operando frameworks de alta vazão como vLLM e TensorRT-LLM, a adoção de FP8 viabiliza aumentos de vazão (throughput) de duas a três vezes na geração de tokens, permitindo acomodar modelos de 70 bilhões de parâmetros em um único nó de computação. Para empresas de tecnologia e centros de dados no Brasil, onde o custo de locação de infraestrutura de nuvem com GPUs é dolarizado e expressivo, a quantização FP8 transforma a viabilidade econômica de projetos de inteligência artificial corporativa sem sacrificar a precisão dos resultados.
Resumo rápido
- O formato FP8 reduz o consumo de memória VRAM pela metade em relação a pesos em FP16 e BF16 nativos.
- As arquiteturas Nvidia Ada Lovelace (RTX 4090, L4, L40S) e Hopper (H100) possuem núcleos tensores com suporte nativo de hardware a FP8.
- O padrão divide-se em dois formatos complementares: E4M3 para pesos e ativações e E5M2 para gradientes e valores extremos.
- Engines de inferência como vLLM e TensorRT-LLM alcançam o dobro de requisições simultâneas por segundo com FP8.
- A perda de perplexidade e precisão matemática em benchmarks de raciocínio é praticamente nula na maioria dos modelos modernos.
O que é o formato FP8 e como ele difere de INT8 e FP16
Diferente de formatos inteiros de quantização como INT8, que mapeiam valores contínuos para números inteiros lineares, o ponto flutuante de 8 bits preserva a estrutura conceitual do ponto flutuante padrão IEEE 754. Ele divide seus 8 bits entre 1 bit de sinal, bits de expoente (que definem a faixa de magnitude) e bits de mantissa (que definem a precisão dos dígitos significativos).
A especificação padronizada pela Nvidia, Intel e Arm estabeleceu duas variantes essenciais de FP8 para aprendizado profundo:
- E4M3 (1 bit de sinal, 4 bits de expoente, 3 bits de mantissa): ideal para representação de pesos estáticos e tensores de ativação, onde a precisão numérica local é mais importante do que uma faixa dinâmica elástica.
- E5M2 (1 bit de sinal, 5 bits de expoente, 2 bits de mantissa): idêntico ao expoente do formato BF16, prioriza ampla faixa dinâmica para suportar valores extremos (outliers) comuns no cálculo de atenção e retropropagação.
Para entender como o FP8 se posiciona em relação a outras técnicas de compactação de modelos abertos, consulte nosso guia comparativo sobre quantização de modelos com GGUF, AWQ e EXL2 e explore a análise avançada sobre quantização EXL2 para modelos de 70B em VRAM.
Suporte de hardware: Ada Lovelace versus Hopper
A execução acelerada de instruções FP8 requer suporte direto dos núcleos tensores (Tensor Cores) da placa de vídeo. As gerações anteriores da Nvidia (como Ampere, presente nas placas A100 e RTX 3090) não possuem instruções nativas para multiplicação de matrizes em ponto flutuante de 8 bits, necessitando emular operações ou recorrer a formatos inteiros INT8 com tabelas de calibração complexas.
Com as famílias Ada Lovelace e Hopper, a Nvidia introduziu o motor Transformer Engine. Esse componente monitora a dinâmica dos tensores em tempo real e alterna dinamicamente cálculos entre FP8 e FP16, mantendo acumuladores em precisão de 32 bits (FP32). Isso garante que o ganho de velocidade não introduza instabilidades numéricas, como divisões por zero ou estouros de representação (overflow) durante a inferência.
Na arquitetura Hopper (placas H100 e H200), a aceleração é potencializada pelo mecanismo de DPX instructions e unidades de descompressão assíncrona, viabilizando ganhos adicionais em pipelines de atenção esparsa (FlashAttention-3). Na arquitetura Ada Lovelace (encontrada nas placas L4, L40 e RTX 4090), os Tensor Cores de quarta geração focam em eficiência energética extrema e throughput sustentado para data centers corporativos com restrições de refrigeração.
Calibração de modelos: Delayed Scaling e AutoFP8
Para converter um modelo originalmente treinado em BF16 para FP8 sem perder a inteligência de raciocínio, aplicam-se algoritmos matemáticos de calibração. O método mais popular no ecossistema open source é o AutoFP8, que utiliza um conjunto representativo de dados textuais para mapear os valores máximos e mínimos das matrizes de projeção.
Outra técnica sofisticada é o Delayed Scaling, implementado pelo Transformer Engine da Nvidia. Em vez de recalcular fatores de escala a cada token gerado (o que consumiria ciclos preciosos de GPU), o sistema utiliza estatísticas móveis das ativações de tokens anteriores para fixar a escala numérica dos tensores. Essa estratégia reduz o overhead computacional a praticamente zero, permitindo que o ganho de velocidade de transferência de memória se traduza diretamente em latência menor para o usuário final.
Comparativo de desempenho: FP16 versus AWQ INT4 versus FP8
A tabela a seguir apresenta os resultados médios de inferência obtidos em um cluster executando o modelo Llama 3 70B com o motor vLLM em servidores corporativos:
| Métrica de Avaliação | Precisão Nativa (FP16 / BF16) | Quantização Inteira (AWQ INT4) | Ponto Flutuante FP8 (E4M3) |
|---|---|---|---|
| Consumo de VRAM por parâmetro | 2,0 bytes | 0,5 a 0,6 bytes | 1,0 byte |
| Memória necessária para modelo 70B | Aproximadamente 140 GB | Aproximadamente 42 GB | Aproximadamente 72 GB |
| Hardware mínimo para rodar 70B | 2x Nvidia A100 (80 GB) | 2x Nvidia RTX 4090 (24 GB) | 1x Nvidia H100 ou 2x L40S |
| Vazão relativa de tokens por segundo | 1,0x (base de comparação) | 1,4x a 1,7x em lotes pequenos | 2,2x a 2,8x em lotes grandes |
| Degradação em tarefas de código/lógica | 0% (referência perfeita) | Perda de 2,5% a 4,0% | Menor que 0,4% de variação |
Implementação prática no vLLM e TensorRT-LLM
No ecossistema moderno de código aberto, aplicar FP8 tornou-se uma tarefa direta. Servidores que utilizam vLLM conseguem carregar modelos pré-quantizados no formato FP8 diretamente do repositório Hugging Face ou converter pesos na inicialização com argumentos simples de linha de comando:
python3 -m vllm.entrypoints.openai.api_server --model meta-llama/Meta-Llama-3-70B-Instruct --quantization fp8 --kv-cache-dtype fp8 --tensor-parallel-size 2 --gpu-memory-utilization 0.92
Ao ativar o parâmetro `–kv-cache-dtype fp8`, até mesmo o cache de chaves e valores (KV Cache) das conversas é comprimido para 8 bits, liberando espaço substancial para janelas de contexto longas com dezenas de milhares de tokens por sessão de atendimento simultâneo. Para acompanhar o ecossistema de modelos que suportam essas técnicas, veja nosso artigo sobre modelos abertos DeepSeek, Llama e Qwen.
Exemplo: servidor de atendimento para operadora em Curitiba
Uma empresa de telecomunicações com sede em Curitiba opera uma central de atendimento automatizado que processa milhares de solicitações de clientes por hora. A equipe de infraestrutura mantinha um cluster com quatro instâncias Nvidia A100 de 80 GB na nuvem rodando um modelo Llama de 70 bilhões de parâmetros em BF16, com custo mensal elevado em moeda estrangeira.
Ao modernizar o parque computacional para duas instâncias equipadas com placas Nvidia L40S de 48 GB da geração Ada Lovelace e habilitar a quantização FP8 via vLLM, a empresa obteve resultados imediatos. A velocidade de resposta passou de 32 tokens por segundo para 74 tokens por segundo em cargas concorrentes intensas, mantendo o índice de resolução de chamados no primeiro contato em 91%.
A economia líquida na fatura mensal de computação em nuvem superou 45%, permitindo que a companhia expandisse o assistente para novos canais de autoatendimento no WhatsApp sem comprometer o orçamento de tecnologia da informação.
Erros comuns
- Tentar rodar FP8 em GPUs de gerações anteriores: inicializar flags de FP8 em placas das arquiteturas Turing ou Ampere resulta em fallback para emulação em software, tornando a inferência extremamente lenta.
- Não quantizar o KV Cache: comprimir apenas os pesos do modelo e esquecer a memória de atenção faz com que servidores fiquem sem memória quando o número de usuários simultâneos aumenta.
- Desconsiderar a calibração de escala (scaling factors): converter modelos para FP8 sem aplicar fatores de escala adequados para tensores de ativação causa truncamento e respostas incoerentes.
- Usar FP8 para ajuste fino (fine-tuning) sem salvaguardas: treinar modelos diretamente em FP8 exige otimizadores específicos e tratamento cuidadoso de gradientes sob pena de colapso de aprendizado.
- Ignorar limites térmicos e de energia (Power Limit): operar GPUs em carga plena contínua com kernels FP8 eleva a densidade térmica e exige refrigeração adequada no datacenter.
Perguntas frequentes
A quantização FP8 funciona em placas GeForce para jogos, como a RTX 4090?
Sim. A arquitetura Ada Lovelace das placas RTX 4090 possui suporte de hardware a instruções FP8, permitindo que desenvolvedores executem modelos quantizados em estações de trabalho locais com alto rendimento.
Qual a diferença de velocidade entre FP8 e INT4 no vLLM?
Em lotes com muitos usuários simultâneos (batch size elevado), o formato FP8 é consideravelmente mais rápido que INT4 porque os núcleos tensores executam operações de multiplicação sem a necessidade de descompactar os pesos para FP16 antes de cada cálculo.
Os modelos quantizados em FP8 perdem capacidade de seguir regras complexas?
Não. Testes empíricos em benchmarks rigorosos como MMLU, HumanEval e GSM8K demonstram que a perda de pontuação com FP8 fica quase sempre abaixo de meio ponto percentual em relação ao modelo original em BF16.
O Ollama suporta modelos em formato FP8 nativo?
O Ollama utiliza o motor llama.cpp, que tradicionalmente foca em formatos inteiros GGUF. Para tirar proveito total da aceleração FP8 de hardware da Nvidia, recomenda-se o uso de vLLM, TensorRT-LLM ou SGLang.
É possível utilizar FP8 em provedores de nuvem brasileiros?
Sim, provedores locais e grandes nuvens públicas que oferecem instâncias com aceleradores L4, L40S e H100 em regiões brasileiras disponibilizam suporte integral a kernels FP8.
Como saber se meu modelo já está quantizado em FP8?
Modelos quantizados geralmente incluem `FP8` no nome do repositório no Hugging Face e trazem arquivos de metadados como `quant_config.json` especificando o esquema de calibração adotado.
