LFM3-1.7B no Ollama: Um comando e um boletim de avaliação que se divide em dois

No momento em que escrevo, a página do Ollama para o lfm3 estava no ar havia cerca de uma hora e havia registrado 45 downloads. Esse é todo o seu uso público até agora. O modelo por trás dela, LiquidAI/LFM3-1.7B, foi anunciado um dia antes, em 27 de outubro de 2026, como o membro de texto da família LFM3, construída a partir do LFM3-1.7B-Base backbone — ao lado dos modelos de visão, áudio, omni e dos dois modelos de decisão que a Liquid AI lançou no mesmo lote. O que mudou em 28 de outubro não é o modelo. É a entrega: ollama run lfm3 substitui a busca por uma build do llama.cpp compatível com o LFM3, que era o caminho no dia do lançamento.

O motivo que vale mais do que uma linha de changelog é a tabela de benchmarks. O LFM3-1.7B apresenta um dos placares mais desequilibrados da classe de modelos pequenos: supera o Qwen3.5-9B — um modelo mais de cinco vezes maior — em automação de navegador, chamada de ferramentas e seguimento de instruções, e perde para ele por dois dígitos em conhecimento geral e recuperação em contexto longo. Todos os números dessa tabela são da própria Liquid AI. Nada disso foi reproduzido de forma independente até o momento.

O que realmente mudou em 28 de outubro

O Ollama lista cinco tags para o lfm3, todas registradas dentro da mesma hora, todas com uma linha de contexto de 256K e entrada somente de texto. O padrão é o que a maioria das pessoas vai baixar.

• lfm3:latest e lfm3:1.7b — 1,7 GB, o artefato padrão da classe Q4 e o mesmo digest sob os dois nomes

• lfm3:1.7b-mlx-bf16 — 3,5 GB, MLX de precisão total para Apple silicon

• lfm3:1.7b-mxfp8 — 2,1 GB, MLX de 8 bits

• lfm3:1.7b-nvfp4 — 1,7 GB, e este é o que deve ser lido com atenção

Essa última tag carrega o digest 2012d88e202f — o mesmo artefato por trás de :latest. Baixar lfm3:1.7b-nvfp4 pelo Ollama não obtém o checkpoint NVFP4; o verdadeiro é um repositório separado no Hugging Face, publicado para servir em GPU em vez de pull local. Se a tag é um placeholder ou um erro de publicação não é algo que a página do Ollama documente. Os digests são verificáveis e são idênticos, que é a parte que importa se você contava com economias de memória FP4 em um laptop.

A própria página do Ollama não é um upload da comunidade. O model card da Liquid AI lista o Ollama como um dos mecanismos GGUF suportados, ao lado de llama.cpp e LM Studio, portanto este é o caminho especificado pelo fornecedor chegando atrasado, e não uma build de um desconhecido. O texto do model card na página é da própria Liquid: "O LFM3-1.7B é um modelo tri-híbrido para agentes locais e aplicações especializadas."

A arquitetura, nos termos que determinam se ela se encaixa

O LFM3-1.7B tem 1,73 bilhão de parâmetros em 24 camadas, e apenas seis dessas camadas fazem atenção completa. Treze são convoluções curtas com gating e tamanho de kernel sete, contra três na geração anterior, e cinco são atenção de janela deslizante com uma janela de 256 tokens. A maioria dos tokens em um prompt longo nunca chega a uma matriz de atenção global, e é daí que vem a questão da memória.

A Liquid coloca um cache KV de 128K tokens em 1,6 GB. O mesmo valor para o Qwen3.5-4B é 4,3 GB e, para o MiniCPM5-2B, é 5,6 GB. Essa diferença, e não a contagem de parâmetros, é o motivo pelo qual um modelo de 1,7B consegue manter um contexto longo em hardware no qual um modelo de 4B não consegue. Vale a pena reter outros dois números: 22T tokens de pré-treinamento e uma etapa final de treinamento intermediário de 3,5T tokens, com peso maior para traços agênticos e chamadas de ferramentas. Essa última etapa é a explicação mais clara para tudo nas próximas duas seções.

A ficha também lista 16 idiomas, um vocabulário de 128K compartilhado com o LFM2.5-8B-A1B e o raciocínio ativado por padrão — o Ollama o expõe como uma tag de capacidade, não como uma flag oculta. O contexto de 256K é real no sentido de configuração, mas a ficha publica o valor de KV somente em 128K; no 256K completo, o cache escala com a janela, então trate o topo dessa faixa como uma configuração de datacenter, e não de laptop.

Onde as pontuações são fortes

O padrão é consistente em todas as tarefas que recompensam fazer algo com uma ferramenta em vez de saber algo sobre o mundo. Estes são números divulgados pelo fornecedor, e os comparadores são os que a Liquid AI escolheu.

• WebArena-Verified — 38,42 para LFM3-1.7B, 3,02 para LFM2.5-2.6B e 28,94 para Qwen3.5-9B

• AutomationBench — 41,29, contra 0,94 do LFM2.5-2.6B e 15,10 do Qwen3.5-9B

