Humanizer 12B com 8, 16 ou 32 GB: qual arquivo GGUF baixar

Uma decisão que quase todo mundo enfrenta com um modelo local

Imagine que você tem um notebook com 16 GB de memória e quer experimentar um reescritor local. Abre a página do modelo e encontra não um download, mas seis, de 3,9 GB a 23,8 GB, com nomes como Q6_K e IQ2_XS-QAT. É uma situação hipotética, mas é a mesma em que quase todo mundo se encontra ao conhecer um modelo quantizado. O card do humanizer ajuda mais do que a maioria, porque dá a cada arquivo um tamanho, um pico de memória medido, uma pontuação de fidelidade e uma contagem de checagem de fatos, e diz com clareza a quem cada arquivo se destina. Este texto lê essa tabela e explica o que suas colunas significam. Sobre o modelo em si e até onde confiar nas suas alegações de destaque, veja o que os números do humanizer realmente dizem.

A tabela

A concordância top-1 mede com que frequência o token seguinte mais provável do arquivo coincide com o do modelo bf16 completo, na média de inglês e chinês. Flagged é o número de reescritas em inglês, de 420, em que um juiz LLM rigoroso encontrou um problema factual. O pico de memória é a medição dos autores com o llama-server em Metal num M5 Max, usando as configurações do aplicativo, durante a reescrita. Todos os números são do autor.

Por que os arquivos pequenos não são só cópias espremidas

O card faz uma distinção que explica por que o meio e o fim da tabela se comportam melhor do que se poderia esperar. Diz que a maioria dos arquivos GGUF vem de uma única passada do llama-quantize, que arredonda cada peso para o tipo de destino. Os arquivos de 2 bits, Q3 e Q4_K_M vão além. Nos de 2 bits e Q3, o autor mediu o quanto cada tensor de pesos prejudica o modelo quando comprimido e deu mais bits aos tensores sensíveis e menos aos robustos. Os três foram então treinados camada por camada para reproduzir o modelo completo, o que é treinamento consciente de quantização, e destilados do modelo bf16 completo com dados de reescrita em inglês e chinês. Q6_K e Q8_0 são builds padrão, porque nesses tamanhos o card diz que quase não resta nada a recuperar.

O efeito, segundo o card, é mensurável. No arquivo de 2 bits, uma build padrão do mesmo tamanho escolhe o mesmo próximo token que o bf16 em 70 por cento das vezes; as etapas extras elevam isso a 81 por cento, depois 85, depois 87. Os detalhes, incluindo a divergência KL e as checagens de fatos por arquivo, estão num documento sobre quantização para o qual o card aponta; não os verificamos.

O resultado continua sendo um arquivo GGUF comum que qualquer llama.cpp recente consegue rodar, o que importa se você não quer depender do aplicativo do autor. O card também observa que os arquivos têm repositório próprio, então os comandos de download existentes continuam funcionando.

O que escolher para a sua memória

As recomendações do próprio card são específicas e batem com a tabela. Com 32 GB ou mais, escolha o Q8_0, que o card chama de recomendado e de melhor qualidade. Com 16 GB, o Q6_K, que segundo o card não tem perda mensurável. Em torno de 14 GB, ou quando o disco está apertado, o Q4_K_M, com perda leve e treinamento consciente de quantização. Com 12 GB, o Q3-QAT, com perda pequena e alguns deslizes de fatos a mais em inglês. Com 8 GB, o menor arquivo, o IQ2_XS-QAT. O aplicativo faz a escolha por você: na primeira execução sugere um de cinco tamanhos conforme a sua memória, até máquinas de 8 GB, baixa uma vez e depois funciona offline.

Duas ressalvas pedem lugar ao lado da lista. Primeiro, a coluna de memória é uma medição de Mac que deixa folga para o sistema; o card diz que o aplicativo mantém cerca de 4 GB livres. Numa máquina Windows ou Linux com GPU dedicada, o que importa é a memória de vídeo, e a única resposta confiável é testar. Segundo, duas linhas são estimativas, não medições: o pico de memória do Q6_K e do bf16. A estimativa de cerca de 11 GB para o Q6_K é o número em que você se apoia se escolher a opção de 16 GB.

Lendo as colunas de qualidade sem se enganar

