LFM2.5-2.6B-DSpark: O Draftador de 328M que Faz o Agente no Dispositivo da Liquid Rodar 2.3× Mais Rápido

Ninguém fora da Liquid AI executou o LFM2.5-2.6B-DSpark em seu próprio hardware e publicou um número até agora. Esse é o ponto de partida honesto para este modelo, porque tudo nele é uma afirmação de desempenho: não é um 2.6B melhor, é um modelo de rascunho de 328M de parâmetros que fica à frente do modelo agêntico de 2.6B LFM2.5-2.6B e propõe tokens para que ele verifique, então o agente roda cerca de duas vezes mais rápido sem alterar sua saída.

Lançado em 20 de agosto de 2026 com um artigo técnico no Hugging Face e uma publicação complementar no blog da própria Liquid, o LFM2.5-2.6B-DSpark é o carro-chefe de uma pequena família de checkpoints drafter de decodificação especulativa que a Liquid publicou naquele dia. Tudo abaixo na coluna de velocidade foi medido pelo fornecedor e ainda não foi confirmado de forma independente; tudo no repositório, nos formatos e no suporte de frameworks está simplesmente lá para ser verificado.

O que é o DSpark, em uma respiração.

Decodificação especulativa é o truque de executar um modelo de rascunho barato à frente do modelo real: o rascunhador adivinha o próximo punhado de tokens, o alvo verifica todo o lote em uma única passagem direta e mantém os tokens com os quais concorda. Quando os palpites estão certos, você avança vários tokens pelo preço de um, então o throughput aumenta sem tocar nos pesos do alvo. DSpark — a técnica, originalmente proposta por pesquisadores da DeepSeek em julho de 2026 e já implantada no DeepSeek-V4 — é uma versão desse truque ajustada para pequenos modelos em dispositivos. A Liquid chama isso de decodificação especulativa com agendamento por confiança, e tem três partes móveis: uma espinha dorsal paralela que produz estados ocultos para todos os tokens de rascunho em uma passada, uma cabeça sequencial leve que modela a dependência entre tokens vizinhos para que a taxa de aceitação não desabe no final do bloco, e um verificador que poda sufixos de baixa confiança quando verificá-los custaria mais do que economiza.

Essa última parte é o que faz o DSpark parecer diferente de um drafter comum: ele nem sempre envia um bloco completo para verificação. Quando a confiança do próprio rascunho indica que um sufixo provavelmente não será aceito, ele encurta o bloco e economiza a computação desperdiçada. O bloco de rascunho tem nove tokens, então o alvo verifica até dez de cada vez.

O redator, em números

O checkpoint LFM2.5-2.6B-DSpark é um modelo de rascunho somente de atenção, com 0,3B de parâmetros: cinco camadas completas de atenção (tamanho oculto 2.048, atenção de consulta agrupada com 32 cabeças e 8 cabeças de chave-valor), um vocabulário de 128 mil tokens, uma cabeça de Markov com posto 256 e uma cabeça de confiança. A Liquid o treinou por 15 épocas em uma mistura de dados de instrução, conversa, código e chamada de funções — em hardware AMD — e escolheu a época pela maior taxa de aceitação, em vez da menor perda.

{{1}}Essa taxa de aceitação é o número que determina quanto vale o rascunhador.{{/1}} {{2}}Em cinco benchmarks, com batch size 1 e temperatura 0,{{/2}} {{3}}o LFM2.5-2.6B-DSpark obteve uma média de 4,83 tokens aceitos por etapa de decodificação em uma H100 e 4,42 em uma M4 Max{{/3}} {{4}}— aproximadamente metade do bloco aceito,{{/4}} {{5}}que é de onde vêm os ganhos de velocidade de duas vezes.{{/5}}

Os speedups, rotulados

Todos os números a seguir vêm de medições próprias da Liquid AI — SGLang em uma única H100 80GB em BF16, e llama.cpp com o backend Metal em um MacBook Pro M4 Max em FP16 GGUF, tamanho de lote 1, temperatura 0 — e nenhum foi reproduzido por uma parte independente até o momento em que este texto foi escrito:

Média H100 — 2,67×, de 323 a 864 tokens/s. Por benchmark: MATH500 3,06×, HumanEval 2,56×, MBPP 2,64×, GSM8K 2,22×, MT-Bench 2,87×.

• M4 Max média — 2.27×, de 61 a 139 tokens/s. Por benchmark: MATH500 2.25×, HumanEval 2.63×, MBPP 2.11×, GSM8K 2.36×, MT-Bench 1.99×.

• Chamada de ferramentas — em cenários de chamada de função com múltiplas ferramentas, a latência média caiu 57%.

• Contexto familiar — o maior drafter da família, LFM2.5-8B-A1B-DSpark, atingiu até 3,18× em H100, e o drafter de 1,2B atingiu até 2,87× em M4 Max; os números de 2,6B acima estão no meio do grupo.

