Variantes, formatos e quantização de LLMs com pesos abertos

Viacheslav Dubrov

2025-05-11 · Atualizado 2026-08-16 · 11 min · Engenharia de modelos

Tradução automática Este artigo foi traduzido automaticamente a partir da versão original em inglês.

Nomes como Model-32B-A3B-Instruct-AWQ parecem densos porque combinam várias decisões independentes: família e dimensão, arquitetura, função no treino e quantização. Um repositório pode empacotar esses pesos como Safetensors fragmentados, enquanto uma conversão comunitária do mesmo checkpoint pode surgir como Q4_K_M.gguf.

Estas etiquetas não pertencem todas à mesma categoria: GPTQ e AWQ são métodos de quantização, GGUF é um contentor e um ecossistema de runtime, e MoE é uma arquitetura. Ler cada camada separadamente facilita a escolha do download.

Ao escolher entre um download Q4_K_M.gguf para inferência local e um repositório AWQ em Safetensors para serving em GPU, comece pelo comportamento e pela arquitetura do checkpoint de que a sua tarefa necessita. Depois, confirme que a sua representação numérica, organização do pacote e runtime de destino são compatíveis com o hardware, a memória e as restrições de serving disponíveis.

Em resumo. Selecione um checkpoint com base na qualidade na tarefa, licença, idioma, contexto e comportamento da interface. Depois, selecione um runtime compatível com a sua arquitetura. Só então escolha uma representação dos pesos e uma quantização adequadas à memória e latência medidas. GPTQ e AWQ são métodos de quantização, Safetensors e GGUF são contentores, e MoE é uma arquitetura. A etiqueta MoE não garante que todos os pesos caibam na memória dos «parâmetros activos».

Para uma escolha compacta de deployment, consulte Formatos de quantização de LLM.

Leia um artefacto de modelo em seis camadas

A proveniência do treino anota estas camadas, em vez de acrescentar outra camada do artefacto. Por exemplo, distilled descreve como o comportamento foi transferido, não a função do checkpoint. Um checkpoint pode ser destilado, ajustado para seguir instruções, ajustado para raciocínio e MoE ao mesmo tempo.

A etiqueta «open-source» requer uma verificação própria. Se um modelo apenas publicar pesos descarregáveis, não assuma que a sua licença cumpre uma definição de open-source ou permite o seu caso de uso. Leia o model card e a licença antes de comparar arquitecturas ou benchmarks.

As etiquetas relativas à função no treino descrevem comportamento, não garantias de capacidade

Base

Um checkpoint base é treinado principalmente para prever o token seguinte. É útil para continued pretraining, investigação controlada ou adaptação quando pretende controlar o comportamento de seguimento de instruções. Pode completar um prompt em vez de responder-lhe.

Não assuma que todo o fine-tuning deve começar num modelo base. Um checkpoint instruct pode ser uma melhor inicialização quando o seu comportamento existente está alinhado com o objectivo. Confirme através da sua avaliação que o comportamento existente não entra em conflito com o novo objectivo.

Instruct ou chat

Estes checkpoints recebem post-training destinado a melhorar o seguimento de instruções e a conversação. A receita exacta pode incluir supervised fine-tuning, optimização por preferências, reinforcement learning, distillation ou uma combinação destes métodos. Não consiste necessariamente em supervised fine-tuning seguido de RLHF.

Use um checkpoint instruct como baseline inicial do assistente. Confirme o seu chat template, o formato de tool call suportado, o comportamento das mensagens de sistema e as características de recusa. «Instruct», por si só, não garante JSON fiável nem tool use.

Reasoning-tuned

Os checkpoints orientados para raciocínio são optimizados em tarefas ou trajectórias que recompensam a resolução de problemas em várias etapas. Alguns expõem texto de raciocínio, outros separam-no através de um parser no serving, e outros apresentam apenas a resposta. Uma geração mais longa não garante um raciocínio fiel nem menos alucinações.

Adopte um destes modelos quando melhorar os segmentos difíceis da avaliação, depois de considerar os tokens de saída, a latência e a verificação. Tarefas rotineiras de extracção ou classificação podem ficar mais lentas sem ficarem melhores.

Distilled

A distillation transfere comportamento de um teacher ou de dados gerados por um teacher para outro modelo. O student pode ser mais pequeno, ter a mesma dimensão ou ser estruturalmente diferente. Não existe uma regra estável de «70–80% da qualidade com metade da dimensão»: a qualidade preservada depende do teacher, dos dados, do objectivo, da capacidade do student e da avaliação.

Trate Distill como proveniência do treino e faça o benchmark como faria com qualquer outro checkpoint.

Que etiqueta deve influenciar cada passo da selecção? Este mapa mantém separadas a função no treino, a proveniência do treino e a arquitectura. Não estabelece uma hierarquia entre tipos de modelos.