As contagens de flagged não caem em linha reta, e o card diz por quê. O bf16 tem 52 sinalizadas e o Q8_0 tem 44, que o card descreve como dentro do ruído uma da outra. Q8_0, Q6_K e Q4_K_M estão dentro do ruído do bf16; Q3 e 2 bits cometem alguns deslizes a mais. O resumo honesto é que os três arquivos de cima são difíceis de distinguir em fatos, e os dois de baixo abrem mão de algo que se vê na contagem, de 64 a 70 em 420.

Há uma reviravolta na coluna do detector sobre a qual o card é cuidadoso. Numa medição separada, os mesmos 60 rascunhos em inglês passados pelo Originality.ai na configuração mais rigorosa, o Q8_0 teve 7 sinalizados de 60, o Q3-QAT teve 4, o arquivo de 2 bits teve 0 e o bf16 teve 4. O menor arquivo pontuou melhor, o que o card rotula como a menor pontuação no detector junto com alguns deslizes de fatos a mais. É um lembrete de que pontuações de detector e fidelidade factual podem puxar em direções opostas, e de que o próprio card diz que os detectores mudam e que esta é uma medição numa data. Se o seu trabalho envolve números e nomes, a coluna de fatos é a que deve pesar.

O tamanho do arquivo também não é toda a conta de memória. A coluna de pico de memória é maior que o tamanho do arquivo em todas as linhas, porque o runtime precisa de espaço para contexto e buffers além dos pesos. O card recomenda um contexto de 8192 tokens, cobrindo juntos a instrução, o rascunho e a reescrita, e manda dividir documentos longos nas quebras de parágrafo. Um bom hábito com qualquer modelo local é tratar o tamanho do arquivo como um piso, não um orçamento, e deixar folga.

Outras formas de fazê-lo rodar mais rápido

O card documenta vários caminhos além do aplicativo. O llama.cpp é o recomendado, com um comando de download, um comando de servidor e um pequeno cliente em Python. Para Apple silicon há um caminho MLX que converte os pesos para 8 bits localmente. Para o Ollama, o card avisa que ele ignora o chat template guardado no arquivo e aplicaria o seu próprio, o que quebra este modelo, então fornece um Modelfile com o template correto. Para um fluxo de linha de comando com documentos longos, uma ferramenta complementar reescreve a prosa trecho a trecho, mantém títulos, código, tabelas e links, e sinaliza qualquer trecho em que um número sumiu.

Um projeto da comunidade merece menção, com a ressalva do próprio card de que não o testamos em benchmark. Um colaborador treinou um modelo rascunho de decodificação especulativa para o humanizer, informando cerca de 1,5 vez a velocidade num M5 Pro com MLX, 34,5 tokens por segundo contra 22,8, e uma saída token a token idêntica à do humanizer sozinho no teste dele. Ele roda ao lado do modelo principal e precisa da configuração MLX descrita no model card do próprio projeto.

Nossa avaliação

Pegue o maior arquivo que a sua máquina comporta com folga. Pela medição do próprio autor, passar do Q8_0 para o Q6_K custa 12 reescritas sinalizadas a mais em 420, passar para o Q4_K_M custa 14 e passar para 2 bits custa 26. Em trabalho com números e nomes, essa diferença é o que deve pesar, não o tamanho do arquivo. Se você está no meio do caminho, a recomendação de 16 GB com o Q6_K parece o ponto ideal nesta tabela: perto do bf16 em fidelidade e checagem de fatos, com menos da metade do tamanho do bf16.

Continue lendo

Todos os artigos, do mais recente ao mais antigo, estão no índice do blog da Front.

• Humanizer 12B: as alegações examinadas: O que as fontes sustentam do que se diz sobre o modelo local Humanizer 12B.
• Ling 3.1 Flash: o que é preciso para rodá-lo: O hardware necessário para rodar o Ling 3.1 Flash.
• Linha do tempo do DeepSeek V4.1 Flash 1017: O lançamento do V4.1 Flash da DeepSeek, a atualização de 17 de outubro, preços e parâmetros.
• Cronologia do Meta Muse Spark Open: O lançamento do Meta Muse Spark Open, em ordem temporal.
• Cronologia do Reflection Beam 501B: O lançamento dos pesos do Reflection Beam 501B, em ordem temporal.

Perguntas frequentes

Fontes

• jialinyyzz/humanizer model card
• jialinyyzz/humanizer-GGUF