• Chamada de ferramentas do BFCL V4 — 71,39, contra 55,89 e 62,83 para os mesmos dois

• IFBench — 73,03, contra 48,84 do Qwen3.5-9B

• IFEval — 96,66, o mais alto na tabela da Liquid

• LiveCodeBench v6 — 73.46, à frente dos 69.86 do Qwen3.5-9B

A linha mais interessante não é a maior. AA-Omniscience é um benchmark pontuado em parte por se um modelo se recusa a responder em vez de chutar, e o LFM3-1.7B registra 92,93 em não alucinação, contra 52,59 do Qwen3.5-9B. Sua acurácia no mesmo conjunto é 7,07. Lidos em conjunto, esses dois números descrevem um modelo que na maioria das vezes diz que não sabe — o que é uma propriedade subestimada em um agente prestes a tomar uma ação, e ruim em um assistente do qual se espera que responda a perguntas.

Onde perde, às vezes gravemente

A mesma tabela, lida no sentido inverso.

• GPQA Diamond — 63,37, contra 80,40 do Qwen3.5-9B e 65,15 do MiniCPM5-2B, um modelo de 2B que o supera

• Humanity's Last Exam, sem ferramentas — 7.17, contra 16.41 do Qwen3.5-9B

• RULER 128K — 65,56, em comparação com 84,63 do Qwen3.5-4B e 87,11 do Qwen3.5-9B

• Raciocínio de contexto longo AA-LCR — 52,83, contra 62,00 do Qwen3.5-9B

• MCP-Atlas — 32,57, contra 41,37 do Qwen3.5-4B e 42,67 do Qwen3.5-9B

• SWE-bench Verified — 43,40, contra 51,20 do Qwen3.5-9B

• Terminal-Bench 2.1 — 12,92, em comparação com 17,98 do Qwen3.5-9B

A linha RULER merece uma frase própria: o modelo cuja especificação de destaque é uma janela de 256K é o recuperador de contexto longo mais fraco na sua própria tabela de comparação, superado por modelos que anunciam um quarto disso. Uma janela longa e a capacidade de encontrar algo nela são habilidades separadas, e o LFM3-1.7B comprou a primeira sem a segunda. Qualquer pessoa que planeje apontá-lo para um repositório grande ou um contrato longo deve testar essa linha antes de confiar na ficha técnica.

MCP-Atlas e o par SWE-bench são a mesma lição em um registro diferente. O LFM3-1.7B é bom em operar uma única ferramenta com um contrato claro. Ele está atrás no trabalho de múltiplas etapas e múltiplas ferramentas para o qual os frameworks de agentes são de fato construídos, e ainda mais atrás quando o trabalho exige saber o que uma base de código faz.

O que estes números são e o que não são

Todos os números acima vêm da própria execução de avaliação da Liquid AI, publicada junto com o lançamento. A metodologia não está no anúncio: nenhuma configuração de harness por teste, nenhuma declaração de quantas tentativas foram usadas na média, nenhuma indicação de se os modelos comparadores foram executados pela Liquid ou citados de seus próprios cards. Uma tabela de 27 linhas com um único responsável é um argumento, não uma medição.

Não há nenhuma entrada do LFM3-1.7B no Artificial Analysis em 28 de outubro, portanto não há nenhum número de terceiros para comparar com o do fornecedor. Isso vai mudar, e quando mudar, a comparação mais informativa serão as linhas agênticas, onde as margens do fornecedor são mais amplas e, portanto, mais precisam de uma segunda opinião.

Um detalhe aponta na direção oposta e merece crédito. A Liquid treinou um checkpoint de destilação ciente de quantização especificamente para recuperar a precisão que a quantização Q4_0 custa, e o disponibiliza como um arquivo GGUF separado. Publicar os números dos modelos pequenos na precisão que as pessoas realmente vão usar é mais do que a maioria dos fornecedores faz, e torna os números de 4 bits um pouco mais confiáveis do que uma quantização pós-hoc tornaria.

Executando-o, e as configurações que importam

O comando de uma linha é ollama run lfm3, e o padrão de 1,7 GB é o ponto de partida certo em uma máquina de 16 GB. A página também traz quatro lançadores de uma linha que conectam o modelo a um harness de agente existente — ollama launch claude --model lfm3, e o mesmo padrão para OpenCode, Hermes Agent e OpenClaw. Essa é a coisa mais útil da página: significa que o modelo pode ser inserido em um loop de agente que você já executa sem escrever um cliente, o que representa uma barreira menor do que a maioria dos lançamentos de modelos locais consegue superar.

Há dois perfis de amostragem no cartão e eles não são intercambiáveis: temperatura 0,1 com top_k 50 e penalidade de repetição 1,1 para chat, uso de ferramentas, agentes e programação; temperatura 1,0 com top_p 0,95 e top_k 20 para matemática e ciência. Executar o perfil de agente em um problema de matemática é a forma mais comum de fazer este modelo parecer pior do que é.

