Escolhendo e julgando um quant da comunidade

01 · Conceito

Conceito

A lição 7.12 terminou com uma decisão já tomada: você sabe qual degrau da escada de quantization sua máquina permite. Agora você busca esse modelo no Hub e recebe quarenta repositórios de volta. Alguns publicados por uma organização, a maioria por indivíduos. Os nomes discordam sobre quase tudo. Um diz 4bit, outro diz Q4_K_M, outro diz iQ-3.8bpw, e outro é o experimento de alguém subido ontem à noite. Não são o mesmo arquivo, não vão se comportar do mesmo jeito, e nada na página os classifica.

Esta lição é sobre ler esses nomes — e depois sobre não confiar neles.

O que um nome consegue te dizer

Nada disso é um padrão, e a discordância que você acabou de ver é a prova: um id de repositório é um namespace e um nome em texto livre, então essas são pistas que podem aparecer, mais ou menos nessa ordem, não campos que todo artefato carrega. 4bit nomeia uma receita e nenhuma taxa de bits; Q4_K_M nomeia uma receita cuja taxa você precisa consultar; iQ-3.8bpw nomeia as duas. Muitos repositórios omitem o formato porque o namespace inteiro já o implica, e muitos anexam a taxa de bits a arquivos individuais em vez de ao repositório.

Das pistas que de fato aparecem, três são confiáveis. O modelo base nomeia os pesos de onde o artefato derivou. O formato de contêiner — GGUF, MLX, safetensors — decide quais runtimes conseguem carregar o arquivo, que é a verificação que a lição 7.12 mandou fazer antes de baixar dezesseis gigabytes. Bits por peso, quando está presente, é uma medição.

Os outros dois não são confiáveis, e confundi-los com padrões é o erro comum. Nome de publicador não é sinal de qualidade: mlx-community é onde vive uma boa quantidade de conversões MLX, e estar lá significa que alguém subiu uma conversão, não que alguém a avaliou. O rótulo da receita é pior. Fora das famílias Q e IQ do llama.cpp, um rótulo como iQ ou oQ4e é a abreviação particular que o publicador escolheu para uma receita. Pode codificar algo cuidadoso. Você não tem como saber pela string.

Bits por peso é o único número honesto

A lição 7.9 estabeleceu que um artefato de 4 bits não contém apenas códigos de meio byte: metadados de grupo e tensores deliberadamente protegidos viajam junto. A lição 7.10 fixa o arquivo de texto Q4_K_M do Qwen3.8-27B em 17,1 GB (15,93 GiB), contra um piso de 13,5 GB dos códigos puros. Bits por peso — bpw — nomeia a taxa de armazenamento medida de um artefato, mas calculá-la exatamente exige o denominador exato de tensores daquele artefato, não uma contagem comercial arredondada.

Depois que você consegue enxergá-lo, os rótulos ficam diferentes. Medido no Llama-3.1-8B, o Q4_K_M armazena 4,8944 bits por peso e o Q8_0 armazena 8,5008. Nenhum dos dois é o número redondo do próprio nome. Ou seja: um repositório anunciando 3.8bpw não está sendo excêntrico — está sendo mais preciso que aquele anunciando 4bit, e está te dizendo algo que o outro nome esconde.

Há um segundo motivo para o número ser fracionário, e é o mais interessante. Uma receita não precisa usar a mesma largura em todo lugar. A quantization mista atribui larguras de bits diferentes a camadas diferentes — protegendo as projeções que mais sofrem quando são grosseiras e gastando menos no resto — e a média cai onde essa mistura a colocar. No mlx-lm elas vêm como receitas nomeadas (mixed_2_6, mixed_3_4, mixed_3_6, mixed_4_6) e, no caminho de learned quantization, como um alvo que você define diretamente: --target-bpw pede uma média e deixa a ferramenta escolher a atribuição por camada que a alcança. Um 3,8 é uma posição de dial, não um erro de digitação.

Importância é mensurável

A pergunta que uma receita mista precisa responder é quais camadas merecem os bits. A lição 7.10 deu uma família de respostas: GPTQ compensa erro camada a camada, AWQ protege os canais que as activations mostram ser significativos. O rótulo do Hub que você ainda não encontrou pertence à mesma família.

Uma importance matrix, geralmente escrita imatrix, é construída passando dados de calibração pelo modelo e acumulando, por coluna de tensor, a soma dos quadrados das ativações que passam por ali. Colunas que os dados de calibração exercitam bastante pontuam alto; colunas que eles mal tocam pontuam baixo. O quantizador então pondera seu erro de acordo, gastando precisão onde a estatística diz que importa. Note o que isso é e o que não é: é uma medição das ativações que um corpus produz, não de quanto cada peso individual move a saída — e a própria documentação do llama.cpp sinaliza que usar ativações ao quadrado, em vez das brutas, torna a estatística menos confiável do que parece à primeira vista.

