LFM3-1.7B-Base: O que o repositório diz e o que a Liquid AI não disse

O checkpoint de maior impacto na nova família da Liquid AI é aquele sobre o qual há menos a ler. LFM3-1.7B-Baseé um modelo pré-treinado apenas de texto com 1,73 bilhão de parâmetros e, em 27 de outubro de 2026, tornou-se o tronco a partir do qual todos os modelos LFM3 pós-treinados foram construídos — o modelo de texto, o de visão, o de áudio, o modelo omni e ambos os modelos de decisão. O post de lançamento da família o menciona em uma única frase. Não há anúncio independente para ele, nenhuma tabela de benchmarks de modelo base e nenhuma cobertura de imprensa voltada a ele. O repositório, por sua vez, é excepcionalmente explícito sobre o que é o checkpoint e para que serve, o que torna este um lançamento fácil de descrever e difícil de superestimar. Nenhum acréscimo é aplicado ao valor cobrado pelo provedor do modelo. Preços de tabela do provedor Uma alteração de preço do fornecedor chega à sua fatura no mesmo dia.

O que segue separa essas duas coisas. Tudo na primeira metade vem do cartão do modelo, do arquivo de configuração, do texto da licença ou do próprio post de lançamento da Liquid, e é verificável hoje. A segunda metade é o que permanece genuinamente desconhecido três dias depois que os pesos foram disponibilizados.

Dois repositórios, um post de lançamento e um intervalo de doze horas

Os carimbos de data e hora contam a história de um lançamento que aconteceu em público antes de acontecer no marketing. O repositório pós-treinado LFM3-1.7B foi criado em 23 de outubro de 2026. O repositório base foi criado em 26 de outubro às 16:28 UTC, e seu card foi modificado pela última vez em 27 de outubro às 04:15 UTC — menos de doze horas depois. A postagem do blog, "Apresentando o LFM3: Todas as modalidades para inteligência especializada", é datada de 27 de outubro. Quando qualquer pessoa fora da empresa pôde ler uma especificação, os pesos já estavam no Hugging Face havia um dia.

Vale dizer essa ordem com clareza, porque é a coisa mais próxima de um “lançamento discreto” aqui. A Liquid anunciou a família, e o anúncio nomeia o LFM3-1.7B-Base como o checkpoint a partir do qual os outros seis modelos foram treinados. O que a empresa não fez foi anunciar o checkpoint base por conta própria — nenhum post separado, nenhuma avaliação específica da base, nenhum posicionamento além de um parágrafo no card. A família recebeu o lançamento. O tronco recebeu um repositório e uma referência à família.

O que está no repositório

O card é compacto e, desta vez, completo nos itens básicos. Um único arquivo model.safetensors de 3,46 GB em bfloat16. Um tokenizador com vocabulário de 128.000 tokens. O código do modelo é fornecido como Python personalizado junto com os pesos, carregado com trust_remote_code=True em vez de por meio de uma versão mesclada upstream do Transformers. A licença é a LFM Open License v1.0, a mesma família de termos que a Liquid usa desde o LFM2.

• Parâmetros — 1,73B, denso, cada parâmetro lido em cada token.

• Camadas — 24: treze blocos de convolução curta com portão, cinco blocos de atenção de janela deslizante, seis blocos de atenção completa.

• Contexto — 262.144 tokens, entrada mais saída.

• Geometria de atenção — tamanho oculto 2.048, dezesseis cabeças de consulta, quatro cabeças de chave-valor, dimensão de cabeça 128. Isso é atenção de consulta agrupada de quatro para um, não de oito para um do LFM2.5.

• Janela local — 256 tokens, com um cache de convolução de sete. Esta é uma configuração de atenção por camada, não o comprimento do contexto, e causou uma pequena onda de relatos equivocados quando a arquitetura surgiu pela primeira vez em um pull request de engine no dia anterior ao lançamento.

• Vocabulários e idiomas — 128.000 tokens, dezesseis idiomas listados: inglês, árabe, chinês, francês, alemão, italiano, japonês, coreano, português, espanhol, vietnamita, tailandês, indonésio, híndi, russo, polonês.

• Memória — cerca de 1 GB em precisão de 4 bits segundo a Liquid, 3,46 GB conforme enviado em BF16.

Há uma pequena inconsistência que vale a pena conhecer antes de citar um tamanho. A barra lateral do Hugging Face arredonda o modelo para “2B parâmetros”, enquanto a tabela do card informa 1,73B. O arquivo resolve a questão: 3,46 GB de bfloat16 correspondem a 1,73 bilhão de parâmetros a dois bytes cada, portanto o rótulo da barra lateral é uma convenção de arredondamento, não uma segunda especificação. No momento em que escrevo, o repositório mostrava quinze downloads no último mês e oito curtidas — o perfil de um checkpoint que foi disponibilizado, recebeu link no post de lançamento e ainda não foi adotado por ninguém.

