2025-05-11 · Atualizado 2026-07-15

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

Variantes de Peso Aberto LLM, Quantização e Formatos: Instruct, MoE, GGUF, GPTQ e AWQ

Nomes como Model-32B-A3B-Instruct-AWQ parece denso porque combina várias decisões independentes: família e tamanho, arquitetura, papel no treino e quantização. Um repositório pode embalar esses pesos como Safetensors fragmentados, enquanto uma conversão comunitária do mesmo checkpoint surge como Q4_K_M.gguf.

Essas etiquetas não pertencem à mesma categoria: GPTQ e AWQ são métodos de quantização, GGUF é um contêiner e runtime um ecossistema, enquanto MoE representa uma arquitetura. Analisar as camadas separadamente facilita bastante a escolha da versão para download.

TL;DR. Escolha um checkpoint com base na qualidade da tarefa, na licença, no idioma, no contexto e no comportamento da interface. Em seguida, selecione um runtime que suporte a sua arquitetura. Só depois é que se deve optar por uma representação de pesos e por uma forma de quantização adequadas às restrições de memória e latência medidas. GPTQ e AWQ são métodos de quantização, enquanto Safetensors e GGUF são formatos de containerização; por fim, MoE refere‑se a uma arquitetura, e não a uma garantia de que todos os pesos caberão na memória destinada aos “parâmetros ativos”.

Ler um artefato de modelo em seis camadas

Estas camadas não são mutuamente exclusivas. Um checkpoint pode ser distilado, ajustado por instruções, ajustado para raciocínio e MoE ao mesmo tempo.

O conceito de “código aberto” também exige atenção especial. Muitos modelos disponíveis para download possuem peso aberto, mas estão sujeitos a licenças que não cumprem a definição de código aberto ou que impõem restrições à sua utilização. Leia sempre o documento descrevendo o modelo e a licença antes de definir a arquitetura ou de realizar comparações com benchmark.

As etiquetas de papel de treino descrevem o comportamento, e não garantias de capacidade

Base

A base checkpoint é treinada principalmente para a previsão do próximo token. É útil para pré-treino contínuo, investigação controlada ou adaptações em que se pretende ter total controlo sobre o comportamento de execução das instruções. Pode optar por completar um prompt em vez de responder diretamente a ele.

Não presuma que todo ajuste fino deve começar a partir da versão base. Um instrutor checkpoint pode representar uma inicialização mais adequada quando o seu comportamento atual se alinha com o objetivo desejado e as suas avaliações confirmarem que ele não entra em conflito com o novo objetivo.

Instruir ou conversar

Estes checkpoints recebem processos pós-treino destinados a melhorar a capacidade de seguir instruções e a conduzir conversas. A abordagem exata pode incluir fine-tuning supervisionado, otimização de preferências, aprendizagem por reforço, destilação ou combinações desses métodos — não necessariamente o SFT clássico aliado ao RLHF.

Utilize um instrutor checkpoint como base inicial para o assistente. Verifique o seu modelo de conversação, o formato suportado para chamadas de ferramentas, o comportamento das mensagens do sistema e as características de recusa. A mera utilização da palavra “instruir” não garante um JSON ou tool use fiável.

Ajustado para raciocínio

Os sistemas orientados para o raciocínio checkpoints são otimizados para tarefas ou trajetórias que recompensam a resolução de problemas em vários passos. Alguns exibem o texto do raciocínio, outros isolam-no através de um analisador serving, e ainda outros apresentam apenas a resposta final. Uma geração mais extensa não garante necessariamente um raciocínio fiel nem uma redução das alucinações.

Adote uma abordagem quando ela melhorar as partes críticas que são relevantes, após levar em conta os tokens de saída, a latência e a verificação. A extração ou classificação rotineira pode tornar-se mais lenta sem, no entanto, se tornar mais eficaz.

Destilado

A destilação transfere o comportamento de um modelo “professor” ou de dados gerados por este para outro modelo. O modelo “aluno” pode ser menor, do mesmo tamanho ou ter uma estrutura diferente. Não existe uma regra fixa que garanta “70–80% da qualidade com metade do tamanho”: a qualidade mantida depende do modelo professor, dos dados utilizados, dos objetivos definidos, da capacidade do modelo aluno e do método de avaliação aplicado.

Tratar Distill Como informação de proveniência relativa ao treino, então benchmark é tratado da mesma forma que qualquer outro checkpoint.

Os rótulos de arquitetura descrevem a execução

Modelos densos

