LiquidAI LFM2.5-24B-A2B: raciocínio com 2B ativos on-device

O que a Liquid AI anunciou em 13 de outubro de 2026

Em 13 de outubro de 2026, a Liquid AI anunciou o LFM2.5-24B-A2B, modelo de raciocínio MoE com 24B de parâmetros totais, 2B ativos por token, contexto de 131K tokens e pesos abertos no HuggingFace. O posicionamento do anúncio é explícito: raciocínio e agentes executando no dispositivo. A verificação do blog, em 2026-10-16, confirma os pesos no repo LiquidAI/LFM2.5-24B-A2B.

Os dois números carregam a história. Um modelo denso de 24B ativa a totalidade dos parâmetros a cada token gerado. Um MoE de 24B com 2B ativos paga compute por uma fração do conjunto, e é essa fração que o anúncio aponta como o mecanismo que permite rodar raciocínio em hardware próprio. Arquitetura de parâmetros ativos, por si só, não é novidade. O que o evento de 2026-10-13 faz é combiná-la com duas propriedades que, juntas, mudam uma decisão de compra: capacidade de raciocínio, que costuma exigir modelos grandes, e pesos que qualquer um baixa. Modelo pequeno perto do líder já era leitura conhecida aqui; a diferença é que agora a eficiência veio acompanhada de raciocínio e de pesos públicos, no mesmo artefato.

Por que isso importa: a rota de agentes ganha uma terceira opção

Quando raciocínio de agente roda com 2B ativos em hardware próprio, a política de rota deixa de ser uma escolha entre endpoints pagos e passa a ter uma terceira opção: executar local quando a tarefa cabe, rotear para a nuvem quando não cabe. Eficiência de parâmetros ativos é decisão de rota, não curiosidade de benchmark. É a tese desta peça.

A terceira opção é o evento.

A semana já tinha mostrado a fronteira hospedada: o Claude Haiku 4.5 baixou o piso de custo de inferência num endpoint. O LFM2.5-24B-A2B ataca a equação pelo outro lado. Em vez de baratear o token hospedado, elimina o token hospedado nas tarefas em que o hardware local dá conta. Para quem roda agentes em volume, essa é a variável que mexe com o break-even: cada tarefa que migra para execução local deixa de aparecer na fatura por milhão de tokens, e o que continua na nuvem passa a precisar de justificativa.

Arquitetura e inovações técnicas: 24B totais, 2B ativos por token

O LFM2.5-24B-A2B é um MoE: dos 24B de parâmetros totais, apenas 2B são ativos em cada token, segundo o anúncio da Liquid AI de 2026-10-13. O custo de compute por token acompanha os parâmetros ativos, enquanto a capacidade do modelo acompanha os totais. O contexto declarado é de 131K tokens. Os pesos estão abertos no HuggingFace.

A diferença para um modelo denso vale um parágrafo, porque é ela que decide a conta de execução. Num modelo denso, todo parâmetro participa do processamento de todo token, então o custo por token escala com o tamanho completo do modelo. Num MoE, um mecanismo interno seleciona, por token, a fração de parâmetros que entra em operação. O resultado prático é um modelo com a capacidade associada a 24B e o custo de execução associado a 2B, com uma ressalva que o anúncio não elimina: a pegada de memória segue os parâmetros totais. Guardar 24B de pesos em disco e memória é condição para ativar 2B deles.

Ficha técnica, conforme o anúncio e o repo:

A descrição acima segue o anúncio da Liquid AI e a ficha do repo de pesos. Este blog não executou o modelo para este texto, e cada linha da tabela é rastreável à fonte primária datada.

Benchmarks e desempenho real: o que é reportado e o que é validado

O anúncio de 2026-10-13 posiciona o LFM2.5-24B-A2B para raciocínio e execução de agentes. Este texto não reproduz placar nenhum: a verificação do blog, em 2026-10-16, não abriu avaliação independente, e número reportado pelo próprio laboratório não é validação. Onde a fonte primária reporta desempenho, a leitura é "a Liquid AI reporta", com data, nunca valor convertido em verdade de produção.

Placar de lançamento não decide rota.

A regra de leitura vale para todo lançamento e vale dobrado para modelos de pesos abertos, porque o ciclo de validação é mais rápido. O número que o laboratório reporta mede o modelo nas condições que o laboratório escolheu. O número que decide rota mede o modelo no seu tráfego, com os seus prompts, no seu hardware. Entre os dois existe uma distância que só teste paralelo fecha, e o método para fechá-la é o mesmo que decidiu o custo de rota entre modelos hospedados. No momento da publicação, o blog não confirma score, latência nem throughput para este modelo, e não cita os valores que circularem sem data nem metodologia.

Economia de inferência e custo por token: ativos versus totais

A economia deste lançamento não está apenas no preço por milhão de tokens, que a Liquid AI publicou no anúncio de 2026-10-13 (US$ 0,10 por 1M de tokens de entrada, US$ 0,05 com entrada em cache, e US$ 1,00 por 1M de tokens de saída, na Liquid Console), e sim na razão entre parâmetros ativos e totais: o compute pago por token escala com os 2B ativos, não com os 24B totais. Essa é a razão econômica real do evento, e ela opera antes de qualquer negociação de preço com provedor.

