LFM3-1.7B no vLLM: Nove dias depois, o suporte nativo ainda está em dois PRs abertos

da Liquid AILFM3-1.7B foi lançado em 27 de outubro de 2026 com um model card que exibe vllm serve "LiquidAI/LFM3-1.7B" como se fosse um comando comum. Nove dias depois, o vLLM upstream não tem nenhuma arquitetura Lfm3ForCausalLM para executá-lo. O que existe, em vez disso, é uma solicitação de recurso aberta em 30 de outubro, um pull request de kernel sobre o qual todo o resto está empilhado, e seis PRs de modelo abertos — dois dos quais implementam o mesmo modelo de texto LFM3-1.7B de duas maneiras diferentes, e nenhum dos quais foi mesclado.

Essa lacuna é toda a história aqui, e é uma lacuna estreita. O modelo é real e pode ser baixado; o suporte de runtime é uma fila. Este é um texto sobre o que sabemos até agora a respeito da fila: o que está em andamento, o que realmente funciona hoje e o que precisaria ser entregue para que "funciona com vLLM" em um cartão de modelo se torne verdadeiro no sentido de que um plano de implantação precisa que seja.

O cartão diz vLLM. A tabela de modelos suportados diz LFM2.

A documentação de modelos suportados do próprio vLLM lista três arquiteturas da Liquid AI: Lfm2ForCausalLM, Lfm2MoeForCausalLM e Lfm2VlForConditionalGeneration. Não há entrada para o LFM3. Enquanto isso, o card do LFM3-1.7B afirma que o checkpoint "funciona com vLLM, SGLang e builds do llama.cpp compatíveis com LFM3" e fornece um comando de serving sem flags anexadas.

A reconciliação está na configuração do próprio checkpoint. O LFM3-1.7B traz um auto_map que aponta para seu modeling_lfm3.py incluído, então o código do lado do Hugging Face existe e se clona em loaders que permitem código remoto. A issue de acompanhamento do vLLM para o porte, #64645 — "[Feature]: Suporte a modelos LiquidAI LFM3", aberta em 30 de outubro por abhijithneilabraham — é direta sobre a consequência: "o vLLM não tem Lfm3ForCausalLM." Sua alternativa listada é a válvula de escape que a maioria das pessoas acabará usando neste mês: "Execute o LFM3 por meio do código remoto do checkpoint com o backend Transformers. Isso abre mão da atenção paginada e do cache de estado da convolução."

Vale a pena declarar essa troca claramente, porque "roda em vLLM" e "roda no backend transformers do vLLM" são produtos diferentes. Paged attention é o mecanismo que permite ao vLLM agrupar em lote requisições de comprimentos radicalmente diferentes sem desperdiçar memória KV; o cache de estado convolucional é a mesma ideia aplicada às camadas de convolução curta desta arquitetura. Retire os dois e você terá um endpoint funcional que abriu mão das duas razões pelas quais o vLLM existe. Para um modelo 1.7B servido com baixa concorrência, isso pode ser um fim de semana aceitável, não um formato de produção aceitável.

Por que um modelo de 1,7B precisa de trabalho no kernel, afinal?

O LFM3-1.7B não é um reajuste simples da família LFM2 que o vLLM já atende. É um híbrido de vinte e quatro camadas com três tipos de camadas em vez de dois: 13 camadas de convolução curta com gate, 5 camadas de atenção de janela deslizante com janela de 256 tokens e 6 camadas de atenção completa. A config do checkpoint detalha a geometria — conv_L_cache: 7, sliding_window: 256, um vocabulário de 128K — e a própria lista de diferenças da issue do vLLM acrescenta QK RMSNorm, um gate sigmoide de saída da atenção por cabeça, normalização sanduíche e RoPE parcial (partial_rotary_factor: 0.5) nas camadas de atenção completa, dispostos no mesmo formato de cauda zero que o Gemma 4 usa.

O número que quebrou o port é o sete. A convolução curta do LFM2 tem três taps de largura; o LFM3 a ampliou para sete. Os kernels causal_conv1d do Triton no vLLM desenrolam um conjunto fixo de larguras e, como diz a issue de acompanhamento: “O kernel de prefill causal_conv1d do Triton desenrola larguras de 2 a 4, e o kernel de decode, de 2 a 6, então um modelo de largura 7 não consegue rodar em CUDA hoje.”

Então o primeiro PR da pilha não é um modelo de forma alguma. O #64647, "[Kernel] Suporte a conv1d causal de largura 7", aberto em 30 de outubro por abhijithneilabraham, altera dois arquivos e 186 linhas adicionadas: ele estende o kernel de prefill de larguras 2–4 para 2–7 e o kernel de decode de 2–6 para 2–7, e faz ambos os wrappers lançarem ValueError para qualquer coisa fora desse intervalo. A própria descrição do PR explica por que a rejeição importa tanto quanto a extensão: antes da mudança, "um peso mais largo era executado sem uma ramificação correspondente e retornava valores errados". Corrupção numérica silenciosa é uma falha pior do que uma recusa, e é o tipo de coisa que só aparece no modelo que você acabou testando.