A maioria dos parâmetros participa no processo de forward pass de cada token. O número de parâmetros é um indicador aproximado do espaço de armazenamento necessário para os pesos, mas a memória runtime também inclui KV cache, as ativações ou o espaço de trabalho, o overhead do alocador, e, por vezes, estados duplicados ou fragmentados.

Mistura de Especialistas

Uma camada MoE encaminha cada token para um subconjunto de redes feed-forward especializadas. Nomes como A3B Geralmente, isso indica que existem aproximadamente três mil milhões de parâmetros ativos por token, mas as convenções de nomenclatura variam consoante a família do modelo. Consulte o cartão do modelo para obter informações sobre o número total de parâmetros, os parâmetros ativos, o número de especialistas e o esquema de roteamento.

Os parâmetros ativos descrevem principalmente os recursos de processamento necessários. A menos que o runtime transfira a execução para especialistas externos, todos os pesos desses especialistas continuam a exigir armazenamento, geralmente na memória do dispositivo, distribuída pela topologia da serving. Um modelo com um total de 30 bilhões de parâmetros e 3 bilhões ativos não se encaixa automaticamente da mesma forma que um modelo denso com 3 bilhões de parâmetros.

O suporte de Runtime também é específico da arquitetura. Verifique previamente a implementação do modelo, o tipo de suporte — seja em paralelismo por especialistas ou em paralelismo por tensores —, os kernels de quantização e o tamanho máximo de contexto antes de efetuar o download.

Os containers e a quantização são camadas distintas

Safetensors

Safetensors é um formato de serialização de tensores seguro, frequentemente utilizado em repositórios Hugging Face. Um modelo pode possuir vários .safetensors shards, bem como ficheiros de configuração, tokenizador e geração. Esses tensores podem ser BF16/FP16 ou pré-quantificados através de métodos como GPTQ ou AWQ.

A extensão por si só não indica a precisão nem a compatibilidade com runtime. É necessário inspecioná‑la. config.jsonconfiguração de quantização, cartão do modelo, tipo de dado do tensor e documentação runtime.

GGUF

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

GGUF é um contêiner. Ele pode armazenar tensores de alta precisão ou quantizados. Modelos multimodais podem também exigir um arquivo de projetor ou codificador separado; a afirmação de que “um único arquivo GGUF contém tudo” não se aplica como regra geral.

GPTQ e AWQ

GPTQ e AWQ são métodos de quantização de pesos pós-treino, e não extensões de ficheiro. Os respetivos artefatos recorrem frequentemente a Safetensors em conjunto com configurações específicas para cada método. Os motores Serving exigem kernels compatíveis com o método utilizado, a largura de bits, o tamanho do grupo, a arquitetura do modelo e o hardware disponível.

Nenhum dos métodos é, por si só, a solução definitiva para garantir qualidade. Dados de calibração, implementação, caminho do kernel e tipo de tarefa são fatores cruciais. Os Transformadores de Corrente, TGI, e vLLM suportam vários mecanismos de quantização, mas as suas matrizes podem variar; verifique os valores fixos de runtime em vez de confiar em tabelas estáticas publicadas em blogs.

A matemática da quantização representa um limite inferior, e não um plano de capacidade

Para parâmetros de peso (P) com (b) bits, o armazenamento bruto dos pesos é aproximadamente:

[ \text{bytes de peso} \approx \frac{P \times b}{8} ]

Um modelo de 13B com pesos nominais de quatro bits começa, portanto, com cerca de 6,5 GB de ocupação. No entanto, ele não necessariamente irá rodar nesse limite de memória. Parâmetros como escalas, pontos zero, tensores de precisão superior, embeddings, metadados, buffers runtime, KV cache, bem como a fragmentação, contribuem para um consumo adicional de memória.

O contexto e a concorrência podem determinar significativamente a diferença entre “cargas” e “serviços”. Meça a memória máxima com a sequência real máxima, a política de loteamento, o tipo de dado do cache e o nível de paralelismo.

A quantização pode reduzir a memória e, por vezes, melhorar a velocidade, mas os kernels de baixo número de bits também podem ser mais lentos em hardware não suportado. Compare a qualidade da tarefa e o rendimento de ponta a ponta — e não apenas o tamanho do ficheiro.

Decodifique com cuidado os nomes de quantização GGUF

In Q4_K_M:

• Q4 indica uma família de quantização de quatro bits, mas nem sempre são exatamente quatro bits para cada tensor. K identifica o esquema K-quant. M identifica uma receita mista que utiliza tipos de tensor diferentes para os pesos selecionados. Isto não significa “tamanho médio do bloco”.

