ARTEMIS vs LFM2.5-2.6B-Base: o checkpoint que não consegue fazer o trabalho, e o harness que precisa que ele o faça

Quatro itens constam no roadmap do ARTEMIS do Google, e exatamente um deles exige um modelo que ainda não existe de forma óbvia: modelos leves de visão-linguagem no dispositivo, para automação de baixa latência e com privacidade em primeiro lugar. O candidato óbvio para uma tarefa dessas é algo na classe de tamanho do LFM2.5-2.6B-Base — o checkpoint pré-treinado de 2,69 bilhões de parâmetros da Liquid AI, publicado como pesos abertos com contexto de 131.072 tokens e uma pegada pequena o suficiente para um celular. Ele também, na forma como é distribuído, é incapaz de preencher essa lacuna, e as razões valem a pena ser compreendidas antes que alguém coloque os dois em uma tabela comparativa. O ARTEMIS do Google é uma estrutura de automação Android em linguagem natural, com código aberto sob a licença Apache 2.0 em agosto de 2026, que opera um aparelho real via ADB e alega uma taxa de conclusão de mais de 99% no benchmark AndroidWorld do Google Research. O LFM2.5-2.6B-Base é material pré-treinado bruto, sem ajuste por instruções, sem template de chat e — deliberadamente — sem benchmarks publicados, destinado a equipes que farão o pós-treinamento por conta própria. Um é software pronto com um problema de modelo não resolvido. O outro são pesos não prontos com um problema de licença resolvido. Nenhum dos dois substitui o outro, e o ponto onde eles realmente se encontram não é o ponto que você imagina.

O que o LFM2.5-2.6B-Base realmente é

Retire o branding e ele é uma base cuidadosamente construída para trabalho no próprio dispositivo, com especificações que parecem ter sido definidas por alguém que otimizou para largura de banda de memória, e não para posição no ranking.

• Tamanho — 2,69B de parâmetros em bfloat16 num único shard de ~5,39 GB, comercializado como "2,6B".

• Arquitetura — 30 camadas em uma divisão híbrida: 22 blocos de convolução curta com duplo portão sobre 8 camadas de atenção com consultas agrupadas, largura oculta 2048, 32 cabeças de atenção contra 8 cabeças KV, embeddings compartilhados. Mesma code>Lfm2ForCausalLM/code> classe da geração anterior, portanto nenhum código de modelagem personalizado é necessário.

• Treinamento — aproximadamente 34 trilhões de tokens, com uma fase dedicada de treinamento intermediário para extensão de contexto.

• Vocabulário — 128.000 tokens, dobrado nesta geração para lidar melhor com escritas não latinas. Cerca de 262M de parâmetros, aproximadamente um décimo do modelo, ficam no embedding compartilhado.

• Contexto — o card do modelo e a configuração divergem aqui, e vale a pena saber: a documentação anuncia 131.072 tokens, enquanto code>config.json/code> define code>max_position_embeddings/code> como 128.000. Dimensione para 128K e trate qualquer valor acima disso como não verificado.

• Idiomas — dezesseis: inglês, árabe, chinês, francês, alemão, hindi, indonésio, italiano, japonês, coreano, polonês, português, russo, espanhol, tailandês, vietnamita.

• Benchmarks — nenhum. A Liquid não publica nenhuma avaliação para o checkpoint base, e o cartão do modelo enquadra a omissão como intencional: este artefato existe para ser pós-treinado, não para ser medido em seu estado bruto.

Essa última linha é o ponto central do lançamento e também é o motivo pelo qual uma comparação "X vs LFM2.5-2.6B-Base" precisa ser tratada com cuidado. Um checkpoint base não tem opinião sobre nada. Peça a ele que planeje um fluxo de trabalho no Android e ele continuará seu texto de forma probabilística, porque nunca foi ensinado a responder. O card o recomenda apenas para casos que exigem ajuste fino pesado: um assistente específico para um idioma, um assistente específico de domínio em um setor regulamentado, treinamento com dados proprietários ou como aluno de destilação. Para qualquer uso pronto de fábrica, incluindo chamada de ferramentas, a Liquid direciona você ao LFM2.5-2.6B pós-treinado.

O que o ARTEMIS precisa de um modelo, que não é o que um checkpoint base oferece

