Como escolher, quantizar e avaliar um modelo de linguagem local

1. Defina o problema antes de escolher o modelo

Um modelo local executa a inferência em um hardware que você controla, em vez de enviar cada solicitação para um serviço remoto. Isso pode reduzir a exposição dos dados a terceiros e permitir a operação sem conexão depois que o modelo e suas dependências forem baixados. Mas isso, por si só, não garante privacidade: uma interface, um complemento, um registro de atividade ou uma ferramenta conectada ainda pode transmitir informações.

Comece descrevendo a tarefa, os dados permitidos, a qualidade mínima e o volume previsto. Um modelo pequeno pode ser suficiente para classificar mensagens ou extrair campos; já um assistente que usa ferramentas, interpreta documentos complexos ou mantém conversas longas exige testes mais rigorosos. O número de parâmetros, por si só, não prevê o resultado no seu caso.

2. Selecione o modelo, a licença e o formato

Compare modelos candidatos que possam ser executados no seu ambiente e cuja licença permita o uso pretendido. Consulte a ficha oficial do modelo: arquitetura, tamanho, limites de contexto, idiomas, recursos multimodais e condições de redistribuição. Confirme também se o runtime escolhido oferece suporte à arquitetura e à variante específica dos pesos. Muitos parâmetros ou uma comunidade ativa não demonstram, por si sós, que um modelo seja adequado para produção.

GGUF é um formato comum em fluxos de trabalho baseados em llama.cpp e ferramentas compatíveis, mas não é um requisito universal para executar inferência local. Outras pilhas usam formatos e motores diferentes. Para cada candidato, registre o identificador exato, a revisão dos pesos, o formato, a quantização, o runtime e a configuração. Assim, você poderá reproduzir um teste e detectar mudanças após uma atualização.

3. Quantize somente depois de estabelecer uma referência

A quantização reduz a precisão numérica dos pesos ou de outros valores do modelo para economizar memória e, dependendo do hardware e do runtime, pode alterar a velocidade de inferência. A economia pode permitir carregar modelos que não caberiam em uma representação de maior precisão, mas a qualidade pode cair. O efeito depende do modelo, do método, da tarefa e do backend: não se deve prometer uma perda fixa nem presumir que uma indicação de quatro ou cinco bits, por si só, preveja o resultado.

Q4_0, Q5_1 e Q4_K_M não são nomes intercambiáveis. Essas variantes pertencem a formatos e esquemas distintos; antes de baixar um modelo, confira a descrição da quantização e o tamanho real do arquivo. LoRA, por sua vez, é uma técnica de adaptação com parâmetros adicionais, não um nível de quantização. Ela pode ser combinada com alguns fluxos de quantização, mas não é uma alternativa equivalente a Q4 ou Q5.

4. Dimensione a memória e o hardware com margem

Uma estimativa inicial do espaço ocupado pelos pesos pode ser feita multiplicando o número de parâmetros pelo número de bytes usados para representá-los. Por exemplo, um modelo com sete bilhões de parâmetros em FP16 exige cerca de 14 bilhões de bytes apenas para os pesos, antes de contabilizar outros consumos. Em uma quantização de quatro bits, o cálculo ideal dos pesos seria menor, mas o tamanho do arquivo e a memória ocupada não correspondem exatamente a esse mínimo: há metadados, escalas, tensores que mantêm outra precisão e requisitos do runtime.

A VRAM é importante quando as camadas são descarregadas para uma GPU; a RAM do sistema permite executar pela CPU ou acomodar partes que não cabem na GPU. O contexto da conversa, o cache KV, as ativações e, em serviços concorrentes, as solicitações simultâneas também consomem memória. Por isso, um arquivo que parece caber na VRAM pode falhar na inicialização ou ficar sem memória com contextos longos. O tamanho do arquivo ajuda a filtrar opções, mas não basta para concluir o dimensionamento.

5. Configure a privacidade e a operação sem rede

A inferência local pode manter os dados no dispositivo, mas “local” não significa automaticamente “isolado”. Downloads de modelos, atualizações, telemetria, interfaces web, proxies, extensões e registros podem gerar comunicações. Identifique cada componente e determine de quais destinos de rede ele precisa. Se o sistema tiver de funcionar sem internet, baixe e verifique previamente os pesos, as dependências e as licenças; depois, teste o bloqueio de saída no ambiente real.

Use segmentação de rede e regras de firewall com privilégios mínimos. Restrinja quem pode acessar o endpoint de inferência, evite expô-lo diretamente a redes públicas e proteja os registros. Trate prompts, respostas e documentos como dados sensíveis quando contiverem informações internas. Um teste de desconexão deve confirmar que a aplicação funciona sem chamadas externas, e não apenas que o modelo já foi baixado.

6. Valide qualidade, latência e desempenho

Avalie cada configuração com um conjunto de testes representativo e estável, separado dos exemplos usados para ajustar prompts. Para avaliar qualidade, escolha métricas adequadas à tarefa: exatidão ou F1 para classificação, taxa de campos corretos para extração e revisão humana com critérios comuns para respostas abertas. BLEU e ROUGE podem ser úteis em alguns problemas de comparação textual, mas não substituem uma avaliação de factualidade, cumprimento de instruções ou risco; alta semelhança lexical não prova que a resposta esteja correta.

Meça a latência de carregamento, o tempo até o primeiro token, o tempo total e os tokens por segundo. Diferencie uma execução a frio de outra com o modelo já carregado. Registre hardware, driver, runtime, versão do modelo, quantização, contexto, tamanho do lote e concorrência. A inferência local elimina parte da latência de rede, mas não garante menor latência total: isso depende do equipamento, do modelo e da carga.

7. Versione e mantenha o serviço

Fixe as versões dos pesos, da quantização, do runtime, das bibliotecas e da configuração. Quando disponíveis, mantenha somas de verificação dos artefatos e armazene os modelos em locais controlados. Antes de atualizar, execute novamente os testes de qualidade, desempenho, compatibilidade e isolamento. Uma atualização pode mudar respostas, uso de memória ou comportamento de ferramentas, mesmo que o nome comercial do modelo continue parecido.

Monitore erros, saturação de memória, latência e disponibilidade. Defina um procedimento de reversão para uma versão testada e uma política para retirar artefatos vulneráveis ou sem licença adequada. Se o sistema usar ferramentas, aplique permissões mínimas e valide as chamadas antes de executá-las; um modelo local também pode produzir instruções incorretas ou conteúdo manipulado.

8. Checklist e critérios práticos de decisão

A escolha certa é a configuração mais simples e enxuta que atende aos requisitos medidos, não necessariamente o maior modelo nem a quantização mais agressiva. Se uma opção não alcançar a qualidade mínima, mude o modelo ou a configuração e repita a avaliação; se exceder a memória ou a latência, examine primeiro o contexto, a concorrência e a distribuição entre CPU e GPU.

As fontes disponíveis sustentam os princípios gerais da quantização e documentam opções de uma plataforma específica, mas não estabelecem uma perda universal de qualidade ao passar de FP16 para uma quantização determinada, nem requisitos universais de VRAM para modelos 7B ou 13B. Esses valores precisam ser verificados para o artefato, o runtime, a tarefa e o hardware específicos.

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.