Vazamento do LFM3: a próxima família da Liquid AI é formada por quatro pequenos modelos Omni

Um pull request aberto no GitHub em 27 de outubro de 2026 quer ensinar ao SGLang como servir uma família de modelos que não existe publicamente. Ele nomeia quatro checkpoints — LFM3-1.7B, LFM3-VL-2B, LFM3-Audio-2B e LFM3-Omni-2B — e, comparado aos LFM2.5-2.6B e LFM2.5-24B-A2B já lançados, lê-se como um projeto do que a Liquid AI construirá em seguida. O PR não foi mesclado. Todas as três verificações de CI dele estão falhando. A Liquid AI não anunciou nada disso. Esse diff não mesclado é todo o registro público do LFM3 até hoje, e é mais informativo que a maioria dos posts de lançamento — desde que você o leia pelo que ele é.

Sejamos precisos quanto às evidências, porque elas são escassas numa direção e excepcionalmente detalhadas noutra. Aqui não há data de lançamento, preço, termo de licença nem pontuação de benchmark. Não existe model card do LFM3, repositório no Hugging Face, publicação em blogue, listagem de API. O que existe é uma contribuição de tugot17 — Piotr Mazurek, que nos últimos dois meses integrou suporte de runtime para LFM no SGLang, no llama.cpp e no mlx-vlm — além do material publicado pela própria Liquid sobre a geração LFM2.5 que está prestes a ser substituída. Tudo abaixo está identificado em conformidade.

O que o pull request realmente coloca na mesa

O título do PR é [Feat] lfm3: Adicionar suporte a texto, visão, áudio e Omni, e ele traz dois rótulos que indicam que tipo de mudança é: jit-kernel e Multi-modal. Ele adiciona geração de texto nativa para uma família de quatro, cada uma com seu próprio caminho de checkpoint:

• LFM3-1.7B — texto entra, texto sai, o modelo de linguagem simples na base da família

• LFM3-VL-2B — texto, imagens e vídeo na entrada, texto na saída

• LFM3-Audio-2B — texto e áudio na entrada, texto na saída, e também conectado ao endpoint /v1/audio/transcriptions

• LFM3-Omni-2B — texto, imagens, áudio e vídeo como entrada, incluindo a própria trilha sonora de um vídeo, texto como saída

Um detalhe nessa lista merece uma pausa. Todas as variantes produzem texto. Não há nenhum caminho de saída de áudio em lugar algum no PR, e a superfície não conversacional do modelo de áudio é a transcrição — fala entra, texto sai. Isso é mais restrito do que a linha de áudio atual da Liquid, na qual o LFM2.5-Audio-1.5B é documentado como capaz de lidar com ASR, TTS e chat de voz intercalado em um único modelo. Ou o primeiro corte do SGLang cobre apenas a metade de geração de texto do LFM3-Audio, ou a família omni realmente abandona a síntese de fala. O PR não pode determinar qual dos dois, e qualquer pessoa que diga que pode está chutando. Trate "LFM3 fala" como não comprovado.

O restante do diff é detalhe de implementação que, ainda assim, revela a época do trabalho. Codificadores de visão e áudio com seus projetores, um backbone compartilhado, integração de cache híbrido, kernels de convolução em CuTe DSL com fallback em PyTorch e uma observação de que o FlashInfer usa paged prefill por padrão para que a atenção com janela deslizante se comporte adequadamente. A validação foi executada em H100s em FP16 usando o que a descrição chama de checkpoints de desenvolvimento — quatro palavras que importam mais tarde.

A frase de arquitetura, e o número que as pessoas vão interpretar errado

O PR descreve o LFM3 como uma espinha dorsal compartilhada de convoluções curtas com gate e atenção completa e com janela deslizante. Trata-se da linhagem do LFM2 continuada, não substituída: o LFM2.5-24B-A2B é documentado como um híbrido de convoluções curtas com gate e atenção de consulta agrupada em 40 camadas. O que parece novo no vazamento é o componente explícito de janela deslizante ao lado da atenção completa.

As notas de validação mencionam um prompt ultrapassando uma janela deslizante de 256 tokens, e este é o número que será citado fora de contexto a semana toda. Não é o comprimento de contexto do LFM3. Em um design híbrido, as camadas de atenção só precisam enxergar localmente porque as camadas de convolução carregam o sinal de longo alcance — essa é a premissa inteira da arquitetura, e é por isso que a família consegue manter 131,072 tokens de contexto no LFM2.5-24B-A2B enquanto a maioria de suas camadas não faz atenção quadrática de forma alguma. Uma janela de atenção de 256 tokens é uma afirmação sobre onde o modelo olha dentro de uma camada, não sobre quanto texto ele consegue aceitar. O PR não declara o contexto total do LFM3, e ninguém fora da Liquid sabe disso ainda.

