Formatos de 16 bits reduzem pela metade a memoria dos pesos do modelo sem alterar a arquitetura

No mesmo modelo de 7 bilhoes de parametros, os pesos podem ocupar aproximadamente 28 GB em FP32, 14 GB em FP16 ou BF16 e 7 GB com oito bits. A arquitetura nao muda; o que muda e a forma de armazenar os numeros. A vantagem parece evidente: menos memoria e menos dados trafegando entre a memoria e as unidades de processamento, portanto o modelo deveria responder mais rapidamente.

Mas e justamente nesse ponto que a confusao costuma comecar. Menos bits nao garantem maior velocidade. Se o processador ou a GPU nao conseguirem executar operacoes com eficiencia no formato escolhido, o ambiente podera adicionar conversoes, trocar para um kernel mais lento ou ate encerrar o calculo com um erro. Alem disso, uma faixa de valores estreita demais pode transformar uma ativacao grande em infinito ou eliminar pequenas diferencas entre numeros.

FP16 e BF16 resolvem problemas diferentes

Um numero de ponto flutuante armazena um sinal, um expoente e uma mantissa. O expoente determina a faixa de magnitudes, enquanto a mantissa determina a capacidade de distinguir valores proximos. Ao reduzir o numero de bits, e preciso escolher o que sacrificar.

O FP16 reserva mais espaco para a mantissa e, por isso, diferencia numeros vizinhos com maior precisao. Sua faixa, porem, e relativamente estreita: valores altos nas ativacoes podem causar overflow. O BF16 armazena a mesma quantidade de bits de expoente que o FP32 e, portanto, suporta magnitudes muito maiores e menores. O custo e uma precisao inferior para valores proximos.

Imagine uma camada que recebe os valores 1,001 e 1,002 e, mais tarde, encontra uma ativacao de 100.000. O FP16 preservara melhor a diferenca entre os dois primeiros numeros, mas podera nao conseguir lidar com o valor alto. O BF16 suportara o valor discrepante com mais facilidade, embora possa arredondar os valores proximos da mesma maneira. A melhor opcao e determinada pelo modelo, pelos dados e pelo hardware, nao pelo nome do formato.

Ha ainda outro detalhe: o tipo usado para armazenar os pesos nao revela o quadro completo. Uma multiplicacao de matrizes pode ler dados em FP16, acumular a soma em FP32 e gravar o resultado novamente em FP16. Por isso, relatorios de desempenho devem informar a precisao das entradas, da acumulacao e das saidas.

A precisao mista protege operacoes sensiveis

Nao e necessario converter o modelo inteiro para um unico formato. As multiplicacoes de matrizes podem ser executadas em FP16 ou BF16, enquanto normalizacao, softmax, reducoes e determinadas camadas permanecem em FP32. Esse modo preserva a aceleracao nas operacoes mais pesadas e reduz o risco de erros numericos.

No entanto, alternar tipos manualmente tambem tem um custo. Conversoes desnecessarias consomem tempo, e uma incompatibilidade entre os tipos das entradas e dos pesos pode interromper a execucao. Para um modelo pre-treinado, e mais sensato comecar pelo modo de precisao mista suportado por sua biblioteca, verificar o profiler e somente depois alterar camadas especificas.

E melhor carregar um checkpoint grande diretamente no formato de destino. Se a versao FP32 for colocada primeiro na memoria e depois convertida para FP16, por um curto periodo sera necessario manter as duas copias. Em um modelo grande, isso pode ser suficiente para provocar um erro de memoria insuficiente antes mesmo da primeira solicitacao.

O que medir antes do lancamento

Os formatos devem ser comparados em tres dimensoes. A primeira e a memoria: tamanho dos pesos, consumo de pico, cache KV e buffers temporarios. A segunda e a velocidade: separadamente, a latencia do processamento do contexto de entrada, a geracao de tokens e o throughput total com tamanhos de lote realistas. A terceira e a qualidade: perplexidade, metricas da aplicacao e respostas a solicitacoes representativas.

Um unico texto coincidente nao e suficiente. Com a selecao gulosa de tokens, as respostas podem parecer identicas mesmo que as distribuicoes de probabilidade ja tenham divergido de forma perceptivel. Para encontrar problemas, e util comparar os logits, especialmente perto de decisoes em que dois tokens recebem pontuacoes quase iguais.

A conclusao pratica e simples: comece com FP32 como referencia numerica, teste FP16 e BF16 no hardware de destino, aqueca o modelo e sincronize o dispositivo antes das medicoes. Em seguida, escolha o formato mais compacto que preserve a qualidade exigida e realmente ofereca maior velocidade em seu hardware. A precisao ideal nao e o menor numero possivel de bits, mas um equilibrio medido entre memoria, velocidade e confiabilidade.