Como avaliar modelos locais quantizados: qualidade e velocidade no seu hardware

Por que medir antes de escolher

A quantização reduz a memória necessária para carregar os pesos, mas, por si só, não permite prever quanto a qualidade mudará em uma tarefa específica. Tampouco basta saber quantos parâmetros um modelo tem para antecipar a velocidade no seu equipamento: o processador, a memória disponível, a configuração de inferência, o contexto e a carga do sistema também influenciam. Uma decisão útil exige medir as alternativas com entradas representativas do uso real.

Um estudo de 2025 comparou a precisão, a latência até o primeiro token e a velocidade de geração de seis modelos executados localmente com Ollama em um sistema acadêmico de recuperação de informações. Esse trabalho oferece uma abordagem empírica pertinente, mas não demonstra que uma quantização GGUF específica preserve a qualidade em outros modelos, tarefas ou equipamentos. O protocolo a seguir transforma esse princípio em um método próprio: primeiro, defina o que significa acertar e qual desempenho você precisa; depois, compare cada configuração com uma referência explícita.

1. Defina a tarefa e a linha de base

Comece descrevendo o que o modelo fará em produção: quem o utilizará, quais entradas receberá, que saída deverá produzir, quais erros são mais custosos e quanto tempo pode levar. Uma avaliação de extração de campos exige medir a correspondência entre valores; respostas baseadas em documentos precisam ser verificadas quanto à fidelidade às fontes; para geração de código, é necessário executar testes, não apenas julgar se a resposta parece plausível. Se você misturar tarefas diferentes em uma única pontuação, poderá ocultar falhas importantes.

Prepare um conjunto de testes representativo da distribuição esperada: inclua tipos de entrada frequentes, casos-limite, entradas ambíguas e exemplos difíceis. Para cada caso, inclua uma referência verificável — uma resposta correta, os campos esperados, testes automatizados ou uma rubrica de avaliação — e registre sua origem. Separe um conjunto de desenvolvimento, que pode ser usado para ajustar prompts ou parâmetros, de outro de avaliação, que não deve ser usado repetidamente para otimização. Assim, você reduz o risco de escolher uma configuração que só funciona bem nos exemplos já vistos.

2. Meça a qualidade de acordo com o trabalho real

Qualidade não é uma métrica única. Para respostas com uma solução conhecida, calcule a exatidão ou a taxa de acertos; para extração, avalie a correspondência exata por campo e por registro; para classificação, informe precisão e revocação quando falsos positivos e falsos negativos tiverem custos diferentes. Em tarefas de geração aberta, use uma rubrica explícita — por exemplo, factualidade, abrangência, clareza e utilidade — e guarde exemplos de erros para interpretar a pontuação. Uma avaliação automática ou feita por outro modelo pode ajudar a revisar muitos casos, mas não deve ser tratada como verdade de referência sem que sua validade para esse uso seja verificada.

Meça o formato como critério independente sempre que o sistema exigir JSON, uma estrutura fixa, uma chamada de ferramenta ou um limite de comprimento. Verifique se a saída pode ser analisada pelo validador real e se respeita os campos obrigatórios, os tipos, as enumerações e as restrições. Quando a amostragem não for determinística, registre também a consistência entre execuções: uma única resposta correta não demonstra que o sistema seja confiável. Em tarefas de risco, contabilize explicitamente os erros graves e estabeleça uma regra de recusa ou revisão humana antes de avaliar.

3. Meça velocidade, latência e memória

Registre pelo menos a latência até o primeiro token e a velocidade de geração em tokens por segundo. A primeira indica quanto uma pessoa espera antes de ver uma resposta; a segunda descreve a produção após o início. Acrescente o tempo total até a conclusão, pois uma resposta longa pode demorar mesmo quando a taxa de geração é alta. Indique qual ferramenta fornece cada medida e o que ela inclui: carregamento inicial do modelo, preparação do prompt, processamento da entrada ou apenas geração.