ARTEMIS é um loop de controle com dois modos. O Flash é um ciclo reativo de observar e agir, com cerca de 3 a 5 segundos por etapa. O Pro é um grafo multiagente, com cerca de 15 a 40 segundos por etapa, com um Planejador mantendo um plano Markdown vivo, um Operador com o conjunto completo de ferramentas e um Verificador somente leitura que valida checkpoints em quatro níveis, de code>off/code> a code>strict/code>. Ambos os modos exigem a mesma coisa do modelo subjacente: olhar para uma captura de tela, escolher uma ação de um conjunto fixo de ferramentas e repetir em um ou dois segundos, cem vezes, sem perder o fio da meada.

Esse é um pedido exigente — seguir instruções sob um esquema rígido, compreensão visual fundamentada e coerência de longo horizonte — e é exatamente o conjunto de habilidades que um checkpoint base não recebeu. Os próprios backends testados do ARTEMIS são modelos hospedados: Gemini, Claude, GPT-4o, Qwen-VL. Todos eles são ajustados por instruções para uso de ferramentas, e todos eles são grandes.

Portanto, a diferença não é de tamanho. Um modelo pós-treinado de 2,6B consegue manter um loop de chamada de ferramentas — o modelo irmão pós-treinado da própria Liquid afirma superar o Gemma 4 E2B-it e o E4B-it em todas as suas avaliações de seguimento de instruções e em quase todas as de uso de ferramentas, embora esses sejam números reportados pelo fornecedor, sem verificação independente. A diferença é que um base checkpoint não teve nenhum desse treinamento aplicado, então não pode ser colocado em um harness de forma alguma.

A licença é a diferença mais acentuada.

É aqui que o confronto é realmente decidido, e é a parte que a maioria das comparações ignora.

• ARTEMIS — Apache 2.0. Use-o comercialmente, faça fork, distribua-o dentro de um produto, sem exigência de receita. A única obrigação é preservar os avisos e declarar suas alterações, uma obrigação que o próprio projeto teve de reparar publicamente em setembro de 2026 depois que a Minitap alegou que 228 dos 229 arquivos do ARTEMIS coincidiam com seu próprio projeto sob Apache-2.0, code>mobile-use/code> e que os nomes dos autores haviam sido removidos por force-push. O repositório agora inclui uma linha de crédito à Minitap.

• LFM2.5-2.6B-Base — a LFM Open License, uma licença personalizada em vez de Apache ou MIT. Abaixo de US$ 10 milhões em receita anual, a concessão é ampla, perpétua e isenta de royalties. Nesse limite ou acima dele, a licença não se estende ao uso comercial de forma alguma, e você deve entrar em contato com a Liquid. O detalhe importante para quem construir sobre ele: obras derivadas herdam os mesmos termos. O checkpoint que você pós-treina não é algo novo que você possui integralmente — ele carrega adiante a licença condicionada à receita, com uma exceção para organizações sem fins lucrativos qualificadas.

Coloque esses dois fatos lado a lado e a decisão se inverte dependendo de quem você é. Uma empresa com financiamento que quer lançar um agente do lado do telefone tem um harness Apache-2.0 que pode usar livremente e um checkpoint que talvez não possa usar comercialmente de forma alguma. Um desenvolvedor individual ou uma startup abaixo do limite tem os dois, e a licença é uma nota de rodapé. Nenhum dos fornecedores está sendo irracional — a Liquid é uma empresa que protege sua camada comercial, o Google está tornando ferramentas de teste de código aberto — mas "pesos abertos" e "pesos abertos" não são a mesma permissão, e uma comparação que para na contagem de parâmetros não lhe dirá qual deles você tem.

A família, porque o checkpoint base é a porta errada para entrar nela.

Se o objetivo é um agente Android no dispositivo, três irmãos importam mais do que a base, e aquele de que o roadmap da ARTEMIS realmente precisa não é o óbvio.

• LFM2.5-2.6B — o irmão agêntico pós-treinado. A taxa de transferência relatada pelo fornecedor é de cerca de 30 tokens por segundo em hardware de classe telefone, 113 em um Ryzen AI Max+ 395 e 220 em um Apple M5 Max, executando em menos de 2,5 GB.

• LFM2.5-VL-3B — o modelo de borda de visão-linguagem, construído sobre a mesma base com um codificador SigLIP2 400M NaFlex, com precisão@1 de grounding relatada pelo fornecedor elevada de 57,1 para 87,9 no RefCOCO e, segundo a Liquid, desempenho em elementos de UI na tela que supera modelos Gemma muito maiores e fica a 0,7% de um Qwen 3.5 de 4,7B. Não verificado, mas é o único membro desta família que consegue ver uma tela.

• LFM2.5-230M — o nível de extração e classificação, explicitamente não recomendado para trabalhos com uso intenso de raciocínio.

