Quantizar um modelo local sem adivinhar: como escolher 4, 6 ou 8 bits conforme a VRAM, o contexto e a perda aceitável

O facto de os pesos caberem na VRAM não significa que o sistema funcione

O erro mais comum ao escolher um modelo local é comparar o tamanho do ficheiro quantizado com a memória da GPU e considerar a decisão resolvida. Esse cálculo cobre apenas, de forma aproximada, os pesos. Durante a inferência, também entram em jogo a cache de chaves e valores — cache KV —, as ativações e os buffers temporários, o espaço reservado pelo runtime, o contexto de cada pedido e, num serviço, os pedidos simultâneos. Uma configuração pode carregar o modelo, responder a uma pergunta curta e ainda assim falhar ao receber um documento longo ou vários pedidos em simultâneo.

A consequência prática é importante: “cabe” deve significar que a configuração conclui a carga máxima prevista com uma margem medida, e não apenas que inicia uma sessão isolada. Se essa margem desaparecer, o resultado pode ser um erro de memória, uma redução automática do contexto, a transferência de parte do trabalho para a RAM do sistema ou uma latência muito irregular. O comportamento efetivo depende do runtime e da sua configuração; não deve ser presumido sem verificação.

A quantização é uma de várias alavancas. Reduzir os bits dos pesos normalmente liberta memória e pode permitir usar um modelo maior, mas não elimina, por si só, o custo crescente da cache KV quando se aumenta o contexto ou a concorrência. Também pode alterar a qualidade, o desempenho ou os caminhos de execução disponíveis, conforme o formato e o backend. Por isso, não existe uma equivalência universal entre “4 bits”, “6 bits” e “8 bits”.

Este guia parte de uma carga de trabalho concreta: qual o comprimento de entrada que tem de ser aceite, quantos tokens serão gerados, quantos pedidos coexistirão, que latência é útil e que erros seriam inaceitáveis. Se ainda estiver a escolher a família de modelos, convém começar pelo guia de modelos locais e, se a dúvida for entre modelos base diferentes, recorrer à secção de comparação antes de atribuir à quantização diferenças que na verdade provêm do modelo.

As parcelas de memória que é preciso separar

Uma estimativa útil começa por decompor a memória em parcelas que possam ser observadas separadamente. A primeira são os pesos do modelo. O seu tamanho depende do número de parâmetros, da representação quantizada e de metadados próprios do formato, como escalas, blocos ou estruturas auxiliares. Por isso, dividir simplesmente os parâmetros por oito, seis ou quatro dá uma orientação, mas não substitui o tamanho real indicado pelo formato e pelo runtime.

A segunda parcela é a cache KV. Num descodificador autorregressivo, o sistema conserva as chaves e os valores dos tokens já processados para não ter de os recalcular em cada token gerado. A documentação do Transformers descreve tensores de cache com dimensões de lote, cabeças, comprimento de sequência e dimensão de cabeça. Existem chaves e valores, e esse armazenamento repete-se por camada. Mantendo a mesma arquitetura, aumentar o contexto, o lote ou a concorrência aumenta a memória necessária.

A terceira parcela reúne ativações e buffers temporários. O seu tamanho depende do backend, da precisão de cálculo, dos kernels, do prefill de entradas longas, do comprimento de geração e da forma como os pedidos são agrupados. Não convém substituí-la por uma constante universal. O quarto componente é a memória não atribuída diretamente ao modelo, como contexto de execução, bibliotecas, alocadores e fragmentação. O quinto é uma margem operacional explícita: memória deliberadamente não alocada para tolerar picos, diferenças entre medições e carga real.

Num servidor, lote e concorrência exigem uma precisão adicional. Um lote pode ser o número de sequências processadas em conjunto num passo, enquanto a concorrência é o número de pedidos ativos. Conforme o escalonador, estes valores podem estar relacionados, mas não são intercambiáveis. Para estimar a cache, deve contar-se a soma dos tokens ativos das sequências que coexistem, e não apenas o comprimento máximo de um único pedido.

Estimar pesos e cache KV antes de descarregar ou implementar

A estimativa não pretende prever cada byte: pretende descartar configurações inviáveis e definir que testes merecem ser executados. Para os pesos, use o tamanho indicado para o artefacto concreto que pretende carregar, e não um valor genérico para a família do modelo. Se só conhecer o número de parâmetros, trate o resultado como um mínimo teórico incompleto. Os formatos de quantização armazenam informação adicional e alguns runtimes convertem ou duplicam estruturas durante o carregamento.

Para uma arquitetura do tipo Llama, uma aproximação conceptual da cache KV por sequência é: camadas multiplicadas por dois, multiplicadas por cabeças de chave-valor, multiplicadas pelo comprimento da sequência, multiplicadas pela dimensão de cabeça e pelos bytes de cada elemento de cache. O fator dois representa K e V. Para várias sequências simultâneas, somam-se os tokens residentes de cada uma. Se o runtime usar uma cache estática, pode reservar capacidade até um máximo mesmo quando a utilização instantânea é inferior; se usar uma cache dinâmica, a utilização pode crescer com o pedido. Ambas as estratégias exigem medição.