O atual llama.cpp A documentação de quantização indica que as regras aplicáveis podem variar consoante a arquitetura e a categoria do tensor. Uma matriz de importância pode também ajudar a determinar quais pesos devem manter maior precisão.

Evite afirmações universais que Q4_K_M não é distinguível de BF16 ou que um modelo Q3 maior sempre supera um modelo Q8 menor. Utilize uma escada pequena para o checkpoint exato:

1. artefato de referência de alta precisão ou fidedigno
2. um candidato próximo ao limite de memória
3. um candidato menor com mais margem disponível

Execute os mesmos testes de prompts, de saída estruturada, casos com contexto extenso e teste de latência em todos os três.

Um fluxo de seleção capaz de lidar com novos formatos

1. Corrigir o contrato da tarefa

Defina a linguagem, a modalidade, o comprimento de contexto, a interface de ferramentas ou esquema, as restrições de segurança, os requisitos de licença e as fatias de avaliação. Compare checkpoints numa representação suficientemente precisa para evitar que a quantização influencie a decisão na primeira rodada.

2. Selecionar o checkpoint

Escolha o menor checkpoint que satisfaça os requisitos inegociáveis de qualidade e comportamento. Registe o repositório e a revisão exatos, o tokenizador, o modelo de conversação e qualquer analisador de raciocínio necessário.

3. Selecione o runtime

Verifique o suporte da arquitetura, o hardware backend, o paralelismo, os kernels de quantização, structured output, os adaptadores e a interface operacional. No que diz respeito à inferência local GGUF, llama.cpp Trata‑se da referência runtime. No que diz respeito a GPU serving, compare os valores atuais de vLLM, TGI, Transformers ou motores especializados com o artefato real.

4. Definir um orçamento de memória controlado

Deve ser incluído o peso dos pesos, o espaço de trabalho KV cache e runtime, a concorrência esperada, bem como a margem disponível para o sistema operativo ou para os processos alojados na mesma infraestrutura. Um ficheiro que caiba na RAM ou em VRAM é necessário, mas não é suficiente.

5. Escolher e validar uma representação

Deve‑se preferir artefatos fornecidos pelo editor, que incluam documentação detalhada sobre calibração e proveniência. Caso se utilize uma conversão da comunidade, é necessário registar a revisão da fonte, a revisão do conversor, as regras de quantização, os dados de calibração ou importância, bem como os hashes.

6. Benchmark a unidade de lançamento

Avalie a qualidade da tarefa, a correção do esquema e das chamadas de ferramenta, o tempo até ao primeiro token, a taxa de produção de saída, o consumo máximo de memória, bem como os falhas no contexto e na concorrência alvo. Repita a execução após alterar qualquer checkpoint, runtime, kernel ou parâmetro de quantização.

Nome funcional

Suponhamos que um repositório tenha o nome:

Acme-32B-A3B-Instruct-AWQ

Leia-o como um conjunto de perguntas:

• Acme: Qual família, licença e revisão? 32B: pesos totais ou outra convenção adotada pela editora? A3B: como é que esta família define os parâmetros ativos? Instruct: Qual método pós-treino e qual modelo de conversação? AWQ: Qual a largura de bits, o tamanho do grupo, o processo de calibração e os kernels suportados?
• Ficheiros do repositório: fragmentos Safetensors, ficheiros de configuração, tokenizador e código personalizado?
• Alvo runtime: A versão fixada suporta efetivamente esta arquitetura e este nível de quantização?

O nome funciona como um índice para a documentação, e não como uma especificação completa de implementação.

Conclusão

A seleção de modelos torna‑se menos confusa assim que as etiquetas deixam de pertencer ao mesmo grupo. O papel do treino indica qual comportamento foi otimizado. A arquitetura revela como a computação é organizada. A quantização explica como alguns tensores foram aproximados. Os containers indicam como os artefatos são armazenados. Os tempos de execução determinam o que é executado de forma eficiente no seu hardware.

Escolha naquela ordem, preservando a origem exata, e permita que uma avaliação de tarefa compare os artefatos de lançamento. Um sufixo familiar não constitui prova de que o modelo se adapta bem, executa-se rapidamente ou mantém o comportamento desejado.

Referências

• GGUF especificação e Guia de quantização llama.cpp
• Hugging Face Conceitos de quantização de Transformers
• GPTQ artigo científico
• AWQ artigo científico
• vLLM documentação de quantização