Liquid AI recupera 97% da precisão em modelos 4-bit com destilação

Quantizar um LLM↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI → para 4 bits é o caminho mais direto para rodá-lo em hardware modesto: menos memória, mais throughput. O problema conhecido é que essa compressão cobra um preço em qualidade. A Liquid AI acaba de publicar, no blog da Hugging Face, checkpoints Q4_0 dos modelos LFM2.5 que, segundo a empresa, recuperam 97% da precisão média perdida na quantização sem abrir mão do tamanho nem da velocidade do formato Q4_0.

O lançamento cobre quatro modelos: LFM2.5-230M, LFM2.5-350M, LFM2.5-1.2B-Instruct e LFM2.5-2.6B. São modelos pequenos, pensados para rodar na borda (edge), e é aí que a técnica faz diferença de verdade.

O problema da quantização pós-treino

A forma mais comum de reduzir um modelo para 4 bits é a quantização pós-treino (PTQ, post-training quantization): pega-se o modelo já treinado em BF16 e converte-se os pesos para uma representação de menor precisão. É rápido e não exige retreino, mas introduz erro de arredondamento em cada peso. Em modelos grandes esse erro se dilui; em modelos pequenos, onde cada parâmetro carrega mais responsabilidade, a degradação aparece em tarefas de raciocínio, seguimento de instruções e uso de ferramentas.

É exatamente esse buraco que a Liquid AI mirou. Os GGUFs Q4_0 que já existiam para os LFM2.5 eram produzidos por PTQ. Os novos vêm de um processo diferente.

Como funciona a destilação com consciência de quantização

A técnica é chamada de Quantization-Aware Distillation (QAD). Combina duas ideias já conhecidas isoladamente:

• Quantization-aware training: em vez de quantizar depois, o modelo é treinado já simulando a quantização de 4 bits durante o forward pass. Assim os pesos aprendem a conviver com a perda de precisão, em vez de sofrerem com ela no fim.
• Destilação: um modelo professor de alta precisão (o BF16) transfere seu conhecimento para um modelo aluno quantizado. O aluno não aprende só a resposta certa, mas a distribuição de probabilidades do professor, um sinal muito mais rico.

A junção das duas faz o aluno de 4 bits reproduzir o comportamento do professor de precisão total. O resultado é um checkpoint que ocupa o mesmo espaço de um Q4_0 comum, mas pensa mais parecido com o original.

Os números

A Liquid AI comparou os GGUFs antigos (PTQ) contra os novos (QAD) usando o BF16 como teto de referência dentro do formato. A bateria de testes cobre raciocínio, seguimento de instruções, uso de ferramentas e capacidades agênticas: GPQA Diamond, MMLU-Pro, IFEval, IFBench, Multi-IF e BFCLv4. Somaram ainda uma avaliação de matemática por escala (GSM8K para os menores, AIME25 para os maiores). Cada número é a média de cinco execuções.

A retenção de performance em relação ao BF16 ficou em:

• 97,1% no LFM2.5-230M
• 96,5% no LFM2.5-350M
• 97,4% no LFM2.5-1.2B-Instruct
• 96,6% no LFM2.5-2.6B

Mais interessante que a média é a comparação com formatos de quantização mais generosos. Os checkpoints QAD Q4_0 de 230M e 350M igualam a qualidade de um Q5_K_M (que usa mais bits) dentro da variância do teste, entregando de 4% a 33% mais throughput de decode. Os de 1.2B e 2.6B empatam com Q4_K_M com 3% a 14% mais velocidade. Em resumo: mesma qualidade de formatos maiores, mas rodando mais rápido e ocupando menos. A Liquid AI diz ainda que os checkpoints batem o UD-Q4_K_XL da Unsloth, uma referência forte de PTQ externa, onde aplicável.

Rodando na prática

Os arquivos são GGUF padrão e funcionam com llama.cpp ou qualquer runtime que aceite artefatos Q4_0. Baixar e executar direto do Hugging Face é uma linha:

llama-cli -hf LiquidAI/LFM2.5-350M \
  --hf-file LFM2.5-350M-QAD-Q4_0.gguf \
  -p "What is C. elegans?"

Os quatro modelos já estão no Hugging Face: LFM2.5-230M, LFM2.5-350M, LFM2.5-1.2B-Instruct e LFM2.5-2.6B.

O ponto que importa para quem constrói no Brasil é o hardware alvo. A empresa mediu throughput em quatro plataformas bem representativas do que se tem à mão por aqui: MacBook Pro, o mini-PC NucBox EVO-X2, um Samsung Galaxy S26 Ultra e um Raspberry Pi 5. MacBook e NucBox usam GPU; celular e Raspberry rodam em CPU Arm. Ou seja: dá para colocar um LLM útil para rodar num Pi 5 ou num celular sem depender de nuvem, o que resolve latência, custo recorrente de API e, principalmente, privacidade de dados que não podem sair do dispositivo.

Onde isso não vale a pena

QAD não é bala de prata. A técnica exige retreino com um professor de alta precisão, algo que só faz sentido para quem publica os modelos, não para o dev que quer quantizar um modelo qualquer em casa. Para uso próprio, a PTQ continua sendo o caminho prático, e ferramentas como as da Unsloth seguem relevantes.

Outro ponto: são modelos pequenos, de 230M a 2.6B de parâmetros. Não substituem um GPT ou Claude em tarefas complexas. O nicho é claro: agentes locais, classificação, extração, ferramentas embarcadas e casos em que rodar na borda vale mais que a capacidade bruta de um modelo grande. Nesses cenários, ganhar velocidade sem perder qualidade num formato de 4 bits é exatamente o tipo de otimização que decide se o projeto roda ou não no hardware disponível.

O recado técnico é que a fronteira da quantização não está mais só em espremer bits depois do treino, e sim em treinar já contando com a compressão. Se a QAD escalar para modelos maiores mantendo essa taxa de recuperação, o cálculo de custo de rodar LLMs localmente muda de forma relevante.

Fonte: Hugging Face Blog