LFM3-1.7B-Base vs LFM2.5-2.6B-Base: Menos parâmetros, menos tokens, mais contexto

A aritmética vai na direção errada. LFM3-1.7B-Base, publicado em 26 de outubro de 2026, é 36% menor que LFM2.5-2.6B-Base, que a Liquid AI lançou em 4 de agosto de 2026 — 1,73 bilhão de parâmetros contra 2,69 bilhões. Também foi treinado com menos tokens: 22 trilhões contra cerca de 34 trilhões. Pelos dois números que a indústria costuma usar para classificar modelos pré-treinados, o checkpoint mais novo deveria ser pior. A afirmação da Liquid é o oposto, pelo menos para o modelo pós-treinado construído sobre ele, e a pergunta interessante para quem está escolhendo um tronco para ajuste fino é qual dessas diferenças é real e qual é uma história contada com um conjunto de benchmarks. Executar a comparação deveria custar computação, não um segundo contrato. 0% de markup O OrcaRouter repassa os preços de tabela dos provedores com 0% de markup.

Trata-se de uma comparação dentro de uma mesma família, o que a torna excepcionalmente limpa. Mesmo fornecedor, mesma família de licenças, mesmo vocabulário de 128.000 tokens, mesmo tamanho oculto de 2.048, mesmo papel de base para base. Os dois checkpoints diferem em arquitetura, volume de dados, comprimento de contexto e na quantidade de pós-treinamento incorporada ao tronco. Quase todo o resto é mantido constante.

O delta, dimensão por dimensão

• Parâmetros — 1,73B para o LFM3-1.7B-Base contra 2,69B para o LFM2.5-2.6B-Base. Uma redução de 35,7%, que é de onde vem a frase "35% menos parâmetros" no post de lançamento da Liquid.

• Camadas — 24 contra 30. O modelo mais novo é mais raso e também mais estreito.

• Composição de camadas — treze convoluções curtas com gate, cinco blocos de atenção de janela deslizante e seis blocos de atenção completa para o LFM3; vinte e duas convoluções e oito blocos de atenção completa para o LFM2.5, sem nível de janela deslizante.

• Atenção — dezesseis cabeças de consulta e quatro cabeças de chave-valor no LFM3, contra trinta e duas e oito no LFM2.5. Ambos mantêm a dimensão de cabeça 128 e o tamanho oculto 2.048.

• Largura feed-forward — 7.680 para o LFM3 contra 10.752 para o LFM2.5. É aqui que está, na verdade, a maior parte da redução de parâmetros.

• Cache de convolução — sete para o LFM3 em comparação com três para o LFM2.5, com uma janela deslizante de 256 tokens adicionada.

• Contexto — 262.144 tokens contra 128.000. O checkpoint mais recente dobra esse valor.

• Tokens de pré-treinamento — 22 trilhões contra aproximadamente 34 trilhões, com os últimos 3,5 trilhões da execução mais recente dedicados a dados curados de mid-training, incluindo traços agênticos e chamadas de ferramentas.

• Artefatos — O LFM3-1.7B-Base é distribuído apenas como safetensors BF16, com 3,46 GB. O LFM2.5-2.6B-Base é distribuído em Safetensors, além de builds GGUF, ONNX e MLX, roda em menos de 2,5 GB quantizado e é compatível com Transformers, vLLM, SGLang, llama.cpp e MLX.

Para onde foram os parâmetros

A redução não é distribuída uniformemente, e isso importa para quem estima o custo de fine-tuning. Os embeddings são vinculados em ambos os modelos e o vocabulário é idêntico em 128.000 tokens, então a matriz de embeddings permanece inalterada. O tamanho oculto permanece inalterado em 2.048. As economias vêm de três lugares: seis camadas a menos, metade do número de cabeças de atenção e um bloco feed-forward cerca de 29% mais estreito.