Duas coisas sobre esses números importam além das médias. Primeiro, eles são medidos a temperatura 0 e tamanho de lote 1 — a configuração que favorece a especulação e a configuração em que o trabalho de agente interativo no dispositivo ocorre majoritariamente. A garantia de identidade também se mantém aí: a decodificação especulativa verifica cada token proposto; portanto, sob decodificação gulosa, o texto emitido é exatamente o que o alvo teria produzido sozinho. Segundo, a lacuna diminui à medida que a concorrência aumenta: em uma única H100, a Liquid relata que a vantagem do DSpark converge em torno do tamanho de lote 128; assim, o drafter é uma vantagem de latência para cargas de trabalho interativas e com uso intensivo de ferramentas, não uma bala de prata de throughput bruto para um servidor no limite.

O que está confirmado e o que não está

Confirmado, no sentido de que o repositório é público e verificável: o drafter é distribuído como Safetensors (BF16) e GGUF; ele pareia com o LFM2.5-2.6B pós-treinado, não com o base; o suporte no dia do lançamento chegou upstream no llama.cpp (com kernels experimentais para Metal) e no SGLang; está licenciado sob a LFM Open License v1.0 da Liquid; e — importante para quem planeja usá-lo — a ficha do modelo afirma que nenhum provedor de inferência o serve, então este é um componente para você mesmo executar.

Ainda não confirmado: que os ganhos de velocidade se reproduzem em outros hardwares e configurações (ninguém fora da Liquid publicou uma medição), como o rascunhador se comporta sob amostragem em vez de decodificação gulosa, e se o número de latência de chamada de ferramenta de 57% se mantém em arcabouços de agentes reais além do arcabouço de benchmark usado pela Liquid. Nenhuma dessas é uma acusação — o lançamento tem apenas um dia — mas elas são a diferença entre um número promissor e um verificado.

Executando.

Em SGLang, você usa um build com suporte a DSpark, inicia o servidor apontando para o modelo-alvo e nomeia o drafter: o algoritmo especulativo é DSPARK, o caminho do modelo de rascunho aponta para LiquidAI/LFM2.5-2.6B-DSpark, e o tamanho do bloco é lido do config.json do rascunho. Em llama.cpp, você carrega o GGUF alvo com o GGUF de rascunho como modelo de rascunho e define o tipo de spec como draft-dspark, com o tamanho do bloco lido dos metadados sidecar. Ambas as integrações foram incorporadas ao upstream, então não são necessários forks — basta um build novo o suficiente para contê-las.

Quando vale a pena adicionar

O LFM2.5-2.6B-DSpark justifica seus aproximadamente 0,3 GB de memória extra quando você está de fato implantando o agente 2.6B onde a Liquid o projetou para funcionar — em um telefone, um laptop ou um dispositivo de borda — para cargas de trabalho interativas ou de chamada de ferramentas que são limitadas por latência e rodam em modo greedy. Esse é precisamente o perfil em que o valor de 2,27× no dispositivo e a redução de 57% na latência de chamadas de ferramentas fazem efeito. É menos interessante se você estiver servindo com lotes grandes em um servidor (a aceleração converge para 1×), ou se sua carga de trabalho roda com temperatura acima de zero, onde os números reportados deixam de se aplicar. E se você está na variante 8B-A1B da família, observe o caso extremo: seu ganho de velocidade no dispositivo é de apenas cerca de 1,18× hoje, porque a verificação de tokens de rascunho ativa mais especialistas no backend Metal do llama.cpp — a Liquid indica isso como um problema conhecido.

Nada sobre o DSpark muda onde o agente de 2.6B é executado — é uma história de auto-hospedagem por design, e ele ficará ao lado dos modelos hospedados que você já utiliza. Essa combinação de um modelo de rascunho local e uma dúzia de endpoints de API é exatamente o tipo de encanamento que uma camada de roteamento existe para consolidar: uma única chave de API em mais de 200 modelos, failover automático quando um provedor degrada e preços de tabela do provedor repassados com margem de 0%, para que a comparação de custo entre local e hospedado para um agente da classe de 2.6B permaneça legível em vez de viver em uma planilha.

A maneira correta de ler o LFM2.5-2.6B-DSpark hoje é como uma promissora alegação de velocidade, medida pelo fornecedor e ainda não verificada de forma independente, associada a um checkpoint real, baixável e executável. Se você implantar o agente de 2.6B no dispositivo, o modelo de rascunho é barato para experimentar e fácil de remover — adicione as duas flags especulativas ao comando do SGLang, mantenha a decodificação gulosa e meça usando sua própria carga de trabalho antes de confiar no 2.3×. O repositório está lá; a verificação independente é o item em aberto.