Se estiver a obter o GGUF diretamente em vez de através do Ollama, os tamanhos dos ficheiros organizam-se de forma útil. O checkpoint QAD Q4_0 tem 1,05 GB, ligeiramente menor do que o Q4_K_M com 1,1 GB, e é o treinado para sobreviver à quantização. O Q6_K tem 1,43 GB e o Q8_0 tem 1,85 GB se houver margem; o BF16 tem 3,47 GB e raramente vale a pena neste tamanho.

A licença é a LFM Open License v1.0 — essencialmente Apache 2.0, com um acréscimo: o uso comercial é gratuito abaixo de US$ 10 milhões em receita anual e exige uma licença paga a partir desse valor. O limite é agregado em todo um grupo empresarial e acompanha os fine-tunes, de modo que um derivado renomeado não escapa a ele. Organizações sem fins lucrativos e usuários de pesquisa estão isentos independentemente da receita. Se você estiver perto dessa linha, leia o texto da licença em vez de um resumo, incluindo este.

O que o perfil split significa para a forma como você o implanta

Um modelo que é forte em seguir instruções e em contratos de ferramentas, fraco em conhecimento paramétrico e recuperação de contexto longo, e barato o suficiente para rodar em um laptop não é um assistente de propósito geral. É um executor. A arquitetura que se adequa a ele é um loop local — o modelo decide qual ferramenta chamar, formata os argumentos, segue o esquema — com as etapas intensivas em conhecimento e genuinamente de contexto longo entregues a algo maior.

Essa divisão é o caso em que um roteador justifica seu lugar, e vale ser preciso sobre o que o OrcaRouter cobre e não cobre aqui. O LFM3-1.7B tem pesos abertos e roda no seu próprio hardware; ele não está no nosso catálogo, e nada neste texto é uma defesa de API para ele. O que fornecemos é a outra metade da divisão: uma chave para mais de 200 modelos hospedados para a etapa de escalonamento, com 0% de acréscimo sobre os preços de tabela dos provedores, failover automático quando um provedor degrada, e uma DSL de roteamento que compõe vários modelos em uma única chamada. A versão prática é que o modelo local continua sendo o padrão para o loop, e as chamadas que precisam de conhecimento real saem por um único endpoint em vez de um segundo SDK e um segundo contrato.

Se você está avaliando o modelo em vez de implantá-lo, o failover é a maneira mais barata de descobrir se ele se sustenta: encaminhe uma parte do tráfego para ele, mantenha o fallback configurado e compare nas suas próprias tarefas em vez da tabela da Liquid AI.

Questões que o lançamento deixa em aberto

A build do Ollama é a mesma coisa que o GGUF do Hugging Face?

Não exatamente. O padrão de 1,7 GB do Ollama é da classe Q4 e corresponde ao GGUF genérico, e não ao checkpoint com reconhecimento de quantização, que é um arquivo separado de 1,05 GB no Hugging Face treinado para recuperar a precisão do Q4_0. A tag nvfp4 resolve para o mesmo digest que :latest, portanto não é a build NVFP4, apesar do nome. Se a qualidade da quantização importa para sua tarefa, baixe o arquivo QAD e execute-o diretamente pelo llama.cpp.

Um laptop pode usar a janela completa de 256K?

Raramente. O valor de cache de 1,6 GB que a Liquid publica é para 128K, e a memória de cache escala com a janela, então os 256K completos precisam de aproximadamente o dobro disso antes de contar os pesos e o runtime. Em uma máquina de 16 GB, um contexto de trabalho na faixa de 32K a 64K é o teto realista; a janela maior é melhor interpretada como uma alegação de folga para implantações em servidor do que como uma capacidade de notebook.

Por que as pontuações dos agentes e as pontuações de conhecimento divergem tanto?

Porque eles estão medindo coisas diferentes, e o treinamento favoreceu uma delas. A etapa final de mid-training de 3,5T tokens enfatizou traços agênticos e chamadas de ferramentas, e então o pós-treinamento adicionou ajuste fino supervisionado em 1,75T tokens e aprendizado por reforço em uso de ferramentas e saída estruturada. Conhecimento paramétrico é o que um modelo de 1,7B tem menos espaço para armazenar, e a divisão do AA-Omniscience — 7,07 de acurácia contra 92,93 de não alucinação — sugere que ele foi treinado para recusar em vez de adivinhar. Essa é uma escolha de design, e é a escolha certa para um agente.

O veredito

LFM3-1.7B é o primeiro modelo nesta faixa de tamanho em que as linhas de benchmark agêntico são o motivo para baixá-lo, e não uma nota de rodapé. Se você está construindo um agente local que precisa chamar ferramentas de forma confiável, seguir um esquema e abster-se em vez de inventar uma resposta, agora ele está a um comando de distância e o perfil se encaixa na tarefa. Se você precisa de um modelo que saiba coisas, recupere informações de um documento longo com precisão ou resolva uma tarefa de engenharia em várias etapas, a tabela diz claramente que você deve procurar em outro lugar — e a especificação de 256K é a linha menos confiável dela.

O número a observar não é a média de 49,37. É se uma execução independente reproduz as margens agênticas, porque são essas as linhas em que um modelo de 1,7B alega superar um de 9B e em que o harness do próprio fornecedor tem mais espaço para favorecer.