É crucial usar o número de cabeças de chave-valor, e não necessariamente o número total de cabeças de atenção. Em atenção multi-query ou grouped-query, várias cabeças de consulta partilham projeções KV. Isto pode reduzir substancialmente a cache face a uma arquitetura com uma projeção KV por cabeça de atenção. A configuração exata do modelo deve indicar camadas, cabeças KV e dimensão de cabeça; estes dados não devem ser deduzidos a partir de um nome comercial.

Os bytes por elemento da cache também devem ser verificados. Quantizar os pesos não implica automaticamente quantizar a cache KV. Alguns ambientes permitem escolher um tipo de dados de cache quantizado, outros usam por predefinição uma precisão diferente e outros aplicam offloading. Estas opções alteram o orçamento de memória e podem afetar o desempenho ou o comportamento numérico. Registe a configuração real do runtime, não apenas os bits presentes no nome do ficheiro.

O que realmente muda ao passar de 8 para 6 ou 4 bits

Como regra geral, reduzir a precisão dos pesos reduz a sua ocupação de memória em comparação com uma representação de maior precisão do mesmo modelo. Isto pode viabilizar uma GPU menor, deixar mais orçamento para contexto ou permitir mais pedidos concorrentes. Contudo, a redução observada não tem de seguir uma proporção exata de oito para seis para quatro. O empacotamento, as escalas por grupo, o formato do ficheiro, as conversões internas e os buffers do backend alteram o resultado.

A qualidade também não depende apenas do número de bits. Importam o algoritmo de quantização, o tamanho do grupo, os tensores que recebem tratamento especial, o modelo base e a tarefa. Uma quantização de 4 bits de um método pode preservar bem uma tarefa, enquanto outra de 6 bits de outro método pode não o fazer; o inverso também é possível. Por esta razão, os bits servem para formular hipóteses de teste, não para certificar precisão.

A velocidade exige a mesma cautela. Menos memória pode reduzir transferências e melhorar a viabilidade num dispositivo limitado, mas um formato pode não ter kernels eficientes num backend específico ou exigir conversões. Aumentar o contexto pode deslocar o gargalo para a gestão de cache e para o prefill. O desempenho deve ser medido com duas métricas separadas: tempo até ao primeiro token para entradas representativas e taxa de geração posterior. Um único valor de tokens por segundo esconde diferenças relevantes.

Como ponto de partida, teste 8 bits quando a qualidade for crítica e o orçamento o permitir; 6 bits quando for necessário recuperar uma parcela significativa de memória sem saltar diretamente para a opção mais agressiva; e 4 bits quando a VRAM for a restrição dominante ou quando os testes demonstrarem que não existe uma perda inaceitável. Estas são prioridades de teste, não recomendações universais.

Procedimento de decisão: da restrição ao candidato viável

Comece por definir o contrato operacional. Escreva o comprimento máximo de entrada que realmente tem de suportar, uma reserva de tokens de saída, o número máximo de pedidos ativos, o objetivo de latência e as tarefas críticas. Diferencie um máximo excecional de um objetivo habitual. Se uma aplicação processa documentos longos, medir apenas mensagens curtas não representa o seu risco de memória nem a sua qualidade útil.

Depois, recolha os parâmetros da arquitetura e do runtime. Para o modelo, registe camadas, cabeças KV, dimensão de cabeça e o formato dos pesos. Para o runtime, registe o tipo de dados da cache, se reserva cache estática ou dinâmica, se permite offloading, o limite de memória da GPU e quaisquer definições de lote ou tokens em voo. Em ferramentas de serviço, o orçamento de cache pode ser configurado explicitamente ou derivado de uma fração da memória disponível; ambos os casos devem constar da experiência.

Calcule um intervalo, e não um valor único: pesos observados ou estimados, cache KV para a carga pretendida, uma reserva para temporários e uma margem. Se o total ultrapassar a VRAM disponível antes de aplicar a margem, descarte a combinação. Se couber por muito pouco, classifique-a como candidata de risco e teste-a sob carga máxima. Se couber com margem, não a considere aprovada até validar qualidade e latência.

Escolha pelo menos três candidatos que respondam a hipóteses diferentes: o modelo pretendido a 8 bits, a 6 bits e a 4 bits; ou, quando um candidato não fizer sentido, um modelo menor com uma precisão superior. Mantenha constantes o modelo base, a revisão, o prompt, o contexto máximo, o limite de saída, a semente quando compatível, os parâmetros de descodificação, o hardware e a versão do runtime. Alterar várias variáveis ao mesmo tempo impede atribuir uma diferença à quantização.

Teste mínimo para detetar uma perda que importa

Um teste útil não tem de ser enorme, mas deve ser representativo. Construa um conjunto pequeno de casos que inclua o trabalho que motiva a implementação: extração estruturada, classificação, síntese de documentos, assistência de código ou respostas com restrições, conforme se aplique. Inclua entradas de comprimento habitual e algumas próximas do limite operacional. As entradas longas são necessárias porque podem revelar tanto erros de memória como perdas no seguimento de instruções ou na recuperação de detalhes.