Duas correções que a maioria dos leitores precisa. Primeira, uma importance matrix não é a mesma coisa que um formato IQ: k-quants são construídos com uma rotineiramente, e muitos arquivos Q4_K_M bem avaliados no Hub são calibrados por imatrix. Nem todo tipo IQ exige uma. O llama.cpp recusa de saída nos seus degraus mais baixos — as famílias IQ1 e IQ2, os tipos IQ3 menores e o Q2_K_S —, avisando que o resultado seria lixo sem dados de calibração; IQ4_XS e IQ4_NL são construídos sem uma e apenas se beneficiam dela. A verificação é por tensor e depende do tipo de destino, então o conjunto exato muda entre releases: leia o erro, não decore uma lista. Segunda, ela importa mais onde a precisão é mais escassa, que é a mesma afirmação pelo outro lado: acima de aproximadamente 4 bits o benefício é modesto; nos degraus que se recusam a ser construídos sem ela, é a diferença entre um modelo que funciona e lixo. O análogo no MLX é a dynamic quantization baseada em sensibilidade, que estima a influência de cada camada e salva as sensibilidades por camada para que a mesma medição possa ser reaproveitada em outros alvos.

Por que dois arquivos de 4 bits diferem

A lição 7.9 avisou que a largura de bits sozinha não prevê nem velocidade nem qualidade, e a lição 8.7 observou que dois conversores produzem arquivos mensuravelmente diferentes. Agora o mecanismo está disponível. Dois artefatos na mesma média podem diferir em group size — quantos pesos compartilham uma escala e, portanto, quão de perto as escalas acompanham as estatísticas locais; em quais tensores foram mantidos em precisão mais alta; e no corpus de calibração, já que um quantizador ajustado em prompts curtos em inglês não viu nada sobre código nem sobre um documento de cem mil tokens.

É por isso que o relato de um praticante de que um build de 4 bits supera outro não é surpreendente nem místico. Mesma largura nominal, receitas diferentes, medições diferentes por baixo.

O que menos bits realmente compram

A primeira metade dessa figura é a lição 7.3 tornada visível. O decode relê aproximadamente todo o conjunto de pesos para cada token que gera, então é limitado por largura de banda, e encolher os pesos ataca diretamente sua restrição. Neste benchmark do Llama-3.1-8B, as linhas quantizadas geram entre 1,75 e 3,09 vezes a vazão do F16: o Q8_0 fica no limite inferior, com 50,93 contra 29,17 tokens por segundo, enquanto o Q2_K_S fica no superior, com 90,01. O prefill é limitado por computação, e a quantization não multiplica unidades aritméticas — pior, desquantizar é aritmética extra —, então o processamento do prompt não melhora e na verdade recua, de 923 tokens por segundo no F16 para 709 no degrau quantizado mais lento.

A segunda metade é a parte que merece calma, porque ela se recusa a virar regra. Abaixo de cerca de 8 bits, o tamanho para de prever a velocidade. Nesta tabela o Q2_K_S, com 2,97 bpw, é o artefato mais rápido medido, a 90 tokens por segundo — mais rápido que todo build de 4 bits. O Q4_K_S, com 4,67 bpw, decodifica a 76,7 enquanto o menor Q3_K_S, com 3,64, alcança apenas 69,8. E o Q4_K_M, o degrau mais baixado do Hub, é mais lento que os dois, a 71,9, apesar de ficar entre eles em tamanho.

O mecanismo é eficiência de kernel, não bytes. Assim que um formato fica pequeno o bastante para o barramento de memória deixar de ser a única restrição, quem decide o resto é quão bem o kernel de desempacotamento se encaixa no hardware — e é por isso que i-quants, cujas consultas a codebook custam tempo de decode que um k-quant nunca paga, podem perder para k-quants maiores, a ressalva que a lição 8.7 levanta pelo lado do llama.cpp.

Então, quando alguém relata que 6 bits é o ponto ideal para ela, está fazendo uma afirmação sobre fidelidade contra velocidade que é inteiramente plausível e não derivável da largura de bits. Nada nesta tabela permitiria prever isso. Essa é a razão honesta pela qual a última seção desta lição existe.

Julgando por conta própria

A medição não é elaborada. Fixe um conjunto de prompts tirado do trabalho que você realmente faz, não de um leaderboard. Fixe os parâmetros de sampling e declare-os — o preset instruct do model card, conforme a disciplina da lição 8.9, em vez do que um runner traz por padrão. Rode os dois artefatos na mesma máquina, mesmo runtime, mesmo comprimento de contexto, e registre tempo de carga, time to first token, tokens por segundo e pico de memória residente ao lado do seu julgamento da saída, como estabelece a nota de benchmarking da lição 7.12. Depois rode de novo, porque um laptop dez minutos adentro de uma sessão é outra máquina.

E aplique o reflexo da lição 0.8 ao que você lê. Quando alguém relata que um quant venceu a comparação noturna dele, ou nomeia um benchmark particular próprio, o que você recebeu foi uma hipótese formada no hardware, nos prompts e no envelope térmico daquela pessoa. Isso é genuinamente útil — é mais evidência do que o nome do arquivo carrega. Não é um resultado até você saber o harness, o número de amostras e a variância, e essas costumam ser justamente as partes que ficam sem ser ditas.

A ideia durável é uma hierarquia de confiança. O formato de contêiner é um fato. Bits por peso é uma medição. O rótulo da receita é uma alegação. O ranking é o experimento de um desconhecido. Só os dois últimos falam de qualidade, e são os dois que você não consegue verificar sem rodar a coisa você mesmo.