LFM3-1.7B vs Granite 4.2 30B: Dois modelos de agente que dividem o veredito por eixo

Coloque LFM3-1.7B e Granite 4.2 30B na mesma página e as médias agregadas apontam em direções opostas dependendo da linha que você lê. No Berkeley Function Calling Leaderboard V4, o modelo de 1,73 bilhão de parâmetros da Liquid AI marca 71,39 contra 61,39 da IBM — uma vitória de dez pontos para um modelo aproximadamente dezessete vezes menor. No SWE-bench Verified, o Granite marca 57,00 contra 43,40 do LFM3-1.7B, uma vitória de 13,6 pontos na direção oposta. O roteamento não adiciona margem ao preço de lista de um provedor. Os preços de lista dos provedores são repassados com 0% de markup.

Ambos os modelos são feitos para agentes, ambos foram lançados com menos de dois meses de diferença em 2026, e ambos os fornecedores publicam benchmarks sobrepostos suficientes para que uma comparação real seja possível, em vez de uma colagem. Isso faz deste um confronto raro em que a pergunta interessante não é qual modelo é melhor, mas em qual eixo sua carga de trabalho realmente se situa. Pouquíssimas tarefas precisam tanto de uma pontuação 71 no BFCL quanto de uma pontuação 57 no SWE-bench, e as que precisam não são bem atendidas por nenhum dos modelos isoladamente.

Os dois números que se cruzam

O Granite 4.2 30B foi lançado em 25 de agosto de 2026 sob a Apache 2.0, um modelo denso de ~30B construído sobre a base do Granite 4.1 30B e treinado com cerca de 15 trilhões de tokens. O enquadramento da IBM é empresarial: três modos de raciocínio configuráveis, chamada nativa de ferramentas conforme o esquema da OpenAI, doze idiomas testados e um pipeline de treinamento em três estágios que termina em aprendizado por reforço GRPO multifásico.

O LFM3-1.7B chegou dois meses depois, anunciado em 27 de outubro de 2026, pós-treinado especificamente em harnesses agênticos — a Liquid cita Hermes Agent, PI e OpenClaw na ficha do modelo. É um modelo denso de 1,73B com contexto de 256K, e é posicionado explicitamente para agentes locais e chamada de ferramentas, em vez de raciocínio geral.

O cruzamento de benchmarks não é acidente de um único número fraco. Toda a tabela publicada do LFM3-1.7B pende para o lado agêntico: 71,39 BFCL V4, 80,36 ToolSandbox, 68,01 τ³-bench, 45,60 LiveClaw, 38,42 WebArena-Verified. A tabela do Granite pende para engenharia: 57,00 SWE-bench Verified, 33,29 SWE-bench Pro, 41,89 SWE-bench Multilingual, 38,76 SciCode, 29,24 no TerminalBench 2.1. Cada fornecedor otimizou para uma definição diferente de "agente", e as tabelas de benchmarks são honestas quanto a qual delas.

τ³ em 68,01 contra 68,05 é a verdadeira manchete

Por baixo das duas diferenças dramáticas, há um empate técnico. No τ³-bench, a avaliação de uso de ferramentas que mede a conclusão de tarefas em múltiplos turnos com simuladores de usuário e políticas de domínio, o LFM3-1.7B obtém 68,01 e o Granite 4.2 30B obtém 68,05 — uma diferença de quatro centésimos de ponto, indistinguível de ruído.

Esse é um resultado mais interessante do que qualquer uma das grandes lacunas, porque τ³ é o benchmark mais próximo do que a maioria das implantações de agentes realmente faz: manter uma conversa, seguir uma política, chamar a função certa, recuperar-se de um erro. Se um modelo de 1,73B empata com um modelo denso de 30B nesse quesito, a contagem de parâmetros está comprando algo além de uso competente de ferramentas em múltiplos turnos.

O que isso proporciona aparece no BFCL e no SWE-bench, que medem coisas diferentes. O BFCL V4 testa a correção de chamadas de função de turno único em relação a um esquema — o 71,39 do LFM3-1.7B sugere que o pós-treinamento da Liquid em harnesses de agentes reais deu retorno direto. O SWE-bench Verified testa a correção de uma issue real do GitHub de ponta a ponta, o que exige manter um repositório no contexto, planejar entre arquivos e produzir um patch que passe nos testes — o 57,00 do Granite reflete um modelo com capacidade para fazer isso e um conjunto de treinamento criado para isso.

Então a divisão é legível. Modelo pequeno, bem treinado em esquemas de ferramentas: vence o teste de chamada de função. Modelo grande, treinado em reparo de código: vence o teste de repositório. Empate no meio-termo de múltiplos turnos, onde ambos foram especificamente treinados.

O contexto é onde as especificações divergem de forma mais acentuada.

• Contexto — 262,144 tokens para o LFM3-1.7B; 128K nativos para o Granite 4.2 30B, extensível até 512K. A extensão não é gratuita, e a IBM é honesta ao afirmar que se trata de uma extensão, e não de uma janela nativa.

• Retenção de contexto longo — 65,56 no RULER a 128K para o LFM3-1.7B, contra 81,4 do Granite 4.2 30B na mesma família de benchmarks. O modelo maior retém mais de um documento longo, o que é o oposto do que os números de contexto divulgados sugerem.

• Pegada — cerca de 1 GB em 4 bits, contra aproximadamente 30B de pesos BF16, com builds oficiais FP8, NVFP4 e MXFP4. Este é um modelo para uma única GPU, não um modelo para laptop.

• Idiomas — dezesseis para o LFM3-1.7B contra doze testados para o Granite, com uma sobreposição diferente. Os doze do Granite incluem tcheco e holandês; os da Liquid incluem tailandês, vietnamita e indonésio.