Uma ressalva merece acompanhar esse PR. Seu autor declara claramente que não possui uma máquina com CUDA: o caminho de referência em CPU passa em 96 testes, os kernels Triton foram verificados por análise estática sobre a AST dos kernels, e a validação em GPU fica a cargo da CI. Trata-se de uma divulgação honesta, e não de um defeito, mas significa que a única mudança da qual todos os outros PRs do LFM3 dependem ainda não foi exercitada no hardware em que a maioria dos leitores a executará.

Duas implementações do mesmo modelo de texto

Em seis dias, dois grupos distintos escreveram suporte nativo ao LFM3 para o vLLM. Eles não são variantes de um único patch; são designs independentes que, por acaso, instalam o mesmo nome de arquitetura.

PR #64959, "[Model] Add LiquidAI LFM3 (Lfm3ForCausalLM)", aberto em 1º de novembro por atmikshetty, é o conservador: sete arquivos e, segundo sua própria descrição, reutiliza ShortConv com largura 7, Lfm2MLP, o mapeador de pesos do LFM2 e o RoPE proporcional existente, sem alterar nenhum componente central. Ele registra o modelo no registro, adiciona-o ao conjunto de testes de modelos híbridos e à tabela de modelos suportados e — de forma útil para quem conseguir executá-lo — documenta as flags de serving com as quais validou: --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice. Sua seção de validação relata 324 testes de kernel passando em uma A100-SXM4-40GB em BF16, testes de registro e inicialização passando, e uma comparação de log-probabilidade com a referência de código remoto do Hugging Face.

PR #65826, "[Model] Add LFM3-Text", aberto em 5 de novembro por paulpak58 — que é da Liquid AI — é a versão do próprio fornecedor: dez arquivos e 829 linhas adicionadas, incluindo sua própria classe de configuração em transformers_utils/configs/lfm3.py e seu próprio módulo de teste. Foi aberto como "[Model] Add LFM3" e renomeado no mesmo dia, quando a família foi dividida em quatro PRs empilhados: #65826 para texto, #65827 para visão-linguagem, #65828 para áudio e #65829 para omni, cada um construído sobre o anterior.

Os dois não estão tanto em conflito quanto em paralelo, e a discussão mostra claramente a malha de dependências. No PR do kernel, paulpak58 escreveu em 4 de novembro: "Temos nossos próprios PRs internos para os modelos LFM3, mas esta é uma adição limpa que podemos apoiar." No PR de texto da comunidade, abhijithneilabraham sugeriu que o merge talvez precise que o trabalho da Liquid no transformers seja mesclado primeiro — "Acredito que o merge deste PR exige o PR do transformers de @paulpak58" — ao que atmikshetty respondeu que Lfm3Config ainda não está em uma release do transformers, então o branch "carrega a config via trust_remote_code a partir do checkpoint, e a execução usa o modelo nativo do vLLM." Esse é o segundo obstáculo que a maioria dos leitores não terá considerado: mesmo um PR do vLLM já mesclado precisa de uma classe de configuração que seja distribuída em algum lugar.

No lado do transformers, o PR equivalente é #50322, "[Model] LFM3 Family: LFM3-Text", aberto em 3 de novembro e ainda aberto, desmembrado de um PR maior da família. Sua própria nota sobre a convolução coincide com a issue do vLLM: a conv curta é "somente torch no LFM3 (os kernels causal_conv1d do Hub atendem larguras 2-4, o LFM3 usa 7)".

A frente de visão-linguagem também está duplicando. Além do #65827 do Liquid, um PR independente do LFM3-VL (#65450, aberto em 3 de novembro) ainda está aberto e depende do PR de texto da comunidade. Portanto, até hoje, há seis PRs abertos do LFM3 em duas frentes e nenhum mesclado.

O que realmente roda hoje

Deixando de lado as especulações, o quadro prático em 5 de novembro é este.

• vLLM, nativo — não é possível em uma build padrão. Não há Lfm3ForCausalLM no registro, nenhuma linha LFM3 na tabela de modelos suportados, e o PR que adicionaria essa linha não foi mesclado.

• vLLM, backend transformers — a solução alternativa documentada, usando o código remoto incluído no checkpoint e trust_remote_code. Você perde a atenção paginada e o cache de estado da convolução; você mantém o servidor compatível com OpenAI.

• SGLang — o próprio caminho de servidor do fornecedor. A postagem de lançamento da Liquid mede seus números de throughput em uma única NVIDIA B300 em BF16 com SGLang, incluindo 3,6 bilhões de tokens por dia com 1.024 solicitações simultâneas. O vLLM aparece nessa postagem apenas como o runtime em que modelos concorrentes foram servidos.

• llama.cpp — o cartão refere-se a "builds de llama.cpp compatíveis com LFM3", o que é um qualificador real em vez de texto padrão; os números on-device da Liquid são llama.cpp em Q4_0 com um contexto de 32K.

• MLX — as notas de lançamento 0.33.0 do projeto separado vLLM-Metal listam checkpoints de texto LFM3 MLX, atrás de --trust-remote-code. Esse é um código-base diferente do vLLM upstream e não implica suporte a CUDA.

