LFM2.5-8B-A1B-DSpark vs LFM2.5-2.6B-Base: A Parte da Velocidade vs a Matéria-Prima

Classifique a família LFM2.5 pelo que cada checkpoint consegue fazer por conta própria, e o LFM2.5-8B-A1B-DSpark e o LFM2.5-2.6B-Base ficam em extremos opostos da linha — e nenhum dos extremos consegue responder a uma pergunta. O primeiro é um modelo de rascunho de 327,7 milhões de parâmetros que existe puramente para fazer o modelo mixture-of-experts de borda da Liquid AI gerar tokens mais rápido. O segundo é um checkpoint bruto pré-treinado de 2,69 bilhões de parâmetros que existe puramente para ser ajustado para se tornar outra coisa. Ambos foram lançados em agosto de 2026 sob a LFM Open License v1.0 da Liquid, ambos estão a um download de distância no Hugging Face, e ambos são extremamente fáceis de baixar por engano — porque seus nomes fazem com que pareçam duas versões da mesma coisa.

{{1}}Os nomes são a armadilha.{{/1}} "DSpark" soa como o novo carro-chefe espirituoso da família, e "Base" soa como o padrão simples que você pode realmente executar. Nenhum dos dois é verdade. {{2}}O checkpoint DSpark não consegue responder nada sozinho — ele apenas propõe tokens para o LFM2.5-8B-A1B verificar.{{/2}} {{3}}O Base também não consegue responder nada, mas pela razão oposta — é uma fundação não ajustada que prevê texto, mas nunca foi pós-treinada em um modelo de chat ou agente.{{/3}} {{4}}Isto não é uma rivalidade; é um pipeline.{{/4}} {{5}}Um checkpoint fica no fim da pilha de servimento, o outro no início de uma execução de treinamento.{{/5}}

Dois checkpoints que compartilham um nome, não uma função

O LFM2.5-8B-A1B-DSpark (lançado em 20 de agosto de 2026) é um modelo de rascunho para decodificação especulativa: uma rede de cinco camadas somente de atenção, um bloco de nove tokens propostos por etapa e uma cabeça de Markov sobre o vocabulário de 128.000 tokens do alvo. Você o carrega junto com o LFM2.5-8B-A1B — um MoE de 8,3B no total, ~1,5B ativos, lançado em 28 de maio — o rascunho adivinha os próximos tokens, e o alvo verifica o bloco inteiro em uma única passagem para frente, mantendo o que for aceito. Como o alvo verifica cada token, a saída sob decodificação gulosa é idêntica à execução do LFM2.5-8B-A1B sozinho: "sem perdas por construção", na expressão da Liquid. O rascunho é um componente de velocidade, não um cérebro. Ele foi lançado junto com rascunhos irmãos para LFM2.5-1.2B-Instruct e LFM2.5-2.6B, cada um em Safetensors e GGUF, com suporte desde o primeiro dia em SGLang e llama.cpp.

LFM2.5-2.6B-Base (lançado em 4 de agosto de 2026) é a outra extremidade do pipeline: um modelo fundacional de 2,69B parâmetros em uma pilha híbrida de 30 camadas — 22 blocos de convolução curta de dupla porta mais 8 blocos de atenção por consulta agrupada — pré-treinado em cerca de 34 trilhões de tokens, com uma fase intermediária de treinamento que estende o contexto para 128K. Não tem template de chat, não tem ajuste de instruções e não tem benchmarks publicados, e a própria ficha do modelo da Liquid recomenda seu uso apenas para ajuste fino extensivo. Seu único propósito é ser a matéria-prima que um pipeline de pós-treinamento de quatro estágios — duas rodadas de SFT, especialização do professor, destilação on-policy e, em seguida, aprendizado por reforço agêntico — transforma no agente de chamada de ferramentas LFM2.5-2.6B. Mesma família, mesma licença, mesma página de download. Trabalhos completamente diferentes.

Lado a lado: sete dimensões, dois trabalhos.

Como os dois checkpoints desempenham funções diferentes, a comparação honesta mantém os papéis de ambos os lados claros:

• O que é — LFM2.5-8B-A1B-DSpark é um modelo de rascunho de decodificação especulativa de 0,3B; LFM2.5-2.6B-Base é um modelo fundacional bruto pré-treinado de 2,69B.