Qual é a conclusão incômoda para o checkpoint base neste confronto: o item de roadmap da ARTEMIS é um requisito de visão, a base é apenas texto, e o membro da família que preenche a vaga é a variante VL que já tem aplicados tanto o codificador de visão quanto o pós-treinamento. O papel do checkpoint base em uma pilha de automação Android não é controlar o telefone. É ser a matéria-prima por baixo de qualquer modelo pequeno que venha a fazer isso.

Onde eles de fato se encontram: o volante de inércia que ninguém construiu ainda

Aqui está a única conexão que é real em vez de retórica, e ela funciona ao contrário da direção habitual. A funcionalidade mais subestimada do ARTEMIS não é o agente — é o escape. Cada execução captura pilhas de falhas, capturas de ecrã de quadros-chave, um registo de sessão de passos comprimidos e um relatório de diagnóstico, e o Pro abre um "incidente de execução" sempre que uma ação falha e mantém-no no contexto até que um sucesso posterior o resolva. Isso é um corpus rotulado exatamente dos momentos em que a perceção de um agente de UI estava errada.

Combine isso com um checkpoint cujo propósito inteiro é o pós-treinamento e você tem um loop óbvio: execute o harness em um modelo hospedado, colete os traços em que ele tropeçou no seu app e faça fine-tuning de um modelo de 2,6B precisamente nesses frames. É o tipo de conjunto de dados proprietário que o próprio card da Liquid cita como a justificativa para lançar um checkpoint base — "treinar com seus próprios dados" —, e a licença condicionada à receita significa que é uma rota que faz sentido para equipes abaixo do limite e exige uma conversa para equipes acima dele.

Para ser explícito sobre o status daquela ideia: ninguém publicou este loop, nenhum fornecedor o sugere, e não há evidências de que qualquer um dos lados o tenha testado. É uma proposta, não um resultado, e deve ser lida como tal. Mas é o único enquadramento no qual esses dois artefatos são colaboradores, e não um erro de categoria.

Se você chegar ao ponto de fazer ajuste fino, o conjunto de comparação é a outra metade do problema. O LFM2.5-2.6B-Base não está no nosso catálogo — nenhuma variante do LFM2.5 está —, então esse checkpoint vem da distribuição da própria Liquid e dos habituais hosts de terceiros. Onde um catálogo com encaminhamento justifica o seu lugar é ao avaliar o seu ajuste fino contra os modelos que ele tem de superar no uso de ferramentas, com uma única chave e uma única fatura, com failover para que uma tarde má de um fornecedor não se torne a tarde má da sua avaliação. Isso é algo genuinamente útil de se ter quando o objetivo de todo o exercício é um confronto direto sobre o qual você pretende agir.

Então, qual deles é o seu problema?

Se você tem um aplicativo Android e quer que ele seja testado automaticamente neste trimestre, você quer o ARTEMIS, e o LFM2.5-2.6B-Base não faz parte da resposta — você executará o ARTEMIS contra um modelo de visão hospedado, pagará por etapa, e o item do roadmap sobre VLMs no dispositivo chegará eventualmente e resolverá um problema de custo que você ainda não mediu.

Se você está criando um produto que precisa rodar em um celular sem rede, você quer o caminho do modelo pequeno, e o LFM2.5-2.6B-Base é o começo desse projeto, e não qualquer parte da solução dele: você vai fazer pós-treinamento nele, vai ler a LFM Open License em relação à sua projeção de receita antes de escrever o primeiro script de treinamento e, se o seu agente precisar ver uma tela, você vai acabar indo para a variante VL.

A única coisa a não fazer é colocar esses dois lado a lado, declarar que o harness é mais capaz e seguir adiante. A comparação útil é entre as duas stacks completas — modelo hospedado mais harness, versus modelo pequeno ajustado mais um framework que você constrói — e só uma delas tem uma taxa de sucesso publicada em um benchmark público, o que vale exatamente tanto quanto o fato de a outra não ter nenhuma fatura de nuvem.

Onde um catálogo roteado justifica o seu lugar é ao comparar o seu fine-tune com os modelos que tem de superar no uso de ferramentas, numa só chave e numa só fatura, com failover para que uma tarde má de um fornecedor não se torne uma tarde má da sua avaliação.

O LFM2.5-2.6B-Base não está no nosso catálogo — nenhuma variante do LFM2.5 está — portanto, esse checkpoint vem da distribuição própria da Liquid e dos habituais hosts de terceiros.