Para cada caso, defina o que será validado antes de executar o modelo. Algumas tarefas permitem comparação exata: um esquema JSON válido, etiquetas permitidas, campos obrigatórios, uma consulta que deve conter valores concretos ou testes automatizados para código. Outras exigem revisão humana com uma grelha: fidelidade ao documento, cobertura, ausência de invenções, cumprimento do formato e utilidade. Não confunda fluência com correção.

Estabeleça um limiar explícito. Por exemplo, uma configuração pode ser descartada se falhar mais casos críticos do que o candidato de referência, se piorar a validade estrutural acima de um limite decidido pela equipa ou se produzir novos erros em dados sensíveis. O limiar pertence ao risco da aplicação; não pode ser inferido a partir dos bits. Numa tarefa de rascunho criativo pode aceitar-se mais variação do que na extração de dados para um processo posterior.

Repita os testes. Com descodificação estocástica, várias execuções ajudam a separar a variação de geração da degradação sistemática. Com descodificação determinística, as repetições continuam a ser úteis para observar estabilidade de desempenho e erros de memória. Apresente os resultados por tipo de tarefa e comprimento de entrada, e não apenas como uma média global. Uma quantização que parece equivalente na média pode concentrar as suas falhas nos documentos mais longos ou na tarefa de maior impacto.

Três perfis operacionais e as suas prioridades

Num portátil com GPU limitada, a prioridade costuma ser evitar uma configuração que dependa continuamente da RAM do sistema ou de offloading para proporcionar uma experiência interativa. Comece com um contexto realista, um único pedido e um modelo ou quantização que deixe margem. Se 4 bits for a única forma de carregar o modelo, compare também um modelo menor a 6 ou 8 bits. O segundo pode ser mais estável e mais útil na tarefa concreta, mesmo tendo menos parâmetros.

Numa estação de trabalho com uma GPU, existe mais margem para escolher entre qualidade, contexto e velocidade, mas o limite continua a ser partilhado por pesos, cache e temporários. É um ambiente adequado para comparar 4, 6 e 8 bits com o mesmo corpus e decidir se deve reservar VRAM para contextos longos. Se prevê alternar entre sessões breves e análise documental, meça ambos os perfis: o resultado de uma conversa curta não dimensiona o segundo.

Num servidor com concorrência moderada, a unidade de planeamento deixa de ser o ficheiro do modelo e passa a ser a capacidade total de tokens ativos. O gestor de cache e o escalonador de pedidos fazem parte da decisão. Uma configuração que funciona numa única sessão pode esgotar a memória quando coincidem prefills longos. Defina limites de admissão, comprimento máximo, reserva de saída e concorrência; depois teste rajadas e combinações de pedidos curtos e longos. As métricas de fila e os percentis de latência são mais informativos do que o melhor resultado isolado.

Em qualquer um dos três perfis, o offloading é uma opção que deve ser declarada, não uma solução invisível. Pode ampliar a capacidade aparente transferindo parte dos dados, mas também pode alterar a latência e depender da ligação entre CPU e GPU. Decida com medições se essa compensação é aceitável para o caso de uso.

Sinais para descartar uma configuração e checklist de adoção

Descarte uma configuração quando produzir erros de memória intermitentes, mesmo que uma demonstração breve funcione. A intermitência costuma indicar que a memória disponível depende da forma dos pedidos, do pico de prefill, da fragmentação ou de outras cargas do processo. Também é motivo de descarte o runtime reduzir silenciosamente o contexto efetivo, o sistema só ser estável com uma carga inferior à prevista ou a margem observada desaparecer em testes repetidos.

A degradação da qualidade deve ser analisada por padrão. Erros concentrados em extração, cálculos, campos obrigatórios, seguimento de instruções ou documentos extensos pesam mais do que alterações estilísticas, caso essas tarefas sejam críticas. Uma saída aparentemente razoável, mas com valores inventados, não deve ser aprovada apenas por uma pontuação média. Verifique também a validade do formato quando a saída alimenta software posterior.

Antes de fixar uma opção predefinida, confirme a privacidade e a operação. Executar inferência no equipamento não garante, por si só, que nenhum dado saia dele: descarregamentos de modelos, telemetria, registo de prompts, atualização de dependências e ferramentas de observabilidade são aspetos separados. Que dados são conservados e que comunicações cada componente realiza deve ser verificado na configuração e no ambiente de rede escolhido.

O resultado final não tem de ser “a maior quantização possível”. Pode ser 6 bits para um perfil interativo, 4 bits para um perfil de análise com grande contexto ou 8 bits para uma tarefa em que a perda detetada não seja aceitável. Mantenha as alternativas juntamente com o respetivo registo de testes. Se mudar o runtime, o hardware, o formato dos pesos ou a carga de trabalho, volte a medir: a conclusão anterior deixa de ser uma garantia.

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.