Por que um pull request de runtime é o sinal, não o ruído

É razoável desconfiar de inferir a estratégia de produto a partir de um diff de infraestrutura. Neste caso específico, o padrão é consistente demais para ser ignorado, porque a Liquid entrega suporte a engines junto com os pesos, e não depois deles. O LFM2.5-2.6B lista llama.cpp, MLX, vLLM, SGLang, ONNX e Transformers 5.0+ como alvos para o primeiro dia. O LFM2.5-24B-A2B tinha suporte em llama.cpp, MLX, vLLM, SGLang e ONNX no lançamento. Uma família que chega com cinco runtimes prontos precisa ter seus kernels escritos antes do anúncio, o que significa que os PRs entram primeiro e o post do blog vem em seguida.

O autor se encaixa exatamente nessa cronologia. O histórico público de Mazurek é uma sequência de trabalho de integração do LFM: decodificação especulativa DSpark para LFM2-VL no SGLang em setembro, LFM2.5-VL-3B e correções do modelo de rascunho DSpark no llama.cpp no mesmo mês, decodificação especulativa herdada do modelo de texto no mlx-vlm, e uma reutilização de configuração do LFM2-MoE no SGLang em 13 de outubro. O LFM3 é a próxima entrada nessa sequência, registrada no fim de semana em que a família mudou de nome.

Duas ausências são tão reveladoras quanto a presença. Não há um pull request correspondente no Hugging Face Transformers para o LFM3 — uma busca nesse repositório não retorna nada —, e o PR do SGLang carrega seus checkpoints por meio do Transformers 5.19.0 padrão com --trust-remote-code, que é o que se faz quando a arquitetura ainda não é nativa da biblioteca. Há também um commit que rejeita explicitamente a decodificação especulativa para o LFM3, então o trabalho do DSpark que foi lançado para a geração 2.5 ainda não foi levado adiante. É cedo, e incompleto por design.

A pergunta sobre tamanho que ninguém respondeu

Aqui, o vazamento e a ambição declarada puxam em direções opostas, e essa tensão é o que há de mais interessante no documento.

Maxime Labonne, Chefe de Pré-treinamento da Liquid, descreveu o objetivo do LFM3 como testar se a abordagem de convolução curta que funciona na escala de 350M a 1,2B consegue se sustentar além de 10 bilhões de parâmetros — o regime em que as arquiteturas de atenção historicamente levaram vantagem. Essa é uma questão de escala, e implica um modelo grande.

Os checkpoints vazados são um de 1,7B e três de 2B. Nenhum deles está acima do limiar a que a pergunta se refere.

Duas interpretações permanecem. A primeira é que estes são a primeira leva compacta — uma família omni para celulares e carros antes da chegada de um irmão maior, o que combina com a forma como a Liquid sempre liderou com modelos pequenos e com a maneira como o PR os descreve como checkpoints de desenvolvimento, e não como lançamentos finais. A segunda é que 1.7B e 2B são simplesmente os tamanhos que eram convenientes para validar kernels, e não nos dizem nada sobre o que será lançado. A posição honesta é que o vazamento prova que a família existe e prova sua forma; não prova seu teto. Se você está esperando um modelo Liquid >10B, este PR nem promete um nem o descarta.

O que o LFM3 herda, para o bem e para o mal

A linha de base que ele precisa superar é recente e bem documentada. O LFM2.5-24B-A2B foi lançado em 13 de outubro de 2026, com 24B de parâmetros totais e 2B ativos, 40 camadas, 64 especialistas e roteamento top-4, contexto de 131.072 tokens, vocabulário de 128K e 33T tokens de pré-treinamento. O LFM2.5-2.6B, do início de agosto, cabe em menos de 2,5 GB com contexto de 128K. O LFM2.5-VL-3B combina a base de 2,6B com um codificador de visão SigLIP2.

Vale a pena dizer claramente: todos os benchmarks que a Liquid publica para estes modelos são executados pelo fornecedor nas próprias infraestruturas de avaliação da Liquid, sem qualquer avaliação independente associada. Os números de destaque do LFM2.5-24B-A2B — AutomationBench 27.69, BFCLv4 65.01, ToolSandbox 80.71, IFEval 96.75 — são números da Liquid, e a mesma tabela mostra que ele perde para o Qwen3.6-35B-A3B no WebArena Verified (26.75 contra 37.62), no GPQA Diamond e no SWE-Bench Verified. Tabelas de fornecedores que incluem derrotas são mais credíveis do que as que não incluem, mas credível não é o mesmo que verificado. Não existe nenhum número do LFM3 de qualquer tipo, portanto ainda não há nada a comparar.