• Com o que ele roda — o rascunho DSpark combina com o MoE LFM2.5-8B-A1B (8,3B no total, ~1,5B ativos por token); o Base roda sozinho, mas apenas como predição de texto não ajustada.

• Uso autônomo — o DSpark não produz nada por si só; ele apenas acelera um alvo. A base produz texto, mas sem comportamento útil de produto — sem seguir instruções, sem chamada de ferramentas, sem template de chat.

• Qualidade de saída — o DSpark herda a saída gulosa exata do alvo, porque cada token proposto é verificado; a Base não tem nenhum benchmark publicado em nenhuma tarefa, por design.

• Velocidade — DSpark adiciona uma média medida pelo fornecedor de 2,54× em um H100 (até 3,18× em MATH500) e 1,18× em um M4 Max ao seu alvo, não reproduzida; Base não tem nenhuma alegação de velocidade de inferência.

• Pegada de memória — DSpark adiciona cerca de 0.3GB de pesos de rascunho além do alvo; Base é o modelo completo de 2.69B, executável em menos de 2.5GB, a menor fundação séria da família.

• Formatos e disponibilidade — DSpark é distribuído em Safetensors e GGUF com suporte a SGLang e llama.cpp desde o primeiro dia; Base é distribuído em Safetensors, além de GGUF, ONNX e MLX, e roda em Transformers, vLLM, SGLang, llama.cpp e MLX. Nenhum é servido por provedores de inferência atualmente — ambos são checkpoints auto-hospedados.

Os únicos números neste confronto vieram de um laboratório.

Tudo o que é quantitativo aqui é uma medição de um único fornecedor, feita no dia em que o rascunho foi divulgado e ainda não reproduzida de forma independente — encare como promissor, não verificado. A Liquid mediu o LFM2.5-8B-A1B-DSpark com tamanho de lote 1, temperatura 0, em uma única H100 de 80GB em BF16 com SGLang e em um MacBook Pro M4 Max em FP16 GGUF com os kernels experimentais Metal do llama.cpp. Na H100, o par obteve média de 2,54× (418 → 1.074 tokens por segundo), com melhor resultado individual de 3,18× no MATH500 (428 → 1.362 tok/s) e aceitação média de cerca de 7 de cada 10 tokens propostos. No M4 Max, o mesmo par teve média de apenas 1,18× (90 → 106 tok/s) — o caso extremo no dispositivo que a própria Liquid sinalizou, porque verificar um bloco ativa mais especialistas no backend MoE Metal atual e movimenta mais tráfego de pesos pelo barramento de memória.

O lado Base deste confronto não tem números nenhum, e essa ausência é em si a especificação. O LFM2.5-2.6B-Base foi pré-treinado, não pós-treinado; nunca foi avaliado para chat, uso de ferramentas ou comportamento de agente, porque ninguém pretendia que fosse usado dessa forma. Seus números significativos são arquiteturais: 2,69 bilhões de parâmetros, contexto de 128K, um tokenizador de 16 idiomas, menos de 2,5GB para executar. Você não avalia uma fundação com benchmarks; você avalia aquilo em que faz fine-tuning dela.

Há uma ironia familiar que vale a pena mencionar antes de você decidir qualquer coisa. O rascunho sobre o qual este artigo trata — o da 8B-A1B — é precisamente o que menos ganha em um laptop (1,18×), enquanto o rascunho irmão da família 2.6B, que acelera o irmão pós-treinado desta mesma Base, atinge em média 2,27× em um M4 Max, com uma redução de 57% na latência de chamada de funções com múltiplas ferramentas. Se o dispositivo em questão for um celular ou um laptop, em vez de uma máquina com GPU, é no caminho da 2.6B que a história da velocidade se encontra.

Então qual você baixa?

Você nunca precisa escolher diretamente entre esses dois, porque eles não são alternativas — mas você precisa saber em qual papel você está:

Se você servir o LFM2.5-8B-A1B em GPUs próprias e quiser mais tokens por segundo do mesmo silício, o LFM2.5-8B-A1B-DSpark é um complemento reversível: compile o SGLang ou o llama.cpp com as integrações DSpark de 20 de agosto, nomeie o rascunho no comando de lançamento, mantenha a decodificação gananciosa, e o tamanho do bloco é lido automaticamente da configuração do rascunho. A vantagem é aproximadamente 2,5× de throughput sem nenhuma mudança nas saídas; a desvantagem é 0,3GB de pesos extras e uma compilação nova o suficiente para conter os PRs. Remova os dois flags especulativos e você volta ao alvo simples.

