Benchmark de Quantização Qwen 3.6 27B: Q4_K_M Supera Q8_0 em Compensações Práticas

Um usuário do Reddit fez benchmark do Qwen 3.6 27B em três variantes de quantização GGUF (BF16, Q4_K_M, Q8_0) usando llama-cpp-python através do framework Neo AI Engineer. A avaliação cobriu 664 amostras no total em três tarefas: HumanEval (geração de código, 164 amostras), HellaSwag (raciocínio de senso comum, 100 amostras) e BFCL (chamada de funções, 400 amostras).

Resultados do Benchmark

• BF16 (tamanho do modelo 53,8 GB, pico de RAM 54 GB, taxa de transferência 15,5 tok/s): HumanEval 56,10% (92/164), HellaSwag 90,00% (90/100), BFCL 63,25% (253/400). Precisão média: 69,78%.
• Q4_K_M (16,8 GB, 28 GB de RAM, 22,5 tok/s): HumanEval 50,61% (83/164), HellaSwag 86,00% (86/100), BFCL 63,00% (252/400). Média: 66,54%.
• Q8_0 (28,6 GB, 42 GB de RAM, 18,0 tok/s): HumanEval 52,44% (86/164), HellaSwag 83,00% (83/100), BFCL 63,00% (252/400). Média: 66,15%.

Principais Conclusões

O Q4_K_M é a variante prática de destaque. Ele preserva a precisão do BFCL (63,00% vs 63,25%), cai apenas ~5,5 pontos no HumanEval e fica ~4 pontos atrás do BF16 no HellaSwag. As compensações: 1,45x mais rápido que o BF16, 48% menos pico de RAM, arquivo 68,8% menor e desempenho quase idêntico em chamada de funções. O Q8_0 foi decepcionante: melhorou o HumanEval em apenas ~1,8 pontos em relação ao Q4_K_M, mas usou 42 GB de RAM contra 28 GB, foi mais lento e obteve pontuação menor no HellaSwag.

Para implantação local/CPU, o Q4_K_M é recomendado, a menos que a carga de trabalho seja fortemente focada em geração de código. Para máxima qualidade, o BF16 ainda vence.

Configuração da Avaliação

Variantes GGUF via llama-cpp-python com n_ctx: 32768, avaliação com checkpoint. O framework Neo AI Engineer construiu o pipeline de avaliação GGUF, gerenciou execuções com checkpoint e consolidou resultados. O estudo de caso completo com trechos de código está linkado nos comentários originais do Reddit.