• Modos de pensamento — O Granite 4.2 30B é fornecido com os modos completo, de baixo esforço e sem pensamento. O LFM3-1.7B não tem essa funcionalidade, e sua ficha indica que ele não foi concebido para raciocínio complexo de múltiplas etapas, desde o início.

• Licença — Apache 2.0 para o Granite contra a LFM Open License v1.0, que é gratuita abaixo de US$ 10 milhões em receita anual e exige uma licença comercial acima desse valor.

Que custos um 30B denso tem que um 1.73B não tem

O Granite 4.2 30B é denso, o que significa que todos os trinta bilhões de parâmetros são processados a cada token. Não há desconto de parâmetros ativos aqui: o custo computacional por token é cerca de dezessete vezes o do modelo pequeno, e o custo de memória é o arquivo de pesos completo. A IBM fornece quantizações para tornar isso viável, mas não há configuração em que ele rode em um telefone.

A vantagem do LFM3-1.7B não está principalmente na velocidade. Está no fato de o modelo caber no mesmo orçamento de memória que o restante da sua aplicação. Um modelo de 1 GB deixa espaço para um armazenamento de documentos, um cache e um segundo modelo no mesmo dispositivo — o que torna possível um agente local, em vez de meramente teórico local. A Liquid relata decodificação de 1,8 a 2,8 vezes mais rápida que seus antecessores em hardware testado e um cache KV de 1,6 GB a 128K, ambos relevantes para um agente no dispositivo mantendo uma conversa longa.

O contrapeso é que a capacidade de 30B do Granite está fazendo trabalho de verdade nos números do SWE-bench. Se o trabalho do seu agente é alterar código em um repositório, a diferença de 13,6 pontos não é algo que um modelo menor recupera por meio de prompting, e a economia de computação compra um resultado pior.

Licenciamento, assinatura e a questão da aquisição

O Apache 2.0 é o motivo pelo qual uma grande organização pode adotar o Granite 4.2 30B sem uma revisão jurídica. Não há limite de receita, nenhum gatilho comercial, nenhuma negociação. A IBM também vem assinando criptograficamente os modelos Granite lançados desde abril de 2026, o que parece um detalhe até você ser a pessoa que precisa provar que os pesos em produção são os pesos que foram avaliados.

A Liquid's LFM Open License v1.0 é genuinamente permissiva na escala de uma startup — gratuita para uso comercial abaixo de US$ 10 milhões em receita anual —, mas acima desse limite exige uma licença comercial paga. Para um desenvolvedor individual ou uma equipe pequena, isso não é problema. Para uma unidade de negócios dentro de uma empresa maior, é uma conversa que começa antes da primeira implantação e pode não terminar rapidamente. Essa assimetria não aparece em nenhum benchmark e, muitas vezes, decide a questão por si só.

Rodando os dois sem apostar em nenhum deles

O padrão prático para uma equipe que avalia esses dois não é escolher um primeiro. Ambos são de pesos abertos e ambos não têm comprovação por avaliadores independentes, o que significa que o único benchmark que importa é o seu próprio. Roteie os modelos candidatos por um único endpoint, execute os mesmos traces de agente pelos dois e compare na sua tarefa, em vez de no BFCL ou no SWE-bench.

O OrcaRouter é útil aqui menos como host do que como superfície de controle: uma única chave e uma única fatura para mais de 200 modelos, preços de lista dos provedores repassados com 0% de markup, e failover automático para que uma execução de avaliação não morra porque um provedor teve uma hora ruim. Nem o LFM3-1.7B nem o Granite 4.2 30B estão no nosso catálogo hoje — ambos são downloads de pesos abertos, e a auto-hospedagem é o caminho para cada um. Onde o roteamento ganha seu lugar é no stack ao redor: o modelo de fronteira para o qual seu agente escala, ou a segunda opinião com que você compara quando o patch do modelo local falha nos testes.

Quem deve levar qual

Escolha o LFM3-1.7B se o agente roda no dispositivo do usuário, se o trabalho é chamada de ferramentas e extração estruturada contra uma API, e se um contexto de 256K com uma pegada de 1 GB é o que torna o produto possível. Aceite o próprio aviso do fornecedor de que ele não é para codificação agêntica e mantenha um modelo maior por trás dele para os casos que precisam de um.

Escolha o Granite 4.2 30B se o agente mexe em uma base de código, se você precisa de Apache 2.0 e pesos assinados para fins de aquisição, se a carga de trabalho se beneficia de esforço de raciocínio configurável e se você tem uma GPU para servi-lo. O déficit no BFCL é real, mas restrito: ele mede a correção do esquema em uma única chamada, e um modelo de 30B com um esquema de ferramentas bem projetado fecha boa parte dessa lacuna na prática.

Adote a divisão se você está construindo o produto que ambos os fornecedores almejam — um agente local que lida com chamadas rotineiras de ferramentas em um gigabyte e escala trabalho de escala de repositório para um servidor. Essa arquitetura usa cada modelo onde sua própria tabela de benchmark indica que ele é forte, e é o único arranjo em que os eixos cruzados deixam de ser um problema.

A questão que vale acompanhar é se a receita de pós-treinamento agêntico do Liquid se transfere para um checkpoint maior. Se um futuro modelo LFM mantiver o comportamento de classe 71.39 no BFCL e adicionar capacidade para trabalho em repositórios, a divisão por eixos colapsa e esta comparação se torna uma decisão simples de tamanho. Até lá, os dois modelos não estão competindo pelo mesmo trabalho — são as duas metades de um só.