O FP8 muda as respostas de um modelo? Uma troca em 120
com Anagha Langhe · LLM auto-hospedado em uma NVIDIA L4
Em meio minuto
Anagha Langhe roda ela mesma um modelo de linguagem, numa única placa NVIDIA L4, e queria saber se passar para FP8 custa precisão. Em 120 perguntas, as duas versões fizeram 72 e 71 pontos. Isso sozinho diz pouco, então contamos as trocas: uma pergunta mudou, e a favor do bf16. 49 respostas foram idênticas palavra por palavra e, quando as duas versões erraram, deram a mesma resposta errada 42 vezes em 48. Anagha rodou um script aberto de comparação nas duas execuções dela, chegou exatamente aos mesmos números e tirou a própria conclusão: os erros vêm da recuperação, não da quantização.
A pergunta
Rodar um modelo em FP8 em vez de bf16 reduz à metade, mais ou menos, a memória de que ele precisa, e é por isso que se faz isso numa única GPU. A preocupação é simples: o formato menor piora as respostas sem que ninguém perceba?
Anagha mediu diretamente. Fez as mesmas 120 perguntas às duas versões e escreveu sobre isso no LinkedIn: 72 acertos em bf16, 71 em FP8, teste exato de McNemar com p = 1,0. No mesmo post ela compartilhou outro número do ambiente dela: a taxa de acerto do cache de prefixo subindo de 12% para 26%.
72 contra 71 parece "nenhuma diferença". Com 120 perguntas, porém, um teste assim só consegue descartar uma queda grande. Uma perda de três ou quatro pontos provavelmente ainda não apareceria como significativa. Então a pergunta interessante não é o valor-p, e sim o que de fato aconteceu com cada pergunta.
Quem fez o quê
- Anagha montou o ambiente, rodou as duas versões nas mesmas 120 perguntas, corrigiu as respostas e, depois, rodou a comparação nos próprios arquivos.
- Nós (Vadym Chernets) perguntamos a ela quantas perguntas mudaram em cada direção, depois acrescentamos um pequeno modo
comparea um script aberto que mantemos para verificar a concordância entre modelos, e calculamos o intervalo e os números de planejamento a partir do resumo dela. - A execução desse script com todos os dados dela trouxe os mesmos números, mais um que não dava para ver no resumo: com que frequência as duas versões erraram do mesmo jeito.
O que mostram os números
| Medida | Valor |
|---|---|
| Acurácia, bf16 | 72 / 120 |
| Acurácia, FP8 | 71 / 120 |
| Trocas: só bf16 certo / só FP8 certo | 1 / 0 |
| Teste exato de McNemar | p = 1,0 |
| Diferença bf16 − FP8 | +0,8 ponto, intervalo de 95% de cerca de −2,3 a +4,6 |
| Respostas idênticas, palavra por palavra | 49 de 120 |
| Ambas erradas, com a mesma resposta errada | 42 de 48 |
Como ler isso. Uma troca é totalmente compatível com o FP8 não custar nada. Não é prova de que não custa nada: uma queda de um par de pontos ainda cabe dentro do intervalo. Com menos de seis trocas, um teste exato de McNemar não chega a p < 0,05 para nenhum lado, então aqui os números úteis são as próprias trocas e o intervalo. Para enxergar uma queda de um ponto, seriam necessárias umas 800 perguntas, mesmo que todas as trocas fossem na mesma direção.
O 42 de 48 é a parte que nos surpreendeu. Se a versão FP8 fosse simplesmente mais ruidosa, os erros dela se espalhariam. Em vez disso, as duas versões tropeçam nas mesmas perguntas e caem na mesma resposta errada. Nas palavras de Anagha, isso "combina com a minha leitura de que os erros vêm da recuperação, não da quantização": quando o contexto recuperado é ruim, as duas versões leem o mesmo contexto ruim e dizem a mesma coisa.
Teste nas suas próprias execuções
Se você tem duas execuções das mesmas perguntas em JSONL (um id da pergunta, a resposta e um campo correct ou um arquivo de gabarito), a comparação é um comando só. Ela faz parte do repositório aberto memory-agreement-check, licença MIT, sem dependências:
git clone https://github.com/vadimchernets/memory-agreement-check
cd memory-agreement-check
python -m memcheck compare bf16.jsonl fp8.jsonl --label-a bf16 --label-b FP8Uma linha por pergunta fica assim:
{"qid": "q001", "answer": "Paris", "correct": true, "category": "factual"}Ele imprime a tabela 2×2, o teste exato de McNemar, o intervalo da diferença de acurácia, quantas respostas são idênticas, com que frequência as duas execuções concordam e erram juntas, e uma divisão por categoria, se as suas perguntas tiverem uma. --md report.md salva o relatório.
O que isso mostra e o que não mostra
- 120 perguntas bastam para ver que o FP8 não estragou este modelo. Não bastam para prometer que não há uma queda de um ou dois pontos.
- O teste trata as perguntas como independentes. Se muitas vêm de um mesmo documento ou de um mesmo modelo de texto, a amostra real é menor que 120.
- "Os erros vêm da recuperação" é a leitura que Anagha faz do próprio sistema. O 42 de 48 a apoia; para checar diretamente, seria preciso responder às mesmas perguntas uma vez com um bom contexto e outra com um contexto ruim.
O que vem a seguir
Anagha concordou em deixar a verificação dela de FP8 contra bf16 entrar no repositório como exemplo prático, com crédito para ela, para que a próxima pessoa que comparar duas versões tenha um caso real para começar, e não só um sintético.
Cronologia
- Anagha publica no LinkedIn a verificação de FP8: 71 contra 72 de 120, McNemar p = 1,0. Comentamos que a contagem de trocas diz mais que o valor-p. Ela responde, e perguntamos quantas perguntas mudaram em cada direção.
-
A resposta dela: só uma, bf16 certo e FP8 errado, nenhuma no sentido contrário, e 49 das 120 respostas idênticas palavra por palavra. Durante a noite o script aberto ganha o modo
compare, e enviamos a ela o intervalo e os números de planejamento calculados a partir do resumo. - Anagha roda nas duas execuções dela: os números batem exatamente e, quando as duas versões erraram, deram a mesma resposta errada em 42 de 48. Ela aceita o exemplo prático.