Execução local com pesos abertos é outro regime. Troca custo variável por custo fixo. O endpoint hospedado cobra por token faturado, sem capital adiantado e sem hardware para gerir. O hardware próprio cobra na frente, em aquisição e operação, e depois cobra pouco por token adicional. O ponto de equilíbrio entre os dois depende de volume e do perfil das tarefas, e a decisão por tarefa é o método que o guia de redução de custo de inferência já descreve em detalhe.

Integração e roteamento em produção: pesos abertos entram na malha de rota

Pesos abertos mudam a integração antes de mudarem a execução: o modelo vira artefato versionado sob gestão própria, com governança e auditoria de versão, e não endpoint do provedor. A rota ganha um destino novo, o hardware próprio, com política escrita como qualquer outro. A seleção entre pesos abertos e modelos hospedados é decisão de governança que antecede qualquer deploy.

Onde a execução local substitui a chamada hospedada: tarefas de agente que cabem em 131K de contexto e na capacidade do modelo, com frequência suficiente para amortizar o hardware. Onde não substitui: picos de demanda acima do hardware, tarefas que exigem capacidade acima do que o modelo entrega e operações sem hardware disponível. A malha de rota que trata os dois destinos como complementares, cada um com critério de entrada, é a que sobrevive ao próximo lançamento.

O Router não roda on-device. Não é isso que ele traz para esta decisão. O papel dele é o plano de controle que decide o que roda onde: teste paralelo do mesmo prompt em destinos locais e hospedados com tráfego real, regras de rota por chave, teto de gasto por chave, agente e projeto, failover e fallback configuráveis quando o destino local não sustenta a tarefa, e rastro de auditoria de cada chamada. A troca de modelo acontece sem reintegração, o que importa num momento em que a malha de destinos acabou de ganhar uma categoria nova. O pilar do Router em escala cobre essa arquitetura em profundidade.

Perguntas frequentes sobre o LFM2.5-24B-A2B

Bloco marcado para FAQPage, com as perguntas que chegam antes da decisão de compra.

O que muda um modelo com 2B de parâmetros ativos? O compute por token. Num modelo denso de 24B, todo parâmetro trabalha a cada token gerado. Num MoE com 2B ativos, apenas uma fração entra em operação por token, então o custo de execução acompanha a fração ativa enquanto a capacidade acompanha o conjunto total, segundo o anúncio da Liquid AI. A contrapartida é a pegada de memória, que segue os 24B totais.

O LFM2.5-24B-A2B roda agentes no dispositivo? Esse é o posicionamento do anúncio, não uma medida verificada por este blog. A Liquid AI apresenta o modelo para raciocínio e agentes executando no dispositivo, com contexto de 131K tokens e pesos baixáveis no HuggingFace. Se a execução sustenta o seu agente no seu hardware é pergunta que só um teste com o seu tráfego responde.

Pesos abertos dispensam endpoint pago? Não de forma absoluta, e esta peça não sugere isso. Pesos abertos criam a opção de execução local para as tarefas que cabem no modelo e no hardware. Picos de demanda, tarefas acima da capacidade do modelo e operações sem hardware disponível continuam dependendo de endpoint hospedado. A mudança real é que a nuvem deixa de ser o default e passa a ser um destino justificado por capacidade.

Como decidir o que roda local e o que vai para a nuvem? Por tarefa, com dado do tráfego real: perfil de cada agente, tamanho de contexto, frequência e tolerância a falha. Tarefa frequente que cabe no modelo e no hardware é candidata à execução local. Tarefa esporádica ou acima da capacidade segue hospedada. O teste paralelo no Router compara os dois destinos com o mesmo prompt antes de a regra de rota ser escrita.

O Nexforce Router executa o modelo on-device? Não. O Router é o plano de controle: decide o que roda onde, aplica regras de rota por chave, teto de gasto, failover, fallback e auditoria por chamada. A execução local acontece no seu hardware; a decisão de quando usá-la é que passa pelo Router, com observabilidade central sobre os dois destinos.

Referências e Leitura Complementar

• Liquid AI, anúncio do LFM2.5-24B-A2B, 13 de outubro de 2026: liquid.ai/blog/lfm2-5-24b-a2b
• Pesos abertos no HuggingFace, repo LiquidAI/LFM2.5-24B-A2B: huggingface.co/LiquidAI/LFM2.5-24B-A2B
• Anthropic lança Claude Haiku 4.5: o novo piso de custo de inferência
• Qwen 3.8 Max: o custo que decide a rota
• Como reduzir custos de inferência de LLM
• Modelo pequeno perto do líder: o que muda no roteamento
• Open weights ou modelos hospedados: seleção e governança
• Nexforce Router: middleware de modelos em escala

Próximo passo

Para quem opera agentes em produção, o passo seguinte não é baixar pesos por impulso. É medir qual fração do tráfego atual cabe no perfil de 2B ativos e 131K de contexto, e transformar essa fração numa regra de rota testada antes de virar default. O caminho cabe numa lista:

1. Mapeie as tarefas de agente por perfil: contexto médio, frequência e tolerância a falha.
2. Monte um teste paralelo no Nexforce Router com o mesmo prompt indo para o destino local e para o endpoint hospedado, com tráfego real.
3. Escreva a regra de rota por chave para a fração que o teste validar, com teto de gasto por chave, agente e projeto.
4. Configure o fallback do destino local para o hospedado, para o caso em que o hardware não sustenta a tarefa.
5. Audite cada chamada desde o início. A governança de pesos abertos é sua, não do provedor.

O LFM2.5-24B-A2B não encerra a era do endpoint pago. Ele obriga cada token a justificar por que subiu.