Se você quiser construir seu próprio especialista — um modelo de domínio, um assistente de linguagem personalizada, um fine-tune em dados proprietários — o LFM2.5-2.6B-Base é um dos pontos de partida sérios mais baratos no ecossistema de pesos abertos: 2,6B, menos de 2,5 GB, contexto de 128K, um tokenizador multilíngue. O checkpoint DSpark não pode ajudar você com isso em nada, porque não é um modelo base.

Se você realmente quer o agente on-device da Liquid — chamada de ferramentas, tarefas de múltiplas etapas — então você não quer nenhum desses dois. Você quer o LFM2.5-2.6B pós-treinado, e pode decidir depois se quer acoplar o próprio draft. O Base é matéria-prima para quem quer treinar; o draft 8B-A1B é um componente de aceleração para quem já implanta o MoE. O erro é baixar o Base porque você queria um agente mais rápido, ou o drafter porque você queria uma base para treinar.

Onde os dois se conectam — e onde um roteador se encaixa

Ambos os checkpoints são casos de auto-hospedagem. O draft é um acessório da camada de serviço que existe apenas dentro da sua própria pilha SGLang ou llama.cpp; a Base é um artefato de treinamento. Nenhum deles aparece em qualquer catálogo hospedado, e nenhum deles tem preço de tabela por token. O que isso significa na prática é que qualquer um dos caminhos acaba ficando ao lado dos modelos hospedados que você já utiliza — e essa mistura é exatamente o encanamento que uma camada de roteamento existe para consolidar.

No lado do serving, a economia do draft é simples e real: {{1}}2,5× mais tokens por segundo da mesma GPU significa 2,5× menos tempo e aproximadamente 2,5× menos GPUs para a mesma carga de trabalho, sem alteração na qualidade{{/1}}. Mas essa alavanca só existe se você controla a inferência. No momento em que você chama o 8B-A1B por uma API, o provedor fica com a aceleração — {{2}}que é onde a comparação pelo lado da API se torna a que importa: o que um provedor cobra e se um corte de preço chega até você no mesmo dia em que é anunciado{{/2}}. Esse é o objetivo de um roteador pass-through: {{3}}uma única API com mais de 200 modelos, preços de tabela do provedor repassados com margem de 0%, para que um corte de preço do fornecedor entre em vigor imediatamente do seu lado, e failover automático para que um pico de latência de um único provedor não se torne a sua latência{{/3}}. Você também pode servir sua própria stack LFM self-hosted através do mesmo endpoint, {{4}}que é como você testa um modelo draft totalmente novo contra tráfego real sem comprometer seu caminho de produção com ele{{/4}}.

LFM2.5-8B-A1B-DSpark e LFM2.5-2.6B-Base compartilham um nome de família e trabalhos opostos: um é uma peça de velocidade acoplada ao MoE de borda, o outro é o cérebro não ajustado a partir do qual o agente 2.6B cresce. Nenhum funciona sozinho. Escolha o rascunhador para acelerar um MoE que você já serve em GPUs, escolha a Base para ajustar uma fundação 2.6B em algo seu, e ignore ambos se o que você queria era um agente funcional — porque a única coisa que os dois checkpoints têm em comum é que nenhum deles, por si só, faz algo que você possa usar.

Perguntas Frequentes

Posso executar o LFM2.5-8B-A1B-DSpark sozinho?

Não. É um modelo de rascunho sem saída autônoma — ele propõe tokens candidatos que o alvo LFM2.5-8B-A1B então verifica, portanto ele só existe dentro de uma pilha de serviço de decodificação especulativa construída sobre as integrações de 20 de agosto do SGLang ou llama.cpp. Baixá-lo isoladamente não lhe dá nada que você possa consultar.

O LFM2.5-2.6B-Base é o checkpoint que roda no dispositivo como um agente?

Não como está. A Base é a fundação pré-treinada bruta, sem ajuste de instruções e sem template de chat. O modelo que roda como agente on-device da Liquid é o LFM2.5-2.6B pós-treinado, que é produzido a partir da Base pelo pipeline de pós-treinamento em quatro etapas — e, se você quiser mais rapidez, combinado com o draft LFM2.5-2.6B-DSpark.