LFM2.5-24B-A2B-DSpark já está disponível no Hugging Face — a Liquid AI simplesmente ainda não o anunciou

A ficha do modelo do maior modelo da Liquid AI ainda diz que seu drafter de decodificação especulativa está em breve. O drafter não vai sair. LFM2.5-24B-A2B-DSpark tem um repositório público desde 2026-10-19, um checkpoint BF16 de 655 MB, uma tabela completa de benchmarks, um sidecar GGUF publicado na noite seguinte e flags de lançamento para SGLang escritas na própria ficha. O que ele não tem é um anúncio. LFM2.5-24B-A2B, o modelo de mistura de especialistas de 24B que ele serve para acelerar, recebeu um post de blog, um lançamento com data, uma lista de preços e um link para playground em 2026-10-13. Seu drafter recebeu um repositório e uma ficha de modelo, e a própria página de documentação da Liquid AI sobre decodificação especulativa ainda lista apenas os alvos 1.2B, 2.6B, 8B e VL-3B como suportados. As falhas de IA e os incidentes de agentes documentados por trás de lançamentos como este estão reunidos em the OrcaRouter AI Incident Archive onde cada entrada traz suas próprias fontes, gravidade, grau de confiança e indicador de contestação.

Essa lacuna é o ponto central aqui, e vale ser preciso sobre o que ela significa e o que não significa. Um repositório cujos pesos são abertos, cujos benchmarks são reproduzíveis a partir de um CSV que está ao lado do modelo e cujo caminho de inferência já foi mesclado no upstream é um lançamento de verdade, não um vazamento. Mas nada a respeito dele foi confirmado pelo fornecedor por escrito, nenhum terceiro o mediu, e os números na ficha são os números da mesma equipe, medidos no mesmo hardware que ela escolheu. Este texto separa as duas coisas: o que o repositório estabelece e o que continua sendo uma alegação.

O que está realmente no repositório

O checkpoint é pequeno o suficiente para que a própria listagem de arquivos seja informativa. O conjunto inteiro é um único model.safetensors com 655.421.522 bytes — 327,7M parâmetros em BF16 — além de um arquivo de configuração, uma licença e um diretório de benchmarks. Nada mais. Não há tokenizer, nem matriz de embeddings, nem LM head, porque a arquitetura reutiliza todos os três do modelo-alvo no momento do carregamento. Esse é o design: o drafter só precisa saber como adivinhar o próximo bloco de tokens no vocabulário do modelo-alvo, não como representar o mundo.

A configuração confirma a estrutura descrita no artigo de agosto sobre o DSpark. Cinco camadas de atenção completa com tamanho oculto de 2.048 e tamanho intermediário de 6.144 com SiLU/SwiGLU; atenção com consultas agrupadas, com 32 cabeças e 8 cabeças KV na dimensão de cabeça 64; uma cabeça Markov de posto 256 e uma cabeça de confiança separada; tamanho de bloco 9; vocabulário de 128.000; e um embedding de posição máximo de 131.072, que corresponde exatamente à janela de contexto do alvo. O único campo que é específico deste drafter é target_layer_ids: [2, 10, 18, 26, 34] em comparação com num_target_layers: 40 — as cinco camadas do modelo de 24B cujos estados ocultos o drafter lê como contexto. Esses índices são o motivo pelo qual um drafter treinado para um modelo LFM2.5 não pode simplesmente ser apontado para outro.

A licença é lfm1.0, a mesma licença personalizada do restante da família, o que vale a pena observar para quem pretende redistribuir um artefato empacotado de target-plus-drafter em vez de usá-lo internamente.

A tabela de benchmark, lida como uma tabela de fornecedores

A placa divulga a taxa de transferência de oito conjuntos de dados com concorrência 1, 32 e 256, em uma única NVIDIA B300 com o alvo FP8, um cache KV BF16 e temperatura 0. Todos os números abaixo são da própria Liquid AI e não foram reproduzidos fora da empresa; as linhas brutas estão no repositório benchmarks/b300-fp8.csv se você quiser conferir a aritmética por conta própria.

• Média aritmética sobre os oito conjuntos de dados — 2,38× na concorrência 1, 2,69× na concorrência 32, 1,71× na concorrência 256.

• Melhor célula individual — MBPP com concorrência 32, 3,28×, com MATH-500 logo atrás em 3,04×.

• Pior célula individual — LiveCodeBench com concorrência 256, 1,34×, e AIME com 256, 1,36×.

• Tokens aceitos por passo — 5,16 em média, contra um teto de 10 definido pelo tamanho do bloco mais o token de bônus do alvo.

• Maior aceitação — MBPP com 6,70 tokens por passo; menor — LiveCodeBench com 4,02.

