A Liquid AI publicou no Hugging Face um novo lote de checkpoints da série LFM2.5, no formato GGUF Q4_0, treinados com um método chamado QAD (quantization-aware distillation, destilação com consciência de quantização). Os quatro tamanhos (230M, 350M, 1.2B-Instruct e 2.6B) recuperaram, respectivamente, 97,1%, 96,5%, 97,4% e 96,6% do desempenho de suas linhas de base em BF16 nos benchmarks.
Para quem não trabalha com inferência local, isso pode não parecer grande coisa. Para entender o impacto, é preciso primeiro saber qual é o status do Q4_0 no ecossistema llama.cpp.
Um formato abandonado pela comunidade
O Q4_0 é um dos primeiros esquemas de quantização em 4 bits, com uma regra simples: a cada 32 pesos, um fator de escala compartilhado, e o restante comprimido diretamente em inteiros de 4 bits. Depois a comunidade criou a série K-quant (Q4_K_M, Q5_K_M etc.), que distribui larguras de bit diferentes conforme a importância de cada tensor, com precisão bem melhor no mesmo tamanho de arquivo. Isso praticamente aposentou o Q4_0, que sobreviveu apenas em alguns dispositivos e runtimes mais antigos.
Mas ele tem uma vantagem que ninguém consegue tirar: uma estrutura regular que mapeia diretamente para as instruções de produto escalar int8 das CPUs Arm. A divisão em blocos e as tabelas de consulta do K-quant exigem alguns desvios a mais em CPUs de celular, o Q4_0 não. É exatamente nisso que os números de velocidade divulgados agora pela Liquid AI se baseiam — nos mesmos modelos, os checkpoints Q4_0 são de 4% a 33% mais rápidos que o Q5_K_M, e de 3% a 14% mais rápidos que o Q4_K_M.
Então o que sempre travou o Q4_0 foi a precisão. E é exatamente aí que o QAD atua.
Levando a quantização para dentro do treinamento
A abordagem convencional é o PTQ (post-training quantization, quantização pós-treinamento): o modelo termina o treino, depois é comprimido, depois se avalia quanto de desempenho foi perdido — se perder demais, troca-se de formato e recomeça. A proposta do QAD é fazer o modelo já saber, durante o treinamento, em que formato ele vai ser comprimido no futuro: um modelo professor de alta precisão destila conhecimento para um modelo aluno já quantizado, a restrição de quantização participa do treino, e a distribuição dos pesos vai se aproximando da grade de 4 bits desde o início. No blog oficial, a Liquid AI descreve assim: "QAD substantially improves the Q4_0 checkpoint" (o QAD melhora substancialmente o checkpoint Q4_0).
Não é um conceito novo — o treinamento com consciência de quantização já é usado há anos em modelos de visão. A dificuldade ao trazer isso para modelos de linguagem está no custo: cada formato-alvo exige uma rodada de treinamento própria. O fato de uma empresa estar disposta a pagar por isso mostra que ela fez as contas. O volume de downloads e chamadas de modelos no dispositivo, aparentemente, justifica treinar especificamente para um formato.
Validação em quatro máquinas
Os testes cobriram duas classes de hardware: MacBook Pro e NucBox EVO-X2 rodando inferência em GPU, e Samsung Galaxy S26 Ultra e Raspberry Pi 5 rodando inferência em CPU Arm. A presença do Raspberry Pi 5 na lista chama atenção — ele representa justamente o cenário sem GPU e com pouca memória, onde a vantagem do Q4_0 é maior.
Fazendo as contas por cima: um modelo de 2,6 bilhões de parâmetros armazenado em 4 bits pesa pouco mais de 1,4 GB; somando o KV cache e o overhead do runtime, um celular com 8 GB de memória ainda cabe o modelo e sobra espaço para outras tarefas. Já a versão de 230M fica na casa de algumas centenas de megabytes, perfeitamente viável para embutir em um app como recurso local.
Em que essa leva de checkpoints está apostando
A direção da escolha aqui é nova. Nos últimos dois anos, a abordagem dominante para inferência no dispositivo foi encolher o modelo: destilar para menos parâmetros, ou trocar para um formato de quantização mais inteligente. Desta vez a Liquid AI escolheu um terceiro caminho — sem mudar o formato, sem mudar o número de parâmetros, transferindo toda a pressão de otimização para o lado do treinamento.
O custo é que o método só funciona nos modelos da própria empresa. A comunidade não pode usar essa técnica para salvar pesos Q4_0 lançados por terceiros, pois isso exige o pipeline de treinamento original. É algo que só o próprio fabricante do modelo consegue oferecer, e é um dos poucos pontos em que ainda dá para abrir vantagem na corrida dos modelos pequenos para dispositivo — mesmo tamanho de 2,6B, mesmo rodando no llama.cpp, quem perder menos precisão na versão de 4 bits vence essa rodada.
Para os desenvolvedores, a barreira de entrada não muda: GGUF Q4_0 é o formato mais universal, carregado diretamente pelo llama.cpp e por qualquer runtime compatível com Q4_0, sem mudar código, sem novos operadores. É também por isso que se escolhe esse formato em vez de um formato customizado — a própria compatibilidade já é uma forma de capacidade de distribuição.
Fontes: blog oficial da Liquid AI, CocoLoop, página do modelo no Hugging Face; os percentuais de recuperação de precisão dos quatro tamanhos e as duas faixas de velocidade foram verificados de acordo com os dados divulgados oficialmente.