A arquitetura, sem o diagrama

O design é mais bem compreendido como um argumento de orçamento. A atenção completa é a parte cara de um transformer em contexto longo: cada token se compara com todos os outros tokens, e o custo cresce com o quadrado da sequência. A pilha tri-híbrida da Liquid dedica apenas seis de suas vinte e quatro camadas a essa operação. Treze camadas são convoluções curtas com gating, que misturam informações localmente a um custo fixo por token, e cinco são blocos de atenção de janela deslizante que veem 256 tokens por vez. Dois terços da rede não realizam nenhuma operação de atenção global.

Essa é a mesma aposta que a Liquid vem fazendo desde o LFM2, levada mais longe. O LFM2.5-2.6B-Base usava trinta camadas divididas em vinte e duas convoluções e oito blocos de atenção completa, sem nível de janela deslizante. O LFM3 substitui um par de convoluções por um bloco de atenção deslizante em cinco pontos da pilha, aumenta o cache de convolução de três para sete e adiciona as configurações de normalização sanduíche e de rotary parcial que aparecem na config. Se essa troca específica melhora a qualidade é uma pergunta que só a avaliação pode responder e, até a publicação, não há avaliação do modelo base para respondê-la. O que a config estabelece é que o contexto de 256K não é alcançado escalando a atenção para 256K; é alcançado mantendo a maior parte da pilha local.

O modelo base vem com um template de chat

Este é o detalhe com maior probabilidade de confundir qualquer pessoa que baixe o checkpoint esperando completude de texto bruta. O LFM3-1.7B-Base inclui um template de chat completo, e o card informa que o mid-training incluiu dados de chat com e sem traces de raciocínio, formatados com o mesmo template do modelo pós-treinado. Chame apply_chat_template e o raciocínio fica habilitado por padrão: a resposta começa dentro de um bloco de pensamento, a menos que você passe enable_thinking=False, que preenche um trace vazio e pede uma resposta direta.

Portanto, ele se comporta um pouco como um modelo instruct e está documentado como algo completamente diferente. A recomendação da própria ficha do modelo é inequívoca: o LFM3-1.7B-Base “é recomendado apenas para tarefas que exigem ajuste fino intenso, como assistentes específicos de idioma ou de domínio, treinamento com dados proprietários ou experimentação com novas abordagens de pós-treinamento”. Para chat, chamada de ferramentas e agentes, ela aponta para o LFM3-1.7B. O template está lá porque os dados de mid-training foram formatados dessa forma e porque um ajuste fino o herda — não porque o checkpoint foi ajustado para conversação. Qualquer pessoa que trate o template como um sinal de prontidão ficará decepcionada com as saídas, e a ficha do modelo diz isso antes mesmo de começarem.

Os números que as pessoas vão citar não são os números deste modelo.

O post de lançamento traz uma tabela substancial de benchmarks, e quase nada dela se aplica ao checkpoint sobre o qual este artigo trata. A média de destaque de 49,37 pertence ao LFM3-1.7B, o modelo pós-treinado, medida na própria suíte da Liquid. As linhas de comparação — LFM2.5-2.6B com 31,55, MiniCPM5-2B com 39,19, Gemma 4 E4B com 31,74, Qwen3.5-4B com 39,27, Qwen3.5-9B com 47,24 — são modelos pós-treinados comparados com modelos pós-treinados. Os 43,40 no SWE-bench Verified e os 73,46 no LiveCodeBench v6 também são pontuações do modelo ajustado.

Duas afirmações são associadas ao checkpoint base na leitura casual e não deveriam ser. A primeira é "35% menos parâmetros" — ou seja, o LFM3-1.7B superando o LFM2.5-2.6B, uma afirmação sobre o par pós-treinado, não um resultado base contra base. A segunda é a afirmação de que o LFM3 "iguala o Gemma 4 12B". Essa frase diz respeito ao LFM3-VL-2B, o modelo de visão, em 62 benchmarks de visão. Ela não diz nada sobre o checkpoint base de texto, que não tem nenhuma avaliação publicada. Um modelo base sem tabela de benchmarks não é incomum — a Liquid deliberadamente não publicou nenhuma para o LFM2.5-2.6B-Base também —, mas a ausência significa que toda alegação de qualidade sobre este checkpoint é, atualmente, uma alegação sobre o modelo que ele produziu.

Treinamento, e a parte que é realmente distintiva