A documentação de chat templates do Transformers explica por que razão o formato exacto das mensagens de um modelo ajustado para seguir instruções é importante. No artigo original sobre knowledge distillation, Hinton, Vinyals e Dean transferem comportamento para um student sem afirmar uma proporção fixa de qualidade. O artigo sobre o Switch Transformer apresenta um desenho de routing esparso para experts. Uma família MoE específica pode encaminhar tokens de forma diferente, pelo que o seu model card continua a ser a referência principal.

As etiquetas da arquitectura descrevem a execução

Modelos Dense

A maioria dos parâmetros participa no forward pass de cada token. A contagem de parâmetros é um indicador aproximado do armazenamento dos pesos. A memória do runtime também inclui KV cache, activações ou workspace, overhead do allocator e, por vezes, estado duplicado ou fragmentado.

Mixture of Experts

Uma camada MoE encaminha cada token para um subconjunto de redes feed-forward de experts. Nomes como A3B significam frequentemente que aproximadamente três mil milhões de parâmetros estão activos por token, mas as convenções de nomenclatura são específicas de cada família. Consulte o model card para saber o número total de parâmetros, os parâmetros activos, o número de experts e o desenho do routing.

A contagem de parâmetros activos descreve o compute encaminhado, não a colocação dos pesos. Por exemplo, o expert parallelism do vLLM distribui as camadas de experts por ranks de expert parallelism e calcula a alocação de experts de cada rank a partir do número total de experts. Outros runtimes podem colocar ou fazer offload dos pesos de forma diferente. Assim, um modelo com 30B parâmetros totais e 3B activos não cabe automaticamente como um modelo Dense de 3B.

O suporte do runtime também é específico da arquitectura. Confirme a implementação do modelo, o suporte para expert parallel ou tensor parallel, os kernels de quantização e o contexto máximo antes de descarregar.

Os contentores e a quantização são camadas diferentes

Safetensors

Safetensors é um formato seguro de serialização de tensores, usado habitualmente em repositórios Hugging Face. Um modelo pode ter vários fragmentos .safetensors, além de ficheiros de configuração, tokenizer e geração. Esses tensores podem estar em BF16/FP16 ou estar pré-quantizados com um método como GPTQ ou AWQ.

A extensão, por si só, não indica a precisão nem a compatibilidade com o runtime. Inspeccione config.json, a configuração da quantização, o model card, o dtype dos tensores e a documentação do runtime.

GGUF

GGUF empacota tensores e metadados para o ecossistema ggml/llama.cpp. llama.cpp carrega GGUF e suporta backends como Metal, CUDA, HIP, Vulkan e percursos para CPU. A arquitectura do modelo e a qualidade da conversão continuam a determinar a compatibilidade.

GGUF é um contentor. Pode conter tensores de alta precisão ou quantizados. Os modelos multimodais podem também precisar de um projector ou ficheiro de encoder separado. «Um único ficheiro GGUF contém tudo» não é uma regra universal.

GPTQ e AWQ

GPTQ e AWQ são métodos de quantização de pesos pós-treino, não extensões de ficheiros. Os seus artefactos usam habitualmente Safetensors juntamente com configuração específica do método. Os serving engines precisam de kernels compatíveis com o método, a largura de bits, o group size, a arquitectura do modelo e o hardware.

Nenhum dos métodos é universalmente superior em qualidade. Os dados de calibração, a implementação, o percurso dos kernels e a tarefa são relevantes. O suporte do runtime muda, por isso verifique o artefacto exacto em relação à versão que fixou. Consulte as páginas oficiais de quantização no Transformers e de quantização no vLLM antes de tomar essa decisão.

O hardware, por si só, não permite escolher o contentor. Primeiro, escolha um runtime compatível com a arquitectura e a interface de serving. Depois, use a organização do artefacto e o percurso de quantização documentados por esse runtime.

Por exemplo, o projecto llama.cpp requer GGUF e documenta vários backends de hardware. A especificação GGUF define um contentor para tensores e metadados. O Transformers, por sua vez, carrega métodos de quantização através de configuração específica do backend, conforme descrito no seu workflow de quantização. Nenhuma destas fontes promete que uma extensão compatível suporte todas as arquitecturas ou funcione bem em todos os dispositivos.

A matemática da quantização é um limite inferior, não um planeamento de capacidade

Para $P$ parâmetros de pesos a $b$ bits, o armazenamento bruto dos pesos é aproximadamente:

Um modelo de 13B com pesos nominais de quatro bits começa, portanto, perto dos 6,5 GB. Não funcionará necessariamente com 6,5 GB. Scales, zero points, tensores de maior precisão, embeddings, metadados, buffers do runtime, KV cache e fragmentação acrescentam consumo de memória.

O contexto e a concorrência podem dominar a diferença entre «carrega» e «serve». Meça o pico de memória com a sequência máxima real, a política de batch, o dtype do cache e o paralelismo pretendidos.

A quantização pode reduzir a memória e, por vezes, melhorar a velocidade, mas os kernels de poucos bits também podem ser mais lentos em hardware não suportado. Compare a qualidade na tarefa e o throughput end-to-end, não apenas o tamanho do ficheiro. Consulte o guia de quantização do llama.cpp para receitas específicas do runtime.