Estreitar o bloco feed-forward é a maneira mais barata de encolher um transformer, porque esse bloco concentra a maior parte dos parâmetros em cada camada. Reduzir pela metade as cabeças de atenção diminui o cache de chave-valor, bem como os pesos, e é por isso que um modelo com contexto dobrado ainda pode ser descrito como cabendo em cerca de 1 GB em 4 bits. O trade-off é capacidade: um MLP mais estreito tem menos espaço para armazenar associações factuais, e um número menor de cabeças dá ao modelo menos padrões de atenção independentes com que trabalhar. O argumento da Liquid é que dados melhores e uma combinação de camadas melhor compensam com folga. Esse argumento é testável e, até o momento da publicação, ninguém fora da empresa o havia testado.

De onde veio o contexto

Dobrar o contexto de 128K para 256K sem dobrar o custo de atenção exige abrir mão da atenção global. A pilha do LFM3 faz isso enviando cinco de suas vinte e quatro camadas para uma janela deslizante de 256 tokens e treze para convoluções, deixando apenas seis camadas que veem a sequência inteira. A configuração também traz um fator rotativo parcial de 0,5 nas camadas de atenção global, aplicando embeddings rotativos a metade das dimensões de cada cabeça, e um theta rotativo de um milhão nessas camadas contra dez mil nas deslizantes.

O post de lançamento da Liquid traz um número concreto para o que isso proporciona: com 128K tokens, o cache KV do modelo de texto é de 1,6 GB. Para o LFM2.5-2.6B-Base, nenhum valor equivalente é publicado. A comparação é, portanto, indicativa e não exata — a arquitetura mais recente foi projetada para sustentar um contexto mais longo com menos memória, e o número divulgado pelo próprio fornecedor é a única medição disponível.

Por que menos tokens é a afirmação interessante

Trinta e quatro trilhões de tokens reduzidos para vinte e dois trilhões representam uma redução de 35% no poder computacional de pré-treinamento no nível dos dados, e é a direção oposta à da maioria das gerações de modelos. A história usual é mais dados, mais parâmetros, melhor modelo. A história da Liquid é menos dos dois, com uma nova arquitetura e uma mistura de dados que acrescenta artigos científicos, código em nível de repositório, matemática e uma distribuição mais ampla de fontes de conhecimento.

A etapa de mid-training de 3,5 trilhões de tokens é o que distingue este checkpoint de um pré-treinamento convencional. Ela usa dados curados e de maior qualidade, com uma proporção maior de traços agênticos e chamadas de ferramentas, e é onde a janela de contexto é estendida. Essa etapa também é o motivo pelo qual o modelo base possui um template de chat: os dados de mid-training foram formatados como conversas, com e sem traços de pensamento.

Nada disso pode ser verificado de fora. As contagens de tokens são autorrelatadas, as misturas de dados não são publicadas e não há ablação mostrando qual mudança produziu qual ganho. A alegação é plausível — a qualidade dos dados tem repetidamente superado o volume bruto nos últimos dois anos —, mas plausível não é medido.

O que uma comparação base a base pode resolver

Ela pode esclarecer especificações, custo e compatibilidade, e esta página faz isso. Não pode esclarecer a qualidade, porque nenhum dos checkpoints tem um benchmark publicado. A Liquid não publicou nenhuma avaliação para o LFM2.5-2.6B-Base e também não publicou nenhuma para o LFM3-1.7B-Base. Ambos os cards recomendam o checkpoint para ajuste fino extensivo e remetem os leitores a outro lugar para chat.

A única evidência de qualidade na família é o par pós-treinado. A Liquid relata o LFM3-1.7B com uma média de 49,37 na sua própria suite, contra 31,55 do LFM2.5-2.6B, com o modelo mais recente a usar 35% menos parâmetros. É uma diferença grande, e é um valor do fabricante medido numa suite escolhida pelo fabricante, comparando dois modelos que diferem tanto no pós-treinamento como no tronco. É evidência de que a receita do LFM3 produz um modelo instruct melhor. Não é evidência de que o checkpoint base seja um ponto de partida melhor, porque o pós-treinamento aplicado sobre ele pode ser responsável por toda a diferença.

