Escolher uma quantização pelos seus resultados, não pelos seus bits.

Descrever a variante além do seu número de bits

Nomeie o método, sua implementação, sua versão e a revisão exata do artefato. Duas variantes em quatro bits podem empregar representações, grupos, metadados e kernels diferentes. Separe o formato de armazenamento dos pesos do formato das operações de cálculo. Anote também os módulos mantidos em outra precisão e qualquer transferência para a CPU.

No bitsandbytes, camadas lineares quantizadas substituem certas camadas comuns; os outros módulos seguem seu dtype configurado. Esse comportamento, portanto, não descreve por si só o pico do processo. Leia a configuração efetiva após o carregamento e depois verifique se a variante realmente realiza o processamento esperado em vez de um fallback de software diferente.

Fontes técnicas: Hugging Face Transformers 5.17 — camadas quantizadas e outros dtypes

Separar calibração e avaliação

Alguns métodos usam exemplos para preparar a quantização. O procedimento GPTQ documentado no Transformers exige, entre outras coisas, um conjunto de calibração e um tokenizer. Esse conjunto participa da fabricação do artefato: ele não constitui uma prova independente de qualidade. Outros métodos seguem um caminho diferente; não presuma que um mesmo protocolo de calibração se aplique a todos os formatos.

Reserve os exemplos de calibração nos dados autorizados para preparar o modelo e depois registre identificadores, procedência, comprimentos e transformação aplicada. Guarde a validação para escolher os ajustes e o teste final para a confirmação. Se você escolher vários conjuntos de calibração após comparar suas pontuações, essa busca faz parte do desenvolvimento e deve ser registrada no balanço.

Fontes técnicas: Hugging Face Transformers 5.17 — calibração de uma quantização GPTQ · Construir partições segundo seu papel

Calcular um limite de peso sem vendê-lo como um pico

Tomemos um modelo fictício de três bilhões de parâmetros, todos armazenados no mesmo número de bits. O volume bruto é calculado por parâmetros × bits / 8. A 16 bits, obtemos 6 bilhões de bytes; a 8 bits, 3 bilhões; a 4 bits, 1,5 bilhão. Esses números são uma aritmética ilustrativa, não os tamanhos observados de um artefato nem as necessidades de um modelo em execução.

A diferença bruta entre 16 e 4 bits é de 4,5 GB, ou seja, aproximadamente 4,191 GiB. Ela exclui escalas, metadados, módulos não quantizados, cache e temporários. Ela permite formular uma hipótese de memória a verificar, sem prever uma divisão por quatro do pico. O dossiê de memória explica como separar as fases e interpretar os contadores.

Fontes técnicas: NIST — prefixos binários e decimais · IteraGPU — estimativas e picos de memória

Mudar os pesos antes de mudar o cache

Comece por uma referência cujo comportamento você conhece. Depois compare as variantes de pesos com o mesmo cache, os mesmos comprimentos, o mesmo batch ou a mesma concorrência. Se você também mudar esses parâmetros, estará comparando configurações completas: informe isso e não atribua toda a diferença à quantização dos pesos.

O cache KV pode ele mesmo ser quantizado quando o modelo e o motor permitem. Trata-se de uma escolha distinta. A documentação do Transformers indica, em particular, que um cache quantizado pode penalizar a latência em contextos curtos quando ainda há memória suficiente. Teste essa segunda mudança em uma série separada; mais memória economizada não garante um melhor tempo de resposta.

Fontes técnicas: Hugging Face Transformers 5.17 — cache KV quantizado e compromisso de latência

Exemplo de regra de qualidade: uma pequena queda pode continuar inadmissível

Eis uma ilustração de decisão, sem execução de modelo. Um projeto avalia 200 documentos e define antes dos testes uma perda máxima de um ponto percentual em relação à referência. Ele também exige pelo menos 90% de acerto em 20 documentos críticos incluídos nesses 200. Um documento só é aceito se todos os seus campos obrigatórios estiverem corretos.

Os valores fictícios abaixo tornam A admissível nessas duas regras: 94% em vez de 95%, e 18/20 no grupo crítico. B falha nas duas. Ainda não é possível declarar A vencedora: nem pico de memória nem duração são informados. Além disso, os totais não mostram quais documentos mudaram; examine os erros pareados para detectar novas regressões importantes.

Fontes técnicas: Examinar os erros em vez do total isolado

Executar uma comparação cujas diferenças se explicam

Prepare primeiro o contrato de comparação, depois os arquivos de resultados. O protocolo a seguir deve ser realizado na sua carga; os números anteriores não o substituem. Se uma variante não carregar ou não possuir os operadores necessários, registre essa falha como uma informação de compatibilidade.

• Fixe corpus, referências, modelo, tokenizer, prompt e regras de saída; mantenha os casos longos e difíceis identificáveis.
• Registre calibração, artefato exportado e configuração efetiva. Verifique os dispositivos utilizados e eventuais transferências CPU/GPU.
• Separe fabricação, carregamento, aquecimento e processamento estabilizado. Use os mesmos limites de medição e conserve as repetições brutas.
• Registre o pico por dispositivo e por fase; mantenha allocated e reserved separados. Não some esses contadores e não subtraia seus máximos independentes.
• Avalie o formato, o conteúdo e os subgrupos acordados, depois relacione os erros por identificador.
• Recarregue o artefato escolhido em um novo processo e refaça um controle definido. Um resultado obtido antes da exportação não valida automaticamente o recarregamento.

Fontes técnicas: Medir corretamente a memória · Definir as repetições e a cronometragem

Ligar o compromisso ao custo assumido

Uma economia de memória pode ampliar as configurações possíveis, permitir mais concorrência ou simplesmente deixar uma margem. Ela não reduz automaticamente a despesa. Se o período, os lotes reservados e os entregáveis aceitos permanecerem idênticos, o custo do pacote permanece idêntico, mesmo que uma passagem seja mais rápida.

Inclua no cronograma a eventual calibração, a quantização, a avaliação, as tentativas rejeitadas e o recarregamento. Compare em seguida os pacotes completos de 3, 7 ou 30 dias entre as opções que atendem aos seus critérios. A razão por corpus útil só se calcula com corpus realmente concluídos e aceitos; as repetições de cronometragem não criam novos entregáveis.

Se uma única locação serve para comparar várias variantes, seu valor é uma despesa comum de campanha. Não debite mentalmente o pacote inteiro a cada variante para depois somar esses valores como despesas reais distintas. Para atribuir uma parcela analítica, anuncie uma convenção; ela não altera o total assumido.

Fontes técnicas: IteraGPU — pacote inteiro e custo de um experimento

Concluir com uma configuração e seus limites

A decisão final nomeia o artefato, o ambiente, a carga coberta, o critério de qualidade atingido e a restrição melhorada. Se as variantes forem próximas, conserve essa incerteza e priorize uma escolha que você saiba recarregar e explicar. O número de bits não é, por si só, uma ordem de preferência.

Uma conclusão sobre um corpus curto não se estende automaticamente a contextos longos, a outro idioma ou a mais requisições simultâneas. Uma quantização escolhida para a inferência também não define os parâmetros treináveis de um fine-tuning. Mantenha essas questões separadas e confirme a variante escolhida no teste mantido à parte.

Perguntas práticas