Interprete cuidadosamente os nomes de quantização GGUF

Em llama.cpp, Q4_K_M designa uma receita de quantização ao nível do ficheiro, não um único tipo de tensor aplicado a tudo. As opções llama-quantize apresentam Q4_K_M como tipo seleccionável e descrevem --pure como a desactivação de misturas de K-quant. A implementação do quantizer usa Q4_K como predefinição para esta receita e aplica outros tipos a algumas categorias de tensores. Trate o sufixo como um nome de receita llama.cpp, não como uma especificação portável da largura de bits.

A documentação actual de quantização do llama.cpp também mostra que as receitas podem variar consoante a arquitectura e a categoria do tensor. Uma matriz de importância pode orientar a retenção de maior precisão em determinados pesos.

Evite afirmações universais de que Q4_K_M é indistinguível de BF16 ou de que um modelo Q3 maior supera sempre um modelo Q8 mais pequeno. Use uma pequena escada para o checkpoint exacto:

1. artefacto de alta precisão ou de referência fiável
2. um candidato próximo do limite de memória
3. um candidato mais pequeno, com maior margem

Execute os mesmos prompts, verificações de structured output, casos de contexto longo e testes de latência nos três.

Um workflow de selecção que resiste a novos formatos

1. Fixe o contrato da tarefa

Defina o idioma, a modalidade, o comprimento do contexto, a interface de tool ou schema, as restrições de segurança, os requisitos de licença e os segmentos de avaliação. Compare checkpoints numa representação suficientemente precisa para que a quantização não decida a primeira ronda.

2. Seleccione o checkpoint

Escolha o checkpoint mais pequeno que ultrapasse os gates não negociáveis de qualidade e comportamento. Registe o repositório e a revisão exactos, o tokenizer, o chat template e qualquer reasoning parser necessário.

3. Seleccione o runtime

Verifique o suporte da arquitectura, o backend de hardware, o paralelismo, os kernels de quantização, o structured output, os adapters e a interface operacional. Para inferência local com GGUF, llama.cpp é o runtime de referência. Para serving em GPU, compare as versões actuais do vLLM, TGI, Transformers ou engines especializados com o artefacto real.

4. Estabeleça um orçamento de memória medido

Inclua os pesos, o KV cache, o workspace do runtime, a concorrência esperada e uma margem para o sistema operativo ou processos co-localizados. Um ficheiro caber na RAM ou na VRAM é necessário, mas não suficiente.

5. Escolha e valide uma representação

Prefira artefactos fornecidos pelo publisher, com calibração e proveniência documentadas. Se utilizar uma conversão comunitária, registe a revisão de origem, a revisão do conversor, a receita de quantização, os dados de calibração ou importância e os hashes.

6. Faça o benchmark da unidade de release

Meça a qualidade na tarefa, a correcção do schema/tool call, o time to first token, o throughput de saída, o pico de memória e as falhas no contexto e na concorrência pretendidos. Repita a medição depois de alterar qualquer checkpoint, runtime, kernel ou definição de quantização.

Exemplo de nome

Suponha que um repositório se chama:

Acme-32B-A3B-Instruct-AWQ

Leia-o como um conjunto de perguntas:

• Acme: qual é a família, a licença e a revisão?
• 32B: pesos totais ou outra convenção do publisher?
• A3B: como define esta família os parâmetros activos?
• Instruct: qual é a receita pós-treino e o chat template?
• AWQ: qual é a largura de bits, o group size, a calibração e que kernels são suportados?
• ficheiros do repositório: fragmentos Safetensors, configurações, tokenizer e código personalizado?
• runtime de destino: a versão fixada suporta exactamente esta arquitectura e esta quantização?

O nome é um índice para a documentação, não uma especificação completa de deployment.

Conclusão

A selecção de modelos torna-se menos confusa quando as etiquetas deixam de partilhar uma única categoria. A função no treino diz-lhe que comportamento foi optimizado. A arquitectura diz-lhe como o compute está organizado. A quantização diz-lhe como alguns tensores foram aproximados; os contentores dizem-lhe como os artefactos são armazenados; e os runtimes dizem-lhe o que é executado eficientemente no seu hardware.

Escolha por essa ordem, preserve a proveniência exacta e deixe uma única avaliação da tarefa comparar os artefactos de release. Um sufixo familiar não prova que o modelo cabe, funciona rapidamente ou preserva o comportamento de que necessita.

Referências

• Chat templates do Transformers - Formatação de mensagens para modelos de linguagem causais base e ajustados para seguir instruções.
• Distilling the Knowledge in a Neural Network - Artigo original sobre distillation de Hinton, Vinyals e Dean.
• Switch Transformers - Arquitectura de routing esparso de experts de Fedus, Zoph e Shazeer.
• Especificação GGUF e guia de quantização do llama.cpp
• Conceitos de quantização do Hugging Face Transformers
• Artigo sobre GPTQ
• Artigo sobre AWQ
• Documentação de quantização do vLLM