Duas coisas sobre essa tabela são mais interessantes do que a manchete. A primeira é que o speedup médio é maior com concorrência 32 do que com concorrência 1 — 2,69× contra 2,38× —, o que é o oposto da história usual de decodificação especulativa, em que o batching consome o benefício. A segunda é que isso colapsa em 256. Com 256 solicitações concorrentes, apenas o modelo alvo já gera cerca de 15.000 tokens por segundo nessa GPU para o MATH-500, e a contribuição do modelo de rascunho cai para 1,79×. Uma equipe de serving que lesse apenas "2,4×" dimensionaria um cluster de forma errada; o número que importa para um endpoint em lote é o 1,71×, e mesmo esse é um número de B300 com um perfil de concorrência que a maioria das implantações não vai corresponder.

A sentença que mudou desde agosto

Quando a Liquid AI lançou os DSpark drafters para os alvos de 1,2B, 2,6B e 8B-A1B em 20/08/2026, seu post no blog fez uma afirmação contundente: como o alvo verifica cada token proposto e substitui as rejeições pela própria escolha, "a sequência emitida é, portanto, idêntica à do greedy de linha de base por construção". A ficha do modelo do drafter de 8B repete o espírito disso, prometendo "exatamente as mesmas saídas".

A ficha do modelo de rascunho de 24B não diz isso. Ela afirma que o modelo alvo verifica cada token proposto e, em seguida: "Diferenças de ponto flutuante entre a verificação em lote e a decodificação comum podem produzir textos diferentes, inclusive sob amostragem gananciosa." Acrescenta que as medições avaliam o desempenho, não a acurácia na tarefa.

Esta é uma frase mais cuidadosa, e é a correta. A verificação em lote não executa as mesmas operações de ponto flutuante na mesma ordem que a decodificação sequencial, portanto a identidade bit a bit é uma suposição que vale em aritmética exata e nem sempre em hardware real. O fato de a placa mais nova dizer isso enquanto a mais antiga não dizia é ou uma correção de documentação ou uma descoberta durante o treinamento deste drafter — o repositório não informa qual dos dois, e a Liquid não publicou uma explicação. Na prática, isso significa algo restrito, mas real: se sua suíte de regressão compara a saída do modelo byte a byte, adicionar este drafter pode fazê-la falhar, e isso é uma propriedade da aritmética, não um bug no draft.

Por que o redator chegou seis dias depois do próprio modelo

Vale a pena apresentar a cronologia, porque ela explica o silêncio melhor do que qualquer especulação sobre estratégia.

• 2026-08-20 — A Liquid publica a família DSpark: modelos de rascunho (drafters) para LFM2.5-1.2B-Instruct, LFM2.5-2.6B e LFM2.5-8B-A1B. Ainda não existe um alvo de 24B.

• 2026-08-31 — O SGLang faz merge do PR #31041, adicionando suporte à decodificação especulativa do LFM2 e do LFM2-MoE DSpark. O caminho MoE de que o 24B precisa chega aqui, um mês e meio antes do modelo que ele vai atender.

• 2026-10-13 — O LFM2.5-24B-A2B é lançado com um post de blog e um preço. No mesmo dia, o SGLang faz o merge do PR #43939, que permite ao servidor reutilizar diretamente a configuração do LFM2-MoE do Hugging Face.

• 2026-10-19 — o repositório LFM2.5-24B-A2B-DSpark aparece, com pesos e benchmarks.

• 2026-10-20 — o sidecar GGUF chega: um único arquivo F16 de 664 MB para o llama.cpp.

• 2026-10-21 — o cartão do modelo de destino ganha uma linha de drafter. Ainda exibe Em breve.

Leia essa sequência e a explicação mais provável é a mais sem graça. A infraestrutura foi lançada antes do artefato; o artefato foi lançado quando o treinamento terminou; o anúncio é uma tarefa de marketing que ainda não aconteceu. Nada no repositório sugere um lançamento deliberadamente silencioso — o card está completo, os benchmarks estão documentados até o protocolo, e as invocações de SGLang e llama.cpp estão escritas por extenso. Silencioso, aqui, significa não anunciado, não escondido.

O que ainda não é possível saber

O limite honesto deste texto é uma lista curta, e cada item é uma lacuna real, não uma formalidade.

Nenhuma medição independente. Não há entrada no Artificial Analysis, nenhuma execução de aceitação por terceiros, nenhuma reprodução da tabela de throughput. Em 2026-10-21, o repositório mostrava sete downloads e uma curtida. Todo ganho de velocidade neste artigo é do fornecedor, na GPU escolhida pelo fornecedor, com a precisão-alvo escolhida pelo fornecedor.

Sem anúncio, portanto sem enquadramento. Não sabemos se a Liquid pretende que isto seja uma recomendação de produção para o 24B ou um artefato de pesquisa. O tom do cartão — indicadores completos de lançamento, uma tabela da família, um link de contato — sugere o primeiro, mas isso é inferência.

Não há preço, porque não pode haver. Um drafter não é um modelo servido. Ele não tem tarifa por milhão de tokens e nunca aparecerá em um catálogo de modelos como um endpoint chamável. Seu custo é os 655 MB de VRAM ou memória unificada que ele ocupa ao lado do alvo, mais o custo computacional extra de verificar um bloco em vez de um token.

Sem números de Apple silicon. Esta é a maior lacuna, e a próxima seção explica por que ela importa mais do que as outras.