O licenciamento também continuará valendo. Os checkpoints LFM recentes da Liquid no Hugging Face estão cada um marcado como license: other — uma licença LFM sob medida, não Apache-2.0 nem MIT. Seja qual for a licença sob a qual o LFM3 for distribuído, presuma os mesmos termos personalizados até que um cartão do modelo diga o contrário, e leia-os antes de criar um produto com os pesos.

Quando isso pode realmente chegar

Ninguém sabe a data, inclusive as pessoas que fazem previsões profissionalmente. Uma pergunta no Manifold Markets sobre quando o LiquidAI LFM3 será lançado atribui 40% ao 4.º trimestre de 2026, 21% ao 1.º trimestre de 2027, 21% ao 2.º trimestre de 2027, 11% ao 3.º trimestre de 2026 e 7% ao 2.º trimestre de 2026 — com um volume total de aproximadamente Ṁ160, que é pequeno o suficiente para que as percentagens reflitam um punhado de traders, em vez de um consenso. Leia isso como "em algum momento nos próximos dois trimestres, provavelmente", e não com mais precisão do que isso.

A mecânica defende mais cedo do que tarde. Trabalho de kernel que chega a um runtime importante é engenharia de fase final, não de fase inicial — não se escrevem kernels de convolução em CuTe nem se conecta cache híbrido para um modelo que só sai daqui a um ano. O nome da família estabilizou-se como LFM3 em quatro variantes e quatro caminhos de checkpoint. Mas o PR não foi mesclado, com as três verificações vermelhas, precisa de uma revisão de aprovação que não tem, e 2 de 22 verificações de validação omni e 2 de 16 verificações de visão ainda falham na sua comparação ROUGE. Isso é um branch em pleno andamento, não um candidato a lançamento.

O que isso significa se você estiver escolhendo um modelo esta semana

Nada sobre o LFM3 deve mudar uma decisão que você tome hoje. Ele não está disponível, não tem preço, não foi avaliado em benchmarks e não é licenciado publicamente. Se você precisa de um modelo multimodal pequeno agora, a geração LFM2.5 é a resposta real, e suas restrições — pontuações relatadas pelo fornecedor, licença personalizada e um perfil de programação que tanto as próprias tabelas da Liquid quanto a cobertura externa apontam como o ponto fraco — são os fatores a ponderar.

O que torna o vazamento genuinamente útil é o planejamento. Ele indica que uma família omni compacta está chegando, que provavelmente chegará em vários runtimes ao mesmo tempo e que sua variante de áudio pode não sintetizar fala. Se o seu roadmap assumia que o próximo movimento da Liquid era um modelo de texto maior, as evidências até agora não sustentam essa suposição.

A fragmentação de runtime é o problema prático que esta família vai criar. O hábito da Liquid de lançar simultaneamente para llama.cpp, MLX, vLLM, SGLang e ONNX é bom para a portabilidade e incômodo para quem quer um único endpoint: cinco engines significam cinco formatos de implantação, cinco conjuntos de peculiaridades de pré-processamento e cinco datas diferentes em que uma correção chega. O catálogo de mais de 200 modelos da OrcaRouter não inclui um único checkpoint LFM hoje, portanto não há como chamar o LFM3 por meio dele e nada aqui deve ser interpretado como promessa de que haverá. O que uma camada de roteamento realmente faz nessa situação é ser a costura entre um modelo não comprovado e um caminho de produção — enviar uma fração do tráfego para algo novo enquanto um modelo conhecido permanece atrás dele, com o failover cobrindo a lacuna, é como se avalia o sucessor de uma família não lançada sem apostar uma funcionalidade voltada ao cliente em um mercado de previsão de 40%.

As questões em aberto que vale a pena acompanhar

Quatro coisas resolverão isto mais depressa do que qualquer especulação adicional. Se os quatro caminhos de checkpoint passarão a ser repositórios reais e descarregáveis no Hugging Face — neste momento, uma pesquisa na organização LiquidAI não devolve nada em LFM3, e os repositórios indicados no PR não são publicamente resolvíveis. Se aparecer um PR para Transformers, o que sinalizaria que a arquitetura está a ser integrada upstream corretamente, em vez de ser executada através de código remoto. Se as verificações de validação com falha forem fechadas, uma vez que 2 de 22 falhas omni é a diferença entre uma demo e um merge. E se surgir um membro da família com >10B, que é a pergunta para a qual Labonne disse que o LFM3 existe para responder.

Até lá, a frase mais precisa que qualquer pessoa pode escrever sobre o LFM3 é aquela com a qual este artigo começou: existe um pull request, ele não foi mesclado e nele são nomeados quatro pequenos modelos omni que a Liquid AI não anunciou. Isso é um sinal real — apenas um sinal precoce, e sinais precoces merecem ser lidos exatamente como tal.