O Liquid afirma que o checkpoint viu 22 trilhões de tokens em duas etapas. A principal etapa de pré-treinamento alterou a mistura de dados em relação ao LFM2, adicionando mais artigos científicos, código em nível de repositório, matemática e uma distribuição mais ampla de fontes de conhecimento. Os 3,5 trilhões de tokens finais são uma etapa de treinamento intermediário com dados curados e de maior qualidade, com uma proporção maior de traços agênticos e chamadas de ferramentas, e é nessa etapa que a janela de contexto é estendida para 256K.

A parte incomum não é a contagem de tokens; é que dados agênticos entraram no modelo base, e não apenas no pós-treinamento. A maioria dos fornecedores mantém rastros de chamadas de ferramentas para a etapa de ajuste de instruções. A Liquid os colocou no tronco e então pós-treinou seis modelos diferentes sobre ele com SFT, RL misto, destilação on-policy multidomínio e RL agêntico. Essa é uma estratégia coerente para uma família destinada a compartilhar um único backbone entre modalidades, e também é por isso que o checkpoint base carrega um template de chat. É uma alegação sobre metodologia de treinamento que não pode ser verificada de fora, e não existe reprodução independente.

O que você pode fazer com isso hoje

O card remete a dois notebooks TRL, um para ajuste fino supervisionado em extração de JSON estruturado de documentos desorganizados e outro para pré-treinamento continuado em um novo idioma, usando turco a partir de texto bruto como exemplo. Ambos foram escritos para o LFM3-1.7B e exigem alterar um único model_id para apontar para o checkpoint base. A página de documentação cobre o restante do caminho de ajuste fino. O modelo instruct tem um conjunto completo de variantes de runtime — BF16 para vLLM, SGLang e Transformers; FP8 e NVFP4 para SGLang; GGUF para llama.cpp, Ollama e LM Studio; MLX para Apple silicon; ONNX Runtime. O checkpoint base tem exatamente um artefato: o arquivo safetensors BF16. Sem GGUF, sem build MLX, sem versão quantizada. Se você quiser executá-lo em um celular, você mesmo fará essa conversão.

Onde isto se encaixa se você ganha a vida servindo modelos

Um checkpoint pré-treinado não é um endpoint de chat, e vale a pena ser concreto sobre isso. O LFM3-1.7B-Base não aparece no catálogo da OrcaRouter no momento em que escrevo, e um modelo base seria uma coisa estranha de rotear: ele não tem capacidade de seguir instruções para a qual rotear. O lugar útil para um roteador começa um passo depois, quando o fine-tune existe. A OrcaRouter coloca mais de 200 modelos por trás de uma única API com 0% de markup sobre os preços de tabela dos provedores, failover automático e uma DSL de roteamento, para que um checkpoint LFM3 ajustado ao domínio possa ficar ao lado de um modelo geral maior e ser comparado ou receber failover sem uma segunda integração. A fusão de modelos — um painel respondendo em conjunto — é a outra opção quando um especialista de 1.73B é bom em uma coisa e você precisa de uma segunda opinião. Nada disso exige que o próprio checkpoint base seja hospedado em qualquer lugar.

O que ainda não foi confirmado

• Qualidade base. Nenhuma tabela de benchmark, nenhuma saída do harness de avaliação, nenhuma comparação com o LFM2.5-2.6B-Base em qualquer tarefa.

• Verificação independente. Nenhum laboratório de terceiros publicou uma execução do modelo base ou do modelo ajustado. Todos os números no post de lançamento são da própria Liquid.

• Suporte a Transformers upstream. O repositório usa código de modelagem personalizado e trust_remote_code. Isso é normal no lançamento e um custo de manutenção depois.

• Como a base é disponibilizada. O post de lançamento diz que os modelos base e pós-treinados estão disponíveis no Hugging Face, no Liquid Playground e na Liquid API. Não se explica o que uma API faz com um checkpoint base não ajustado, e nenhum preço para isso é publicado.

• Casos limítrofes de licença. A LFM Open License v1.0 é gratuita para uso comercial abaixo de US$ 10 milhões em receita anual; acima desse limite, aplica-se uma licença comercial. O texto é público, mas como ele trata um modelo derivado treinado na base e depois disponibilizado comercialmente é uma questão para um advogado, não para uma ficha de modelo.

O que assistir

O próximo sinal significativo não é outro anúncio — é a primeira avaliação independente do modelo pós-treinado, e o primeiro fine-tune público que relata como era treinar a partir do checkpoint base. O próprio enquadramento da Liquid convida a esse teste: um tronco de 1,73B que gerou seis modelos e afirma superar um predecessor de 2,69B ou é uma arquitetura genuinamente eficiente, ou é um conjunto de benchmarks bem escolhido, e só execuções externas separarão as duas coisas. Até lá, o repositório é toda a história: um arquivo de 3,46 GB, uma especificação clara, um template de chat que não é um convite e uma licença que vale a pena ler antes que a linha de receita se aproxime.