O número do Mac ausente é a omissão interessante.

O modelo de 24B é vendido como um modelo no dispositivo. O post de lançamento da Liquid abre com 184 tokens por segundo em um Apple M5 Max e afirma que ele foi feito para agentes rápidos e privados no dispositivo. O card do drafter, por outro lado, informa apenas números do B300. Para o drafter de 8B em agosto, a Liquid publicou resultados tanto para H100 quanto para M4 Max e foi transparente sobre a diferença entre eles: um ganho de velocidade médio de 2,54× em um H100 se tornava 1,18× em um MacBook. O motivo declarado era mecânico — verificar k tokens ativa mais especialistas do que uma única etapa de decodificação, então um alvo MoE paga mais tráfego de pesos por token verificado, e o backend Metal do llama.cpp piorava isso.

O LFM2.5-24B-A2B também é uma mistura de especialistas: 64 especialistas por bloco com roteamento top-4. O mesmo mecanismo se aplica, e o 24B é um modelo maior, com um conjunto de especialistas maior para percorrer. Isso não prova que o ganho de velocidade no dispositivo seja pequeno — o modelo de rascunho foi treinado especificamente para este alvo, e a aceitação é muito melhor do que a do 8B era no início —, mas significa que o único número de que um usuário de laptop precisa é o único número que a ficha não contém. Trate qualquer suposição de que a proporção do B300 se transfere para um Mac como não verificada.

Executando isso, e a única flag que vai te pegar

Na GPU, a receita publicada é o SGLang com o alvo FP8 e o drafter acoplado, tamanho de bloco 9 e dez tokens de draft. O SGLang instalado precisa ser recente o suficiente para incluir o caminho DSpark do LFM2-MoE da PR #31041 e a reutilização de configuração da PR #43939; em uma compilação mais antiga, o servidor não reconhecerá a arquitetura do drafter de forma alguma. Observe que os números de benchmark pressupõem o alvo FP8 — o alvo BF16 se comportará de forma diferente, e não necessariamente melhor, porque o drafter foi treinado com base em uma distribuição específica de logits do alvo.

Em CPU e Apple silicon, o caminho é o llama.cpp com o sidecar F16 GGUF. O sidecar lê seu tamanho de bloco a partir dos próprios metadados e limita --spec-draft-n-max a esse valor, então definir o comprimento do rascunho como 12 não resulta em 12. Os tempos por resposta expõem draft_n e draft_n_accepted, que é o campo a monitorar na sua própria carga de trabalho: se a aceitação no seu tráfego ficar muito abaixo da média de 5,16 do cartão, o drafter está custando a você um forward pass e rendendo pouco, e a atitude honesta é desacoplá-lo.

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

Para a maioria das equipes, a consequência prática é pequena, porque o modelo de rascunho muda a velocidade, não a capacidade. O LFM2.5-24B-A2B é o que responde aos prompts; o modelo de rascunho só muda quantas dessas respostas você recebe por segundo. Se o 24B não estava na sua lista de finalistas na semana passada, uma versão mais rápida dele não vai colocá-lo lá.

Se estava na sua lista de finalistas, o modelo de rascunho melhora o argumento a favor da auto-hospedagem e não acrescenta nada ao caso de uso via API. Vale a pena declarar essa distinção com clareza: um checkpoint de decodificação especulativa é invisível para qualquer pessoa que chame um endpoint hospedado, porque a pilha de serviço decide se o anexa. O que dá para comparar em igualdade de condições é o próprio modelo com as alternativas para as quais você rotearia de outra forma — e, se estiver avaliando-o em comparação com algo como Qwen3.6-35B-A3B, o modelo em relação ao qual a Liquid faz benchmark em cinco de oito tarefas agênticas, o OrcaRouter disponibiliza esse alvo de comparação por trás de uma única chave com 0% de markup sobre o preço de tabela do provedor, com failover automático entre provedores. Não disponibilizamos a família LFM2.5 hoje, então o próprio 24B precisa vir da API do próprio fornecedor ou das suas próprias GPUs; o que oferecemos é o outro lado da comparação sem um segundo contrato.

O que mudaria esta imagem?

Três coisas, em ordem do quanto elas mudariam a narrativa. Um post no blog da Liquid definiria o enquadramento — se este é um pareamento recomendado para produção ou um lançamento de pesquisa. Uma medição publicada no Mac resolveria a afirmação que importa para o público para o qual o 24B foi criado. E uma execução de aceitação independente com tráfego real, em vez de oito conjuntos de dados de benchmark com temperatura 0, diria se 5.16 tokens por passo sobrevivem ao contato com os prompts longos, bagunçados e de chamada de ferramentas para os quais este modelo é realmente vendido.

Até lá, o repositório é público, os pesos podem ser baixados, o CSV está bem ali, e o model card do próprio fornecedor é o último lugar onde você deveria procurar notícias a respeito. É um estado incomum para um lançamento estar — mas é real, e o artefato não se torna menos real só porque ninguém escreveu o post do blog.