Notas de migração para quem usa o LFM2.5

Os dois checkpoints compartilham um tamanho de vocabulário, um tamanho oculto e uma família de tokenizadores, o que faz a migração parecer mais fácil do que é. Eles não compartilham código de modelagem: o LFM2.5 carrega como Lfm2ForCausalLM e o LFM3 como Lfm3ForCausalLM, ambos por meio de código personalizado com trust_remote_code=True. Um script de treinamento escrito para um não carregará o outro sem alterar a classe do modelo, e os templates de chat são diferentes no tratamento dos rastros de pensamento.

A maior diferença operacional é o empacotamento. O LFM2.5-2.6B-Base tem builds GGUF, ONNX e MLX e roda em llama.cpp, vLLM, SGLang, Transformers e MLX. O LFM3-1.7B-Base é distribuído como um único arquivo BF16 safetensors; as builds quantizadas e multiplataforma existem para o LFM3-1.7B pós-treinado, não para o checkpoint base. Se seu pipeline depende de um artefato GGUF, você mesmo o está convertendo e validando o resultado.

O suporte a fine-tuning é o contrapeso. O LFM3-1.7B-Base remete a notebooks do TRL para fine-tuning supervisionado e pré-treinamento contínuo, e a documentação cobre o caminho a partir daí. O checkpoint menor, o contexto de 256K e o mid-training agêntico visam exatamente o tipo de adaptação de domínio que esses notebooks demonstram.

Qual trunk usar como ponto de partida

Comece a partir do LFM3-1.7B-Base se você estiver iniciando um novo ajuste fino, sua tarefa se beneficiar de contexto longo e você puder trabalhar em BF16 com Transformers ou converter os pesos você mesmo. A redução de 35% nos parâmetros é dinheiro de verdade em uma execução de treinamento em uma única GPU, o contexto dobrado é uma mudança genuína de capacidade, e o template de chat encurta a fase supervisionada.

Continue no LFM2.5-2.6B-Base se você já tem um pipeline funcionando, depende de um artefato GGUF ou ONNX, ou precisa de um checkpoint com um ano de ferramentas da comunidade por trás. O modelo mais novo tem três dias. O modelo irmão instruct tem builds quantizados e suporte desde o primeiro dia em vLLM, SGLang, llama.cpp, Ollama, LM Studio, MLX e ONNX Runtime, mas o checkpoint base não tem, e essa lacuna é o custo prático de chegar cedo.

Se você não tiver certeza, faça o experimento em vez de ler o material de marketing.Pegue uma pequena amostra dos seus próprios dados, rode a mesma receita de pré-treinamento continuado nos dois troncos pelo mesmo número de etapas e avalie em um conjunto reservado que você montou antes de começar. São algumas horas de GPU e isso responde a uma pergunta que nenhuma tabela de fornecedor consegue responder. Quando os dois fine-tunes existirem, coloque ambos atrás de um único endpoint: o OrcaRouter tem uma DSL de roteamento capaz de dividir o tráfego entre eles, e o failover automático significa que um experimento ruim não vira um dia ruim de produção. A plataforma repassa os preços de tabela dos provedores com 0% de markup, então o custo de rodar o teste é o custo da computação, e não um segundo contrato.

O número a acompanhar

A afirmação que resolveria isso não é outra média. É uma avaliação de modelo base — qualquer avaliação de modelo base — publicada pela Liquid ou por terceiros, comparando LFM3-1.7B-Base e LFM2.5-2.6B-Base após uma receita de fine-tuning idêntica. Até que isso exista, o delta geracional está documentado na arquitetura e na configuração, é plausível nas contagens de tokens e não comprovado onde importa. O checkpoint mais recente é menor, tem contexto mais longo e está melhor empacotado para treinamento. Se ele é melhor é uma questão que o repositório não responde.