• Hospedado — A API e o playground da própria Liquid. O cartão não fornece uma tabela de preços, portanto o custo por token não é algo que você possa orçar a partir de material público.

Dois números colocam o caso da auto-hospedagem em perspectiva. Os pesos são pequenos o suficiente para que a memória não seja a restrição — a Liquid afirma cerca de 1 GB em 4 bits — e o fornecedor diz que um contexto de 128K tokens custa aproximadamente 1,6 GB de cache KV. A restrição é a stack de serving, não a GPU.

O que mudaria isso, em ordem

A cadeia de dependências é incomumente limpa, o que torna o motivo de acompanhar o assunto incomumente específico. Primeiro, o #64647 precisa ser integrado, porque todos os outros PRs do LFM3 ou incluem esse commit ou estão empilhados sobre ele. Depois, um dos dois PRs de texto precisa vencer a revisão — o da comunidade tem o registro de validação mais completo, o do Liquid tem o autor que também é responsável pelo lado dos transformers. Em seguida, o Lfm3Config precisa entrar em um release dos transformers, ou toda implantação continuará passando trust_remote_code. Só depois disso o LFM3-VL-2B, o LFM3-Audio-2B e o LFM3-Omni-2B se tornam realistas, e eles ficam atrás de outros PRs que pressupõem que o modelo de texto já foi integrado.

Nada disso deve ser lido como uma crítica ao ritmo. Nove dias entre um lançamento e uma pilha completa e testada de PRs de kernel e modelo é rápido, e o fato de duas equipes independentes terem produzido implementações funcionais em menos de uma semana diz mais sobre o quão perto a LFM3 está da LFM2 do que sobre qualquer atraso. Mas um cartão de modelo é uma alegação de compatibilidade, e a leitura honesta da LFM3-1.7B hoje é "compatível com o vLLM por meio do backend transformers", não "suportado pelo vLLM".

Se você precisar de um modelo pequeno para chamada de ferramentas esta semana

O LFM3-1.7B é algo atraente de se desejar. Os números relatados pelo fornecedor são fortes exatamente onde modelos pequenos costumam falhar — 71,39 no BFCL V4, 80,36 no ToolSandbox, 96,66 no IFEval, 43,40 no SWE-bench Verified —, contra uma média geral de 49,37 que a Liquid coloca à frente do seu próprio LFM2.5-2.6B, com 31,55. Essas são avaliações do próprio fornecedor, executadas pela empresa que construiu o modelo, sem reprodução independente e sem nenhuma entrada no Artificial Analysis que conseguimos encontrar até hoje; trate a ordenação como uma hipótese e os números individuais como alegações. A ressalva que acompanha vem da mesma fonte: o card do modelo desaconselha programação agêntica e raciocínio complexo em várias etapas, e os benchmarks de conhecimento corroboram esse conselho — 63,37 no GPQA Diamond e 65,56 no RULER em 128K não são os números de um generalista.

Então, a decisão não é realmente sobre o modelo. É sobre se você pode se dar ao luxo de construir sobre um caminho de serving que atualmente é um pull request aberto. Se você consegue executar SGLang ou llama.cpp, pode usar o LFM3-1.7B hoje e a questão do vLLM é acadêmica. Se sua stack é vLLM por política, você está escolhendo entre a falta de paged attention no backend transformers e esperar.

Há uma terceira opção que vale a pena nomear para as cargas de trabalho que não podem esperar: encaminhar outra coisa. O OrcaRouter não oferece o LFM3-1.7B — uma verificação do nosso catálogo hoje retorna mais de 200 IDs de modelos e nenhum deles é da Liquid — portanto, este não é um argumento de venda para chamá-lo por meio de nós. É o ponto mais simples de que um PR de kernel não mesclado é um péssimo ponto único de falha para um caminho de produção. Colocar uma API única e failover automático na frente de um modelo hospedado custa apenas uma alteração de configuração e permite que você troque para o LFM3-1.7B no dia em que o suporte nativo dele for mesclado, em vez do dia em que você terminar de apostar nele. Se você estiver modificando o modelo em vez de apenas chamá-lo, nosso próprio LFM3-1.7B-abliterated é uma ablação de direção de recusa do mesmo checkpoint e herda precisamente esta situação de serving.

A versão resumida

O LFM3-1.7B foi lançado, é pequeno e adequado às tarefas de chamada de ferramentas em turno único para as quais foi treinado. O suporte ao vLLM está sendo escrito agora, por duas equipes, sobre uma extensão de kernel que ainda não foi executada em CUDA pela pessoa que a escreveu. Acompanhe o #64647 primeiro — quando a convolução de largura 7 for mesclada, o restante da pilha avança rapidamente, e “funciona com vLLM” na ficha do modelo deixa de ser uma afirmação sobre código remoto e passa a ser uma afirmação sobre paged attention e batching. Até lá, qualquer pessoa que cite “suporte ao vLLM desde o primeiro dia” para este modelo está citando algo que o repositório ainda não contém.