Anote o consumo de memória durante a inferência e o contexto testado. O tamanho do arquivo GGUF não equivale automaticamente à memória total necessária: o contexto, o cache de atenção, o runtime e o sistema operacional também podem influenciar. Compare o mesmo modelo e a mesma tarefa com limite de contexto, parâmetros de geração e hardware idênticos. Se uma configuração não couber na memória e recorrer à troca com o armazenamento ou a outro caminho de execução, registre isso: a comparação deixa de ser equivalente.

4. Execute uma comparação controlada

Para atribuir diferenças à configuração avaliada, mantenha constantes o conjunto de entradas, o modelo de prompt, o limite de tokens, a temperatura e os demais parâmetros relevantes. Anote o nome e a revisão do modelo, a origem do arquivo GGUF e sua quantização exata. Registre também as versões do Ollama ou do LM Studio, o sistema operacional, o processador, o acelerador, a memória e as opções de descarregamento de camadas. Especifique no protocolo se o modelo já estava carregado ou se o carregamento inicial também foi medido.

Faça primeiro uma execução de preparação, se precisar carregar e estabilizar o modelo, e não a misture às medições habituais, a menos que a inicialização faça parte do requisito operacional. Repita cada teste várias vezes e informe a mediana e a variabilidade, não apenas a execução mais favorável. Se o aplicativo gerar saídas estocásticas, fixe a semente quando a ferramenta permitir ou avalie várias amostras com a mesma política. Alterne a ordem das configurações se a carga térmica ou do sistema puder mudar durante a sessão. Repita os testes em condições próximas às de implantação, não apenas com o equipamento recém-iniciado.

5. Decida entre quantização e tamanho do modelo

Primeiro, avalie se cada opção atende aos requisitos de qualidade e desempenho definidos previamente. Descarte configurações que não satisfaçam um critério crítico, mesmo que se destaquem em outra métrica. Entre as opções aprovadas, compare o tempo total, a latência inicial, a memória e a estabilidade do formato. Se uma quantização mais agressiva do modelo maior mantiver a qualidade necessária e couber no hardware, ela pode ser preferível; se perder precisão em uma tarefa sensível, um modelo menor com quantização mais conservadora pode oferecer resultados melhores. Não há uma regra geral que resolva essa escolha sem medições.

Também é possível que a melhor opção seja um modelo diferente do previsto inicialmente ou que o fluxo encaminhe tarefas simples a um modelo rápido e reserve outro mais capaz para casos difíceis. O estudo acadêmico com Ollama mencionado anteriormente encontrou diferenças de velocidade e precisão entre modelos no próprio sistema RAG; seus resultados não garantem o mesmo comportamento em outra configuração. Para justificar uma decisão técnica, conserve os resultados por tipo de tarefa e explique quais compromissos a equipe aceita. Se duas alternativas tiverem resultados muito próximos, considere a incerteza das medições e repita o teste antes de chegar a uma conclusão.

6. Limites e boas práticas

Um conjunto pequeno pode deixar passar erros raros; um conjunto muito parecido com os exemplos de desenvolvimento pode favorecer a configuração ajustada a esses casos. Uma pontuação agregada também pode ocultar falhas por idioma, comprimento, tipo de documento ou classe minoritária. Analise os resultados desagregados e guarde exemplos de erros. Se uma diferença estiver dentro da variação entre execuções, não a descreva como uma melhoria conclusiva sem mais repetições ou evidências.

Os resultados de uma pesquisa publicada em um ambiente acadêmico de RAG são evidências daquele trabalho e daquela configuração, não uma avaliação de GGUF nem uma recomendação universal. Da mesma forma, números genéricos sobre uma suposta perda fixa de qualidade por nível de quantização não substituem um teste com o modelo e a tarefa específicos. Documente a origem dos arquivos, evite incluir dados pessoais em prompts de teste sem autorização e estabeleça revisão humana ou mecanismos de recusa quando um erro puder causar danos. Depois da implantação, revise periodicamente uma amostra de uso real e repita o protocolo se o modelo, o runtime, o hardware ou o padrão de entradas mudar.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.